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 <[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. 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 <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. 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 <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]> 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. 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/bd1bdad8-9ea8-4f36-b23b-a7fdf4f50352n%40chromium.org.
