LGTM3 On Fri, Jul 26, 2024 at 2:04 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8bd0031a-6868-4184-ae35-d3e611293613n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw89JSf6HSn85m9Y9-PBYo4_Yrxx_TX6-_OJR6Sib4t2bQ%40mail.gmail.com.
