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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2dcedd27-960b-436f-8993-820ae2a0deb4n%40chromium.org.
