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

[Domenic Denicola]

Thanks for being flexible on this in response to feedback!

On Wed, May 29, 2024 at 5:08 AM Anthony Garant 
wrote:

> After getting feedback, we decided to no longer pursue this feature. We
> appreciate the input.
>
> Thanks,
> Anthony
>
> On Mon, May 20, 2024 at 1:13 AM Domenic Denicola 
> wrote:
>
>> This feature seems problematic from a web architecture point of view. I
>> have added a comment on
>> https://github.com/WICG/attribution-reporting-api/issues/1202 .
>>
>> Getting full review from parties like the TAG or other browsers probably
>> does not make sense for this kind of a small change to the Attribution
>> Reporting Feature (which has had its own previous reviews). But, there are
>> several experts in the Fetch and HTTP space who I would like to give a
>> chance to comment on this, as I am especially worried about the precedent
>> it sets. I have tagged them in the above issue.
>>
>> On Sat, May 18, 2024 at 1:23 AM 'Akash Nadan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> 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
>>> 

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

['Anthony Garant' via blink-dev]

After getting feedback, we decided to no longer pursue this feature. We
appreciate the input.

Thanks,
Anthony

On Mon, May 20, 2024 at 1:13 AM Domenic Denicola 
wrote:

> This feature seems problematic from a web architecture point of view. I
> have added a comment on
> https://github.com/WICG/attribution-reporting-api/issues/1202 .
>
> Getting full review from parties like the TAG or other browsers probably
> does not make sense for this kind of a small change to the Attribution
> Reporting Feature (which has had its own previous reviews). But, there are
> several experts in the Fetch and HTTP space who I would like to give a
> chance to comment on this, as I am especially worried about the precedent
> it sets. I have tagged them in the above issue.
>
> On Sat, May 18, 2024 at 1:23 AM 'Akash Nadan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> 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
>> 

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

[Domenic Denicola]

This feature seems problematic from a web architecture point of view. I
have added a comment on
https://github.com/WICG/attribution-reporting-api/issues/1202 .

Getting full review from parties like the TAG or other browsers probably
does not make sense for this kind of a small change to the Attribution
Reporting Feature (which has had its own previous reviews). But, there are
several experts in the Fetch and HTTP space who I would like to give a
chance to comment on this, as I am especially worried about the precedent
it sets. I have tagged them in the above issue.

On Sat, May 18, 2024 at 1:23 AM 'Akash Nadan' via blink-dev <
blink-dev@chromium.org> wrote:

> 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