Intent to Ship: Attribution Reporting Feature: Flexible contributions filtering
Akash Nadan
akash...@google.com, lin...@chromium.org, john...@chromium.org
Explainer
Attribution Reporting with event-level reports
Attribution Reporting API with Aggregatable Reports
Aggregation Service for the Attribution Reporting API
Specification
https://wicg.github.io/attribution-reporting-api/
Blink component
Internals > AttributionReporting
TAG review
Still under review under the original I2S for the Attribution Reporting API
TAG review status
Pending
Summary
We are landing the following change to the Attribution Reporting API focused on:
Improving API report batching capabilities
This change is based on ad-tech feedback that we heard regarding the need for additional report batching flexibility so that different report contributions can be batched at different cadences.
Currently aggregatable reports generated by the API can consist of multiple separate contributions which are key:value pairs. API callers can batch together aggregatable reports and then process them in the aggregation service, which consists of decrypting the reports, aggregating the values, and adding noise, before returning a summary report to the API caller. Additionally, all contributions in an aggregatable report must currently be processed by aggregation service at the same time.
With this change, the API will now allow API callers to specify filtering IDs as part of each contribution (i.e. each key:value pair) in the aggregatable report. API callers can then use these filtering IDs, which will also be part of the encrypted payload of the report, to specify which contributions they want to have processed by the aggregation service at a given time.
This will allow API callers to process contributions with different filtering IDs at different cadences. Allowing this flexibility is a utility improvement, because the noise added in the aggregation service per key:value pair bucket may have a lower relative impact on values that are batched on a longer cadence.
Explainer/Spec changes
Risks
Interoperability and Compatibility
This is an optional and fully backwards compatible change. This feature provides a new filtering ID that can be set as part of the aggregatable report contributions and does not break any pre-existing API or web functionality.
Gecko: No signal (Original request: https://github.com/mozilla/standards-positions/issues/791)
WebKit: No signal (Original request: https://github.com/WebKit/standards-positions/issues/180)
Web developers: https://github.com/patcg-individual-drafts/private-aggregation-api/issues/92
*although this is a private aggregation issue link, it also applies to ARA use cases*
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
The attribution reporting feature will be supported on all platforms with the exception of Android WebView
Is this feature fully tested by web-platform-tests?
Yes
Estimated milestones
This feature is anticipated to ship as part of Chrome 128.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5487434799513600
Links to previous Intent discussions
Previous I2S:
Intent to Ship: Attribution Reporting API
Intent to Ship: Attribution Reporting features M117
Intent to Ship: Attribution Reporting features M118
Intent to Ship: Attribution Reporting features M119
Intent to Ship: Attribution Reporting features M120
Intent to Ship: Attribution Reporting features M121
Intent to Ship: Attribution Reporting features M123
Intent to Ship: Attribution Reporting features M124
Intent to Ship: Attribution Reporting features M125
Intent to Ship: Attribution Reporting features M126
Intent to Ship: Attribution Reporting features M127
Thanks,
Akash
Akash Nadan
Hi All,
Just adding some additional detail regarding the interoperability and compatibility of this feature:
Interoperability and Compatibility
This change is optional and will be fully backwards compatible once Aggregation Service release 2.3 reaches end-of-support on August 2nd (before M128 reaches Stable).
Additionally, developers that want to use this new feature will need to upgrade their Aggregation Service release to version 2.5 or later. The Aggregation Service is used to process the aggregatable reports that a developer receives. We have notified partners of these considerations through the API mailing list. A similar feature is being released for the Private Aggregation API, with the same Aggregation Service considerations.
Thanks,
Akash
Chris Harrelson
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ccf4f345-f1e8-4216-bd21-1231214dc0ben%40chromium.org.
Mike Taylor
LGTM2
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_Eb6PwjOArQqsbFDVgs6jgsx6vf9SRw-9v6_6H2bAXkw%40mail.gmail.com.
Yoav Weiss (@Shopify)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db55d5d9-8c21-4df2-b110-1cdf69cafd43%40chromium.org.