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?
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?
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. :)
Compatibility
No compatibility concerns. The existing APIs either return promises,
and will reject for callers that are not enrolled (and they can
already reject for other reasons today), or they don’t return anything
and the script will not break.
In my experience, developers don't often attempt to `catch()` rejected
promises (...we're all very optimistic about our bug-free code and
network conditions).
A quick spot check on 2 Privacy Sandbox API code examples shows we also
seem to have left this out:
https://developer.chrome.com/docs/privacy-sandbox/topics/#access-topics
https://developer.chrome.com/docs/privacy-sandbox/protected-audience-api/ad-auction/#runadauction
We should probably update the docs to take error handling into account,
what do you think?
Is this feature fully tested 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/5ec444ae-89ab-4040-885a-b9e9f76e5c01%40chromium.org.
