Thanks Mike! Responses inline. On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor <[email protected]> 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 > > [email protected], [email protected] > > > 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 > <https://patcg-individual-drafts.github.io/private-aggregation-api/#scheduling-reports> > ) > > Shared Storage (pull request > <https://github.com/WICG/shared-storage/pull/105>) > > Topics (pull request > <https://github.com/patcg-individual-drafts/topics/pull/238/files>) > > Attribution reporting API (pull request > <https://github.com/WICG/attribution-reporting-api/pull/968>) > > Protected Audience (pull requests: 1 > <https://github.com/WICG/fenced-frame/pull/114/files>, 2 > <https://github.com/WICG/turtledove/pull/766/files>) > > > 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 > <https://developer.chrome.com/blog/announce-enrollment-privacy-sandbox/>, > 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 > <https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/README.md>) > and using it to gate access to the Privacy Sandbox APIs. > > Blink component > > Blink>PrivateAggregation > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPrivateAggregation> > > Blink>Storage>SharedStorage > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EStorage%3ESharedStorage&can=2> > > Blink>TopicsAPI > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ETopicsAPI> > > Internals > AttributionReporting > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting> > > Blink>InterestGroups > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EInterestGroups&can=2> > > 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 > <https://github.com/w3ctag/design-reviews/issues/846#issuecomment-1690139513> > ) > > Shared Storage (comment > <https://github.com/w3ctag/design-reviews/issues/747#issuecomment-1690156498> > ) > > Topics (comment > <https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1690087586> > ) > > Attribution reporting API (comment > <https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1690076332> > ) > > Protected Audience (comment > <https://github.com/w3ctag/design-reviews/issues/723#issuecomment-1690413217> > ) > > 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 [email protected] <[email protected]> > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? > > 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp086BcDbQX%2B2ED-9eU06ZZPH6_MMpB0cr2F0Jf40H4EACw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp0-pnkw5sqNqLZQZO87z6kSWchUSxVROwYX54JrWR%2BCtpA%40mail.gmail.com.
