Cookie教程-partitioned属性（CHIPS）

partitioned属性机制有一个别名CHIPS，英文全称Cookies Having Independent Partitioned State。

partitioned属性是Cookie家庭的新成员，主流浏览器都会支持该属性，且后续有变动的可能性较小。 在第三方Cookie很快终结的背景下，partitioned属性变得越来越重要了。

用法

partitioned属性不区分大小写，没有值。

假设我们要设置的Cookie名称为x，值为value，带partitioned属性：

JavaScript设置方式：

document.cookie = "x=value; secure; path=/; partitioned;"

HTTP的设置方式：

Set-Cookie: x=value; secure; path=/; partitioned;

每次设置Cookie时，Partitioned只要不是放在最前面都可以。第一个;前的内容一定是Cookie的名称和值，其他任何属性放到最前面都会被浏览器解释为Cookie的名称或者值。

partitioned的含义

第三方Cookie即将被浏览器禁用，如果你还想使用第三方Cookie，只需要在设置第三方Cookie时，加上partitioned属性。

partitioned属性（CHIPS）是谷歌Privacy Sandbox计划的一部分，用于应对禁用第三方Cookie。

从业务角度理解 partitioned

加上partitioned属性虽然可以绕过浏览器对第三方Cookie的禁用，但是该第三方Cookie不再可以跨站点使用。

下面以两个实际场景为例，来帮助大家理解。

场景1：第三方Cookie禁用前

用户访问网站a.com =>

网站a.com用iframe内嵌了客服服务third-party.com =>

third-party.com客服服务在浏览器中种了一个Cookie userId用来标识当前用户。

后来用户又访问了b.com =>

网站b.com也用iframe内嵌了客服服务third-party.com =>

third-party.com客服服务可以访问到之前种的Cookie userId。

third-party.com客服服务可以通过HTTP的请求头referer得知自己被哪些网站使用过了，还可以通过Cookie userId得知用户访问了两个网站a.com和b.com。这就形成了对用户行为的跟踪，这是第三方Cookie要被禁用的主要原因。

一下图片来自Chrome开发者网站的官方文章，形象地展示了这种场景：

图片中，A内嵌的C和B内嵌的C和C自身可以供用相同的Cookie。

场景2：第三方Cooke禁用后

用户访问网站a.com =>

网站a.com用iframe内嵌了客服服务third-party.com =>

third-party.com客服服务想在浏览器中种一个Cookie userId用来标识当前用户，对用户的上网痕迹进行追踪，但是这个Cookie被浏览器拒绝了，因为浏览器已经禁用了第三方Cookie。

third-party.com客服服务追踪用户上网痕迹的想法落空。

third-party.com客服服务的产品经理认为不能追踪用户可以接受，因为这本身就是对用户隐私的窥探。

但是不能设置Cookie导致无法标识用户，从而保存聊天记录到服务端时，无法和用户的标识对应上，用户下次进入时将没有聊天记录。 这个是产品经理不能接受的，这个是客服服务的核心功能，没有这个功能会影响用户体验。

这时partitioned可以出场了。客服服务的开发人员说：我们可以给Cookie userId加上partitioned属性，这样我们还可以往浏览器里种Cookie，但是我们内嵌到a.com网站时种的Cookie只能在用户访问a.com网站时才能用，用户访问b.com网站时，虽然也内嵌了我们的服务，但是我们拿不到之前内嵌到a.com网站时种的Cookie，需要在内嵌到b.com网站时重新种Cookie。也就是说，我们虽然是第三方的服务，但是我们依然可以通过Cookie标识用户，但是我们不能跨站追踪用户了，因为虽然都是内嵌了third-party.com，但是两个网站中third-party.com种的Cookie不能共享。

从上面的例子可以看出partitioned的存在价值。禁用第三方Cookie是为了防止用户隐私泄露，但是禁用第三方Cookie有时也会损害用户体验，而partitioned属性可以让我们继续使用第三方Cookie，而且还不会让用户的隐私泄露。

因此严格来说，浏览器禁用第三方Cookie这个说法并不准确，准确的说是禁止了非partitioned的第三方Cookie。

一下图片来自Chrome开发者网站的官方文章，形象地展示了这种场景：

使用Partitioned属性后

图片中，A中内嵌的C单独存了一份Cookie，B中内嵌的C也单独存了一份。

另外C也无法单独获取在A和B环境下种的Cookie，请看下图：

第三方网站无法单独获取Partitioned的Cookie

从技术角度理解 partitioned

对于普通的没有partitioned属性的Cookie，我们可以理解为每个Cookie都使用一个域名作为Key。 例如：https://support.chat.example网站种一个Cookie，那它的Key有可能是support.chat.example或者chat.example，不管是哪个，他的Key只有一个。 但是使用partitinoed后，这个Cookie会有两个key，一个是Cookie所在HTTP服务的域名Key，还有一个叫做Partitioned Key，Partitioned Key是http://或https://加上当前用户访问的网站的域名所对应的一级域名。只有这两个Key同时满足时，才能被种它的HTTP服务访问到。

举例如下： 网站https://xxx.a.com嵌入了第三方客服服务third-party.com，第三方客服服务通过HTTP的Response种了一个Cookie userId。

种法如下：

Set-Cookie: userId=xxx; secure; path=/; partitioned;

有partitioned属性，因此该Cookie有两个Key，一个是它所属的域名：third-party.com，另一个是partitioned key：https://a.com。

这里有两点要注意：

1. partitioned key是带https://的。
2. partitioned key是https://a.com，而不是https://xxx.a.com，partitioned key总是当前浏览器访问网站的一级域名a.com，而不是正在访问的二级域名xxx.a.com。

我们再跳出Key的概念，可以这样来理解带partitioned属性的Cookie：

普通Cookie的访问受制于domain path 等等属性，而带partitioned属性的Cookie比普通Cookie多了一个限制条件就是partitioned key。

到这里相信大家应该对partioned有一个较为详细的认识了。

下图是partioned key在Chrome浏览器的开发者工具中的显示：

Partitioned Key在Chrome开发者工具中

至此Partitioned属性的主要内容就讲完了。它还有一些使用上的限制，我们继续往下看。

必须和 secure 一起使用

partitioned属性必须和secure属性一起使用，这就意味着它必须在https或者http://localhost的环境下使用，否则整个Cookie设置无效。

浏览器支持情况

Chrome 114 版本开始正式支持该属性。Chrome 114 版本2023年5月份才发版，国内使用的人还不多。 不过主流浏览器对于无法识别的Cookie属性都是直接忽略，并不会影响整个Cookie的设置，因此如果我们确实需要第三方Cookie，那可以把该属性加上。

结束语

partitioned属性（CHIPS）的讲解到此结束。