On 7/12/24 10:44 AM, Alex Turner wrote:
On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor <miketa...@chromium.org>
wrote:
On 7/8/24 4:05 PM, Alex Turner wrote:
Interoperability and Compatibility
The Aggregation Service (used to process the aggregatable
reports) typically allows its releases to be used for up to six
months. To reduce the compatibility impact of this change, we are
waiting until all current Aggregation Service releases support
the new version before rolling to Stable.
Can you say more about this? How many parties are running these
services, and do we have any way of knowing what the uptake of new
versions is, or said differently - can we tell if they're still on
older versions?
Also, what happens if you send the filter ID to an older version?
The Aggregation Service in general has a six-month support schedule
<https://github.com/privacysandbox/aggregation-service/wiki/Aggregation-Service-release-and-end%E2%80%90of%E2%80%90support-plan#release-and-end-of-support-schedules>,
i.e. attempts to use a release more than six months after it was
released will fail. Currently, there are three Aggregation Service
releases that are available for use (2.3, 2.4, 2.5). All previous
releases (2.2 and before) have already reached end-of-support and can
no longer be used.
I see - thanks. Just a few more questions to help me understand:
There's mention of an image hash allowlist - presumably this is how you
enforce versioning on the server side. Is that correct?
Release 2.3 does not support the new report format, but we have
announced it will reach end-of-support on August 2nd, i.e. before M128
reaches Stable. (Note that we have already enabled the feature on
Canary for testing.) Attempting to process reports with the new “1.0”
report version on this release will result in the aggregation job
failing with a descriptive error message. In this case, however, no
budget will be consumed and the aggregation can be re-attempted
(either on a newer release or after excluding the “1.0” reports).
Why doesn't this count as a breaking change, per your wiki page? Or the
idea is you don't need to rev the major version number because it will
be unsupported before this feature is usable in Chrome stable?
Release 2.4 supports the new report format, but it does not allow for
filtering_ids to be specified for the aggregation; the default value
([0]) is always used. On this release, existing flows that do not use
the new feature will be unaffected by the report version change.
This also feels like a breakage change to me - if I'm using a supported
service version, but I can't use the updated report version because I
will get unexpected/inconsistent behavior with 2.5.
Release 2.5 supports the new report format and allows filtering_ids to
be specified for the aggregation. Developers who want to use the new
feature should upgrade to this release.
We don't currently have metrics on usage of each Aggregation Service
release, but plan to add those. Still, we have notified partners of
these considerations through the API mailing lists
<https://groups.google.com/a/chromium.org/g/shared-storage-api-announcements/c/qlL4kpdgvP0>.
We'll also remind partners of the upcoming end-of-support.
Thanks for the public comms - having some form of telemetry for
aggregation service versions in the wild does seem useful.
thanks,
Mike
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/40956f3a-474f-4878-81f2-f353f400f049%40chromium.org.
