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

1,073 views
Skip to first unread message

Anton Maliev

unread,
May 14, 2024, 5:15:29 PMMay 14
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

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)

unread,
May 16, 2024, 3:56:15 AMMay 16
to Anton Maliev, blink-dev
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

unread,
May 16, 2024, 10:15:20 AMMay 16
to blink-dev, Yoav Weiss, blink-dev, 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

unread,
May 16, 2024, 1:19:23 PMMay 16
to blink-dev, Anton Maliev, Yoav Weiss, blink-dev
> 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

unread,
May 23, 2024, 2:53:27 PMMay 23
to blink-dev, Anton Maliev, Yoav Weiss, blink-dev
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

unread,
May 23, 2024, 3:48:11 PMMay 23
to Jonathan Njeunje, blink-dev, Anton Maliev, Yoav Weiss

Yoav Weiss (@Shopify)

unread,
May 23, 2024, 4:17:14 PMMay 23
to Anton Maliev, blink-dev
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.

--
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

unread,
May 24, 2024, 11:54:05 AMMay 24
to blink-dev, Yoav Weiss, blink-dev, 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.

--
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)

unread,
May 27, 2024, 3:09:41 AMMay 27
to Anton Maliev, blink-dev
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.

--
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

unread,
May 28, 2024, 10:59:53 AMMay 28
to Yoav Weiss (@Shopify), Anton Maliev, blink-dev
Hey Anton,

Can you please request reviews for the various chips
chips.png

Thanks!
Vlad

Ben Kelly

unread,
May 28, 2024, 12:56:00 PMMay 28
to Vladimir Levin, Yoav Weiss (@Shopify), Anton Maliev, blink-dev
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
chips.png

Done. Thanks.

 

Vladimir Levin

unread,
May 28, 2024, 2:42:26 PMMay 28
to Ben Kelly, Yoav Weiss (@Shopify), Anton Maliev, blink-dev

Caleb Raitto

unread,
Jun 4, 2024, 3:09:24 PMJun 4
to blink-dev, Vladimir Levin, Yoav Weiss, Anton Maliev, blink-dev, Ben Kelly
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



Thanks!
Vlad

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.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.

--
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.

--
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.

--
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

unread,
Jun 4, 2024, 4:52:55 PMJun 4
to Caleb Raitto, blink-dev, Vladimir Levin, Yoav Weiss, Ben Kelly
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.

--
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.

--
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.

--
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.

--
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

unread,
Jun 4, 2024, 6:39:32 PMJun 4
to Anton Maliev, blink-dev, Vladimir Levin, Yoav Weiss, Ben Kelly
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

unread,
Jun 7, 2024, 7:57:28 PMJun 7
to Caleb Raitto, blink-dev, Vladimir Levin, Yoav Weiss, Ben Kelly
Added to the explainer. Thanks for calling that out.

Ben Kelly

unread,
Jun 14, 2024, 2:35:29 PMJun 14
to Anton Maliev, Caleb Raitto, blink-dev, Vladimir Levin, Yoav Weiss
FYI, there is now some developer documentation for this feature here:

Reply all
Reply to author
Forward
0 new messages