Intent to Ship: Attribution Reporting features (lookback windows, flex-lite)

[John Delaney]

Contact emails

john...@chromium.org, cshar...@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

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

2. Lookback window in filters

3. Developer defined configurations for reporting windows and maximum # of reports

• Separate verbose debug report for start time

4. Reduce min event report window time from 1 day to 1 hour and prohibit negative durations

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?

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

[Mike Taylor]

On 8/3/23 4:39 PM, John Delaney wrote:

Contact emails

john...@chromium.org, cshar...@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

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

2. Lookback window in filters

3. Developer defined configurations for reporting windows and maximum # of reports

• Separate verbose debug report for start time

4. Reduce min event report window time from 1 day to 1 hour and prohibit negative durations

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.

Is this based on metrics you have in front of you, or something else? Also, what might breakage look like in this situation?

             (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.

Why would a negative duration be used today? It sounds weird, but I've also seen "max-age=-1" w/ cookies to mean "like, now-now". Are we aware of any usage of negative durations?

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?

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+...@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.

[John Delaney]

> Is this based on metrics you have in front of you, or something else? Also, what might breakage look like in this situation?

We don't have metrics measuring the usage of this key directly, but we have checked with a number of known partners from the origin trial to see if this was being used. Breakage in this situation, similar to below, would not be user-visible or immediately web-visible. Ultimately, this will cause reports to be matched/generated differently than before, so a developer may see a different set of reports for the same set of events, or no reports at all.

> Why would a negative duration be used today? It sounds weird, but I've also seen "max-age=-1" w/ cookies to mean "like, now-now". Are we aware of any usage of negative durations?

Currently, negatives are clamped to the minimum of 1 day, and don't hold any special value. They would only be used if someone had observed they were clamped to the minimum, and decided to rely on that behavior rather than setting the minimum themself (or even 0). Similar to above, we are not aware of any usage but do not have targeted metrics for this.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike Taylor]

Thanks - the risk seems pretty low from a compat POV.

LGTM1

[Yoav Weiss]

LGTM2

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/3c8f2f73-db97-4c39-9af4-c4c05539504cn%40chromium.org.

--

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/5d8d1b39-95e0-4b6a-9745-c368c9d31816%40chromium.org.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX%3D0JZ_4jyoQOCJssh%2BdL%2BDZsXX63XozqPMv_62hYBBzQ%40mail.gmail.com.