LGTM3 On Friday, May 3, 2024 at 1:34:21 PM UTC-4 Chris Harrelson wrote:
> Thanks for these mini-explainers, they clarified what is changing for me! > > LGTM2 > > On Fri, May 3, 2024 at 9:31 AM 'Akash Nadan' via blink-dev < > blin...@chromium.org> wrote: > >> 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 >>>>> >>>>> akash...@google.com, lin...@chromium.org, john...@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> >>>>> >>>>> 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 blink-dev+...@chromium.org. >>>>> 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 blink-dev+...@chromium.org. >> > 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2fb1a68d-bdc7-4428-ab3f-858b7cabd91en%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/1167e174-9c55-40e3-b105-a07a70d18b4bn%40chromium.org.
