Contact emails johni...@chromium.org, csharri...@chromium.org
Explainer https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md#phase-1-lite-flexible-event-level https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md Specification https://wicg.github.io/attribution-reporting-api/ Blink component Internals > AttributionReporting <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting> Summary We plan on landing a number of changes to the Attribution Reporting API focused on: - registration ergonomics allowing better flexibility when controlling whether attribution should occur based on the time between the two events - support for developer controlled configurations that allow for callers to specify the windowing scheme and number of reports to receive for an event, in order to more efficiently extract utility out of the privacy mechanism Spec changes 1. Allow expiry, event_report_window, aggregatable_report_window fields to be integers <https://github.com/WICG/attribution-reporting-api/pull/895> 2. Lookback window in filters <https://github.com/WICG/attribution-reporting-api/pull/914> 3. Developer defined configurations for reporting windows and maximum # of reports <https://github.com/WICG/attribution-reporting-api/pull/856> - Separate verbose debug report for start time <https://github.com/WICG/attribution-reporting-api/pull/916> 1. Reduce min event report window time from 1 day to 1 hour and prohibit negative durations <https://github.com/WICG/attribution-reporting-api/pull/876> Risks Interoperability and Compatibility Changes (1) (3) are all fully backwards compatible. (2) (3) are optional, additive changes to the API surface which allow for additional information to be provided by developers at registration time. (2) is largely backwards compatible except in the case a developer was previously using a key with the name "_lookback_window", where they will now see different behavior when matching. We expect the API breakage to be negligible. (4) has some marginal backwards incompatibility. “prohibit negative durations” will result in any previous registrations now resulting in a failure rather than being clamped to a minimum value. In the event a registration fails, there will be no user-visible / web-visible breakage outside of different reports being emitted than before. That being said, we also expect API breakage here to be negligible. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? All except Android WebView Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes Estimated milestones Chrome 117 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5089526405398528 Links to previous Intent discussions Previous I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY -- 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/3c8f2f73-db97-4c39-9af4-c4c05539504cn%40chromium.org.
