Intent to Ship: Enrollment for Privacy Sandbox

[Shivani Sharma]

Contact emails

shiva...@chromium.org, geor...@google.com

 

Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md

Design document

https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing

Specification

While the enrollment process itself is not intended to be standardized, the impacted API specifications allow for a user agent defined gating mechanism such as enrollment and attestation. The spec changes for the gated APIs are linked below:

Private aggregation (section with note on enrollment) 

Shared Storage (pull request)

Topics (pull request)

Attribution reporting API (pull request)

Protected Audience (pull requests: 1, 2)

 

Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start ramping up for general availability, we want to make sure these technologies are used as intended and with transparency. The APIs include Attribution Reporting, the Protected Audience API, Topics, Private Aggregation and Shared Storage. As announced in a blog post, a new Developer Enrollment process for Privacy Sandbox relevance and measurement APIs is being introduced across Chrome and Android. This I2S refers to Chrome’s implementation of fetching the enrolled-sites list from the enrollment server (via component updater) and using it to gate access to the Privacy Sandbox APIs.

Blink component

Blink>PrivateAggregation

Blink>Storage>SharedStorage

Blink>TopicsAPI

Internals > AttributionReporting

Blink>InterestGroups

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

Supported on all the above platforms except Android WebView.

In the initial version, no gated APIs are supported on WebView , with the caveat that the Attribution Reporting API delegates from WebView to Android and would be gated as part of Android’s attestation based gating.

Debuggability

Console errors: The API surfaces gated on enrollment and attestation will output relevant console error messages if a given site is not allowed to participate/invoke those API surfaces. (Private Aggregation API-related console messages are output during its consumer API enrollment checks e.g. Shared Storage, but could be made more specific in the future).

Local override: For local testing, we are providing developer overrides with a Chrome flag and CLI switch:

Flag: chrome://flags/#privacy-sandbox-enrollment-overrides

CLI: --privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...

Initial public proposal

https://github.com/privacysandbox/attestation/blob/main/README.md

TAG review

Private Aggregation (comment)

Shared Storage (comment)

Topics (comment)

Attribution reporting API (comment)

Protected Audience (comment)

Risks

Interoperability

Initially the enrolled and attested sites list will only be available to Chrome browsers. The list is publicly available in the sense that it's shipped to Chrome browsers, but we don't have an official site currently where we post it. However, we could potentially do so in the future and that would enable other browsers to have a consistent gating mechanism.

Compatibility

No compatibility concerns. The existing APIs either return promises, and will reject for callers that are not enrolled (and they can already reject for other reasons today), or they don’t return anything and the script will not break.

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

No, as there are no plans to standardize this behavior.

Tracking bug

crbug.com/1448875

Launch bug

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

Estimated milestones

M118

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Zy6uyaTdcJ8 

[Mike Taylor]

Hi Shivani,

In general I think this is a pretty interesting idea, just a few minor questions below:

On 8/30/23 8:16 AM, Shivani Sharma wrote:

Contact emails

shiva...@chromium.org, geor...@google.com

 

Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md

A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any more info on this? Does a renewal mean incrementing attestation_version?

2) attestation_version states "This allows the maintenance of a historical record of attestations." Is that something you plan on exposing to the public somewhere? Or would you expect a site to maintain previous versions somewhere?

Also, how does unenrollment happen?

Design document

https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing

Specification

While the enrollment process itself is not intended to be standardized, the impacted API specifications allow for a user agent defined gating mechanism such as enrollment and attestation. The spec changes for the gated APIs are linked below:

Private aggregation (section with note on enrollment) 

Shared Storage (pull request)

Topics (pull request)

Attribution reporting API (pull request)

Protected Audience (pull requests: 1, 2)

 

Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start ramping up for general availability, we want to make sure these technologies are used as intended and with transparency. The APIs include Attribution Reporting, the Protected Audience API, Topics, Private Aggregation and Shared Storage. As announced in a blog post, a new Developer Enrollment process for Privacy Sandbox relevance and measurement APIs is being introduced across Chrome and Android. This I2S refers to Chrome’s implementation of fetching the enrolled-sites list from the enrollment server (via component updater) and using it to gate access to the Privacy Sandbox APIs.

Blink component

Blink>PrivateAggregation

Blink>Storage>SharedStorage

Blink>TopicsAPI

Internals > AttributionReporting

Blink>InterestGroups

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

Supported on all the above platforms except Android WebView.

In the initial version, no gated APIs are supported on WebView , with the caveat that the Attribution Reporting API delegates from WebView to Android and would be gated as part of Android’s attestation based gating.

Debuggability

Console errors: The API surfaces gated on enrollment and attestation will output relevant console error messages if a given site is not allowed to participate/invoke those API surfaces. (Private Aggregation API-related console messages are output during its consumer API enrollment checks e.g. Shared Storage, but could be made more specific in the future).

Is integration with the Reporting API also planned?

Local override: For local testing, we are providing developer overrides with a Chrome flag and CLI switch:

Flag: chrome://flags/#privacy-sandbox-enrollment-overrides

CLI: --privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...

Initial public proposal

https://github.com/privacysandbox/attestation/blob/main/README.md

TAG review

Private Aggregation (comment)

Shared Storage (comment)

Topics (comment)

Attribution reporting API (comment)

Protected Audience (comment)

Risks

Interoperability

Initially the enrolled and attested sites list will only be available to Chrome browsers. The list is publicly available in the sense that it's shipped to Chrome browsers, but we don't have an official site currently where we post it. However, we could potentially do so in the future and that would enable other browsers to have a consistent gating mechanism.

Since one of the stated goals is transparency, it would be nice to eventually host site enrollment and attestation in the open. Grabbing a file that is downloaded from the component updater isn't rocket science, but I wouldn't call it ergonomic. :)

Compatibility

No compatibility concerns. The existing APIs either return promises, and will reject for callers that are not enrolled (and they can already reject for other reasons today), or they don’t return anything and the script will not break.

In my experience, developers don't often attempt to `catch()` rejected promises (...we're all very optimistic about our bug-free code and network conditions).

A quick spot check on 2 Privacy Sandbox API code examples shows we also seem to have left this out:

https://developer.chrome.com/docs/privacy-sandbox/topics/#access-topics
https://developer.chrome.com/docs/privacy-sandbox/protected-audience-api/ad-auction/#runadauction

We should probably update the docs to take error handling into account, what do you think?

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

No, as there are no plans to standardize this behavior.

Tracking bug

crbug.com/1448875

Launch bug

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

Estimated milestones

M118

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Zy6uyaTdcJ8 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp086BcDbQX%2B2ED-9eU06ZZPH6_MMpB0cr2F0Jf40H4EACw%40mail.gmail.com.

[Shivani Sharma]

Thanks Mike! Responses inline.

On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Shivani,

In general I think this is a pretty interesting idea, just a few minor questions below:

On 8/30/23 8:16 AM, Shivani Sharma wrote:

Contact emails

shiva...@chromium.org, geor...@google.com

 

Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md

A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any more info on this? Does a renewal mean incrementing attestation_version?

2) attestation_version states "This allows the maintenance of a historical record of attestations." Is that something you plan on exposing to the public somewhere? Or would you expect a site to maintain previous versions somewhere?

Also, how does unenrollment happen?

1. Yes the plan is to have attestations expire, and have adtechs step through re-attestation process which would increment the version. 

2. The attestation file hosted on the .well-known will include all their historical attestations. We could also consider maintaining a historical record on the transparency server.

Unenrollment would be either when the original attestation expires or the entity explicitly requests to unenroll (via the form asking to cancel existing enrollment). When that happens, their data will be removed from the enrollment records and the updated list pushed to Chrome will not have their site.

Design document

https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing

Specification

While the enrollment process itself is not intended to be standardized, the impacted API specifications allow for a user agent defined gating mechanism such as enrollment and attestation. The spec changes for the gated APIs are linked below:

Private aggregation (section with note on enrollment) 

Shared Storage (pull request)

Topics (pull request)

Attribution reporting API (pull request)

Protected Audience (pull requests: 1, 2)

 

Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start ramping up for general availability, we want to make sure these technologies are used as intended and with transparency. The APIs include Attribution Reporting, the Protected Audience API, Topics, Private Aggregation and Shared Storage. As announced in a blog post, a new Developer Enrollment process for Privacy Sandbox relevance and measurement APIs is being introduced across Chrome and Android. This I2S refers to Chrome’s implementation of fetching the enrolled-sites list from the enrollment server (via component updater) and using it to gate access to the Privacy Sandbox APIs.

Blink component

Blink>PrivateAggregation

Blink>Storage>SharedStorage

Blink>TopicsAPI

Internals > AttributionReporting

Blink>InterestGroups

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

Supported on all the above platforms except Android WebView.

In the initial version, no gated APIs are supported on WebView , with the caveat that the Attribution Reporting API delegates from WebView to Android and would be gated as part of Android’s attestation based gating.

Debuggability

Console errors: The API surfaces gated on enrollment and attestation will output relevant console error messages if a given site is not allowed to participate/invoke those API surfaces. (Private Aggregation API-related console messages are output during its consumer API enrollment checks e.g. Shared Storage, but could be made more specific in the future).

Is integration with the Reporting API also planned?

 

The error reporting currently follows what happens in the gated APIs for their existing failure paths. Looking at their specs, it seems none of the gated APIs report via the reporting API today and either reject the promise or return. Given this, failure due to enrollment also doesn't have any specific plans to integrate with the reporting API.

Local override: For local testing, we are providing developer overrides with a Chrome flag and CLI switch:

Flag: chrome://flags/#privacy-sandbox-enrollment-overrides

CLI: --privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...

Initial public proposal

https://github.com/privacysandbox/attestation/blob/main/README.md

TAG review

Private Aggregation (comment)

Shared Storage (comment)

Topics (comment)

Attribution reporting API (comment)

Protected Audience (comment)

Risks

Interoperability

Initially the enrolled and attested sites list will only be available to Chrome browsers. The list is publicly available in the sense that it's shipped to Chrome browsers, but we don't have an official site currently where we post it. However, we could potentially do so in the future and that would enable other browsers to have a consistent gating mechanism.

Since one of the stated goals is transparency, it would be nice to eventually host site enrollment and attestation in the open. Grabbing a file that is downloaded from the component updater isn't rocket science, but I wouldn't call it ergonomic. :)

Agree and this is on the roadmap for transparency reports. 

Compatibility

No compatibility concerns. The existing APIs either return promises, and will reject for callers that are not enrolled (and they can already reject for other reasons today), or they don’t return anything and the script will not break.

In my experience, developers don't often attempt to `catch()` rejected promises (...we're all very optimistic about our bug-free code and network conditions).

A quick spot check on 2 Privacy Sandbox API code examples shows we also seem to have left this out:

https://developer.chrome.com/docs/privacy-sandbox/topics/#access-topics
https://developer.chrome.com/docs/privacy-sandbox/protected-audience-api/ad-auction/#runadauction

We should probably update the docs to take error handling into account, what do you think?

Updating the docs makes sense. Adding +du...@google.com 

[Mike Taylor]

On 9/1/23 2:46 PM, Shivani Sharma wrote:

Thanks Mike! Responses inline.

On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Shivani,

In general I think this is a pretty interesting idea, just a few minor questions below:

On 8/30/23 8:16 AM, Shivani Sharma wrote:

Contact emails

shiva...@chromium.org, geor...@google.com

 

Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md

A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any more info on this? Does a renewal mean incrementing attestation_version?

2) attestation_version states "This allows the maintenance of a historical record of attestations." Is that something you plan on exposing to the public somewhere? Or would you expect a site to maintain previous versions somewhere?

Also, how does unenrollment happen?

1. Yes the plan is to have attestations expire, and have adtechs step through re-attestation process which would increment the version. 

2. The attestation file hosted on the .well-known will include all their historical attestations. We could also consider maintaining a historical record on the transparency server.

Cool - makes sense. The explainer (or blog post) could probably be updated to make this more clear.

Unenrollment would be either when the original attestation expires or the entity explicitly requests to unenroll (via the form asking to cancel existing enrollment). When that happens, their data will be removed from the enrollment records and the updated list pushed to Chrome will not have their site.

Thanks - it would be nice to document this in the explainer again (and the form, if it's not already documented).

Design document

https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing

Specification

While the enrollment process itself is not intended to be standardized, the impacted API specifications allow for a user agent defined gating mechanism such as enrollment and attestation. The spec changes for the gated APIs are linked below:

Private aggregation (section with note on enrollment) 

Shared Storage (pull request)

Topics (pull request)

Attribution reporting API (pull request)

Protected Audience (pull requests: 1, 2)

 

Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start ramping up for general availability, we want to make sure these technologies are used as intended and with transparency. The APIs include Attribution Reporting, the Protected Audience API, Topics, Private Aggregation and Shared Storage. As announced in a blog post, a new Developer Enrollment process for Privacy Sandbox relevance and measurement APIs is being introduced across Chrome and Android. This I2S refers to Chrome’s implementation of fetching the enrolled-sites list from the enrollment server (via component updater) and using it to gate access to the Privacy Sandbox APIs.

Blink component

Blink>PrivateAggregation

Blink>Storage>SharedStorage

Blink>TopicsAPI

Internals > AttributionReporting

Blink>InterestGroups

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

Supported on all the above platforms except Android WebView.

In the initial version, no gated APIs are supported on WebView , with the caveat that the Attribution Reporting API delegates from WebView to Android and would be gated as part of Android’s attestation based gating.

Debuggability

Console errors: The API surfaces gated on enrollment and attestation will output relevant console error messages if a given site is not allowed to participate/invoke those API surfaces. (Private Aggregation API-related console messages are output during its consumer API enrollment checks e.g. Shared Storage, but could be made more specific in the future).

Is integration with the Reporting API also planned?

 

The error reporting currently follows what happens in the gated APIs for their existing failure paths. Looking at their specs, it seems none of the gated APIs report via the reporting API today and either reject the promise or return. Given this, failure due to enrollment also doesn't have any specific plans to integrate with the reporting API.

Ack.

Local override: For local testing, we are providing developer overrides with a Chrome flag and CLI switch:

Flag: chrome://flags/#privacy-sandbox-enrollment-overrides

CLI: --privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...

Initial public proposal

https://github.com/privacysandbox/attestation/blob/main/README.md

TAG review

Private Aggregation (comment)

Shared Storage (comment)

Topics (comment)

Attribution reporting API (comment)

Protected Audience (comment)

Risks

Interoperability

Initially the enrolled and attested sites list will only be available to Chrome browsers. The list is publicly available in the sense that it's shipped to Chrome browsers, but we don't have an official site currently where we post it. However, we could potentially do so in the future and that would enable other browsers to have a consistent gating mechanism.

Since one of the stated goals is transparency, it would be nice to eventually host site enrollment and attestation in the open. Grabbing a file that is downloaded from the component updater isn't rocket science, but I wouldn't call it ergonomic. :)

Agree and this is on the roadmap for transparency reports. 

Compatibility

No compatibility concerns. The existing APIs either return promises, and will reject for callers that are not enrolled (and they can already reject for other reasons today), or they don’t return anything and the script will not break.

In my experience, developers don't often attempt to `catch()` rejected promises (...we're all very optimistic about our bug-free code and network conditions).

A quick spot check on 2 Privacy Sandbox API code examples shows we also seem to have left this out:

https://developer.chrome.com/docs/privacy-sandbox/topics/#access-topics
https://developer.chrome.com/docs/privacy-sandbox/protected-audience-api/ad-auction/#runadauction

We should probably update the docs to take error handling into account, what do you think?

Updating the docs makes sense. Adding +du...@google.com

Thanks. One last question here: how confident are y'all that consumers of these APIs are well-equipped for errors in case they don't enroll? Have you looked at any Privacy Sandbox API usage in the wild to verify that early adopters aren't going to break?

[Shivani Sharma]

On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote:

On 9/1/23 2:46 PM, Shivani Sharma wrote:

Thanks Mike! Responses inline.

On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Shivani,

In general I think this is a pretty interesting idea, just a few minor questions below:

On 8/30/23 8:16 AM, Shivani Sharma wrote:

Contact emails

shiva...@chromium.org, geor...@google.com

 

Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md

A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any more info on this? Does a renewal mean incrementing attestation_version?

2) attestation_version states "This allows the maintenance of a historical record of attestations." Is that something you plan on exposing to the public somewhere? Or would you expect a site to maintain previous versions somewhere?

Also, how does unenrollment happen?

1. Yes the plan is to have attestations expire, and have adtechs step through re-attestation process which would increment the version. 

2. The attestation file hosted on the .well-known will include all their historical attestations. We could also consider maintaining a historical record on the transparency server.

Cool - makes sense. The explainer (or blog post) could probably be updated to make this more clear.

Unenrollment would be either when the original attestation expires or the entity explicitly requests to unenroll (via the form asking to cancel existing enrollment). When that happens, their data will be removed from the enrollment records and the updated list pushed to Chrome will not have their site.

Thanks - it would be nice to document this in the explainer again (and the form, if it's not already documented).

Yes, I have reached out to the team so we can update both of these in the explainer/blog. Thanks! 

The Impact of not enrolling has been well publicized over the past few months on multiple levels and through various form factors, including blog posts and 1:1 conversations with ad tech companies testing the APIs.
While we have been thoughtful in our design, allowing sufficient time between outreach and enforcement, and supporting adtechs in their migration journey,  adtechs would need to enroll if they plan to call the APIs post-enforcement successfully. 
We also think it’s important to launch this process now, to provide time for API callers to complete enrollment and work out any issues that may arise, ahead of expanded API testing in early 2024.

 

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

No, as there are no plans to standardize this behavior.

Tracking bug crbug.com/1448875
Launch bug

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

Estimated milestones

M118

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Zy6uyaTdcJ8 

--
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+unsubscribe@chromium.org.

[Mike Taylor]

Thanks for the answer. It sounds like there is some compat risk for early adopters, but y'all have mechanisms in place to communicate the changes and do outreach if needed.

LGTM1 to ship.

[Chris Harrelson]

LGTM2 conditioned on the spec PRs landing (some are still open).

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org.

[Chris Harrelson]

Also: is there a chromestatus.com entry for this feature?

[Shivani Sharma]

On Fri, Sep 8, 2023 at 10:43 AM Chris Harrelson <chri...@chromium.org> wrote:

Also: is there a chromestatus.com entry for this feature?

Yes, https://chromestatus.com/feature/5190179073032192 

[Tom Jones]

I cannot understand how it is possible to claim transparency with the following explanation. It seems completely misleading.

Today, the attestation model does not seek to provide information to users within the browser or device in real-time about a developer's attestations

thx ..Tom (mobile)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp086BcDbQX%2B2ED-9eU06ZZPH6_MMpB0cr2F0Jf40H4EACw%40mail.gmail.com.

[Shivani Sharma]

On Fri, Sep 8, 2023 at 12:55 PM Tom Jones <thomascli...@gmail.com> wrote:

I cannot understand how it is possible to claim transparency with the following explanation. It seems completely misleading.

Today, the attestation model does not seek to provide information to users within the browser or device in real-time about a developer's attestations

Thanks for the question! The transparency for attestations is something that would be added in a future iteration and as mentioned in the earlier response, that will likely also include a public list of enrolled and attested sites. 

[Tom Jones]

This statement is under non goals. So I think you need to change that or remove the claim of transparency.

thx ..Tom (mobile)

[Shivani Sharma]

On Fri, Sep 8, 2023 at 2:51 PM Tom Jones <thomascli...@gmail.com> wrote:

This statement is under non goals. So I think you need to change that or remove the claim of transparency.

This is specifically about whether the end user can see the result of attestation of a given site "in the browser", which at this time is not supported.   

[Tom Jones]

so explain to me how you can claim transparency?

..tom

[Jeffrey Yasskin]

Transparency serves a bunch of different goals, as described in
https://w3ctag.github.io/privacy-principles/#transparency, and the
most valuable aren't always to give an end-user more information while
they're trying to make a decision. I think the explainer is clear
enough in saying that its goal is "providing transparency to the
ecosystem" rather than to "provide information to users ... in
real-time".

It sounds like the team is open to evolving toward showing information
directly to end-users, but that decision should be based on something
we expect the users to do with that information in real time, rather
than on transparency in the abstract.

Jeffrey

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK2Cwb5WAk215SzY%3DnKOgvhgXNH02TVn4NsOCKwFQoan5ZREjQ%40mail.gmail.com.

[Tom Jones]

The W3C document you referenced is about privacy principles. Ecosystems do not have privacy, people have privacy. The snippet below is from the document and should make it very clear that your document is not in compliance with privacy principles. If you do not correct this document, i am sure that Google will be embarrassed, yet again for misleading people about their intentions,

"Such transparency can only function if there are strong rights of access to data (including data derived from one's personal data) as well as mechanisms to explain the outcomes of automated decisions.

" ..tom

[Shivani Sharma]

On Fri, Sep 8, 2023 at 10:40 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM2 conditioned on the spec PRs landing (some are still open).

Thanks Chris! The spec PRs are now all merged. 

[Rick Byers]

LGTM3 

On the compat front this is technically a breaking change for shipped APIs. Normally we'd want to see a more thorough a compat analysis to back up the claim of sites not being functionally broken. However, running through a compat analysis in my head I think what you've provided is sufficient, because:

• Our primary tool of UseCounters isn't going to be too helpful here. We know these APIs are being widely tested and we know we can't realistically measure whether errors are being handled properly. I don't have any easy suggestions for how to quantify this particular risk well.
• These are brand new APIs with a generally small number of customers who are probably actively experimenting
• All the APIs are for use cases which aren't directly relevant to the core functioning of a site - so any breakage is unlikely to be noticed by users, except possibly by ads not showing (though unhandled exceptions in async functions in initialization routines are potentially a problem)
• I know these launches are being rolled out and watched carefully. I assume we'll do some small percentage first and verify we don't hear complaints before ramping up? And worst case and there's significant functional breakage, we can use a killswitch to roll back, right?

While I know the utility of this system remains to be seen, I personally like the added transparency compared to the current state where these APIs are just available to anyone - especially given the new ground we're breaking with these APIs. I imagine researchers and others can get some value out of the .well-known file such as by crawling popular sites. However I can imagine some forms of research would benefit from access to the enrolled-sites list being used in Chrome (to analyze less popular sites that might not show up in a top sites list). Are you able to provide instructions for easily extracting the site list from a Chrome install? Or do you have a date by which you expect you can make the enrolled-sites list available elsewhere?

I don't see a particular interoperability concern here since we're not aware of any other browsers who have said they're shipping these APIs (right?), and if they were they could probably just make it available to all sites, clone our system, or use their own system for gating access (a similar cross-browser dynamic we have with the origin trials system, which doesn't appear to have been a problem so far). But we should keep our ears open for any other browser who might want to use a similar system and be open to collaboration. 

Thanks,

   Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0_M%3D2sAK%3DfVs_qgXON2pnxVcricnejtJUExm34fdgfgqw%40mail.gmail.com.

[Shivani Sharma]

Thanks Rick! Responses inline.

On Fri, Sep 15, 2023 at 4:55 PM Rick Byers <rby...@google.com> wrote:

LGTM3 

On the compat front this is technically a breaking change for shipped APIs. Normally we'd want to see a more thorough a compat analysis to back up the claim of sites not being functionally broken. However, running through a compat analysis in my head I think what you've provided is sufficient, because:

• Our primary tool of UseCounters isn't going to be too helpful here. We know these APIs are being widely tested and we know we can't realistically measure whether errors are being handled properly. I don't have any easy suggestions for how to quantify this particular risk well.
• These are brand new APIs with a generally small number of customers who are probably actively experimenting
• All the APIs are for use cases which aren't directly relevant to the core functioning of a site - so any breakage is unlikely to be noticed by users, except possibly by ads not showing (though unhandled exceptions in async functions in initialization routines are potentially a problem)
• I know these launches are being rolled out and watched carefully. I assume we'll do some small percentage first and verify we don't hear complaints before ramping up? And worst case and there's significant functional breakage, we can use a killswitch to roll back, right?

Agree with the above points! In terms of rollout, the plan is to have this be enabled for pre-stable now and then go to stable via waterfall. We would find out via pre-stable rollout if there is an issue and if required, use the kill switch, since all of the enrollment code is behind a feature flag.

 

While I know the utility of this system remains to be seen, I personally like the added transparency compared to the current state where these APIs are just available to anyone - especially given the new ground we're breaking with these APIs. I imagine researchers and others can get some value out of the .well-known file such as by crawling popular sites. However I can imagine some forms of research would benefit from access to the enrolled-sites list being used in Chrome (to analyze less popular sites that might not show up in a top sites list). Are you able to provide instructions for easily extracting the site list from a Chrome install? Or do you have a date by which you expect you can make the enrolled-sites list available elsewhere?

To be able to extract the list from a Chrome install, the instructions would include protobuf decoding as the list is encoded using protobuf. Compared to that, it would be simpler to have the list be publicly hosted and we are targeting that as a fast follow to stable enforcement, sometime in Q4. 

I don't see a particular interoperability concern here since we're not aware of any other browsers who have said they're shipping these APIs (right?), and if they were they could probably just make it available to all sites, clone our system, or use their own system for gating access (a similar cross-browser dynamic we have with the origin trials system, which doesn't appear to have been a problem so far). But we should keep our ears open for any other browser who might want to use a similar system and be open to collaboration. 

That makes sense.