[blink-dev] Intent to Ship: Attribution Reporting Feature: Debug Key Privacy Improvement

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


TAG review

Still under review  
under the original I2S for the Attribution Reporting API

TAG review status

Pending

Summary

We are landing the following changes to the Attribution Reporting API 
focused on:

   - 
   
   Improving privacy for debug keys
   

This change helps to mitigate a potential privacy gap with debug keys.

Currently the API allows a source debug key or a trigger debug key to be 
specified if third party cookies are available and can be set by API 
callers. If either a source or trigger debug key is specified then it will 
be included in the attribution report. This may lead to a privacy leak if 
third party cookies are only allowed on either the publisher or the 
advertiser site but not both. 

This change mitigates this issue by enforcing that source debug keys and 
trigger debug keys are only included in the attribution report if they’re 
present on both the source and trigger, which would mean that third party 
cookies were available on both the publisher and advertiser site. This 
change will apply to both event-level reports and aggregatable reports.


Explainer/Spec changes
   
   1. 
   
   Explainer & Spec: 
   https://github.com/WICG/attribution-reporting-api/pull/1403
   

Risks
Interoperability and Compatibility

This is a backwards incompatible change. API callers will continue to 
receive Attribution Reporting API reports but the information contained in 
the report may change if the API caller only specifies a debug key on only 
the source or trigger registration. If they only specify a debug key on one 
side, then they will no longer receive debug key information in the report 
they receive but they will continue to receive reports. We expect this to 
have minimal impact since the API caller will continue to receive 
attribution reports as expected.

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)


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?

No

  
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 

?

Yes

Estimated milestones

This feature is anticipated to ship as part of Chrome 130 
. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6257907243679744

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


Intent to Ship: Attribution Reporting features M123 


Intent to Ship: Attribution Reporting features M124 


Intent to Ship: Attribution Reporting features M125 


Intent to Ship: Attribution Reporting features M126 


Intent to Ship: Attribution Repor

[blink-dev] Intent to Ship: Attribution Reporting Feature: Attribution Scopes

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


TAG review

Still under review  
under the original I2S for the Attribution Reporting API

TAG review status

Pending

Summary

We are landing the following changes to the Attribution Reporting API 
focused on:

   - 
   
   providing more control over the attribution filtering
   

This change is based on ad-tech feedback and the need for more fine grained 
filtering controls before the attribution process takes place.

Currently the API performs filtering after a source is chosen based on 
matching  fields. This results in API 
callers either not receiving attribution reports or incorrect attribution 
in scenarios where there are multiple different advertisers/campaigns that 
all convert on the same destination site.

This change allows API callers to now specify a field called 
"attribution_scopes" which will be used for filtering before starting the 
regular attribution flow. This allows API callers more fine grained control 
over the attribution granularity and the ability to receive proper 
attribution reports in the scenario described above (i.e. where there are 
multiple different advertisers/campaigns that all convert on the same 
destination site).

This change directly addresses API caller feedback and allows them to have 
more control over their attribution filtering.

Explainer/Spec changes
   
   1. 
   
   Explainer: 
   
https://github.com/WICG/attribution-reporting-api/blob/main/attribution_scopes.md
   2. 
   
   Spec: https://github.com/WICG/attribution-reporting-api/pull/1215
   

Risks
Interoperability and Compatibility

This is an optional and fully backwards compatible change. This feature 
provides a new field for specifying filters that can be checked before the 
regular attribution process takes place and does not break any pre-existing 
API or web functionality.

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/1229


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?

No

  
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 

?

No, currently the behavior around attribution scopes is not covered in WPT 
due to difficulty of adding significant coverage for the feature because of 
API-mandated delays and noise. However, the feature is covered by 
comprehensive integration tests (commonly referred to as “interop tests”) 
that are also reusable by other implementations. 

Estimated milestones

This feature is anticipated to ship as part of Chrome 130 
. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096560068395008

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


Intent to Ship: Attribution Reporting features M123 


Intent to Ship: Attribution 

[blink-dev] Re: Intent to Ship: Attribution Reporting Feature: Flexible contributions filtering

['Akash Nadan' via blink-dev]

Hi All,


Just adding some additional detail regarding the interoperability and 
compatibility of this feature:


Interoperability and Compatibility

This change is optional and will be fully backwards compatible once 
Aggregation Service release 2.3 reaches end-of-support on August 2nd 
(before M128 reaches Stable).


Additionally, developers that want to use this new feature will need to 
upgrade their Aggregation Service release to version 2.5 or later. The 
Aggregation Service is used to process the aggregatable reports that a 
developer receives. We have notified partners of these considerations 
through the API mailing list 
.
 
A similar feature is being released for the Private Aggregation API, with 
the same Aggregation Service considerations 

.


Thanks,

Akash


On Thursday, July 11, 2024 at 12:54:08 PM UTC-7 Akash Nadan wrote:

> Contact emails
>
> akash...@google.com, lin...@chromium.org, john...@chromium.org
>
> Explainer
>
> Attribution Reporting with event-level reports 
> 
>
> Attribution Reporting API with Aggregatable Reports 
> 
>
> Aggregation Service for the Attribution Reporting API 
> 
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/
>
> Blink component
>
> Internals > AttributionReporting 
> 
>
> TAG review
>
> Still under review  
> 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 API report batching capabilities
>
>
> This change is based on ad-tech feedback that we heard regarding the need 
> for additional report batching flexibility so that different report 
> contributions can be batched at different cadences.
>
> Currently aggregatable reports generated by the API can consist of 
> multiple separate contributions which are key:value pairs. API callers can 
> batch together aggregatable reports and then process them in the 
> aggregation service, which consists of decrypting the reports, aggregating 
> the values, and adding noise, before returning a summary report to the API 
> caller. Additionally, all contributions in an aggregatable report must 
> currently be processed by aggregation service at the same time.
>
> With this change, the API will now allow API callers to specify filtering 
> IDs as part of each contribution (i.e. each key:value pair) in the 
> aggregatable report. API callers can then use these filtering IDs, which 
> will also be part of the encrypted payload of the report, to specify which 
> contributions they want to have processed by the aggregation service at a 
> given time.
>
> This will allow API callers to process contributions with different 
> filtering IDs at different cadences. Allowing this flexibility is a utility 
> improvement, because the noise added in the aggregation service per 
> key:value pair bucket may have a lower relative impact on values that are 
> batched on a longer cadence.
>
> Explainer/Spec changes
>
>1. 
>
>Flexible contributions filtering 
>
>
>
> Risks
> Interoperability and Compatibility
>
> This is an optional and fully backwards compatible change. This feature 
> provides a new filtering ID that can be set as part of the aggregatable 
> report contributions and does not break any pre-existing API or web 
> functionality.
>
> 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/patcg-individual-drafts/private-aggregation-api/issues/92
>
> *although this is a private aggregation issue link, it also applies to ARA 
> use cases*
>
>
> 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 
> 

[blink-dev] Intent to Ship: Attribution Reporting Feature: Flexible contributions filtering

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


TAG review

Still under review  
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 API report batching capabilities
   

This change is based on ad-tech feedback that we heard regarding the need 
for additional report batching flexibility so that different report 
contributions can be batched at different cadences.

Currently aggregatable reports generated by the API can consist of multiple 
separate contributions which are key:value pairs. API callers can batch 
together aggregatable reports and then process them in the aggregation 
service, which consists of decrypting the reports, aggregating the values, 
and adding noise, before returning a summary report to the API caller. 
Additionally, all contributions in an aggregatable report must currently be 
processed by aggregation service at the same time.

With this change, the API will now allow API callers to specify filtering 
IDs as part of each contribution (i.e. each key:value pair) in the 
aggregatable report. API callers can then use these filtering IDs, which 
will also be part of the encrypted payload of the report, to specify which 
contributions they want to have processed by the aggregation service at a 
given time.

This will allow API callers to process contributions with different 
filtering IDs at different cadences. Allowing this flexibility is a utility 
improvement, because the noise added in the aggregation service per 
key:value pair bucket may have a lower relative impact on values that are 
batched on a longer cadence.

Explainer/Spec changes
   
   1. 
   
   Flexible contributions filtering 
   
   

Risks
Interoperability and Compatibility

This is an optional and fully backwards compatible change. This feature 
provides a new filtering ID that can be set as part of the aggregatable 
report contributions and does not break any pre-existing API or web 
functionality.

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/patcg-individual-drafts/private-aggregation-api/issues/92

*although this is a private aggregation issue link, it also applies to ARA 
use cases*


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 

?

Yes

Estimated milestones

This feature is anticipated to ship as part of Chrome 128 
. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5487434799513600

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


Intent to Ship: Attribution Reporting features M123 

[blink-dev] Intent to Ship: Attribution Reporting Feature: Changes to source-destination-limit logic

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


TAG review

Still under review  
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.

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 
   
   

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 t

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

['Akash Nadan' via blink-dev]

Hi Yoav,

The debug signals that will be reported on are documented 
here: 
https://github.com/WICG/attribution-reporting-api/blob/main/verbose_debugging_reports.md

These are the same debug signals that current debug reports support. We 
plan to support the same set of debug signals in this new feature as well.

These debug signals are not developer defined, however a developer can 
specify which of the signals they want to track and can group certain 
signals together (more details here 
<https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md#opting-in-aggregate-debug-reporting>
).

Thanks,
Akash
On Monday, June 10, 2024 at 10:02:08 PM UTC-7 Yoav Weiss (@Shopify) wrote:

> On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via blink-dev <
> blin...@chromium.org> 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>
>>
>> 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 changes to the Attribution Reporting API 
>> focused on:
>>
>>- 
>>
>>improving debugging capabilities
>>
>>
>> This change is based on ad-tech feedback and the need to support 
>> debugging capabilities after third-party cookie deprecation. 
>>
>> Currently the API supports debug reports that are tied to third-party 
>> cookies. In order for an API caller to receive a debug report of any kind 
>> they need to make sure a specific third-party cookie (i.e. ar_debug) is 
>> properly set. The API will check to make sure this cookie is set before 
>> providing any kind of debug report. Once third-party cookies are deprecated 
>> these debug reports will no longer be available. 
>>
>> This change is so the API can continue to provide debugging information 
>> after third-party cookie deprecation when the current debug reports that 
>> are tied to third-party cookies are no longer available. This is a new 
>> report type that is not tied to third-party cookies and provides similar 
>> debug information. This feature allows API callers to request and receive 
>> debug signals in aggregate form. This feature is very similar to current 
>> Aggregate Reports supported by the API, except these new reports will be 
>> specifically for debug signals. 
>>
>
> Can you expand on what debug signals are being aggregated? Are they 
> developer-defined somehow?
>   
>
>>
>> This new feature will allow API callers to continue receiving debugging 
>> information even after third-party cookie deprecation.
>>
>> Explainer/Spec changes
>>
>>1. 
>>
>>Explainer: 
>>
>> https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md
>>2. 
>>
>>Spec: 
>>1. 
>>   
>>   https://github.com/WICG/attribution-reporting-api/pull/1310
>>   2. 
>>   
>>   https://github.com/WICG/attribution-reporting-api/pull/1292
>>   
>>
>> Risks
>> Interoperability and Compatibility
>>
>> This is an optional and fully backwards compatible change. This feature 
>> provides a new mechanism for receiving debugging information and does not 
>> break any pre-existing API or web functionality.
>>
>> 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/705
>>
>>
>> WebView ap

[blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


TAG review

Still under review  
under the original I2S for the Attribution Reporting API

TAG review status

Pending

Summary

We are landing the following changes to the Attribution Reporting API 
focused on:

   - 
   
   improving debugging capabilities
   

This change is based on ad-tech feedback and the need to support debugging 
capabilities after third-party cookie deprecation. 

Currently the API supports debug reports that are tied to third-party 
cookies. In order for an API caller to receive a debug report of any kind 
they need to make sure a specific third-party cookie (i.e. ar_debug) is 
properly set. The API will check to make sure this cookie is set before 
providing any kind of debug report. Once third-party cookies are deprecated 
these debug reports will no longer be available. 

This change is so the API can continue to provide debugging information 
after third-party cookie deprecation when the current debug reports that 
are tied to third-party cookies are no longer available. This is a new 
report type that is not tied to third-party cookies and provides similar 
debug information. This feature allows API callers to request and receive 
debug signals in aggregate form. This feature is very similar to current 
Aggregate Reports supported by the API, except these new reports will be 
specifically for debug signals. 

This new feature will allow API callers to continue receiving debugging 
information even after third-party cookie deprecation.

Explainer/Spec changes
   
   1. 
   
   Explainer: 
   
https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md
   2. 
   
   Spec: 
   1. 
  
  https://github.com/WICG/attribution-reporting-api/pull/1310
  2. 
  
  https://github.com/WICG/attribution-reporting-api/pull/1292
  

Risks
Interoperability and Compatibility

This is an optional and fully backwards compatible change. This feature 
provides a new mechanism for receiving debugging information and does not 
break any pre-existing API or web functionality.

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/705


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?

No

  
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 

?

Yes

Estimated milestones

This feature is anticipated to ship as part of Chrome 127 
. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5086433709916160

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


Intent to Ship: Attribution Reporting features M123 


Intent to Ship: Attribution Reporting features M124 

[blink-dev] Intent to Ship: Attribution Reporting Feature: Prevent Coalescing of Headers

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


Summary

We are landing the following change to the Attribution Reporting API 
focused on:

   - 
   
   improving handling of registrations with multiple of the same header
   

This feature is mainly to address the following edge case 
.

Currently the API coalesces registration headers if the same header appears 
multiple times in a response. The individual response values are joined by 
a "," (comma).

Because the headers contain JSON, this almost always results in an invalid 
value and therefore responses with multiple of the same header will cause 
the registration to fail, except in the scenario of the edge case.

Given this potential edge case, and so that the current API behavior 
persists, this change makes it so that the API explicitly prevents header 
coalescing. If the same header appears more than once in the response then 
the registration will be rejected.

Explainer/Spec changes
   
   1. 
   
   Prevent coalescing for web source/trigger headers  
   
   

Risks
Interoperability and Compatibility

This feature is a backwards incompatible change because of the edge case 
scenario described above. However, as described above, this is not a major 
concern because currently in all cases except the edge case scenario, which 
seems very unlikely, the behavior for having multiple of the same header in 
the response is the same.

  
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 

?

Yes

Estimated milestones

This feature is anticipated to ship as part of Chrome 126. 
 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5204901830590464

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


Intent to Ship: Attribution Reporting features M123 


Intent to Ship: Attribution Reporting features M124 


Intern to Ship: Attribution Reporting features M125 


-- 
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/c1897a01-ad86-492a-8cac-e6c0033be278n%40chromium.org.

[blink-dev] Intent to Ship: Attribution Reporting Feature: Referrer Policy for Attributionsrc Requests

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


Summary

We are landing the following change to the Attribution Reporting API 
focused on:

   - 
   
   applying element-level referrer policy for specific html elements
   

This change is based on ad-tech feedback 
 and so that 
attributionsrc requests are treated like other subresources on the page.

Currently when the API is called through the use of the attributionsrc 
attribution as part of various html elements (i.e. , 

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

['Akash Nadan' via blink-dev]

ttribution 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 m

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

['Akash Nadan' via blink-dev]

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>
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 <

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

['Akash Nadan' via blink-dev]

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 supe

[blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Additional Verbose Debug Reports, Further Gating Source Verbose Debug Reports, Splitting the Attribution Rate Limit

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


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 
   
   2. 
   
   Report source reporting origins per site limit explicitly 
   
   3. 
   
   Gate all source verbose debug reports behind cookie access 
   
   4. 
   
   Split attribution rate-limit into separate event & aggregate rate-limits 
   
   

Risks
Interoperability and Compatibility

(1 , 2 
) Additional 
verbose debug reports and (4 
) splitting 
the attribution rate limit into separate limits for event and aggregate are 
fully backwards compatible changes. Feature (3 
) 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.

  
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 

?

Yes

Estimated milestones

This feature bundle is anticipated to ship as part of Chrome 125 
. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/514688368640

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


Intent to Ship: Attribution Reporting features M123 


Intent to Ship: Attribution Reporting features M124 


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/194f8cc0-03b3-47e5-ad1c-0938c1a686ben%40chromium.org.

[blink-dev] Re: Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

['Akash Nadan' via blink-dev]

Hi Yoav, the reasoning behind this change is that there is a privacy gap 
with the current attribution flow and position of the source deactivation 
logic. The current position of the source deactivation logic makes it 
possible for API callers to identify when a source is noise (versus a real 
source) in certain scenarios. Additional details/example in this Github 
issue: https://github.com/WICG/attribution-reporting-api/issues/842

Regarding the implications, an ad-tech may get different reports in some 
circumstances (or no report where they previously would have gotten one) 
which may have implications when they are comparing these reports to other 
mechanisms they may be using for conversion measurement. They may see a 
slight difference in those comparisons, although given that this scenario 
is rare, it may not cause any issues or change in comparison.

Let me know if you have any other questions.

Thanks,
Akash

On Tuesday, March 26, 2024 at 10:54:02 AM UTC-7 Yoav Weiss (@Shopify) wrote:

> On Tuesday, March 19, 2024 at 12:18:00 AM UTC+1 Akash Nadan wrote:
>
> Contact emails
>
> akash...@google.com, lin...@chromium.org, john...@chromium.org
>
> Explainer
>
> Attribution Reporting with event-level reports 
> 
>
> Attribution Reporting API with Aggregatable Reports 
> 
>
> Aggregation Service for the Attribution Reporting API 
> 
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/
>
> Blink component
>
> Internals > AttributionReporting 
> 
>
> Summary
>
> We are landing the following changes to the Attribution Reporting API 
> focused on:
>
>- 
>
>additional debugging capabilities by supporting parsing failure debug 
>reports
>- 
>
>improving API ergonomics by supporting a field to specify preferred 
>registration platform
>- 
>
>improving privacy
>
>
> Explainer/Spec changes
>
>1. Response header errors debug reports 
>
>2. Supporting preferred platform for cross app attribution 
>
>3. Move source deactivation step after top level filter matching  
>
>
>
> Can you provide more details on the reasoning and implications of (3)? A 
> lack of explainer or details on the PR itself make it somewhat of an opaque 
> change..
>  
>
>
> Risks
> Interoperability and Compatibility
>
> (1 ) Header 
> errors debug reports and (2 
> ) preferred 
> platform are both fully backwards compatible changes and are optional 
> features.  (3 ) 
> The source deactivation change has very low compatibility risk because it 
> does not require any developer changes and only results in ad techs getting 
> different reports in cases where a user had multiple interactions across 
> different ads when rate limits in the API are hit, which should be very 
> rare.
>
>   
> 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 
> 
> ?
>
> Yes
>
> Estimated milestones
>
> This feature bundle is anticipated to ship as part of Chrome 124 
> . 
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5117902786396160
>
> Links to previous Intent discussions
>
> Previous I2S: 
>
> Intent to Ship: Attribution Reporting API 
> 
>
> Intent to Ship: Attribution Reporting features M117 
> 
>
> Intent to Ship: Attribution Reporting features M118 
> 
>
> Intent to Ship: Attribution Reporting features M119 
> 
>
> Intent to Ship: Attribution Reporting features M120 
> 
>
> Intent to Ship: Attribution Reporting features M121 
> 

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

['Akash Nadan' via blink-dev]

Hi Mike, other than the blink-dev and GitHub Issue and PR, we have not yet. 
But I am planning to post an announcement about the change to the Attribution 
Reporting API Announcements 
<https://groups.google.com/a/chromium.org/g/attribution-reporting-api-dev> 
group as well.

Thanks,
Akash

On Monday, March 25, 2024 at 7:45:42 AM UTC-7 Mike Taylor wrote:

> Thanks Akash. Follow up question: besides reading blink-dev, have we 
> otherwise made relevant ad techs aware of the changes coming to reports?
> On 3/22/24 5:52 PM, Akash Nadan wrote:
>
> Hi Mike, the implications of an adtech getting different reports in some 
> circumstances (or no report where they previously would have gotten one) 
> are mainly when they are comparing these reports to other mechanisms they 
> may be using for conversion measurement. They may see a slight difference 
> in those comparisons, although given that this scenario is rare, it may not 
> cause any issues or change in comparison. 
>
> Let me know if you have any other questions.
>
> Thanks,
> Akash
>
>
> On Wednesday, March 20, 2024 at 8:30:31 AM UTC-7 Mike Taylor wrote:
>
>> On 3/18/24 7:17 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 capabilities by supporting parsing failure debug 
>>reports
>>- 
>>
>>improving API ergonomics by supporting a field to specify preferred 
>>registration platform
>>- 
>>
>>improving privacy
>>
>>
>> Explainer/Spec changes 
>>
>>1. Response header errors debug reports 
>><https://github.com/WICG/attribution-reporting-api/pull/1180> 
>>2. Supporting preferred platform for cross app attribution 
>><https://github.com/WICG/attribution-reporting-api/pull/1161> 
>>3. Move source deactivation step after top level filter matching  
>><https://github.com/WICG/attribution-reporting-api/pull/851> 
>>
>>
>> Risks
>> Interoperability and Compatibility 
>>
>> (1 <https://github.com/WICG/attribution-reporting-api/pull/1180>) Header 
>> errors debug reports and (2 
>> <https://github.com/WICG/attribution-reporting-api/pull/1161>) preferred 
>> platform are both fully backwards compatible changes and are optional 
>> features.  (3 
>> <https://github.com/WICG/attribution-reporting-api/pull/851>) The source 
>> deactivation change has very low compatibility risk because it does not 
>> require any developer changes and only results in ad techs getting 
>> different reports in cases where a user had multiple interactions across 
>> different ads when rate limits in the API are hit, which should be very 
>> rare.
>>
>> I think I understand why the potential compat issue should be rare based 
>> on reading 
>> https://github.com/WICG/attribution-reporting-api/issues/842#issuecomment-1612096408,
>>  
>> but it's not super clear to me what the implications for "adtechs getting 
>> different reports in some circumstances (or not report where they 
>> previously would have gotten one)" are. Mind clarifying?
>>
>>   
>> 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>
>> ? 
>>

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

['Akash Nadan' via blink-dev]

Hi Mike, the implications of an adtech getting different reports in some 
circumstances (or no report where they previously would have gotten one) 
are mainly when they are comparing these reports to other mechanisms they 
may be using for conversion measurement. They may see a slight difference 
in those comparisons, although given that this scenario is rare, it may not 
cause any issues or change in comparison.

Let me know if you have any other questions.

Thanks,
Akash


On Wednesday, March 20, 2024 at 8:30:31 AM UTC-7 Mike Taylor wrote:

> On 3/18/24 7:17 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 capabilities by supporting parsing failure debug 
>reports
>- 
>
>improving API ergonomics by supporting a field to specify preferred 
>registration platform
>- 
>
>improving privacy
>
>
> Explainer/Spec changes 
>
>1. Response header errors debug reports 
><https://github.com/WICG/attribution-reporting-api/pull/1180> 
>2. Supporting preferred platform for cross app attribution 
><https://github.com/WICG/attribution-reporting-api/pull/1161> 
>3. Move source deactivation step after top level filter matching  
><https://github.com/WICG/attribution-reporting-api/pull/851> 
>
>
> Risks
> Interoperability and Compatibility 
>
> (1 <https://github.com/WICG/attribution-reporting-api/pull/1180>) Header 
> errors debug reports and (2 
> <https://github.com/WICG/attribution-reporting-api/pull/1161>) preferred 
> platform are both fully backwards compatible changes and are optional 
> features.  (3 <https://github.com/WICG/attribution-reporting-api/pull/851>) 
> The source deactivation change has very low compatibility risk because it 
> does not require any developer changes and only results in ad techs getting 
> different reports in cases where a user had multiple interactions across 
> different ads when rate limits in the API are hit, which should be very 
> rare.
>
> I think I understand why the potential compat issue should be rare based 
> on reading 
> https://github.com/WICG/attribution-reporting-api/issues/842#issuecomment-1612096408,
>  
> but it's not super clear to me what the implications for "adtechs getting 
> different reports in some circumstances (or not report where they 
> previously would have gotten one)" are. Mind clarifying?
>
>   
> 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 124 
> <https://chromiumdash.appspot.com/schedule>. 
>
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/5117902786396160
>
> 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: Attributi

[blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


Summary

We are landing the following changes to the Attribution Reporting API 
focused on:

   - 
   
   additional debugging capabilities by supporting parsing failure debug 
   reports
   - 
   
   improving API ergonomics by supporting a field to specify preferred 
   registration platform
   - 
   
   improving privacy
   

Explainer/Spec changes
   
   1. Response header errors debug reports 
   
   2. Supporting preferred platform for cross app attribution 
   
   3. Move source deactivation step after top level filter matching  
   


Risks
Interoperability and Compatibility

(1 ) Header 
errors debug reports and (2 
) preferred 
platform are both fully backwards compatible changes and are optional 
features.  (3 ) 
The source deactivation change has very low compatibility risk because it 
does not require any developer changes and only results in ad techs getting 
different reports in cases where a user had multiple interactions across 
different ads when rate limits in the API are hit, which should be very 
rare.

  
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 

?

Yes

Estimated milestones

This feature bundle is anticipated to ship as part of Chrome 124 
. 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5117902786396160

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


Intent to Ship: Attribution Reporting features M123 


-- 
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/c691e58e-bfbb-492b-b235-6facc6d12062n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Attribution Reporting API Features (Trigger Data Customization and Aggregatable Value Filters)

['Akash Nadan' via blink-dev]

Thanks all. Just adding the following Github Issue with additional context 
regarding the need for these features: 
https://github.com/WICG/attribution-reporting-api/issues/733

Thanks,
Akash

On Wednesday, February 28, 2024 at 6:56:51 PM UTC-8 Mike Taylor wrote:

> Thank you for the code pointer (and education). LGTM3
> On 2/26/24 2:00 PM, Nan Lin wrote:
>
> Hi Mike,
>
> The web API is not supported for WebView ( 
>
> https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_content_browser_client.cc;l=1217?q=aw_content_browser_client&ss=chromium),
>  
> and therefore these features in the web API are not supported for WebView, 
> but may be supported when these features are supported in the Android API.
>
> Thanks,
> Nan
>
> On Mon, Feb 26, 2024 at 1:53 PM Mike Taylor  wrote:
>
>> Hi Akash,
>>
>> Could you please clarify: if WebView supports the web API (which it does, 
>> IIUC?), these new features also be supported in the WebView context, 
>> correct?
>>
>> I'm not able to find where the Attribution Reporting API is _disabled_ 
>> for WebView (assuming it would be in 
>> https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_field_trials.cc;l=72-73
>> ).
>> On 2/23/24 1:38 PM, 'Akash Nadan' via blink-dev wrote:
>>
>> Hi Peter, 
>>
>> The Attribution Reporting Web API is currently not supported in Android 
>> WebView, but events can be delegated to Android. These extensions are only 
>> for the web API.
>>
>> Thanks,
>> Akash
>>
>> On Friday, February 23, 2024 at 2:45:11 AM UTC-8 Peter Beverloo wrote:
>>
>>> Hi Akash - the Attribution Reporting API is supported in Android 
>>> WebView, why won't these extensions be? 
>>>
>>> Thanks,
>>> Peter
>>>
>>> On Thu, Feb 22, 2024 at 8:32 PM 'Akash Nadan' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>>> Hi All, 
>>>>
>>>> We did not do an OT for these features. But we have discussed and 
>>>> collected feedback regarding these features with multiple ad-techs and 
>>>> have 
>>>> shared these features during the WICG (web platform incubator community 
>>>> group) weekly calls.
>>>>
>>>> Thanks,
>>>> Akash
>>>>
>>>> On Wednesday, February 21, 2024 at 8:57:48 AM UTC-8 Alex Russell wrote:
>>>>
>>>>> Hey folks, 
>>>>>
>>>>> I also appreciate the quality of the design work here, but we need 
>>>>> developer interest to be able to launch features out ahead of other 
>>>>> engines. Was an OT done? What other signals do we have to go on?
>>>>>
>>>>> Best,
>>>>>
>>>>> Alex
>>>>>
>>>>> On Tuesday, February 20, 2024 at 10:56:21 PM UTC-8 Yoav Weiss wrote:
>>>>>
>>>>>> LGTM2
>>>>>>
>>>>>> On Wednesday, February 21, 2024 at 6:02:29 AM UTC+1 Domenic Denicola 
>>>>>> wrote:
>>>>>>
>>>>>>> LGTM1. I appreciate the detailed explainers and well-reviewed spec 
>>>>>>> updates. 
>>>>>>>
>>>>>>> I noticed the TAG review field was missing, but it seems the TAG 
>>>>>>> review for the base feature is still ongoing 
>>>>>>> <https://github.com/w3ctag/design-reviews/issues/724> since 
>>>>>>> 2022-03-24, so I agree with the decision to not derailing that ongoing 
>>>>>>> review by requesting additional review for small additions like this.
>>>>>>>
>>>>>>> On Tuesday, February 13, 2024 at 3:12:22 AM UTC+9 Akash Nadan 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>
>>>>>>>>
>>>

Re: [blink-dev] Re: Intent to Ship: Attribution Reporting API Features (Trigger Data Customization and Aggregatable Value Filters)

['Akash Nadan' via blink-dev]

Hi Peter,

The Attribution Reporting Web API is currently not supported in Android 
WebView, but events can be delegated to Android. These extensions are only 
for the web API.

Thanks,
Akash

On Friday, February 23, 2024 at 2:45:11 AM UTC-8 Peter Beverloo wrote:

> Hi Akash - the Attribution Reporting API is supported in Android WebView, 
> why won't these extensions be?
>
> Thanks,
> Peter
>
> On Thu, Feb 22, 2024 at 8:32 PM 'Akash Nadan' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hi All,
>>
>> We did not do an OT for these features. But we have discussed and 
>> collected feedback regarding these features with multiple ad-techs and have 
>> shared these features during the WICG (web platform incubator community 
>> group) weekly calls.
>>
>> Thanks,
>> Akash
>>
>> On Wednesday, February 21, 2024 at 8:57:48 AM UTC-8 Alex Russell wrote:
>>
>>> Hey folks,
>>>
>>> I also appreciate the quality of the design work here, but we need 
>>> developer interest to be able to launch features out ahead of other 
>>> engines. Was an OT done? What other signals do we have to go on?
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tuesday, February 20, 2024 at 10:56:21 PM UTC-8 Yoav Weiss wrote:
>>>
>>>> LGTM2
>>>>
>>>> On Wednesday, February 21, 2024 at 6:02:29 AM UTC+1 Domenic Denicola 
>>>> wrote:
>>>>
>>>>> LGTM1. I appreciate the detailed explainers and well-reviewed spec 
>>>>> updates.
>>>>>
>>>>> I noticed the TAG review field was missing, but it seems the TAG 
>>>>> review for the base feature is still ongoing 
>>>>> <https://github.com/w3ctag/design-reviews/issues/724> since 
>>>>> 2022-03-24, so I agree with the decision to not derailing that ongoing 
>>>>> review by requesting additional review for small additions like this.
>>>>>
>>>>> On Tuesday, February 13, 2024 at 3:12:22 AM UTC+9 Akash Nadan 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 plan on landing the following changes to the Attribution Reporting 
>>>>>> API focused on:
>>>>>>
>>>>>>- 
>>>>>>
>>>>>>additional API configurability for event-level reporting by 
>>>>>>supporting customization for trigger data cardinality and values
>>>>>>- 
>>>>>>
>>>>>>additional API configurability for summary reports by supporting 
>>>>>>filters in aggregatable values
>>>>>>
>>>>>>
>>>>>> Explainer/Spec changes
>>>>>>
>>>>>>- Allow sources to customize trigger data cardinality and values 
>>>>>><https://github.com/WICG/attribution-reporting-api/pull/1129>
>>>>>>- Allow trigger side filtering on aggregation keys 
>>>>>><https://github.com/WICG/attribution-reporting-api/pull/1149>
>>>>>>
>>>>>>
>>>>>> Risks
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> Both

[blink-dev] Re: Intent to Ship: Attribution Reporting API Features (Trigger Data Customization and Aggregatable Value Filters)

['Akash Nadan' via blink-dev]

Hi All,

We did not do an OT for these features. But we have discussed and collected 
feedback regarding these features with multiple ad-techs and have shared 
these features during the WICG (web platform incubator community group) 
weekly calls.

Thanks,
Akash

On Wednesday, February 21, 2024 at 8:57:48 AM UTC-8 Alex Russell wrote:

> Hey folks,
>
> I also appreciate the quality of the design work here, but we need 
> developer interest to be able to launch features out ahead of other 
> engines. Was an OT done? What other signals do we have to go on?
>
> Best,
>
> Alex
>
> On Tuesday, February 20, 2024 at 10:56:21 PM UTC-8 Yoav Weiss wrote:
>
>> LGTM2
>>
>> On Wednesday, February 21, 2024 at 6:02:29 AM UTC+1 Domenic Denicola 
>> wrote:
>>
>>> LGTM1. I appreciate the detailed explainers and well-reviewed spec 
>>> updates.
>>>
>>> I noticed the TAG review field was missing, but it seems the TAG review 
>>> for the base feature is still ongoing 
>>>  since 2022-03-24, 
>>> so I agree with the decision to not derailing that ongoing review by 
>>> requesting additional review for small additions like this.
>>>
>>> On Tuesday, February 13, 2024 at 3:12:22 AM UTC+9 Akash Nadan wrote:
>>>
 Contact emails

 akash...@google.com, lin...@chromium.org, john...@chromium.org

 Explainer

 Attribution Reporting with event-level reports 
 

 Attribution Reporting API with Aggregatable Reports 
 

 Aggregation Service for the Attribution Reporting API 
 

 Specification

 https://wicg.github.io/attribution-reporting-api/

 Blink component

 Internals > AttributionReporting 
 

 Summary

 We plan on landing the following changes to the Attribution Reporting 
 API focused on:

- 

additional API configurability for event-level reporting by 
supporting customization for trigger data cardinality and values
- 

additional API configurability for summary reports by supporting 
filters in aggregatable values


 Explainer/Spec changes

- Allow sources to customize trigger data cardinality and values 

- Allow trigger side filtering on aggregation keys 



 Risks
 Interoperability and Compatibility

 Both features are fully backwards compatible changes and are optional 
 features.

   
 Will this feature be supported on all six Blink platforms (Windows, 
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 All except Android WebView

 Is this feature fully tested by web-platform-tests 
 
 ?

 Yes

 Estimated milestones

 Chrome 123

 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5170344510095360

 Links to previous Intent discussions

 Previous I2S: 

 Intent to Ship: Attribution Reporting API 
 

 Intent to Ship: Attribution Reporting features M117 
 

 Intent to Ship: Attribution Reporting features M118 
 

 Intent to Ship: Attribution Reporting features M119 
 

 Intent to Ship: Attribution Reporting features M120 
 

 Intent to Ship: Attribution Reporting features M121 
 



-- 
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/cb63f3a9-0856-4387-8e5b-1a2281d60409n%40chromium.org.

[blink-dev] Intent to Ship: Attribution Reporting API Features (Trigger Data Customization and Aggregatable Value Filters)

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


Summary

We plan on landing the following changes to the Attribution Reporting API 
focused on:

   - 
   
   additional API configurability for event-level reporting by supporting 
   customization for trigger data cardinality and values
   - 
   
   additional API configurability for summary reports by supporting filters 
   in aggregatable values
   

Explainer/Spec changes
   
   - Allow sources to customize trigger data cardinality and values 
   
   - Allow trigger side filtering on aggregation keys 
   


Risks
Interoperability and Compatibility

Both features are fully backwards compatible changes and are optional 
features.

  
Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?

All except Android WebView

Is this feature fully tested by web-platform-tests 

?

Yes

Estimated milestones

Chrome 123

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5170344510095360

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


Intent to Ship: Attribution Reporting features M121 


-- 
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/d922a5aa-6591-4511-b83f-75e8a5e763ean%40chromium.org.

Re: [blink-dev] Intent to Ship: Attribution Reporting Features (Reduced Aggregate Delays, Event-Level Report Epsilon Field, Reserved Keys)

['Akash Nadan' via blink-dev]

Hi Mike,

I have requested the various reviews needed.

Thanks,
Akash

On Friday, December 1, 2023 at 2:25:48 PM UTC-8 Mike Taylor wrote:

> Hi Akash,
>
> Can you request reviews for the various review gates on your chromestatus 
> entry?
>
> thanks,
> Mike
> On 11/30/23 12:37 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 plan on landing the following changes to the Attribution Reporting API 
> focused on:
>
>- 
>
>reducing transmission loss by supporting reduced aggregatable report 
>delays with trigger context ID
>- 
>
>additional API configurability by supporting an event-level reporting 
>epsilon field
>- 
>
>improve extensibility of the API by failing registrations when 
>encountering reserved keys
>
> Explainer/Spec changes 
>
>- Reduce aggregate delays and support trigger context ID 
><https://github.com/WICG/attribution-reporting-api/pull/1114>  
>- 
>
>Event-level reporting epsilon field 
><https://github.com/WICG/attribution-reporting-api/pull/1097> 
>- 
>
>Reserve keys starting with an underscore 
><https://github.com/WICG/attribution-reporting-api/pull/967> 
>
>
> Risks
> Interoperability and Compatibility 
>
> The first two changes (1. supporting reduced aggregatable report delays 
> and 2. supporting event-level reporting epsilon field) are fully backwards 
> compatible changes. Both of these features are optional features.
>
> The third change (3. failing registrations when encountering reserved 
> keys) is backwards incompatible. Any keys starting with an underscore will 
> cause the registration to fail. We have checked the usage of such keys, and 
> the data shows that keys that start with an underscore are not currently 
> used. Therefore this change will most likely not break any current 
> registrations or have minimal impact.
>
>   
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)? 
>
> All except 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 
>
> Chrome 121
>
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/5181611197071360
>
> 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>
>
> -- 
> 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/e20140d1-74ea-4535-b20a-9bfd89e27954n%40chromium.org
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e20140d1-74ea-4535-b20a-9bfd89e27954n%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/8bb01e48-91d4-4e05-99b1-2caccf0dc94an%40chromium.org.

[blink-dev] Intent to Ship: Attribution Reporting Features (Reduced Aggregate Delays, Event-Level Report Epsilon Field, Reserved Keys)

['Akash Nadan' via blink-dev]

Contact emails

akashna...@google.com, lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


Summary

We plan on landing the following changes to the Attribution Reporting API 
focused on:

   - 
   
   reducing transmission loss by supporting reduced aggregatable report 
   delays with trigger context ID
   - 
   
   additional API configurability by supporting an event-level reporting 
   epsilon field
   - 
   
   improve extensibility of the API by failing registrations when 
   encountering reserved keys
   
Explainer/Spec changes
   
   - Reduce aggregate delays and support trigger context ID 
    
   - 
   
   Event-level reporting epsilon field 
    
   - 
   
   Reserve keys starting with an underscore 
    
   

Risks
Interoperability and Compatibility

The first two changes (1. supporting reduced aggregatable report delays and 
2. supporting event-level reporting epsilon field) are fully backwards 
compatible changes. Both of these features are optional features.

The third change (3. failing registrations when encountering reserved keys) 
is backwards incompatible. Any keys starting with an underscore will cause 
the registration to fail. We have checked the usage of such keys, and the 
data shows that keys that start with an underscore are not currently used. 
Therefore this change will most likely not break any current registrations 
or have minimal impact.

  
Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?

All except Android WebView

Is this feature fully tested by web-platform-tests 

?

Yes

Estimated milestones

Chrome 121

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5181611197071360

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


Intent to Ship: Attribution Reporting features M120 


-- 
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/e20140d1-74ea-4535-b20a-9bfd89e27954n%40chromium.org.

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (further gating for trigger verbose debug reports)

['Akash Nadan' via blink-dev]

Hi Mike,

I've spot checked some popular publisher sites, and can see that the 
ar_debug cookie is being set on these sites. Additionally, we are planning 
on sending out an email to the attribution-reporting-api-...@chromium.org 
email group later this week, to notify them of the upcoming change.

Thanks,
Akash

On Monday, November 6, 2023 at 9:40:50 AM UTC-8 Mike Taylor wrote:

>
> On 11/3/23 6:12 PM, 'Akash Nadan' via blink-dev wrote:
>
>
> Contact emails 
>
> 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 plan on landing one change to the Attribution Reporting API focused on:
>
>- 
>
>further gating for trigger verbose debug reports
>- 
>   
>   Trigger verbose debug reports were only gated by the presence of 
>   the ar_debug cookie (3PC) at trigger registrations. To improve privacy, 
>  
>   this change further gates trigger verbose debug reports by the presence 
> of 
>   the ar_debug cookie at source registrations. Therefore, in order to 
> receive 
>   trigger verbose debug reports, the ar_debug cookie needs to be present 
> at 
>   both source and trigger registrations.
>   
> Explainer changes 
>
>- 
>
>Require ar_debug cookie presence on source registrations for trigger 
>verbose debug reports 
><https://github.com/WICG/attribution-reporting-api/pull/1088>
>
> Spec changes 
>
>- 
>
>Require ar_debug cookie presence on source registrations for trigger 
>verbose debug reports 
><https://github.com/WICG/attribution-reporting-api/pull/1088>
>
>
> Risks
> Interoperability and Compatibility 
>
> This change is backwards incompatible as developers need to ensure the 
> special ar_debug cookie is present at source registrations as well in order 
> to receive trigger verbose debug reports. We consider this less concerning 
> as it’s very likely that developers already set the ar_debug cookie on 
> source registrations for debugging purposes while third-party cookies are 
> available. Developers may expect to receive fewer trigger verbose debug 
> reports in a more privacy-preserving way.
>
> Is there any way for you to do a spot check on some sites that are known 
> to use the API to confirm this intuition? Have we done any outreach or 
> considered added something like a DevTools issue to tell developers why 
> they're no longer receiving verbose debug reports?
>
>   
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)? 
>
> All except 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 
>
> Chrome 120
>
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/5092796566601728
>
> 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>
>
> -- 
> 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/db5ba937-4a1e-4dc1-a2ef-44559f967

[blink-dev] Intent to Ship: Attribution Reporting API feature (further gating for trigger verbose debug reports)

['Akash Nadan' via blink-dev]

Contact emails

lin...@chromium.org, johni...@chromium.org

Explainer

Attribution Reporting with event-level reports 


Attribution Reporting API with Aggregatable Reports 


Aggregation Service for the Attribution Reporting API 


Specification

https://wicg.github.io/attribution-reporting-api/

Blink component

Internals > AttributionReporting 


Summary

We plan on landing one change to the Attribution Reporting API focused on:

   - 
   
   further gating for trigger verbose debug reports
   - 
  
  Trigger verbose debug reports were only gated by the presence of the 
  ar_debug cookie (3PC) at trigger registrations. To improve privacy,  this 
  change further gates trigger verbose debug reports by the presence of the 
  ar_debug cookie at source registrations. Therefore, in order to receive 
  trigger verbose debug reports, the ar_debug cookie needs to be present at 
  both source and trigger registrations.
  
Explainer changes
   
   - 
   
   Require ar_debug cookie presence on source registrations for trigger 
   verbose debug reports 
   
   
Spec changes
   
   - 
   
   Require ar_debug cookie presence on source registrations for trigger 
   verbose debug reports 
   
   

Risks
Interoperability and Compatibility

This change is backwards incompatible as developers need to ensure the 
special ar_debug cookie is present at source registrations as well in order 
to receive trigger verbose debug reports. We consider this less concerning 
as it’s very likely that developers already set the ar_debug cookie on 
source registrations for debugging purposes while third-party cookies are 
available. Developers may expect to receive fewer trigger verbose debug 
reports in a more privacy-preserving way.

  
Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?

All except Android WebView

Is this feature fully tested by web-platform-tests 

?

Yes

Estimated milestones

Chrome 120

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5092796566601728

Links to previous Intent discussions

Previous I2S: 

Intent to Ship: Attribution Reporting API 


Intent to Ship: Attribution Reporting features M117 


Intent to Ship: Attribution Reporting features M118 


Intent to Ship: Attribution Reporting features M119 


-- 
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/db5ba937-4a1e-4dc1-a2ef-44559f967a9en%40chromium.org.

[blink-dev] Intent to Ship: Attribution Reporting features (change registration limit, remove 1hr delay)

['Akash Nadan' via blink-dev]

Contact emails

johni...@chromium.org, csharri...@chromium.org

Explainer

https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md

https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md

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 


Summary

We plan on landing a few changes to the Attribution Reporting API focused 
on:

   - 
   
   Increasing limits on registration data size to allow more flexibility
   - 
   
   Removing non-privacy-bearing browser-imposed delay to allow reports to 
   be received faster
   

Spec changes
   
   1. Remove aggregation keys size limit on trigger registration 
   
   2. Remove 1-hour delay between end of report window and transmission 
   


Risks
Interoperability and Compatibility

Change (1) and (2) are both fully backwards compatible. (1) will allow 
registration of more data than before. (2) will allow reports to arrive 
more quickly than before.

  

Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?

All except Android WebView

Is this feature fully tested by web-platform-tests 

?

Yes

Estimated milestones

Chrome 118

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5089526405398528

Links to previous Intent discussions

Previous I2S: 

https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY

https://groups.google.com/a/chromium.org/g/blink-dev/c/nWF61c8xu-M/m/uMmH1ewcAQAJ

-- 
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/2a8f10f8-b85f-42eb-9059-3eacb4b0ba27n%40chromium.org.