On Thu, Jul 25, 2024 at 11:24 PM Chris Harrelson <chris...@chromium.org> wrote:
> LGTM2 > > On Mon, Jul 22, 2024 at 11:42 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> > This change will not cause any site breakage or change for end users of >> Chrome. >> >> LGTM1 >> On 7/11/24 3:48 PM, 'Akash Nadan' via blink-dev wrote: >> >> Contact emails >> >> akashna...@google.com, lin...@chromium.org, johni...@chromium.org >> >> Explainer >> >> Attribution Reporting with event-level reports >> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md> >> >> Attribution Reporting API with Aggregatable Reports >> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md> >> >> Aggregation Service for the Attribution Reporting API >> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.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> >> >> TAG review >> >> Still under review <https://github.com/w3ctag/design-reviews/issues/724> >> 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. >> >> 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? > >> 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 >> <https://github.com/WICG/attribution-reporting-api/pull/1217> >> >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> 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 >> <https://chromiumdash.appspot.com/schedule>. >> >> 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 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY> >> >> Intent to Ship: Attribution Reporting features M117 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/nWF61c8xu-M/m/uMmH1ewcAQAJ> >> >> Intent to Ship: Attribution Reporting features M118 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Mh-mJiyJZFk/m/HlgzpphYBQAJ> >> >> Intent to Ship: Attribution Reporting features M119 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/6e44SBtEtcQ> >> >> Intent to Ship: Attribution Reporting features M120 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/jSk3xpNPzGQ/m/VZPsdYgGCAAJ> >> >> Intent to Ship: Attribution Reporting features M121 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/g9KiC6Rg_mA/m/V679WcWuAQAJ> >> >> Intent to Ship: Attribution Reporting features M123 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NE7VGke1Bjc/m/bIX00t4CAAAJ> >> >> Intent to Ship: Attribution Reporting features M124 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/aregp1li6xk/m/IhBB2z8tBQAJ> >> >> Intent to Ship: Attribution Reporting features M125 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/9UyhI6SRyxM/m/zgWWckgWAQAJ> >> >> Intent to Ship: Attribution Reporting features M126 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/7UQR2lPn5KE/m/q_kL6ZiJDgAJ> >> >> Intent to Ship: Attribution Reporting features M127 >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/LAgnyPsJyJg?pli=1> >> >> >> Thanks, >> >> Akash >> >> -- >> 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/305f8767-6782-4432-b37e-dbd58ada703en%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/305f8767-6782-4432-b37e-dbd58ada703en%40chromium.org?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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/7e647d22-1ce9-46b2-ae03-887131c6bbd8%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e647d22-1ce9-46b2-ae03-887131c6bbd8%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAOMQ%2Bw-NMpZHfekH2OZScDRFg70H%2BULuTmx4DtA2ArQswoQLww%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-NMpZHfekH2OZScDRFg70H%2BULuTmx4DtA2ArQswoQLww%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOmohSLcQnZr_XxgJFQQnrVd9ydRwGyAhhXm8Mnj5V0L%3DjjYRA%40mail.gmail.com.
