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 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>
   1. 
      
      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>
   1. 
      
      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>
   1. 
      
      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>
   1. 
      
      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/7750d5b3-2f73-4200-ad64-cdfba4114995n%40chromium.org.

Reply via email to