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

[Anton Maliev]

Contact emails

ama...@chromium.org

nje...@chromium.org

wande...@chromium.org

Explainer

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

Specification

Well-known resource specification: https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md

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.  Sites may also use this opt-out to test long term solutions.

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

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.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All except WebView. (Third-party cookie deprecation launches don’t include WebView.)

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

No

Flag name on chrome://flags

N/A

Finch feature name

base::features::TpcdMetadataStageControl

Non-finch justification

N/A

Requires code in //chrome?

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

Estimated milestones

Client support is shipping to M125 on May 14.  Server-side file processing will begin some time after that date.  A separate notice will be sent when that process begins.

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5205350707101696

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/O9mh5XvbqqE/m/IyK22zHkAAAJ

[Yoav Weiss (@Shopify)]

This is an odd one, but I agree that it's a web exposed feature and hence should go through the blink process. Thanks for sending this!

On Tue, May 14, 2024 at 11:15 PM Anton Maliev <ama...@chromium.org> wrote:

Contact emails

ama...@chromium.org

nje...@chromium.org

wande...@chromium.org

Explainer

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

Specification

Well-known resource specification: https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md

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.  Sites may also use this opt-out to test long term solutions.

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.

Will developers have a way of knowing if the current site (where they may see breakage metrics) is opted-out of the grace period?

 

Blink component

Privacy

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.

Beyond that, I think that the fact that this is a short-lived capability also significantly reduces risk.

Do you have a rough estimate on the length of the grace period? (I'm guessing this will not be relevant after it) 

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%40mail.gmail.com.

[Anton Maliev]

> Will developers have a way of knowing if the current site (where they may see breakage metrics) is opted-out of the grace period?

Google is planning to build a site dashboard where developers can check on the status of their grace period and opt-out values. In the interim, Chrome DevTools shows an Issue for third-party cookies which are allowed due to the grace period - this can be used to validate whether the grace period is active for that particular client.

> Do you have a rough estimate on the length of the grace period? (I'm guessing this will not be relevant after it) 

That's correct, a site will no longer need an opt-out file after it is removed from the grace period. Each grace period entry has its own expiration date, depending on when the site applied for the deprecation trial. We will need to assess the demand for new sites onboarding to the trial before we can give an estimate on how long we will continue to support grace periods overall.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Anton Maliev]

> Each grace period entry has its own expiration date, depending on when the site applied for the deprecation trial.

To clarify, the currently published expiration date is June 30, but we are assessing how grace periods will be used after that date. This feature, though, is intended to help sites migrate off the grace period in a safe way.

[Jonathan Njeunje]

In anticipation of approval here, we have a small tool to help people validate their well-known files accessible at https://3pcd-mitigations-wrv.glitch.me.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2064a6b6-bbed-4e37-a4a4-4d707b2c373dn%40chromium.org.

[Yoav Weiss (@Shopify)]

On Thu, May 16, 2024 at 4:15 PM Anton Maliev <ama...@chromium.org> wrote:

> Will developers have a way of knowing if the current site (where they may see breakage metrics) is opted-out of the grace period?

Google is planning to build a site dashboard where developers can check on the status of their grace period and opt-out values. In the interim, Chrome DevTools shows an Issue for third-party cookies which are allowed due to the grace period - this can be used to validate whether the grace period is active for that particular client.

While that's potentially useful, that's not what I had in mind.

If a site opt-outs of the grace period, that may impact 3Ps that the site embeds.

Those 3Ps (if they are not ready for it) are likely to notice some drop in their functionality or conversion, but they'd need a way of attributing that to the lack of 3P cookies.

At the same time, while writing this, I was reminded of navigator.cookieEnabled. Do I understand correctly that it would indicate the lack of 3P cookie support in these cases?

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%40mail.gmail.com.

--

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25be1203-c642-426a-bfeb-27592e50e113n%40chromium.org.

[Anton Maliev]

I see the concern. The 3P can use document.hasStorageAccess() to check for cookie support, which accounts for the grace period and opt-out. (It would return true if there is an active grace period on the 1P or 3P that affects the current frame, or false if the current client is opted out.) Per the linked I2S, we recommend document.hasStorageAccess() instead of navigator.cookieEnabled moving forward for validation relating to Chrome's 3PCD rollout - the latter doesn't return the correct value for this case.

This also depends if the 3P in question is also on the grace period. If it is not, we would expect them to notice any breakage on other 1Ps as well.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Yoav Weiss (@Shopify)]

LGTM2

On Fri, May 24, 2024 at 5:53 PM Anton Maliev <ama...@chromium.org> wrote:

I see the concern. The 3P can use document.hasStorageAccess() to check for cookie support, which accounts for the grace period and opt-out. (It would return true if there is an active grace period on the 1P or 3P that affects the current frame, or false if the current client is opted out.) Per the linked I2S, we recommend document.hasStorageAccess() instead of navigator.cookieEnabled moving forward for validation relating to Chrome's 3PCD rollout - the latter doesn't return the correct value for this case.

Thanks! That makes sense.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%40mail.gmail.com.

--
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+...@chromium.org.

[Vladimir Levin]

Hey Anton,

Can you please request reviews for the various chips

Thanks!

Vlad

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJif6nxD4S5hcwoO%3DB1vSzHBphr0E%3DxuzLxRHBfVsbk9g%40mail.gmail.com.

[Ben Kelly]

On Tue, May 28, 2024 at 10:59 AM Vladimir Levin <vmp...@chromium.org> wrote:

Hey Anton,

Can you please request reviews for the various chips

Done. Thanks.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2M2d%2Byw2hPYBGAhiQ5Hwj5C27VdgYcaYuj_Uq4DUJwPoA%40mail.gmail.com.

[Vladimir Levin]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMhBom03OwAvRWrS2UPmRmLqWqOQPWCb97K6P%2Bx0e1S%3D7Q%40mail.gmail.com.

[Caleb Raitto]

Hi -- just had some questions about this (I'm the Potassium open web platform security / privacy reviewer this week), as I was a bit confused...

I'm trying to understand how the tokens work for origin trials. IIUC, the origin trial "enabled" behavior only happens if you serve the deprecation trial token on pages you want to be opted into the deprecation trial [0].

But, (perhaps this is a naive question) doesn't that mean that a server could just only serve those tokens for some percentage of requests, thereby achieving a "self-service system that gives sites the ability to opt-out of the grace period for a certain percentage of clients."?

My other question is around considered alternative #3, where the client fetches the .well-known file. That section says that one issue with this approach is that it "[...] accentuates the privacy/security risks of the network fetches." What is the exact nature of these privacy/security risks? I didn't see these privacy explained anywhere? The privacy issues in the security / privacy section don't seem relevant to the way the .well-known data is fetched, AFAICT.

Thanks, 

-Caleb

[0] 

https://developer.chrome.com/docs/web-platform/origin-trials/#take_part_in_an_origin_trial

Thanks!

Vlad

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25be1203-c642-426a-bfeb-27592e50e113n%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJif6nxD4S5hcwoO%3DB1vSzHBphr0E%3DxuzLxRHBfVsbk9g%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2M2d%2Byw2hPYBGAhiQ5Hwj5C27VdgYcaYuj_Uq4DUJwPoA%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Anton Maliev]

Hi Caleb,

The 3PCD grace period overrides any origin/deprecation trial tokens. This is so it can act as an immediate mitigation between when a site notices a breakage and applies for the trial, and when it is able to deploy the tokens. So a site may choose to serve tokens for some percentage of requests, but while the grace period is active this will have no effect - all of the affected cookies will be allowed regardless. The well-known file gives the site control over how the grace period is applied, and when it opts out, the clients fall back to the deprecation trial tokens or other 3PCD alternatives.

Having each client fetch the well-known file adds the following privacy/security risks. (These are distinct from the risks mentioned in the Privacy/Security section, sorry for the confusion there.)

- It would expose client browsing history via its network requests to specific .well-known resources.

- It would require requests to the domain of embedded sites (if there is a third-party grace period active) which adds new cross-site information leakage through timing attacks, etc.

- It would greatly increase the traffic load to the .well-known resource and could overload its server.

- Not a privacy/security risk, but there would be a performance cost to an additional request for each client navigation that could slow down the browser.

Thanks!

Vlad

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAODhGg7m2ARTr5%3DxE0Jex1bcmQ2ySUZRa%3DJSWpW6UuX56sD5Yg%40mail.gmail.com.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25be1203-c642-426a-bfeb-27592e50e113n%40chromium.org.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJif6nxD4S5hcwoO%3DB1vSzHBphr0E%3DxuzLxRHBfVsbk9g%40mail.gmail.com.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2M2d%2Byw2hPYBGAhiQ5Hwj5C27VdgYcaYuj_Uq4DUJwPoA%40mail.gmail.com.

--
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+...@chromium.org.

[Caleb Raitto]

Thanks! I was mixing up the grace period and the deprecation trial.

For the second part -- thanks for the context -- could you add some of that context to the explainer?

Thanks, 

-Caleb

[Anton Maliev]

Added to the explainer. Thanks for calling that out.

[Ben Kelly]

FYI, there is now some developer documentation for this feature here:

https://developers.google.com/privacy-sandbox/blog/grace-period-opt-out