Three sides of Tencent: SameSite of Cookie, let’s understand, what about SameParty?

Hello everyone, I am Nian Nian!

Today, we will introduce the content related to third-party cookies. This article will make it clear:

1. What are third-party cookies?
2. What are the changes to the same-site and how will it affect our business?
3. Why do we need same-party when we have same-site?

The article was first published on my official account: front-end private education every year

What are third party cookies

The three parties refer to the non-same site. This same site is different from the source in the same-origin agreement origin , and its requirements are more relaxed.

The source in the same-origin protocol is defined by "protocol + domain name + port" together. If there is a difference, it is not a homologous source, and the same site is only constrained by the domain name, and does not require the same - as long as the "valid top-level" Domain name + second-level domain name” is the same, and they are considered the same site.

Valid TLDs are a table maintained by Mozilla that includes .com , .co.uk , .github.io , etc. Therefore, ai.taobao.com and www.taobao.com are on the same site, because their top-level domain name (.com) + second-level domain name (.taobao) are the same.

Now that you know what a station is, you can easily distinguish:

Open the application of the developer tools, the domain column shows that the three-party cookie is different from the current domain name

How to carry third-party cookies

The carrying of cookies is an automatic operation of the browser. The rule is "don't recognize the source, just look at the purpose". The meaning of this sentence will be explained below.

cookie delivery

First of all, you need to understand the delivery of cookies, the server will deliver them to the browser by passing the set-cookie field in the response header

It also includes some configuration properties, the key is the domain

domain

Specifies which domains the cookie can be carried to when it is used in the future. Its value can be set to the parent domain name of the current server or itself, such as ai.taobao.com The domain of the set cookie can be .taobao.com , and all subdomains of the set value can be used, such as www.taobao.com .

If you don't set it, it will default to the current domain name ai.taobao.com , and only you can use it yourself. The subdomain name sub.ai.taobao.com cannot be used, and the scope of application is much smaller, so it is generally set.

But it cannot be set to cross-site .baidu.com , nor can it be a top-level domain .com .

The rest of the properties are these:

1. path: Specifies which URIs the cookie can be carried to legitimate domain names when the cookie is used in the future. Similar to domain, it can only be set to the parent path of the current path or itself, and all child paths of the set value can be accessed.
2. expire/max-age: Specify the validity period of the cookie, where expire is an absolute time, max-age is a relative time, the unit is seconds, when both exist at the same time, max-age has a higher priority; if neither of them exist, then It is a session-level cookie, that is, it expires when the user closes the browser.

 Set-Cookie: id=nian; Expires=Wed, 30 Aug 2022 00:00:00 GMT; Max-Age=3600

3. secure: can only be issued and carried in an HTTPS environment
4. http-only: Prevents client-side scripts from obtaining cookies through document.cookie to avoid XSS attacks.
5. There are also the same-site and the same-party that will be highlighted below

Cookie carry

As mentioned above, the domain field of the cookie is very critical. It specifies which domain names are requested to be carried. Note that this refers to the domain name of the request destination.

For example, first I set a cookie in the browser through the response header, the domain is .a.com

 set-cookie: id=nian; domain=.a.com;

There are now three requests:

1. The front-end page of the webpage www.a.com/index.html , go to the request interface www.b.com/api
2. The front-end page of the webpage www.b.com/index.html , go to the request interface www.a.com/api
3. The front-end page of the webpage www.a.com/index.html , go to the request interface www.a.com/api

It's a bit confusing, you can pause to think for 10 seconds, which request will bring the previously set cookie?

The answer is that both 2 and 3 will bring cookies, because the cookie access rule is to see the destination of the request, 2 and 3 requests are all www.a.com/api hit domain=.a.com rule.

This is the meaning of "don't recognize the source, just look at the purpose", no matter where the request source is, as long as the purpose of the request is station a, the cookie will be carried.

This case can also be reviewed again: the case of 3 is called a first-party cookie, and the case of 2 is called a third-party cookie.

Restrict the carrying of third-party cookies

The rule of "don't recognize the source, only look at the purpose" began to be broken in 2020. This change is reflected in the browser setting same-site:lax as the default attribute.

Chrome's operation is relatively gentle, and currently it can be manually set same-site:none to restore the previous rules.

But if this is set in safari, it will be treated as same-site:strict

It can be seen that all first-party cookies are used in safari. The intuitive experience is that after logging in on Tmall and opening Taobao, you need to log in again.

That is to say, the use of cookies is now "seeing both the source and the purpose".

SameSite

The same-site mentioned above is an attribute of the cookie, which restricts the carrying of third-party cookies, and its values are three none , strict , lax .

1. strict represents the complete prohibition of third-party cookies, which is the strictest protection and can avoid CSRF attacks, but the shortcomings are also obvious, such as Tmall, Taobao, which are operated by the same subject, have to log in repeatedly;
2. none represents no restrictions at all, that is, the previous cookie access principle of "don't recognize the source, just look at the purpose";

3. Lax is a compromise. In some cases, it will restrict the carrying of third-party cookies, and in some cases, it will be allowed. This is also the default value of browsers (including safari).

   In safari, the default value of same-site is lax. If you set it to same-site:none, it will be counterproductive and will be treated as strict

   Modification of SameSite

   It can be understood that the browser adjusts the default value of same-site from none to lax

The specific rules for same-site:lax are as follows:

type	example	whether to send
a link	<a href="..."></a>	send
Preloading	<link rel="prerender" href="..."/>	send
GET form	<form method="GET" action="...">	send
POST form	<form method="POST" action="...">	Do not send
iframe	<iframe src="..."></iframe>	Do not send
AJAX	axios.post	Do not send
picture	<img src="..."></a>	Do not send

And before that all will be sent.

Impact of SameSite Modifications

Like a link, it is not affected, and it will still bring a third-party cookie, which can ensure that Taobao is opened from Baidu search, and there is a login state.

But the impact on most businesses is huge, such as monitoring the buried point system.

The buried point monitoring SDK uses the src of the image to send the request. From the above table, it can be seen that it will not be sent by default after it becomes lax. At this time, the user's identity cannot be confirmed, and the UV cannot be counted.

Why do you use the src of the picture for buried monitoring? I wrote an article in detail before, click here

In order to solve these problems, the current solution of most companies is to set same-site:none and cooperate with secure , so that they can continue to carry third-party cookies as before.

But this is not a version answer.

SameParty

As mentioned above, in order to bypass the browser's restriction on third-party cookies and ensure the normal operation of the business, our solution is to set the same-site back to none.

But this is not a long-term solution. First, the browser adjusts the default value of same-site from none to lax to avoid CSRF attacks and ensure security, but for the normal business It runs, but it turns back; secondly, chrome promises that in 2022, that is, this year, it will completely disable third-party cookies. At that time, like in safari, we can no longer use this method to hack.

If we don't want to use same-site:none, or in the future, same-party will be our only option.

What is SameParty

Continuing to use the example of the Ali system, same-party can combine the three stations .taobao.com , .tmall.com and .alimama.com , and the cookies they set are not in this set. will be treated as a third-party cookie.

First need to define a set of First-Party: In .taobao.com , .tmall.com and .alimama.com next three stations are added to the server a profile on /.well-know/ directory, named first-party-set .

One of them is the "group leader", tentatively set to be .taobao.com , and write it under its server

 // /.well-know/first-party-set
{
  "owner": ".taobao.com",
  "members": [".tmall.com", ".alimama.com"]
}

The other two are team members:

 // /.well-know/first-party-set
{
  "owner": ".taobao.com",
}

And, when sending cookies, you need to specify the same-party attribute:

 Set-Cookie: id=nian; SameParty; Secure; SameSite=Lax; domain=.taobao.com

In this way, when we open the website of .tmall.com .taobao.com and initiate an AJAX request to ---fdaa88ae60e777a54bfaff74af262da3---, we will bring this cookie, even if the current same-site attribute is lax, because the three domain names in this set will be treated as a station, that is, in the eyes of the browser, this cookie is now a first-party cookie.

AJAX requests initiated by baidu.com that are not in the collection will not be included.

It should be noted that when using the same-party attribute, you must use https (secure attribute) at the same time, and the same-site cannot be strict.

Epilogue

One of the restrictions on third-party cookies is for browser security, but the more important reason for promotion abroad is personal privacy security. But whatever the purpose, this change will have a big impact on the current business architecture.

same-site:lax becoming the default is a temporary warning, which restricts the use of third-party cookies in certain scenarios. Currently in a softer transition, as in most browsers we can simply adjust it back to same-site:none to lift these restrictions and work as unblocked as before.

But in the future, this restriction will not be able to be taken off, same-party is the version answer, with it, we can flexibly define which stations belong to the "first party" in the business sense, and which ones are what we want "Third Party".

If you think this article is helpful to you, please like and follow!

Your support is the driving force of my creation ❤️