On Mon, Jul 15, 2024 at 11:03 AM Mike Taylor <miketa...@chromium.org> wrote:
> 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? > Yep, exactly. > 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? > The Aggregation Service versioning scheme applies to server-side changes only. That is, a breaking change is one that would require an active migration for a partner when they update their Aggregation Service release. As the processing changes on the server are backwards compatible (more detail below), we haven't updated the major version. When attempting to process the new “1.0” reports, the old Aggregation Service releases (2.3 and before) error out and the new releases (2.4+) succeed. So, we consider that new support to be backwards compatible *server-side*. And when attempting to additionally specify custom filtering_ids *on the server*, Aggregation Service release 2.4 doesn’t let you (always uses the default, discussed below in more detail), while release 2.5 does let you. So, that change should also count as backwards compatible. Separately, there’s a question of whether the *browser-side* API change (to change the report version/format) is backwards compatible. While Aggregation Service release 2.3 is available, it is a breaking change. But, it will be backwards compatible once all current Aggregation Service releases support the report version (before M128 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. > Let me clarify the behavior of Releases 2.4 and 2.5 a bit. On the web API after this change, you can optionally specify a filtering ID for each histogram contribution; if you don’t, the default of 0 is used. On the server API, you can optionally specify which filtering IDs to keep (i.e. all histogram contributions with other filtering IDs are ignored for the aggregation). If you don’t specify any (either because 2.4 doesn’t let you or if you use the default in 2.5), the default of keeping just filtering ID 0 is used. So, any existing flows that don’t care about the new filtering ID feature will behave exactly as before – all contributions are processed as they all have the default filtering ID of 0. Additionally, 2.4 and 2.5 have consistent behavior when no IDs are specified server-side. But, if you want to process histogram contributions with other/non-default filtering IDs, you need to upgrade to 2.5 as those contributions will always be ignored in 2.4. Thanks, Alex > > 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/CAA%2BBiF%3DXOFuj8KCRNxtMk%3DA%3DOFO0u-s5WwreoNL00YCOkJ%2BeyQ%40mail.gmail.com.
