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 <miketa...@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
shivani...@chromium.org <mailto:shivani...@chromium.org>,
georg...@google.com <mailto:georg...@google.com>
Explainer
https://github.com/privacysandbox/attestation/blob/main/README.md
<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
<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.
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
<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 +dut...@google.com
<mailto:dut...@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?
Is this feature fully tested byweb-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 <http://crbug.com/1448875>
Launch bug
https://launch.corp.google.com/launch/4260778
<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+unsubscr...@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
<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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c3a47b4-47e7-401b-9093-916124fecf31%40chromium.org.
