Cross-site cookies have been a critical part of the web for over a quarter of a century. This makes any change, especially a breaking change, a complex process that requires a coordinated and incremental approach. While the additional cookie attributes and new privacy-focused APIs account for the majority of use cases, there are specific scenarios where we want to ensure we don't break the experience for people using those sites. Explore these temporary options while you continue making the necessary changes to migrate away from unrestricted third-party cookies.
Deprecation trials for non-advertising use cases
Third-party cookie deprecation trials provide a way for sites or services experiencing breakage to request additional time to migrate away from third-party cookie dependencies. To be eligible for either of the available trials, sites must demonstrate functional breakage in user journeys that are not related to advertising use-cases. Sites participating in the deprecation trials will have continued access to third-party cookies for a limited period of time.
The trials are based on the following key principles:
- Registering requires a review process to ensure the deprecation trial is only used for functions that greatly affect critical user journeys and registrations will be considered on a case by case basis.
- It won't interfere with the advertising testing planned for the start of 2024, as described by the CMA. This means advertising use cases won't be considered for the deprecation trial.
The two available trials are:
- First-party deprecation trial: intended for top-level sites relying on embedded third-party sites and services.
- Third-party deprecation trial: intended for embedded sites and services.
In addition a separate deprecation trial for Storage Partitioning is also available:
- Storage Partitioning deprecation trial: intended for sites depending on unpartitioned storage outside of cookies.
Heuristics based exceptions
There are specific critical user experiences where there are established practices in the ecosystem where temporary third-party cookie access is granted in a predefined flow.
Primarily these are authentication or payment flows where a top-level site either opens a dialog or redirects to a third-party site for an operation and then returns to the top-level site, making use of a cookie either on that return journey or in the embedded context. To learn more visit the deep dive on the temporary set of heuristics that identify these scenarios and allow third-party cookies for a limited amount of time, giving sites a longer window to implement the necessary changes.
We have published an Intent to the blink-dev mailing list with further details and we will continue to update documentation here.
Enterprise support
See Chrome Enterprise third-party cookie policies.
Report issues with third-party cookies and get help
We want to ensure we capture the various scenarios where sites break without third-party cookies to ensure that we have provided guidance, tooling, and features to allow sites to migrate away from their third-party cookie dependencies. If your site or a service you depend on is breaking with third-party cookies disabled, you can submit it to our breakage tracker at goo.gle/report-3pc-broken.
If you have questions around the deprecation process and Chrome's plan, you can raise a new issue using the "third-party cookie deprecation" tag in our developer support repository.