Hi Alex, Thanks for the feedback and sorry for the initial lack of detail! We hope the following explanations (below) make each of these proposed changes more clear.
We will keep the feedback in mind and make sure to include the level of detail similar to the Explainer format going forward. 1. Spec verbose debug report for max channel capacity and max trigger states cardinality <https://github.com/WICG/attribution-reporting-api/pull/1223> Currently the API supports a feature called Flexible Event-Level reporting, which gives API callers additional customization capabilities by allowing them to change the number of conversion reports, number and length of reporting windows, and trigger data cardinality per source that they register. As part of Flexible Event-Level, the API only allows configurations that do not exceed our current privacy bar (i.e. max channel capacity) of 11.5 bits of information gain for clicks and 6.5 bits of information gain for views. So currently if an ad-tech using Flexible Event-Level chooses a configuration that exceeds the current privacy bar their registration will fail silently. With the addition of the “max channel capacity limit” verbose signal, ad-techs will now be able to receive a verbose debug report telling them that they have exceeded the “max channel capacity” and will allow them to know that they need to use a different configuration and allow them to identify why their source registrations may be failing. This new verbose debug report will also help with future features that may be taken into account when calculating the information gain for a given configuration. Similarly, as part of ARA source registrations and Flexible Event-Level, an ad-tech can customize their trigger data cardinality up to a maximum of 32 trigger states. The “max trigger states cardinality limit” verbose signal, will allow ad-techs to know if they have set a source registration that exceeds this maximum threshold on the trigger data cardinality, making the API easier to debug for ad-techs. 2. Report source reporting origins per site limit explicitly <https://github.com/WICG/attribution-reporting-api/pull/1225> Currently the API has a rate limit that only allows a maximum of 1 reporting origin per {source site, reporting site, 1 day} per source registration. This limit is in place to help prevent ad-techs from cycling through multiple different reporting origins as a way to measure additional information on a user. Currently if an ad-tech exceeds this limit, their source registration will fail silently. In order to make the debugging process easier and help ad-techs identify a potential cause of data loss, the API will now provide a verbose signal for this error any time an ad-tech’s registration exceeds the limit. 3. Gate all source verbose debug reports behind cookie access <https://github.com/WICG/attribution-reporting-api/pull/1204> Currently the API provides 9 different source verbose debug signals. All of these signals require that the ad-tech has set the ar_debug cookie on the source in order to receive the verbose debug signal, except for two errors: “source-destination-limit” and “source-destination-rate-limit”. In order to reduce complexity for ad-techs so that there is no difference in when an ar_debug cookie needs to be set in order to receive a debug report across the different error signals, this change will now require the ar_debug cookie to be set for all source verbose debug signals. This change also has the added benefit of improving privacy by adding an additional check for the two rate limits listed above. 4. Split attribution rate-limit into separate event & aggregate rate-limits <https://github.com/WICG/attribution-reporting-api/pull/1211> Currently the API has a single attribution rate limit of 100 attributions per {source site, destination site, reporting} per 30 days, and this limit is across both report types supported in the API (i.e. event-level reports and aggregate reports). For example, currently if 1 trigger registration generates both an event-level report and aggregate report this will count as 1 towards the attribution limit. And if the attribution limit is hit, neither event-level report nor aggregatable report is created. Now that the API supports a subset of Flexible event-level, there may be scenarios where 1 trigger registration can generate multiple event-level reports, but still only 1 aggregate report. Because of this new behavior it would not be accurate to count and may negatively impact ad-techs if the API tracks the rate limit across both report types. With this change, the API will now track the attribution rate limit separately for each report type. So in the example above, where a trigger registration generates multiple event-level attribution reports, these will only count for the event-level report limit, and not impact the aggregate attribution rate limit, which will allow ad-techs to continue generating aggregate reports. Additionally, this separation of rate limits will also provide better report deletion accounting in the API in scenarios where a pending event-level report is scheduled to be sent at a later time, but then gets replaced by a higher priority newly generated event-level report. In the current API this scenario counts as 2 attribution reports, when in reality the first report is never sent since it is replaced by the higher priority second report. With this change, the API will only count this as 1 report towards the attribution rate limit, and specifically the event-level report count, and not the aggregate report count. Thanks, Akash On Wednesday, May 1, 2024 at 8:59:24 AM UTC-7 Alex Russell wrote: > Hey folks, > > We've talked about this in API OWNERS again, and the presentation of this > set of features is...frustrating. > > Several of these features lack any explanation, example code, or any > outline of alternative approaches that were considered and discarded. > Having multiple features presented in a low-quality way does not make it > easier to evaluate them, particularly when the relationship between them is > unclear and no example code has been produced to demonstrate how they work > together to solve an important problem, let alone why it solves those > problem(s) well. > > I've flipped the bit in chromestatus to "Needs Work" and will hold > shipping these features until such time as a full explanation is produced. > A good way to do that would be to produce an Explainer document (in the > usual format <https://w3ctag.org/explainers/>) for each change, > highlighting considered alternatives and foregrounding end-to-end example > code for both the selected solution and the alternatives. > > Looking forward to working with y'all to get this unblocked. > > Best, > > Alex > > > On Monday, April 29, 2024 at 7:43:06 AM UTC-7 Mike Taylor wrote: > >> Thanks Akash. >> >> This is not quite the level of detail I was hoping for (I've more or less >> grokked that from the commits themselves), but I'm satisfied with the >> compat implications of always requiring the ar_debug cookie. >> >> LGTM1 >> On 4/26/24 5:10 PM, Akash Nadan wrote: >> >> Hi Mike, >> >> We have not fully considered adding this functionality to WPT and it may >> be challenging due to delays and noise added by the Attribution Reporting >> API, but we will evaluate what is possible here. >> >> Thanks - even if challenging, this is super important for long-term >> interop. So whatever we can do to improve the status quo will be >> worthwhile, IMHO. >> >> >> Thanks for the suggestions regarding the features. We will make sure to >> break apart the I2S based on features that can be grouped together in the >> future. >> >> Regarding the motivation for the features: >> >> >> 1. Spec verbose debug report for max channel capacity and max trigger >> states cardinality >> <https://github.com/WICG/attribution-reporting-api/pull/1223> >> For debugging completeness of potential errors that can occur. This is an >> important debug error signal for the flexible event level reporting feature. >> >> 2. Report source reporting origins per site limit explicitly >> <https://github.com/WICG/attribution-reporting-api/pull/1225> >> For debugging completeness of potential errors. >> >> 3. Gate all source verbose debug reports behind cookie access >> <https://github.com/WICG/attribution-reporting-api/pull/1204> >> For reducing complexity across all source verbose debug reports by >> applying the same requirement across all of them. >> >> 4. Split attribution rate-limit into separate event & aggregate >> rate-limits <https://github.com/WICG/attribution-reporting-api/pull/1211> >> For the ability to properly account for report deletions and support the >> flexible event level reporting feature (which may produce more than 1 event >> report per trigger registration, whereas aggregate reports would not). >> >> >> Regarding the interoperability and compatibility question, it is >> currently not possible to register for a specific error signal. The API >> caller would register to receive a debug report and the API then provides >> the error that occurs (assuming an error occurs). Additionally, it would be >> extremely unlikely for sites to only be interested in the >> source-destination-limit and source-destination-rate-limit errors, since >> they would most likely be interested in also understanding any error >> signals that may be impacting their conversions as well. >> >> Thanks, >> >> Akash >> >> >> On Thursday, April 25, 2024 at 11:17:05 AM UTC-7 Mike Taylor wrote: >> >>> Apologies for the delay here - it's a bit challenging to review 4 >>> features at once. >>> >>> (Aside: it seems like this particular intent could have been split into >>> 2... one for 2 debug report features, and another for rate limits?) >>> On 4/19/24 12:51 PM, 'Akash Nadan' via blink-dev wrote: >>> >>> Contact emails >>> >>> [email protected], [email protected], [email protected] >>> >>> 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> >>> >>> Summary >>> >>> We are landing the following changes to the Attribution Reporting API >>> focused on: >>> >>> - >>> >>> additional debugging support by supporting new verbose debug reports >>> - >>> >>> improving privacy & security by adding additional gating to source >>> verbose debug reports >>> - >>> >>> improving rate limit accounting by separating the attribution count >>> for the two ARA report types >>> >>> >>> Explainer/Spec changes >>> >>> 1. Spec verbose debug report for max channel capacity and max >>> trigger states cardinality >>> <https://github.com/WICG/attribution-reporting-api/pull/1223> >>> 2. >>> >>> Report source reporting origins per site limit explicitly >>> <https://github.com/WICG/attribution-reporting-api/pull/1225> >>> 3. >>> >>> Gate all source verbose debug reports behind cookie access >>> <https://github.com/WICG/attribution-reporting-api/pull/1204> >>> 4. >>> >>> Split attribution rate-limit into separate event & aggregate >>> rate-limits >>> <https://github.com/WICG/attribution-reporting-api/pull/1211> >>> >>> These are also challenging to review, as each PR doesn't have a >>> corresponding issue, or given a _why_, just the what (or maybe I'm missing >>> something). The diffs for the explainers also aren't super enlightening. >>> Could you write a few sentences on the motivations for each of these >>> changes? >>> >>> >>> Risks >>> Interoperability and Compatibility >>> >>> (1 <https://github.com/WICG/attribution-reporting-api/pull/1223>, 2 >>> <https://github.com/WICG/attribution-reporting-api/pull/1225>) >>> Additional verbose debug reports and (4 >>> <https://github.com/WICG/attribution-reporting-api/pull/1211>) >>> splitting the attribution rate limit into separate limits for event and >>> aggregate are fully backwards compatible changes. Feature (3 >>> <https://github.com/WICG/attribution-reporting-api/pull/1204>) gating >>> all source verbose debug reports is a backwards incompatible change because >>> now source-destination-limit and source-destination-rate-limit verbose >>> debug reports now require the ar_debug cookie to be set at source >>> registration time. This is not a major concern because all other current >>> source verbose debug signals already require the ar_debug cookie to be set >>> and most ad-techs would already be setting this cookie at source >>> registration time. >>> >>> Is it reasonable to assume that there aren't sites only registering for >>> source-destination-limit and source-destination-rate-limit reports? Do we >>> have usecounters or UKM to verify? >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)? >>> >>> The attribution reporting feature bundle 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> >>> ? >>> >>> Yes >>> >>> Estimated milestones >>> >>> This feature bundle is anticipated to ship as part of Chrome 125 >>> <https://chromiumdash.appspot.com/schedule>. >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5146883686400000 >>> >>> 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> >>> >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/194f8cc0-03b3-47e5-ad1c-0938c1a686ben%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/194f8cc0-03b3-47e5-ad1c-0938c1a686ben%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2fb1a68d-bdc7-4428-ab3f-858b7cabd91en%40chromium.org.
