Disabling third-party cookies is a trend, but how will third-party cookies be called in the future?

What happened?#

In the recent releases of Chrome 113 and 114, there are two changes related to cookies:
Chrome 113: First-Party Sets enters stable version;
Chrome 114: CHIPS (Cookie Independent Partitioning) is enabled by default for all browsers;

Both of these changes are related to cookie access methods and are aimed at preparing for the complete deprecation of third-party cookies. Chrome has planned to completely deprecate third-party cookies two years ago because this change has a significant impact on current websites. If they are directly deprecated, it may cause many websites to lose their normal functionality.

Chrome plans to completely disable third-party cookies in Q3 2024.
The following content is quoted from the Google Developers website's Privacy Sandbox article.

Deprecating 1% of third-party cookies and Chrome assisting in testing#

On the privacysandbox.com timeline, you can see two milestones in Q4 2023 and Q1 2024, which are part of Chrome's assistance testing mode. This test is mainly aimed at organizations testing the relevance and effectiveness measurement APIs of Privacy Sandbox, but in the process, we have disabled third-party cookies for 1% of Chrome stable version users.

Timeline for deprecating third-party cookies.

As part of Chrome's assistance testing, "Enable Testing with Tag Mode" will start in Q4 2023 and will limit 1% of third-party cookies starting from January 4, 2024. Both will continue until mid-Q3 2024, when the phase-out of third-party cookies will gradually begin.
This means that starting from early 2024, even if you are not actively participating in Chrome's assistance testing, more Chrome users will visit your website with third-party cookies disabled. This testing period will continue until Q3 2024. After consultation with the Competition and Markets Authority (CMA), we plan to start disabling third-party cookies for all Chrome users.

Cookies sent in a cross-site context (such as iframe or subresource requests) are usually referred to as third-party cookies.

What impact will this change have?#

In 2019, browsers changed the behavior of cookies, restricting cookies to first-party access by default. Any cookies used in a cross-site context must be set with the SameSite=None attribute. However, after disabling third-party cookies, even if SameSite=None is set, the cookie cannot be read by third parties.

For example, when we are watching videos on Douyin (the Chinese version of TikTok), there are often requests from third-party advertisers. These advertisers can track user behavior through third-party cookies. Then, when you browse Taobao (an e-commerce platform) next time, you may encounter the same advertiser again because they have recorded your user behavior through third-party cookies and know what you are interested in. As a result, you will receive targeted advertisements, and your privacy has been compromised without your knowledge.
In terms of user privacy, Safira and Firefox, two major browsers, have already disabled third-party cookies under pressure. This means that if you visit the website www.douyin.com on these two browsers, requests from the domain bytedance.com will not be able to set cookies.

If third-party cookies are disabled, the ability to share cookies across different domains of a company will also be affected. This will have a significant impact on normal business needs. A common scenario is single sign-on, where you only need to log in once when visiting different websites of a company. This is because the user's personal information is stored in a shared cookie of a common login service. With the disabling of third-party cookies, the login information cannot be shared anymore. Now, let's see how to solve these two problems.

Proposed Solutions#

Google provides four solutions for this:

Today, we will use the first method as an example with my Bilibili forum embedded content. You can refer to the other methods at https://developers.google.com/privacy-sandbox/3pcd?hl=en.

Since this is already a problem solved by an extension, and I don't have control over Bilibili (obviously), in the following cases, if you want to read third-party cookies, you need to have the ability to control the cookies of the third-party website you need (including writing an extension, but obviously it cannot be used in most cases where third-party cookies are required), or the ability to contact them to modify the cookie attributes for you.

This is how my extension code was written before:

let newCookie = {
            url: `https://bilibili.com`,
            name: cookie.name,
            value: cookie.value,
            domain: 'bilibili.com',
            path: cookie.path,
            secure: true,
            httpOnly: cookie.httpOnly,
            sameSite: "no_restriction",
            expirationDate: cookie.expirationDate
          };

This code is still valid in the current situation because I have set the SameSite value of these cookies to None. Here is the effect:

However!!!
If third-party cookies are disabled, this attribute cannot read the data anymore. The testing method is also provided in Chrome's article:

To support the 1% testing and maturation phases of deprecating third-party cookies in Chrome, we provide several Chrome flags.
In Chrome 121 and later, you can simulate the state after gradually phasing out third-party cookies:

Enable chrome://flags/#test-third-party-cookie-phaseout

Run Chrome with the flag --test-third-party-cookie-phaseout from the command line
This will set Chrome to block third-party cookies and ensure that the new features and mitigations are effective.

After setting it:

The cookie cannot be read on the i1.yuereqb.cn page, but it can be read on the embedded domain of the Twilight Block Forum. Considering whether the browser has forgotten to consider this situation.

Currently, the method given is that if you want to retain third-party cookies that need to be shared on the current website, you only need to add a Partitioned attribute when setting this cookie. Another prerequisite is that the cookie must have the Secure attribute:

Set-Cookie: name=name; SameSite=None; Secure; Path=/; Partitioned;

Currently, Chrome extensions cannot set the Partitioned attribute and will throw an error.

The reading mode of Partitioned is to read each site separately. Google has drawn a diagram to describe it:

The above diagram depicts the current situation without the partitioned cookie reading mode.

The above diagram depicts the situation after enabling the cookie partitioning feature. If a third-party service embeds a top-level website and sets a cookie, it will not be able to access the same cookie when embedded in other top-level websites.

The above diagram depicts the situation after enabling the cookie partitioning feature. If a third-party service sets a cookie when embedded in a website, even if the user accesses that service as a top-level website, the service will not be able to access the same cookie.

Therefore, the current situation is that the extension can only be like this. We must wait for future updates from Chrome to see if the extension has the permission to operate this. If not, this project can only be discontinued.

Recommendations for other services#

It is best to avoid using third-party cookies unless necessary. After all, cookies are just one way of transmitting information. In the future, try to use other methods. If it is necessary to read cookies, consider whether these cookies need to be read by third parties and then consider the situations of these third-party websites.

For now, we can only hope that the road ahead will not be so difficult...

That's all for now, more updates to come!