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/4ea815ba-5aad-4bfd-8056-ed30eacdef30%40chromium.org.
