Intent to Ship: Attribution Reporting Feature: Changes to source-destination-limit logic

[Akash Nadan]

Contact emails

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 utility by changing the methodology for a rate limit

This change is based on ad-tech feedback that we have heard regarding a current rate limit for the Attribution Reporting API.

Currently the API has a limit called the source-destination-limit which allows API callers to register up to 100 distinct destinations per {source site, reporting site} applied to all unexpired sources per browser.

This rate limit also uses a LIFO model (last-in-first-out) in the sense that once the limit is reached, any new source registrations will be rejected.

We have heard feedback from multiple ad-techs that they are running into this limit which then causes some amount of loss in terms of not being able to register new sources.

This change proposes to use a FIFO model (first-in-first-out) for this rate limit. So once the limit is reached, any new source registration will cause the API to delete the oldest pending source registration for the same {source site, reporting site} pair, and allow the new source registration to be stored.

In order to safely support this FIFO model, the following rate limit needs to also be added to the API:

• 100 distinct destinations per {source site, reporting site, 24 hours}.

  • This new rate limit will help to prevent any attacks where an adversary may want to try to cycle through many different destinations in one attempt

In terms of the rollout plan for this feature, we would like to directly switch this rate limit from being a LIFO model to a FIFO model. This means the LIFO model will no longer be an option. Based on feedback we have heard, this type of model where more recent sources are given a stronger preference is in line with how ad-techs think about measuring conversions. Additionally, the API will support a priority field, so that within the FIFO model ad-techs can still specify if certain destinations require a higher priority than others.

This change is not backwards compatible since the model for this rate limit will be changing.

This change will help to reduce the registration and conversion loss ad-techs may see with the current limit.

Explainer/Spec changes

1. Deactivate earliest destinations if exceeding distinct destination limit for unexpired sources

Risks
Interoperability and Compatibility

This feature is not a backwards compatible change because the behavior for which sources will be rejected or deleted once the source destination limit is hit will now be different. The new behavior is intuitively more in line with how ad-techs measure conversions currently, however there may be some scenarios where keeping older source registrations is more important to an ad-tech, which may still be achieved through the use of the priority field that is part of this feature.

This change will not cause any site breakage or change for end users of Chrome. Additionally, once this feature is released it will only be applicable to users running on Chrome M128 and future chrome versions. This change will also not delete any existing source registrations in storage unless the limit is hit and there are source registrations that exceed the limit.

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/WICG/attribution-reporting-api/issues/1228

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?

No, the behavior around destination limiting is not covered in WPT due to performance issues when registering many events to trigger the limits. We are looking at adding WebDriver support to better test some of these privacy limits in the future.

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/6320694358179840

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

[Mike Taylor]

> This change will not cause any site breakage or change for end users of Chrome.

LGTM1

--
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/305f8767-6782-4432-b37e-dbd58ada703en%40chromium.org.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e647d22-1ce9-46b2-ae03-887131c6bbd8%40chromium.org.

[Yoav Weiss (@Shopify)]

Can you expand on that?

What would ad-tech folks need to do differently? Am I right to assume that this would cause attribution breakage only in cases that are currently exceeding the limit?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-NMpZHfekH2OZScDRFg70H%2BULuTmx4DtA2ArQswoQLww%40mail.gmail.com.

[Nan Lin]

Thanks Yoav. Please see the inline response.

Best,

Nan

That's correct that this would only affect ad-techs that are currently exceeding the limit. No change is needed if they want to use the new FIFO behavior. Otherwise, they would need to set the destination priority for the source registrations properly to prioritize destinations and achieve the desired behavior, e.g. the previous LIFO behavior. 

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

[Yoav Weiss (@Shopify)]

Thanks!! Do we have any stats RE how often the limits are exceeded? Is it fair to assume it's a rare occasion?

[Nan Lin]

On Fri, Jul 26, 2024 at 10:30 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Thanks!! Do we have any stats RE how often the limits are exceeded? Is it fair to assume it's a rare occasion?

The metric shows that the limits are exceeded rarely, and the change is based on feedbacks of a few ad-techs that exceed the limit. 

[Yoav Weiss (@Shopify)]

LGTM3