Archived: Prepare for phasing out third-party cookies - Chrome Developers

Third-party cookies are the main mechanism that enables cross-site tracking and several major browsers either already placed restrictions on third-party cookies in some way or are planning to. Third-party cookies also enable many valid use cases such as managing state in embedded content or enabling user sessions across multiple sites.

As part of the Privacy Sandbox project, Chrome is phasing out support for third-party cookies and proposing new functionality for cookies along with purpose-built APIs to continue supporting legitimate use cases while preserving user privacy. The phase out will be gradual, starting from midway through 2024.

To get ready for the future without cross-site tracking, audit your use of cookies and plan the actions needed if your site is impacted.

Overview

1. Identify first-party and third-party cookies in your code. Cookies that contain SameSite=None will require updates.
2. If you use third-party cookies in a fully contained, embedded context, investigate partitioned cookies.
3. If you need third-party cookies across multiple sites that form one cohesive group, investigate First-Party Sets.
4. If you're not covered by either of these options, investigate other Privacy Sandbox APIs for individual use cases that don't rely on cross-site tracking.

Identify your first-party and third-party cookies

Cookies can be first-party or third-party relative to the user's context; depending on which site the user is on at the time. This distinction between first-party and third-party context on the web isn't always obvious and the effect it has on different resources can vary.

Cookies are associated with the site that set them and they can be sent on HTTP requests or accessed by JavaScript. If the site in the browser's location bar matches the site associated with the cookie request, then that's a first-party cookie. If the site is different, it's a third-party cookie.

First-party cookies

If your cookie is never used on a third-party site, for example if you set a cookie to manage the session on your site and it's never used in a cross-site iframe, that cookie is always used in a first-party context. To identify your first-party or same-site cookies, look for:

• Cookies set without any SameSite attribute.
  • Set-Cookie: cookie-name=value;
• Cookies with SameSite set to Lax or Strict.
  • Set-Cookie: cookie-name=value; SameSite=Lax;
  • Set-Cookie: cookie-name=value; SameSite=Strict;

There are a number of other sensible defaults for other first-party cookie attributes in the best practice recipe:

Set-Cookie:
__Host-cookiename=value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax

For more details, check out Recipes for first-party cookies.

Third-party cookies

Cookies that are sent in cross-site contexts, like iframes or subresource requests, are generally referred to as third-party cookies. Some use cases for third-party cookies include:

• Embedded content shared from other sites, such as videos, maps, code samples, and social posts.
• Widgets from external services such as payments, calendars, booking, and reservation functionality.
• Widgets such as social buttons or anti-fraud services.
• Remote resources on a page such as <img> or <script> tags, that rely on cookies to be sent with a request (commonly used for tracking pixels and personalizing content).

In 2019, browsers changed the cookie behavior, restricting them to first-party access by default. Any cookies used in cross-site contexts today must be set with SameSite=None attribute.

Set-Cookie: cookie-name=value; SameSite=None; Secure

One way to identify them is to examine your code base and search for cookies containing SameSite=None.

Another option is to browse through your site with third-party cookies blocked on your machine and use DevTools to investigate any potential breakage.

To learn more about DevTools features you can use to investigate third-party cookies check out the instructions on chromium.org.

Partitioned cookies

CHIPS (Cookies Having Independent Partitioned State) is a web platform mechanism that enables opting-in to having third-party cookies partitioned by top-level site using a new cookie attribute Partitioned.

If you have a service that is used as a component on another site, any cookies it sets are in a cross-site context. The way cookies currently work, the same cookie that service C sets on site A, can be read when service C is embedded on site B.

If your service and the sites using it have a 1:1 relationship, those cookies are only ever needed on the site where they were set and not used across multiple sites. Examples include saving preferences for a widget or sharing a session cookie for an API.

In this case, having cookies partitioned by top-level site is an improvement as it reduces the complexity and risk of cross-site data leaks. Third-party cookies can still be used across sites, however, you will see different cookies when the browser is on different top-level sites.

Set-Cookie: __Host-cookie=value; SameSite=None; Secure; Path=/; Partitioned;

Learn more

For more details about technical design, use cases, and testing, check out CHIPS documentation.

First-Party Sets

First-Party Sets (FPS) is a web platform mechanism for developers to declare relationships among sites, so that browsers can use this information to enable limited cross-site cookie access for specific, user-facing purposes. Chrome will use these declared relationships to decide when to allow or deny a site access to their cookies when in a third-party context.

If a cookie is used across multiple related sites, blocking cross-site cookies or partitioning by top-level site would prevent use cases such as single sign-on or a shared shopping cart.

Declaring your sites as part of a First-Party Set will allow you to use Storage Access API (SAA) and the requestStorageAccessFor API to request access to those cookies.

The sets are declared in JSON format–in the example below, the primary domain is travel.site, and air-travel.site is in the list of associated sites.

{
 "primary": "https://travel.site",
 "associatedSites": ["https://air-travel.site"]
}

Top-level sites can request storage access on behalf of specific origins with Document.requestStorageAccessFor() (rSAFor).

document.requestStorageAccessFor('https://target.site')

Learn more

For more details about technical design, use cases, and set submission process, check out First-Party Sets developer documentation.

Privacy Sandbox APIs replacing the need for cookies

CHIPS and First-Party Sets cover use cases that can continue to rely on cross-site cookies in a privacy-preserving way.

If neither meets your needs, there is a wider set of Privacy Sandbox proposals for new APIs for specific use cases, replacing the need for cookies. Some of the new APIs are focused on identity, fraud detection, and more, while others cover advertising.

Federated Credential Management (FedCM) enables privacy-preserving approach to federated identity services so users can log into sites without sharing their personal information with a third-party service or website.

Private State Tokens convey a limited amount of information from one browsing context to another (for example, across sites) to help combat fraud, without passive tracking.

A suite of APIs is available to cover ad relevance and measurement use cases such as interest-based advertising, on-device auctions for custom audiences, cross-site content selection, ad conversion measurement and attribution, and more.

To learn more about how new APIs might serve use cases that are not covered in this post, explore the Privacy Sandbox documentation.