LGTM2 On Friday, July 19, 2024 at 6:56:59 PM UTC+2 Mike Taylor wrote:
> LGTM1 > On 7/17/24 5:24 PM, Alex Turner wrote: > > 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*. > > OK - understood. These server errors won't affect clients sending the new > report version (and I realize I missed the distinction between report and > aggregation service version). > > > 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/8bd0031a-6868-4184-ae35-d3e611293613n%40chromium.org.
