Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Shivani Sharma]

Thanks Rick! Responses inline.

On Fri, Sep 15, 2023 at 4:55 PM Rick Byers  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.

>
> Thanks,
>Rick
>
> On Mon, Sep 11, 2023 at 7:09 PM Shivani Sharma 
> wrote:
>
>>
>>
>> On Fri, Sep 8, 2023 at 10:40 AM Chris Harrelson 
>> wrote:
>>
>>> LGTM2 conditioned on the spec PRs landing (some are still open).
>>>
>> Thanks Chris! The spec PRs are now all merged.
>>
>>>
>>> On Fri, Sep 8, 2023 at 6:02 AM Mike Taylor 
>>> wrote:
>>>
 On 9/7/23 6:06 PM, Shivani Sharma wrote:

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

 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?


 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.

 Thanks for the answer. It sounds like there is some compat risk for
 early adopters, but y'all have

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

['Rick Byers' via blink-dev]

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

On Mon, Sep 11, 2023 at 7:09 PM Shivani Sharma 
wrote:

>
>
> On Fri, Sep 8, 2023 at 10:40 AM Chris Harrelson 
> wrote:
>
>> LGTM2 conditioned on the spec PRs landing (some are still open).
>>
> Thanks Chris! The spec PRs are now all merged.
>
>>
>> On Fri, Sep 8, 2023 at 6:02 AM Mike Taylor 
>> wrote:
>>
>>> On 9/7/23 6:06 PM, Shivani Sharma wrote:
>>>
>>> On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote:
>>>
>>> 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?
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> --
>>> 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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org
>>> 
>>> .
>>>
>> --
> 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

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Shivani Sharma]

On Fri, Sep 8, 2023 at 10:40 AM Chris Harrelson 
wrote:

> LGTM2 conditioned on the spec PRs landing (some are still open).
>
Thanks Chris! The spec PRs are now all merged.

>
> On Fri, Sep 8, 2023 at 6:02 AM Mike Taylor  wrote:
>
>> On 9/7/23 6:06 PM, Shivani Sharma wrote:
>>
>> On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote:
>>
>> 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?
>>
>>
>> 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.
>>
>> 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.
>>
>> --
>> 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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org
>> 
>> .
>>
>

-- 
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/CADAcp0_M%3D2sAK%3DfVs_qgXON2pnxVcricnejtJUExm34fdgfgqw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[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


On Fri, Sep 8, 2023 at 12:48 PM Jeffrey Yasskin  wrote:

> 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
>
> On Fri, Sep 8, 2023 at 12:28 PM Tom Jones 
> wrote:
> >
> > so explain to me how you can claim transparency?
> >
> > ..tom
> >
> >
> > On Fri, Sep 8, 2023 at 12:26 PM Shivani Sharma 
> wrote:
> >>
> >>
> >>
> >> On Fri, Sep 8, 2023 at 2:51 PM Tom Jones 
> 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.
> >>>
> >>>
> >>> thx ..Tom (mobile)
> >>>
> >>> On Fri, Sep 8, 2023, 11:06 AM Shivani Sharma 
> wrote:
> 
> 
> 
>  On Fri, Sep 8, 2023 at 12:55 PM Tom Jones <
> thomasclinganjo...@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.
> >
> >
> >
> > thx ..Tom (mobile)
> >
> > On Wed, Aug 30, 2023, 6:16 AM Shivani Sharma <
> shivani...@chromium.org> wrote:
> >>
> >> Contact emails
> >>
> >> shivani...@chromium.org, georg...@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 a

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

['Jeffrey Yasskin' via blink-dev]

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

On Fri, Sep 8, 2023 at 12:28 PM Tom Jones  wrote:
>
> so explain to me how you can claim transparency?
>
> ..tom
>
>
> On Fri, Sep 8, 2023 at 12:26 PM Shivani Sharma  
> wrote:
>>
>>
>>
>> On Fri, Sep 8, 2023 at 2:51 PM Tom Jones  
>> 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.
>>>
>>>
>>> thx ..Tom (mobile)
>>>
>>> On Fri, Sep 8, 2023, 11:06 AM Shivani Sharma  
>>> wrote:



 On Fri, Sep 8, 2023 at 12:55 PM Tom Jones  
 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.
>
>
>
> thx ..Tom (mobile)
>
> On Wed, Aug 30, 2023, 6:16 AM Shivani Sharma  
> wrote:
>>
>> Contact emails
>>
>> shivani...@chromium.org, georg...@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 provid

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Tom Jones]

so explain to me how you can claim transparency?

..tom


On Fri, Sep 8, 2023 at 12:26 PM Shivani Sharma 
wrote:

>
>
> On Fri, Sep 8, 2023 at 2:51 PM Tom Jones 
> 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.
>
>>
>> thx ..Tom (mobile)
>>
>> On Fri, Sep 8, 2023, 11:06 AM Shivani Sharma 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 8, 2023 at 12:55 PM Tom Jones 
>>> 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.
>>>


 thx ..Tom (mobile)

 On Wed, Aug 30, 2023, 6:16 AM Shivani Sharma 
 wrote:

> Contact emails
>
> shivani...@chromium.org, georg...@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 che

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Shivani Sharma]

On Fri, Sep 8, 2023 at 2:51 PM Tom Jones 
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.

>
> thx ..Tom (mobile)
>
> On Fri, Sep 8, 2023, 11:06 AM Shivani Sharma 
> wrote:
>
>>
>>
>> On Fri, Sep 8, 2023 at 12:55 PM Tom Jones 
>> 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.
>>
>>>
>>>
>>> thx ..Tom (mobile)
>>>
>>> On Wed, Aug 30, 2023, 6:16 AM Shivani Sharma 
>>> wrote:
>>>
 Contact emails

 shivani...@chromium.org, georg...@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-enrollme

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

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

On Fri, Sep 8, 2023, 11:06 AM Shivani Sharma 
wrote:

>
>
> On Fri, Sep 8, 2023 at 12:55 PM Tom Jones 
> 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.
>
>>
>>
>> thx ..Tom (mobile)
>>
>> On Wed, Aug 30, 2023, 6:16 AM Shivani Sharma 
>> wrote:
>>
>>> Contact emails
>>>
>>> shivani...@chromium.org, georg...@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
>>> 

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Shivani Sharma]

On Fri, Sep 8, 2023 at 12:55 PM Tom Jones 
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.

>
>
> thx ..Tom (mobile)
>
> On Wed, Aug 30, 2023, 6:16 AM Shivani Sharma 
> wrote:
>
>> Contact emails
>>
>> shivani...@chromium.org, georg...@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
>> 

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

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

On Wed, Aug 30, 2023, 6:16 AM Shivani Sharma 
wrote:

> Contact emails
>
> shivani...@chromium.org, georg...@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
> 
> )
>
> RisksInteroperability
>
> 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 curre

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Shivani Sharma]

On Fri, Sep 8, 2023 at 10:43 AM Chris Harrelson 
wrote:

> Also: is there a chromestatus.com entry for this feature?
>
Yes, https://chromestatus.com/feature/5190179073032192

>
> On Fri, Sep 8, 2023 at 7:39 AM Chris Harrelson 
> wrote:
>
>> LGTM2 conditioned on the spec PRs landing (some are still open).
>>
>> On Fri, Sep 8, 2023 at 6:02 AM Mike Taylor 
>> wrote:
>>
>>> On 9/7/23 6:06 PM, Shivani Sharma wrote:
>>>
>>> On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote:
>>>
>>> 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?
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> --
>>> 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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org
>>> 
>>> .
>>>
>>

-- 
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/CADAcp0_ksZc7V73TjP_hLg4_O6%3DDy_t%2B8oAY%3Dc6pBtnn_eHkDA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Chris Harrelson]

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

On Fri, Sep 8, 2023 at 7:39 AM Chris Harrelson 
wrote:

> LGTM2 conditioned on the spec PRs landing (some are still open).
>
> On Fri, Sep 8, 2023 at 6:02 AM Mike Taylor  wrote:
>
>> On 9/7/23 6:06 PM, Shivani Sharma wrote:
>>
>> On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote:
>>
>> 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?
>>
>>
>> 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.
>>
>> 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.
>>
>> --
>> 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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org
>> 
>> .
>>
>

-- 
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/CAOMQ%2Bw-%2BhG9ZFJEzzMA7VBgJMK3a0b5QKeB%2BJeASCzcanN%2BRsw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Chris Harrelson]

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

On Fri, Sep 8, 2023 at 6:02 AM Mike Taylor  wrote:

> On 9/7/23 6:06 PM, Shivani Sharma wrote:
>
> On Friday, September 1, 2023 at 6:20:34 PM UTC-4 Mike Taylor wrote:
>
> 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?
>
>
> 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.
>
> 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.
>
> --
> 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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org
> 
> .
>

-- 
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/CAOMQ%2Bw9L8vKZqarR1aa2Ti1qAn%3DeqwtutnSzCSzH_-oQjjAZyw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Mike Taylor]

On 9/7/23 6:06 PM, Shivani Sharma wrote:


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

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?


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.


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.

--
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/1688dcc9-8dca-4e89-bc06-4b58725c22a9%40chromium.org.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

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

shivani...@chromium.org, georg...@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! 



Design document

https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N
4PcvpY0Js1qN1k/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 consu

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

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

shivani...@chromium.org ,
georg...@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

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[Shivani Sharma]

Thanks Mike! Responses inline.

On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor  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
>
> shivani...@chromium.org, georg...@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

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

[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

shivani...@chromium.org , 
georg...@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