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

[Nan Lin]

On Fri, Jul 26, 2024 at 10:30 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Thanks!! Do we have any stats RE how often the limits are exceeded? Is it
> fair to assume it's a rare occasion?
>
The metric shows that the limits are exceeded rarely, and the change is
based on feedbacks of a few ad-techs that exceed the limit.

>
> On Fri, Jul 26, 2024 at 3:36 PM Nan Lin  wrote:
>
>> Thanks Yoav. Please see the inline response.
>>
>> Best,
>> Nan
>>
>> On Fri, Jul 26, 2024 at 5:09 PM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>> On Thu, Jul 25, 2024 at 11:24 PM Chris Harrelson 
>>> wrote:
>>>
>>>> LGTM2
>>>>
>>>> On Mon, Jul 22, 2024 at 11:42 AM Mike Taylor 
>>>> wrote:
>>>>
>>>>> > This change will not cause any site breakage or change for end users
>>>>> of Chrome.
>>>>>
>>>>> LGTM1
>>>>> On 7/11/24 3:48 PM, 'Akash Nadan' via blink-dev wrote:
>>>>>
>>>>> Contact emails
>>>>>
>>>>> akashna...@google.com, lin...@chromium.org, johni...@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 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}.
>>>>>-
>&

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

[Nan Lin]

Thanks Yoav. Please see the inline response.

Best,
Nan

On Fri, Jul 26, 2024 at 5:09 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
> On Thu, Jul 25, 2024 at 11:24 PM Chris Harrelson 
> wrote:
>
>> LGTM2
>>
>> On Mon, Jul 22, 2024 at 11:42 AM Mike Taylor 
>> wrote:
>>
>>> > This change will not cause any site breakage or change for end users
>>> of Chrome.
>>>
>>> LGTM1
>>> On 7/11/24 3:48 PM, 'Akash Nadan' via blink-dev 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
>>> 
>>>
>>> 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.
>>>
>>> Can you expand on that?
> What would ad-tech folks need to do differently? Am I right to assume that
> this would cause attribution breakage only in cases that are currently
> exceeding the limit?
>
That's correct that this would only affect ad-techs that are currently
exceeding the limit. No change is needed if they want to use the new FIFO
behavior. Otherwise, they would need to set the destination priority for
the source registrations properly to prioritize destinations and achieve
the desired behavior, e.g. the previous LIFO behavior.

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

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

[Nan Lin]

Hi Yoav,

The list of debugging signals is part of the spec:

https://wicg.github.io/attribution-reporting-api/#source-debug-data-type
https://wicg.github.io/attribution-reporting-api/#trigger-debug-data-type

Thanks,
Nan

On Wednesday, June 12, 2024 at 4:27:41 AM UTC-4 Yoav Weiss wrote:

> On Tue, Jun 11, 2024 at 7:43 PM Akash Nadan  wrote:
>
>> 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
>>
>
> Thanks! Should that be part of the spec?
>  
>
>>
>> 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 
>> 
>> ).
>>
>> 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 
 

 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. 

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

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

[Nan Lin]

Hi Philip,

These tests are for Attribution Reporting API, but not explicitly related
to the features in this intent. We do expect that all the tests there will
be passing.

Those 3 tests involve writing to and reading from the stash, which probably
causes the timeout flakiness.

As currently the rate limits are not configurable in the web platform tests
yet, we don't add web platform tests for the new features which depend on
the rate limits.

Thanks,
Nan

On Wed, Apr 24, 2024 at 11:41 AM Philip Jägenstedt 
wrote:

> Hi Akash,
>
> Are https://wpt.fyi/results/attribution-reporting all of the tests for
> this feature and these changes? Do you expect that all of the tests there
> will be passing?
>
> I see that 3 of the tests time out which make it harder to understand the
> status. Is it possible to make these tests fail fast with more details
> about why they fail?
>
> Best regards,
> Philip
>
> On Fri, Apr 19, 2024 at 9:51 PM '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 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: A

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

[Nan Lin]

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

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

On Tue, Feb 13, 2024 at 7:35 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Tue, Feb 13, 2024 at 12:10 PM Nan Lin  wrote:
>
>> Hi Yoav,
>>
>> On Tue, Feb 13, 2024 at 3:10 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Fri, Feb 9, 2024 at 5:59 AM Nan Lin  wrote:
>>>
>>>> Hi Yoav,
>>>>
>>>> On Thu, Feb 8, 2024 at 11:09 PM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 7, 2024 at 12:58 PM Nan Lin  wrote:
>>>>>
>>>>>> Thanks Mike.
>>>>>>
>>>>>> On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor 
>>>>>> wrote:
>>>>>>
>>>>>>> On 2/6/24 3:59 AM, Nan Lin wrote:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> Thanks for reviewing. Please see responses inline.
>>>>>>>
>>>>>>> Nan
>>>>>>>
>>>>>>> On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Nan,
>>>>>>>> On 2/2/24 5:00 AM, Nan Lin wrote:
>>>>>>>>
>>>>>>>> Contact emails
>>>>>>>>
>>>>>>>> lin...@chromium.org, johni...@chromium.org
>>>>>>>>
>>>>>>>> Explainer
>>>>>>>>
>>>>>>>> Cross App and Web Attribution Measurement
>>>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>
>>>>>>>>
>>>>>>>> Specification
>>>>>>>>
>>>>>>>> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> This is an extension to the Attribution Reporting API
>>>>>>>> <https://github.com/WICG/conversion-measurement-api> that has
>>>>>>>> already shipped.
>>>>>>>>
>>>>>>>> Currently, the Attribution Reporting API
>>>>>>>> <https://github.com/WICG/conversion-measurement-api> supports
>>>>>>>> attributing events within a single browser instance. This proposal 
>>>>>>>> expands
>>>>>>>> the scope of attribution to allow attributing conversions that happen 
>>>>>>>> on
>>>>>>>> the web to events that happen off the browser on the same device, 
>>>>>>>> within
>>>>>>>> other applications such as mobile applications, or vice-versa.
>>>>>>>>
>>>>>>>> The proposal here leverages OS-level support for attribution. In
>>>>>>>> particular, it gives the developer an option to allow events on the 
>>>>>>>> mobile
>>>>>>>> web to be delegated to Android’s Privacy Sandbox
>>>>>>>> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
>>>>>>>> although support for other platforms could also be implemented in the
>>>>>>>> future.
>>>>>>>>
>>>>>>>> Note that with this proposal new features shipped by the OS may be
>>>>>>>> implicitly supported without web API changes. For example, Android may 
>>>>>>>> ship
>>>>>>>> support for new registration fields not supported in the existing
>>>>>>>> Attribution Reporting API. Once a developer elects to delegate events 
>>>>>>>> to
>>>>>>>> the OS, there is no way web-visible to introspect this.
>>>>>>>>
>>>>>>>> Could you help me better understand the implications of this? Does
>>>>>>>> it just mean that debugging becomes challenging for new fields, or are
>>>>>>>> there other possible implications depending on new OS features? Or 
>>>>>>>> possibly
>>>>>>>> the web API lags behind what is possible via the pl

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Hi Yoav,

On Tue, Feb 13, 2024 at 3:10 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Fri, Feb 9, 2024 at 5:59 AM Nan Lin  wrote:
>
>> Hi Yoav,
>>
>> On Thu, Feb 8, 2024 at 11:09 PM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 7, 2024 at 12:58 PM Nan Lin  wrote:
>>>
>>>> Thanks Mike.
>>>>
>>>> On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor 
>>>> wrote:
>>>>
>>>>> On 2/6/24 3:59 AM, Nan Lin wrote:
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> Thanks for reviewing. Please see responses inline.
>>>>>
>>>>> Nan
>>>>>
>>>>> On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor 
>>>>> wrote:
>>>>>
>>>>>> Hi Nan,
>>>>>> On 2/2/24 5:00 AM, Nan Lin wrote:
>>>>>>
>>>>>> Contact emails
>>>>>>
>>>>>> lin...@chromium.org, johni...@chromium.org
>>>>>>
>>>>>> Explainer
>>>>>>
>>>>>> Cross App and Web Attribution Measurement
>>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>
>>>>>>
>>>>>> Specification
>>>>>>
>>>>>> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> This is an extension to the Attribution Reporting API
>>>>>> <https://github.com/WICG/conversion-measurement-api> that has
>>>>>> already shipped.
>>>>>>
>>>>>> Currently, the Attribution Reporting API
>>>>>> <https://github.com/WICG/conversion-measurement-api> supports
>>>>>> attributing events within a single browser instance. This proposal 
>>>>>> expands
>>>>>> the scope of attribution to allow attributing conversions that happen on
>>>>>> the web to events that happen off the browser on the same device, within
>>>>>> other applications such as mobile applications, or vice-versa.
>>>>>>
>>>>>> The proposal here leverages OS-level support for attribution. In
>>>>>> particular, it gives the developer an option to allow events on the 
>>>>>> mobile
>>>>>> web to be delegated to Android’s Privacy Sandbox
>>>>>> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
>>>>>> although support for other platforms could also be implemented in the
>>>>>> future.
>>>>>>
>>>>>> Note that with this proposal new features shipped by the OS may be
>>>>>> implicitly supported without web API changes. For example, Android may 
>>>>>> ship
>>>>>> support for new registration fields not supported in the existing
>>>>>> Attribution Reporting API. Once a developer elects to delegate events to
>>>>>> the OS, there is no way web-visible to introspect this.
>>>>>>
>>>>>> Could you help me better understand the implications of this? Does it
>>>>>> just mean that debugging becomes challenging for new fields, or are there
>>>>>> other possible implications depending on new OS features? Or possibly the
>>>>>> web API lags behind what is possible via the platform, until the web API
>>>>>> catches up formally?
>>>>>>
>>>>>
>>>>> It’s not about debugging. Currently the web API and the Android’s
>>>>> implementation of the Attribution Reporting API are expected to be
>>>>> interoperable. However it’s possible that Android may ship support for new
>>>>> registration fields in the OS-level API, which may or may not be supported
>>>>> in the web API. The web API may lag behind, or even not implement the new
>>>>> features at all. Once the event is delegated to the OS, the attribution
>>>>> registration will be handled by the OS and possibly using the new features
>>>>> in its API.
>>>>>
>>>>>
>>> Can you provide an example of how future OS-level changes can result in
>>> semantics changes for the web exposed A

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Hi Yoav,

On Thu, Feb 8, 2024 at 11:09 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
>
>
> On Wed, Feb 7, 2024 at 12:58 PM Nan Lin  wrote:
>
>> Thanks Mike.
>>
>> On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor 
>> wrote:
>>
>>> On 2/6/24 3:59 AM, Nan Lin wrote:
>>>
>>> Hi Mike,
>>>
>>> Thanks for reviewing. Please see responses inline.
>>>
>>> Nan
>>>
>>> On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor 
>>> wrote:
>>>
>>>> Hi Nan,
>>>> On 2/2/24 5:00 AM, Nan Lin wrote:
>>>>
>>>> Contact emails
>>>>
>>>> lin...@chromium.org, johni...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>> Cross App and Web Attribution Measurement
>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>
>>>>
>>>> Specification
>>>>
>>>> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
>>>>
>>>> Summary
>>>>
>>>> This is an extension to the Attribution Reporting API
>>>> <https://github.com/WICG/conversion-measurement-api> that has already
>>>> shipped.
>>>>
>>>> Currently, the Attribution Reporting API
>>>> <https://github.com/WICG/conversion-measurement-api> supports
>>>> attributing events within a single browser instance. This proposal expands
>>>> the scope of attribution to allow attributing conversions that happen on
>>>> the web to events that happen off the browser on the same device, within
>>>> other applications such as mobile applications, or vice-versa.
>>>>
>>>> The proposal here leverages OS-level support for attribution. In
>>>> particular, it gives the developer an option to allow events on the mobile
>>>> web to be delegated to Android’s Privacy Sandbox
>>>> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
>>>> although support for other platforms could also be implemented in the
>>>> future.
>>>>
>>>> Note that with this proposal new features shipped by the OS may be
>>>> implicitly supported without web API changes. For example, Android may ship
>>>> support for new registration fields not supported in the existing
>>>> Attribution Reporting API. Once a developer elects to delegate events to
>>>> the OS, there is no way web-visible to introspect this.
>>>>
>>>> Could you help me better understand the implications of this? Does it
>>>> just mean that debugging becomes challenging for new fields, or are there
>>>> other possible implications depending on new OS features? Or possibly the
>>>> web API lags behind what is possible via the platform, until the web API
>>>> catches up formally?
>>>>
>>>
>>> It’s not about debugging. Currently the web API and the Android’s
>>> implementation of the Attribution Reporting API are expected to be
>>> interoperable. However it’s possible that Android may ship support for new
>>> registration fields in the OS-level API, which may or may not be supported
>>> in the web API. The web API may lag behind, or even not implement the new
>>> features at all. Once the event is delegated to the OS, the attribution
>>> registration will be handled by the OS and possibly using the new features
>>> in its API.
>>>
>>>
> Can you provide an example of how future OS-level changes can result in
> semantics changes for the web exposed API?
> Is the information flow here strictly from the web API to the OS API? Or
> is it possible for the OS attribution to flow into the web? (e.g. if an ad
> on a native app ends up landing on a website)
>

Please see my response below for the workflow to delegate a web event to
the OS.

For example, the OS API implements a new feature, and allows developers to
opt in this feature with a new field in the
Attribution-Reporting-Register-Source/Trigger JSON.

The web API only delegates the registration url (to which the OS API will
ping) to the OS API, and the registration url can respond to OS API ping
with the new field in the Attribution Reporting response headers to opt in
the new feature implemented by the OS API.

All the cross app web attribution is handled by the OS API. For app to web
flow (an ad on a native app ends up landing on a website), the reporting
origin can respond with Attribution-Reporting-Register-OS-Trigger 

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Also to clarify, we will remove the origin trial requirement for all
platforms.

The feature will be shipped on all platforms except for Android WebView.
Android WebView may have a slower rollout using Finch.

Thanks,
Nan

On Fri, Feb 2, 2024 at 8:00 AM Nan Lin  wrote:

> Contact emails
>
> lin...@chromium.org, johni...@chromium.org
>
> Explainer
>
> Cross App and Web Attribution Measurement
> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
>
> Summary
>
> This is an extension to the Attribution Reporting API
> <https://github.com/WICG/conversion-measurement-api> that has already
> shipped.
>
> Currently, the Attribution Reporting API
> <https://github.com/WICG/conversion-measurement-api> supports attributing
> events within a single browser instance. This proposal expands the scope of
> attribution to allow attributing conversions that happen on the web to
> events that happen off the browser on the same device, within other
> applications such as mobile applications, or vice-versa.
>
> The proposal here leverages OS-level support for attribution. In
> particular, it gives the developer an option to allow events on the mobile
> web to be delegated to Android’s Privacy Sandbox
> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
> although support for other platforms could also be implemented in the
> future.
>
> Note that with this proposal new features shipped by the OS may be
> implicitly supported without web API changes. For example, Android may ship
> support for new registration fields not supported in the existing
> Attribution Reporting API. Once a developer elects to delegate events to
> the OS, there is no way web-visible to introspect this.
>
>
> Blink component
>
> Internals > AttributionReporting
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938
>
> TAG review status
>
> Pending
>
> Risks
>
>  Interoperability and Compatibility
>
> See the Attribution Reporting API I2S
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY> for
> information on the other general measurement proposals in this space.
>
> Private Click Measurement in Safari supports app to web measurement (
> https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement).
> On iOS, some web to app measurement is supported via SKAdNetwork (
> https://developer.apple.com/documentation/skadnetworkforwebads). There is
> currently no interop between these proposals and the cross app web API for
> Attribution Reporting.
>
> Gecko: No official position (
> https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889
> )
>
> WebKit: No official position (
> https://github.com/WebKit/standards-positions/issues/307)
>
> Web developers: Positive. Some testers are currently implementing and
> providing feedback and more usage expected in 2024. Developers have
> requested expansion of coverage of this feature (example:
> https://github.com/WICG/attribution-reporting-api/issues/1125).
>
> Debuggability
>
> The Attribution Reporting API utilizes DevTools and an internal page
> (chrome://attribution-internals) to facilitate testing and integration. The
> debugging information for OS registrations from Chrome will be displayed in
> DevTools and the internal page as well.
> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#optional-transitional-debugging-reports>
>
> Additionally, debug reports
> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md#optional-debugging-reports>
> are supported for OS registrations. The Attribution Reporting API for
> Android also implements a similar debugging reports framework
> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution-app-to-web#transitional-debugging>
> to facilitate cross app and web testing.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> The Attribution-Reporting-Support header is supported on all platforms.
> Today, only Android offers a native Attribution Reporting API, so the
> ability to register with the OS is only supported on those platforms
> (Android and Android WebView).
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromi

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Thanks Mike.

On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor  wrote:

> On 2/6/24 3:59 AM, Nan Lin wrote:
>
> Hi Mike,
>
> Thanks for reviewing. Please see responses inline.
>
> Nan
>
> On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor  wrote:
>
>> Hi Nan,
>> On 2/2/24 5:00 AM, Nan Lin wrote:
>>
>> Contact emails
>>
>> lin...@chromium.org, johni...@chromium.org
>>
>> Explainer
>>
>> Cross App and Web Attribution Measurement
>> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>
>>
>> Specification
>>
>> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
>>
>> Summary
>>
>> This is an extension to the Attribution Reporting API
>> <https://github.com/WICG/conversion-measurement-api> that has already
>> shipped.
>>
>> Currently, the Attribution Reporting API
>> <https://github.com/WICG/conversion-measurement-api> supports
>> attributing events within a single browser instance. This proposal expands
>> the scope of attribution to allow attributing conversions that happen on
>> the web to events that happen off the browser on the same device, within
>> other applications such as mobile applications, or vice-versa.
>>
>> The proposal here leverages OS-level support for attribution. In
>> particular, it gives the developer an option to allow events on the mobile
>> web to be delegated to Android’s Privacy Sandbox
>> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
>> although support for other platforms could also be implemented in the
>> future.
>>
>> Note that with this proposal new features shipped by the OS may be
>> implicitly supported without web API changes. For example, Android may ship
>> support for new registration fields not supported in the existing
>> Attribution Reporting API. Once a developer elects to delegate events to
>> the OS, there is no way web-visible to introspect this.
>>
>> Could you help me better understand the implications of this? Does it
>> just mean that debugging becomes challenging for new fields, or are there
>> other possible implications depending on new OS features? Or possibly the
>> web API lags behind what is possible via the platform, until the web API
>> catches up formally?
>>
>
> It’s not about debugging. Currently the web API and the Android’s
> implementation of the Attribution Reporting API are expected to be
> interoperable. However it’s possible that Android may ship support for new
> registration fields in the OS-level API, which may or may not be supported
> in the web API. The web API may lag behind, or even not implement the new
> features at all. Once the event is delegated to the OS, the attribution
> registration will be handled by the OS and possibly using the new features
> in its API.
>
> Thanks for the response! I'm still trying to understand what a
> registration field is in the context of this API - is that a possible
> future item added to the OS registration struct in
> https://wicg.github.io/attribution-reporting-api/#os-registration?
> (Apologies, I can't find any reference to "registration field" in the draft
> spec...).
>

Sorry for the confusion. The registration field in the context of the
Attribution Reporting API is a JSON field in the
Attribution-Reporting-Register-Source (
https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#registering-attribution-sources)
and Attribution-Reporting-Register-Trigger (
https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#triggering-attribution
) headers. Android also implements the Attribution Reporting API that
supports header-based registration (
https://developer.android.com/design-for-safety/privacy-sandbox/attribution#enroll-ad-tech-platform
).

The workflow to delegate a web event to the OS is as follows:
1. In the web API, the reporting origin can respond with a list of
registration urls in the Attribution-Reporting-Register-OS-Source and
Attribution-Reporting-Register-OS-Trigger headers.
2.  The browser delegates the registration urls to the OS-level API.
3. The OS-level API makes a request to the registration url.
4. The registration url responds with the
Attribution-Reporting-Register-Source or
Attribution-Reporting-Register-Trigger header, which is handled by the
OS-level API.

If the OS-level API supports a new registration field in the
Attribution-Reporting-Register-Source or
Attribution-Reporting-Register-Trigger JSON, in step 4 above the
registration url could respond with the new registration field for new
features supported in the OS-level API but not the web API.

Hope that clarifies.


&

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Hi Mike,

Thanks for reviewing. Please see responses inline.

Nan

On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor  wrote:

> Hi Nan,
> On 2/2/24 5:00 AM, Nan Lin wrote:
>
> Contact emails
>
> lin...@chromium.org, johni...@chromium.org
>
> Explainer
>
> Cross App and Web Attribution Measurement
> <https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
>
> Summary
>
> This is an extension to the Attribution Reporting API
> <https://github.com/WICG/conversion-measurement-api> that has already
> shipped.
>
> Currently, the Attribution Reporting API
> <https://github.com/WICG/conversion-measurement-api> supports attributing
> events within a single browser instance. This proposal expands the scope of
> attribution to allow attributing conversions that happen on the web to
> events that happen off the browser on the same device, within other
> applications such as mobile applications, or vice-versa.
>
> The proposal here leverages OS-level support for attribution. In
> particular, it gives the developer an option to allow events on the mobile
> web to be delegated to Android’s Privacy Sandbox
> <https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
> although support for other platforms could also be implemented in the
> future.
>
> Note that with this proposal new features shipped by the OS may be
> implicitly supported without web API changes. For example, Android may ship
> support for new registration fields not supported in the existing
> Attribution Reporting API. Once a developer elects to delegate events to
> the OS, there is no way web-visible to introspect this.
>
> Could you help me better understand the implications of this? Does it just
> mean that debugging becomes challenging for new fields, or are there other
> possible implications depending on new OS features? Or possibly the web API
> lags behind what is possible via the platform, until the web API catches up
> formally?
>

It’s not about debugging. Currently the web API and the Android’s
implementation of the Attribution Reporting API are expected to be
interoperable. However it’s possible that Android may ship support for new
registration fields in the OS-level API, which may or may not be supported
in the web API. The web API may lag behind, or even not implement the new
features at all. Once the event is delegated to the OS, the attribution
registration will be handled by the OS and possibly using the new features
in its API. This can happen without web API change and there’s no way
web-visible to introspect this.


> Blink component
>
> Internals > AttributionReporting
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938
>
> TAG review status
>
> Pending
>
> Risks
>
>  Interoperability and Compatibility
>
> See the Attribution Reporting API I2S
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY> for
> information on the other general measurement proposals in this space.
>
> Private Click Measurement in Safari supports app to web measurement (
> https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement).
> On iOS, some web to app measurement is supported via SKAdNetwork (
> https://developer.apple.com/documentation/skadnetworkforwebads). There is
> currently no interop between these proposals and the cross app web API for
> Attribution Reporting.
>
> If Blink ever ships on iOS (at least in the EU, given recent announcements
> by Apple), would it be possible to expect interop between iOS and Android?
>

There’s no official position from WebKit yet, but there’s some concern on
the interoperability between Safari’s Private Click Measurement and the
Attribution Reporting API. We may expect similar concerns on supporting
Attribution Reporting API on iOS, therefore would not expect
interoperability between iOS and Android in the short term.


>
> Gecko: No official position (
> https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889
> )
>
> Any reason we didn't file a new issue w/ Mozilla (or TAG...), but we did
> with WebKit?
>

We initially requested feedbacks for TAG, Mozilla and Webkit all in the
comments of the Attribution Reporting API requests as it’s an extension of
that API. We were then suggested by WebKit folks to file a new issue
instead as it’s easier for their system to handle new requests.


>
> WebKit: No official position (
> htt

[blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Contact emails

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

Explainer

Cross App and Web Attribution Measurement


Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API
 that has already
shipped.

Currently, the Attribution Reporting API
 supports attributing
events within a single browser instance. This proposal expands the scope of
attribution to allow attributing conversions that happen on the web to
events that happen off the browser on the same device, within other
applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In
particular, it gives the developer an option to allow events on the mobile
web to be delegated to Android’s Privacy Sandbox
,
although support for other platforms could also be implemented in the
future.

Note that with this proposal new features shipped by the OS may be
implicitly supported without web API changes. For example, Android may ship
support for new registration fields not supported in the existing
Attribution Reporting API. Once a developer elects to delegate events to
the OS, there is no way web-visible to introspect this.


Blink component

Internals > AttributionReporting



TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

TAG review status

Pending

Risks

 Interoperability and Compatibility

See the Attribution Reporting API I2S
 for
information on the other general measurement proposals in this space.

Private Click Measurement in Safari supports app to web measurement (
https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement).
On iOS, some web to app measurement is supported via SKAdNetwork (
https://developer.apple.com/documentation/skadnetworkforwebads). There is
currently no interop between these proposals and the cross app web API for
Attribution Reporting.

Gecko: No official position (
https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889
)

WebKit: No official position (
https://github.com/WebKit/standards-positions/issues/307)

Web developers: Positive. Some testers are currently implementing and
providing feedback and more usage expected in 2024. Developers have
requested expansion of coverage of this feature (example:
https://github.com/WICG/attribution-reporting-api/issues/1125).

Debuggability

The Attribution Reporting API utilizes DevTools and an internal page
(chrome://attribution-internals) to facilitate testing and integration. The
debugging information for OS registrations from Chrome will be displayed in
DevTools and the internal page as well.


Additionally, debug reports

are supported for OS registrations. The Attribution Reporting API for
Android also implements a similar debugging reports framework

to facilitate cross app and web testing.


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

The Attribution-Reporting-Support header is supported on all platforms.
Today, only Android offers a native Attribution Reporting API, so the
ability to register with the OS is only supported on those platforms
(Android and Android WebView).

Is this feature fully tested by web-platform-tests

?

The Attribution-Reporting-Support header is tested by web platform tests,
but the integration with OS is not as web platform tests are not supported
for Android.

Requires code in //chrome?

False

Estimated milestones

Chrome 123

Launch bug

https://launch.corp.google.com/launch/4238495

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4994430156668928

Links to previous Intent discussions

Cross App and Web Attribution Measurement Intent to Experiment


Cross App and Web Attribution Measurement Intent to Extend Experiment


Attribution Reporting API Intent to Ship

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Nan Lin]

A few more inline comments, thanks!

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  wrote:

> Hi Nan, a few questions inline:
> On 10/6/23 8:45 AM, Nan Lin wrote:
>
> Contact emails
>
> lin...@chromium.org, johni...@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:
>
>-
>
>Multiple cloud providers support for aggregate reporting, supporting
>AWS and GCP
>-
>
>   **Note**: This change will also affect Private Aggregation API
>   <https://github.com/patcg-individual-drafts/private-aggregation-api>’s
>   aggregatable reports by adding a new top-level field
>   aggregation_coordinator_origin.
>
> Does this proposed change correspond to the TODO at the bottom of
> https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service?
> I think no, but I'm not entirely sure.
>
The TODO is actually related to the proposed change. We have a pending PR
<https://github.com/WICG/attribution-reporting-api/pull/1068> to expose the
allowlist of the aggregation coordinator origins that will be used to
verify the aggregation coordinator origin specified in the API surface. Any
origins not included in the allowlist will be rejected.

> In the Private Aggregation API,
> https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports
> seems to define this aggregation_coordinator_origin but there's an open
> inline spec issue just after (pointing to a closed issue 78). Is that
> entirely resolved, or are there still open questions that may change the
> API?
>
This is not resolved yet and the proposed spec change is here
<https://github.com/patcg-individual-drafts/private-aggregation-api/pull/106>.
The aggregation coordinator selection is not supported in Private
Aggregation API yet, which is being spec'ed and implemented,
but the aggregatable reports created by the API will include the
aggregation_coordinator_origin field with the default value.

> Explainer changes
>
>-
>
>Add aggregation coordinator identifier to support multiple cloud
>providers <https://github.com/WICG/attribution-reporting-api/pull/622>
>-
>
>Use aggregation coordinator origin instead of identifier
><https://github.com/WICG/attribution-reporting-api/pull/829>
>
> Spec changes
>
>-
>
>Add aggregation coordinator identifier to aggregatable report
><https://github.com/WICG/attribution-reporting-api/pull/728>
>-
>
>Use aggregation coordinator origin instead of identifier
><https://github.com/WICG/attribution-reporting-api/pull/829>
>-
>
>Add aggregation_coordinator_origin to PAA serialized report
>
> <https://github.com/patcg-individual-drafts/private-aggregation-api/pull/105>
>
>
> Risks
> Interoperability and Compatibility
>
> The change is backwards compatible, and allows developers to select the
> deployment option for the aggregation service. By default, the AWS
> coordinator will be used (the existing behavior), and the public keys will
> be served on both old and new endpoints during the transition period.
>
> Can you say more about this transition period? Is this related to
> "transitional debugging reports", or something else entirely?
>
>
> 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 119
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5197591256236032
>
> Links to previous Intent discussions
>
> Previous I2S:
>
> Intent to Ship: Attribution Reporting API
> <https://groups.google.com/a/chromium.org/g/b

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Nan Lin]

Thanks Mike, please see the inline comment.

On Mon, Oct 16, 2023 at 10:41 AM Mike Taylor  wrote:

> Hi Nan, a few questions inline:
> On 10/6/23 8:45 AM, Nan Lin wrote:
>
> Contact emails
>
> lin...@chromium.org, johni...@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:
>
>-
>
>Multiple cloud providers support for aggregate reporting, supporting
>AWS and GCP
>-
>
>   **Note**: This change will also affect Private Aggregation API
>   <https://github.com/patcg-individual-drafts/private-aggregation-api>’s
>   aggregatable reports by adding a new top-level field
>   aggregation_coordinator_origin.
>
> Does this proposed change correspond to the TODO at the bottom of
> https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#data-processing-through-a-secure-aggregation-service?
> I think no, but I'm not entirely sure.
>
> In the Private Aggregation API,
> https://patcg-individual-drafts.github.io/private-aggregation-api/#serializing-reports
> seems to define this aggregation_coordinator_origin but there's an open
> inline spec issue just after (pointing to a closed issue 78). Is that
> entirely resolved, or are there still open questions that may change the
> API?
>
> Explainer changes
>
>-
>
>Add aggregation coordinator identifier to support multiple cloud
>providers <https://github.com/WICG/attribution-reporting-api/pull/622>
>-
>
>Use aggregation coordinator origin instead of identifier
><https://github.com/WICG/attribution-reporting-api/pull/829>
>
> Spec changes
>
>-
>
>Add aggregation coordinator identifier to aggregatable report
><https://github.com/WICG/attribution-reporting-api/pull/728>
>-
>
>Use aggregation coordinator origin instead of identifier
><https://github.com/WICG/attribution-reporting-api/pull/829>
>-
>
>Add aggregation_coordinator_origin to PAA serialized report
>
> <https://github.com/patcg-individual-drafts/private-aggregation-api/pull/105>
>
>
> Risks
> Interoperability and Compatibility
>
> The change is backwards compatible, and allows developers to select the
> deployment option for the aggregation service. By default, the AWS
> coordinator will be used (the existing behavior), and the public keys will
> be served on both old and new endpoints during the transition period.
>
> Can you say more about this transition period? Is this related to
> "transitional debugging reports", or something else entirely?
>

This is about the transition period for releasing multiple cloud providers
support. M119+ is going to fetch public keys from the new endpoint, whereas
older versions still fetch from the old endpoint.
Therefore to ensure not breaking older versions, the public keys will be
served on both endpoints for some time after M119 release.

>
> 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 119
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5197591256236032
>
> 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>
>
> --
> You received this message because you are subscribed to th

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Nan Lin]

Thanks Chris.

I kicked off those reviews in chromestatus, and will ping this thread when
those reviews are complete.

Thanks,
Nan

On Wed, Oct 11, 2023 at 10:53 AM Chris Harrelson 
wrote:

> Please fill out the 5 other review categories (security, privacy, etc) in
> chromestatus. Those will need to be started before the API owners can
> review.
>
>
> On Fri, Oct 6, 2023 at 5:46 AM Nan Lin  wrote:
>
>> Contact emails
>>
>> lin...@chromium.org, johni...@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:
>>
>>-
>>
>>Multiple cloud providers support for aggregate reporting, supporting
>>AWS and GCP
>>-
>>
>>   **Note**: This change will also affect Private Aggregation API
>>   <https://github.com/patcg-individual-drafts/private-aggregation-api>’s
>>   aggregatable reports by adding a new top-level field
>>   aggregation_coordinator_origin.
>>
>> Explainer changes
>>
>>-
>>
>>Add aggregation coordinator identifier to support multiple cloud
>>providers <https://github.com/WICG/attribution-reporting-api/pull/622>
>>-
>>
>>Use aggregation coordinator origin instead of identifier
>><https://github.com/WICG/attribution-reporting-api/pull/829>
>>
>> Spec changes
>>
>>-
>>
>>Add aggregation coordinator identifier to aggregatable report
>><https://github.com/WICG/attribution-reporting-api/pull/728>
>>-
>>
>>Use aggregation coordinator origin instead of identifier
>><https://github.com/WICG/attribution-reporting-api/pull/829>
>>-
>>
>>Add aggregation_coordinator_origin to PAA serialized report
>>
>> <https://github.com/patcg-individual-drafts/private-aggregation-api/pull/105>
>>
>>
>> Risks
>> Interoperability and Compatibility
>>
>> The change is backwards compatible, and allows developers to select the
>> deployment option for the aggregation service. By default, the AWS
>> coordinator will be used (the existing behavior), and the public keys will
>> be served on both old and new endpoints during the transition period.
>>
>>
>> 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 119
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5197591256236032
>>
>> 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>
>>
>> --
>> 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/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%40mail.gmail.com?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/CA%2BVrgP%3DzjLF2Qmp4k64LUiNnpS1GT7w5VjEYD44fXsbrUS7LLg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

['Nan Lin' via blink-dev]

Hi Chris,

I don't see the other review categories (security, privacy, etc) in the
Prepare to Ship stage in chromestatus.
How shall I edit and request review for those? Thanks.

Best,
Nan

On Wed, Oct 11, 2023 at 10:53 AM Chris Harrelson 
wrote:

> Please fill out the 5 other review categories (security, privacy, etc) in
> chromestatus. Those will need to be started before the API owners can
> review.
>
>
> On Fri, Oct 6, 2023 at 5:46 AM Nan Lin  wrote:
>
>> Contact emails
>>
>> lin...@chromium.org, johni...@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:
>>
>>-
>>
>>Multiple cloud providers support for aggregate reporting, supporting
>>AWS and GCP
>>-
>>
>>   **Note**: This change will also affect Private Aggregation API
>>   <https://github.com/patcg-individual-drafts/private-aggregation-api>’s
>>   aggregatable reports by adding a new top-level field
>>   aggregation_coordinator_origin.
>>
>> Explainer changes
>>
>>-
>>
>>Add aggregation coordinator identifier to support multiple cloud
>>providers <https://github.com/WICG/attribution-reporting-api/pull/622>
>>-
>>
>>Use aggregation coordinator origin instead of identifier
>><https://github.com/WICG/attribution-reporting-api/pull/829>
>>
>> Spec changes
>>
>>-
>>
>>Add aggregation coordinator identifier to aggregatable report
>><https://github.com/WICG/attribution-reporting-api/pull/728>
>>-
>>
>>Use aggregation coordinator origin instead of identifier
>><https://github.com/WICG/attribution-reporting-api/pull/829>
>>-
>>
>>Add aggregation_coordinator_origin to PAA serialized report
>>
>> <https://github.com/patcg-individual-drafts/private-aggregation-api/pull/105>
>>
>>
>> Risks
>> Interoperability and Compatibility
>>
>> The change is backwards compatible, and allows developers to select the
>> deployment option for the aggregation service. By default, the AWS
>> coordinator will be used (the existing behavior), and the public keys will
>> be served on both old and new endpoints during the transition period.
>>
>>
>> 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 119
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5197591256236032
>>
>> 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>
>>
>> --
>> 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/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%40mail.gmail.com?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/CAO%3Dtj9GJbp%3DZbbJQK%2BQQoHaaRRG0_p1S3%2BUAPH6SQ82HgUvZcw%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Origin Trial: Cross App and Web Attribution Measurement M120-M123

[Nan Lin]

Thanks Chris.

Since the original OT request, we have spec'd most of the cross app and web
algorithms:
https://wicg.github.io/attribution-reporting-api/#cross-app-and-web.

The Cross App and Web Attribution Reporting is an extension to the
Attribution Reporting API (shipped in M115, I2S
), for
which the TAG review 
is in progress, and signals from other implementations have been requested.
We plan to request reviews and signals for this particular extension as
comments to those requests soon.

Here are the feedbacks from the current experiment.

   - Initial experiments saw some unexpected losses (e.g. source/trigger
   registration failures or ARA reports not received) that the Android team is
   debugging & addressing. Some fixes depend on Android release schedules
   which are much longer than Chrome.
   - We're also adding the ability to register sources and triggers from
   WebView
   
.
   We plan for that functionality to be available later this year and included
   in the same Origin Trial for ease of implementation.

BTW, I just realized that we should only request extension for 3 milestones
at a time, so that would be from 120-122 inclusive.

Thanks,
Nan

-- 
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/CA%2BVrgPmH5wWBz0KNFV_LAa1vOx3z8GE3DYmVXBekdtVrR101TQ%40mail.gmail.com.

[blink-dev] Intent to Ship: Attribution Reporting API feature (aggregation coordinator selection)

[Nan Lin]

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:

   -

   Multiple cloud providers support for aggregate reporting, supporting AWS
   and GCP
   -

  **Note**: This change will also affect Private Aggregation API
  ’s
  aggregatable reports by adding a new top-level field
  aggregation_coordinator_origin.

Explainer changes

   -

   Add aggregation coordinator identifier to support multiple cloud
   providers 
   -

   Use aggregation coordinator origin instead of identifier
   

Spec changes

   -

   Add aggregation coordinator identifier to aggregatable report
   
   -

   Use aggregation coordinator origin instead of identifier
   
   -

   Add aggregation_coordinator_origin to PAA serialized report
   


Risks
Interoperability and Compatibility

The change is backwards compatible, and allows developers to select the
deployment option for the aggregation service. By default, the AWS
coordinator will be used (the existing behavior), and the public keys will
be served on both old and new endpoints during the transition period.


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 119

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5197591256236032

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


-- 
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/CA%2BVrgPkpNoOJk60RjTsK2u%2BbCMbM2VkDwjPzqFUEaP7oZ2egoQ%40mail.gmail.com.

[blink-dev] Intent to Extend Origin Trial: Cross App and Web Attribution Measurement M120-M123

[Nan Lin]

Contact emails

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

Explainer

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

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web



Summary

Currently, the Attribution Reporting API
 supports attributing
events within a single browser instance. This proposal expands the scope of
attribution to allow attributing conversions that happen on the web to
events that happen off the browser, within other applications such as
mobile applications, or vice-versa.

The proposal here takes advantage of OS-level support for attribution. In
particular, it gives the developer an option to allow events on the mobile
web to be joinable with events in Android’s Privacy Sandbox
,
although support for other platforms could also be implemented in the
future.

The experiment will be on Android T
, S
, and R
 devices only.

We are planning to extend the experiment for 4 more milestones M120 to M123
inclusive.


Blink component

Internals>AttributionReporting


TAG review

https://github.com/w3ctag/design-reviews/issues/724 (Attribution Reporting
API)

TAG review status

Pending

Risks
Interoperability

Web developers: Some testers are currently implementing and providing
feedback, and commitment from an additional 5+ testers to begin engagement
later this year.


Goals for experimentation

For experimentation with the new extension of the Attribution Reporting
API, we hope to see that the measurement data made available through the
API provides useful ad conversion data cross app and web, and that
developers are able to work against both the Chrome and Android Attribution
APIs.


Justification for extension

Cross app web Attribution Reporting API is currently enabled on Android T+
devices on the following platforms/channels:

Android: Canary/Dev (50%), Beta (50%), Stable (99%)

Android WebView: Canary/Dev (50%), Beta (50%), Stable (10%)

The Android API itself is available on 90% on Android T.

Currently the page load for the Cross App Web Attribution Reporting API is
at 0.0128%
,
which we feel also mitigates burn-in risk.

The experiment on Android WebView is still being ramped up with a few
planned enhancements. We plan to start the experiment on Android S and R
devices soon as well.

Given the complexity of using the new Web API in conjunction with the new
Android APIs, partner testing has taken longer than expected. With this
extension, we hope to get additional data on the usefulness of this API and
insights into any issues in the system.

Ongoing technical constraints

None.


Debuggability

The Attribution Reporting API utilizes DevTools and an internal page
(chrome://attribution-internals) to facilitate testing and integration. Debug
reports

are supported (and when configured in a third-party context, require
third-party cookies to be available).


The debugging information for OS registrations is displayed in DevTools and
in chrome://attribution-internals as well. Android Measurement is also
implementing a similar debugging reports framework to facilitate cross app
and web testing.

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

No, only on Android and Android WebView for this experiment.

Is this feature fully tested by web-platform-tests

?

No, web platform tests are not supported for Android.

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

No.

Launch bug

https://launch.corp.google.com/launch/4238495

Estimated milestones

We’d like to extend the origin trial for 4 additional milestones, with the
extension starting in M120 continuing through M123. The experiment is
therefore running from Chrome M114 through M123.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4994430156668928

Links to previous Intent discussions

Cross App Web Attribution Measurement I2E


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

[blink-dev] Re: blink-dev@chromium.org

[Nan Lin]

Please ignore this one. Thanks!

On Monday, May 1, 2023 at 9:11:45 AM UTC-4 lin...@google.com wrote:

> Contact emails
>
> johni...@chromium.org, csharri...@chromium.org, lin...@chromium.org
>
> Explainer
>
> https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/#cross-app-and-web (a 
> rough shell at this point)
>
> Summary
>
> Currently, the Attribution Reporting API 
>  supports attributing 
> events within a single browser instance. This proposal expands the scope of 
> attribution to allow attributing conversions that happen on the web to 
> events that happen off the browser, within other applications such as 
> mobile applications.
>
> The proposal here takes advantage of OS-level support for attribution. In 
> particular, it gives the developer an option to allow events on the mobile 
> web to be joinable with events in Android’s Privacy Sandbox 
> ,
>  
> although support for other platforms could also be implemented in the 
> future.
>
> The experiment will be on Android T 
>  devices only.
> Blink component
>
> Internals>AttributionReporting  
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/724 (Attribution 
> Reporting API)
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability
>
> There are several other different attribution measurement proposals from a 
> variety of browser vendors and companies, each offering different forms of 
> privacy and utility:
>
> Safari has proposed and implemented Private Click Measurement.
>
> Mozilla has proposed Interoperable Private Attribution.
>
> Microsoft has proposed a few ideas (MaskedLARK, Bucketization).
>
> The following signals are for the Attribution Reporting API, we haven’t 
> requested signals separately for the cross app and web extension yet.
>
> Gecko: No official position
>
>
> WebKit: No official position
>
> Web developers: TBD
>
>
> Ergonomics
>
> N/A
>
> Activation
>
> A successful API flow involves enabling Measurement API on Android and 
> registering events on the web to pass to Android. Android is responsible 
> for the actual attribution and reporting.
>
> WebView Application Risks
>
> N/A
>
>
>   Security
>
> Security considerations 
> are
>  
> detailed here 
> 
> .
>
> Privacy
>
> Privacy considerations are detailed here 
> 
> .
>
> Goals for experimentation
>
> For experimentation with the new extension of the Attribution Reporting 
> API, we hope to see that the measurement data made available through the 
> API provides useful ad conversion data cross app and web.
>
> Experiment Configuration
>
> The origin trial for this experiment will be separate from existing 
> Privacy Sandbox APIs to reduce risks for other APIs in case of bugs in 
> this origin trial.
>
>
> The new origin trial will support third-party origin trial 
> 
>  
> configurations. To ensure that developers can run this experiment without 
> concern for crash/breakage, this origin trial will be available for a 
> subset of users by default. Initially, the Cross App And Web Attribution 
> Measurement API will only be enabled on 50% Canary/Dev Chrome channels. 
> As we gain confidence that the API is working properly by monitoring 
> feature usage, we will enable the API for the Beta Chrome channel and 
> eventually the Stable Chrome channel.
>
>
> The Attribution Reporting API will be fully enabled (app-to-web, 
> web-to-app, web-to-web) with the new origin trial token.
>
> Ongoing technical constraints
>
> None. 
>
>
> Debuggability
>
> The Attribution Reporting API utilizes DevTools and an internal page 
> (chrome://attribution-internals) to facilitate testing and integration. Debug 
> reports 
> 
>  
> are supported (and when configured in a third-party context, require 
> third-party cookies to be available).
>
>
> The debugging information for OS registrations will be displayed in 
> DevTools and in chrome://attribution-internals as well. Android Measurement 
> is also implementing a similar debugging reports framework to facilitate 
> cross app and web testing.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?
>
>

[blink-dev] Intent to Experiment: Cross App and Web Attribution Measurement

[Nan Lin]

Contact emails

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

Explainer

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

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web (a 
rough shell at this point)

Summary

Currently, the Attribution Reporting API 
 supports attributing 
events within a single browser instance. This proposal expands the scope of 
attribution to allow attributing conversions that happen on the web to 
events that happen off the browser, within other applications such as 
mobile applications.

The proposal here takes advantage of OS-level support for attribution. In 
particular, it gives the developer an option to allow events on the mobile 
web to be joinable with events in Android’s Privacy Sandbox 
, 
although support for other platforms could also be implemented in the 
future.

The experiment will be on Android T 
 devices only.


Blink component

Internals>AttributionReporting  


TAG review

https://github.com/w3ctag/design-reviews/issues/724 (Attribution Reporting 
API)

TAG review status

Pending

Risks
Interoperability

There are several other different attribution measurement proposals from a 
variety of browser vendors and companies, each offering different forms of 
privacy and utility:

Safari has proposed and implemented Private Click Measurement.

Mozilla has proposed Interoperable Private Attribution.

Microsoft has proposed a few ideas (MaskedLARK, Bucketization).

The following signals are for the Attribution Reporting API, we haven’t 
requested signals separately for the cross app and web extension yet.

Gecko: No official position


WebKit: No official position

Web developers: TBD


Ergonomics

N/A

Activation

A successful API flow involves enabling Measurement API on Android and 
registering events on the web to pass to Android. Android is responsible 
for the actual attribution and reporting.

WebView Application Risks

N/A


  Security

Security considerations 
are
 
detailed here 

.

Privacy

Privacy considerations are detailed here 

.

Goals for experimentation

For experimentation with the new extension of the Attribution Reporting 
API, we hope to see that the measurement data made available through the 
API provides useful ad conversion data cross app and web.

Experiment Configuration

The origin trial for this experiment will be separate from existing Privacy 
Sandbox APIs to reduce risks for other APIs in case of bugs in this origin 
trial.


The new origin trial will support third-party origin trial 
 
configurations. To ensure that developers can run this experiment without 
concern for crash/breakage, this origin trial will be available for a 
subset of users by default. Initially, the Cross App And Web Attribution 
Measurement API will only be enabled on 50% Canary/Dev Chrome channels. As 
we gain confidence that the API is working properly by monitoring feature 
usage, we will enable the API for the Beta Chrome channel and eventually 
the Stable Chrome channel.


The Attribution Reporting API will be fully enabled (app-to-web, 
web-to-app, web-to-web) with the new origin trial token.

Ongoing technical constraints

None.

Debuggability

The Attribution Reporting API utilizes DevTools and an internal page 
(chrome://attribution-internals) to facilitate testing and integration. Debug 
reports 

 
are supported (and when configured in a third-party context, require 
third-party cookies to be available).


The debugging information for OS registrations will be displayed in 
DevTools and in chrome://attribution-internals as well. Android Measurement 
is also implementing a similar debugging reports framework to facilitate 
cross app and web testing.

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

No, only on Android for this experiment.

Is this feature fully tested by web-platform-tests 

?

No, web platform tests are not supported for Android.

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

No. 

Launch bug

https://launch.corp.google.c

[blink-dev] blink-dev@chromium.org

['Nan Lin' via blink-dev]

Contact emails

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

Explainer

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

Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web (a 
rough shell at this point)

Summary

Currently, the Attribution Reporting API 
 supports attributing 
events within a single browser instance. This proposal expands the scope of 
attribution to allow attributing conversions that happen on the web to 
events that happen off the browser, within other applications such as 
mobile applications.

The proposal here takes advantage of OS-level support for attribution. In 
particular, it gives the developer an option to allow events on the mobile 
web to be joinable with events in Android’s Privacy Sandbox 
, 
although support for other platforms could also be implemented in the 
future.

The experiment will be on Android T 
 devices only.
Blink component

Internals>AttributionReporting  


TAG review

https://github.com/w3ctag/design-reviews/issues/724 (Attribution Reporting 
API)

TAG review status

Pending

Risks
Interoperability

There are several other different attribution measurement proposals from a 
variety of browser vendors and companies, each offering different forms of 
privacy and utility:

Safari has proposed and implemented Private Click Measurement.

Mozilla has proposed Interoperable Private Attribution.

Microsoft has proposed a few ideas (MaskedLARK, Bucketization).

The following signals are for the Attribution Reporting API, we haven’t 
requested signals separately for the cross app and web extension yet.

Gecko: No official position


WebKit: No official position

Web developers: TBD


Ergonomics

N/A

Activation

A successful API flow involves enabling Measurement API on Android and 
registering events on the web to pass to Android. Android is responsible 
for the actual attribution and reporting.

WebView Application Risks

N/A


  Security

Security considerations 
are
 
detailed here 

.

Privacy

Privacy considerations are detailed here 

.

Goals for experimentation

For experimentation with the new extension of the Attribution Reporting 
API, we hope to see that the measurement data made available through the 
API provides useful ad conversion data cross app and web.

Experiment Configuration

The origin trial for this experiment will be separate from existing Privacy 
Sandbox APIs to reduce risks for other APIs in case of bugs in this origin 
trial.


The new origin trial will support third-party origin trial 
 
configurations. To ensure that developers can run this experiment without 
concern for crash/breakage, this origin trial will be available for a 
subset of users by default. Initially, the Cross App And Web Attribution 
Measurement API will only be enabled on 50% Canary/Dev Chrome channels. As 
we gain confidence that the API is working properly by monitoring feature 
usage, we will enable the API for the Beta Chrome channel and eventually 
the Stable Chrome channel.


The Attribution Reporting API will be fully enabled (app-to-web, 
web-to-app, web-to-web) with the new origin trial token.

Ongoing technical constraints

None. 


Debuggability

The Attribution Reporting API utilizes DevTools and an internal page 
(chrome://attribution-internals) to facilitate testing and integration. Debug 
reports 

 
are supported (and when configured in a third-party context, require 
third-party cookies to be available).


The debugging information for OS registrations will be displayed in 
DevTools and in chrome://attribution-internals as well. Android Measurement 
is also implementing a similar debugging reports framework to facilitate 
cross app and web testing.

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

No, only on Android for this experiment.

Is this feature fully tested by web-platform-tests 

?

No, web platform tests are not supported for Android.

Flag name

The API can be enabled using chrome://flags/#privacy-sandbox-ads-apis.

Requires code in //chrome?