Intent to Prototype: Third-party Cookie Grace Period Opt-Out

391 views
Skip to first unread message

Anton Maliev

unread,
Apr 16, 2024, 2:59:16 PMApr 16
to blink-dev

Contact emails

ama...@chromium.org

nje...@chromium.org

wande...@chromium.org


Explainer

https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out


Specification

TBD


Summary

This proposal details a new mechanism for site developers to conduct a self-service staged opt-out of their third-party cookie phaseout grace period. This is intended primarily for Chrome’s active trials for third-party cookie deprecation - one for top-level sites and one for embedded sites. When a site is approved for one of these trials, they are added to a short-term grace period which mitigates breakage until the token is launched.


Each site on the trial will specify their desired opt-out percentage in a new resource in their .well-known directory, specified here. Google will implement server infrastructure to fetch and update these values on a schedule, and assign clients randomly to cohorts matching this percentage. These cohorts persist for a client up until clearing site storage or reinstalling the browser.


Blink component

Privacy


Motivation

Currently, developers can use a local testing setup to test the launch of their deprecation trial token, or other privacy-preserving API, by disabling the grace period. However, the site has no global control over the grace period - it is impossible to run a production test, or staged opt-out, without coordinating closely with Chrome. The system of defining and fetching the well-known resource allows sites to adjust their opt-out percentage (or ramp down completely if an issue is found) with minimal latency and communication turnover.


Initial public proposal

N/A


Search tags

third-party cookie deprecation


TAG review

N/A


TAG review status

N/A


Risks

There aren’t inherent security implications for fetching external resources using server-side infrastructure, but there is a risk of fetching bad data, which our implementation addresses.


There are also privacy implications for randomly assigning clients to cohorts, which we mitigate by clearing cohorts on site data deletion. There is also a risk that the fetching system fails or that a site loses access to its .well-known resource, both cases which we have planned mitigations for.


Interoperability and Compatibility

The third-party cookie deprecation trials are a Chrome feature, so these new .well-known resources will only be fetched by the Chrome browser. The new resource will be distinct and will not interfere with any existing resources used by other browsers or features. This approach may be used to address a similar need in the future (self-service restriction from an origin or deprecation trial), although it would also require a new resource spec.


Debuggability

N/A


Is this feature fully tested by web-platform-tests?

No


Flag name

base::features::TpcdMetadataStageControl


Requires code in //chrome?

No. All code for the grace period and new staged opt-out handling is in //components/tpcd/metadata.


Tracking bug

https://issuetracker.google.com/331957180


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5205350707101696


Reply all
Reply to author
Forward
0 new messages