具有独立分区状态 (CHIPS) 的 Cookie

允许开发者选择将 Cookie 纳入“分区”存储空间，每个顶级网站都有单独的 Cookie Jar。

实现状态

• Chrome 114 及更高版本默认支持。
• Chrome 100 至 Chrome 116 已有一项源试用现已结束，
• 阅读实验意图和发布意图。

什么是 CHIPS？

借助具有独立分区状态的 Cookie (CHIPS)，开发者可以选择将 Cookie 纳入分区存储，每个顶级网站都有单独的 Cookie 容器，从而提高用户隐私保护和安全性。

如果不进行分区，第三方 Cookie 可让服务跟踪用户，并从许多无关的顶级网站中联接用户的信息。这称为跨网站跟踪。

在第三方 Cookie 被屏蔽的情况下，只有 CHIPS、Storage Access API 和 Related Website Sets 才能从跨网站上下文（例如 iframe）读取和写入 Cookie。

CHIPS 引入了一项新的 Cookie 属性 Partitioned，以支持按顶级上下文分区的跨网站 Cookie。

Set-Cookie 标头：

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

JavaScript:

document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"

分区第三方 Cookie 与最初设置它的顶级网站相关联，无法从其他位置访问。这样，第三方服务设置的 Cookie 只能在最初设置这些 Cookie 的顶级网站的同一嵌入式环境中读取。

使用分区 Cookie 时，如果用户访问网站 A，并且来自网站 C 的嵌入式内容设置了带有 Partitioned 属性的 Cookie，则该 Cookie 会保存在一个分区 jar 中，该 jar 仅用于存储网站 C 在嵌入到网站 A 时设置的 Cookie。仅当顶级网站为 A 时，浏览器才会发送该 Cookie。

当用户访问新网站（例如网站 B）时，嵌入的 C 框架不会收到在 C 嵌入网站 A 时设置的 Cookie。

如果用户将网站 C 作为顶级网站进行访问，那么 C 在嵌入到 A 中时设置的分区 Cookie 也不会随该请求发送。

使用场景

例如，网站 retail.example 可能希望与第三方服务 support.chat.example 合作，在其网站上嵌入支持聊天框。如今，许多可嵌入的聊天服务都依赖 Cookie 来保存状态。

如果无法设置跨网站 Cookie，support.chat.example 就需要寻找替代方法（通常更复杂）来存储状态。或者，它需要嵌入到顶级网页中，这会带来风险，因为这会允许 support.chat.example 脚本在 retail.example 上拥有更高的权限，例如能够访问身份验证 Cookie。

CHIPS 提供了一种更简单的选项，可让您继续使用跨网站 Cookie，而无需承担与未分区 Cookie 相关的风险。

CHIPS 的使用情形示例包括任何需要某种会话概念或持久状态的跨网站子资源，这些子资源的作用范围限定为用户在单个顶级网站上的活动，例如：

• 第三方聊天嵌入
• 第三方地图嵌入
• 第三方付款嵌入
• 子资源 CDN 负载均衡
• 无头 CMS 提供商
• 用于提供不受信任的用户内容的沙盒网域（例如 googleusercontent.com 和 githubusercontent.com）
• 使用 Cookie 提供受第一方网站上的身份验证状态控制的内容的第三方 CDN（例如，托管在第三方 CDN 上的社交媒体网站上的个人资料照片）
• 依赖于在请求中使用 Cookie 的远程 API 的前端框架
• 需要按发布商确定状态范围的嵌入式广告（例如，捕获用户对相应网站的广告偏好设置）

为何 CHIPS 使用选择启用分区模型

在无法访问未分区第三方 Cookie 的情况下，我们尝试了其他几种分区方法。

Firefox 宣布，在 ETP 严格模式和无痕浏览模式下，他们将默认对所有第三方 Cookie 进行分区，因此所有跨网站 Cookie 都会按顶级网站进行分区。不过，在没有第三方选择启用分区 Cookie 的情况下对 Cookie 进行分区可能会导致意外的 bug，因为某些第三方服务构建的服务器需要未分区的第三方 Cookie。

Safari 之前曾尝试基于启发式方法对 Cookie 进行分区，但最终选择完全屏蔽 Cookie，并以开发者困惑为由说明了原因。最近，Safari 表示对基于选择接受的模式感兴趣。

CHIPS 与现有分区 Cookie 实现的不同之处在于第三方选择启用。必须使用新属性设置 Cookie，才能在（未分区的）第三方 Cookie 被弃用后，在跨方请求中发送 Cookie。

虽然第三方 Cookie 仍然存在，但 Partitioned 属性可选择启用更严格、更安全的 Cookie 行为。CHIPS 是一项重要措施，可帮助服务顺利过渡到不使用第三方 Cookie 的未来。

Cookie 分区技术设计

如今，Cookie 是根据设置它们的网站的主机名或网域（即它们的主机键）来确定键的。

例如，对于来自 https://support.chat.example 的 Cookie，主机键为 ("support.chat.example")。

在 CHIPS 下，选择加入分区的 Cookie 将通过其主机密钥和分区密钥进行双重键控。

Cookie 的分区键是浏览器在开始向设置 Cookie 的端点发出请求时所访问的顶级网址的网站（方案和可注册的网域）。

在前面的示例中，https://support.chat.example 嵌入在 https://retail.example 中，因此顶级网址为 https://retail.example。

在这种情况下，分区键为 ("https", "retail.example")。

同样，请求的分区键是指浏览器在请求开始时访问的顶级网址的网站。浏览器必须仅在具有与 Partitioned 属性相同的分区键的请求中发送具有该属性的 Cookie。

以下示例展示了之前的 Cookie 键在采用 CHIPS 前后的样子。

CHIPS 之前

key=("support.chat.example")

CHIPS 之后

key={("support.chat.example"),("https", "retail.example")}

安全设计

为了鼓励良好的安全实践，借助 CHIPS，Cookie 只能通过安全协议设置和发送。

• 必须使用 Secure 设置分区 Cookie。
• 建议在设置分区 Cookie 时使用 __Host- 前缀，以使这些 Cookie 绑定到主机名（而不是可注册的网域）。

示例：

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

CHIPS 的替代方案

Storage Access API 和关联的 Related Website Set (RWS) 是一种 Web 平台机制，可实现有限的跨网站 Cookie 访问，以满足特定的面向用户的用途。

这些是 CHIPS 分区的替代方案，需要访问跨网站的未分区 Cookie。

如果您需要让嵌入在多个相关网站中的服务能够访问同一 Cookie，请考虑使用 Storage Access API 和 Related Website Sets。

借助 CHIPS，服务可以作为隔离的组件跨多个网站运行，而无需在多个网站上提供相同的 Cookie。如果服务设置了分区 Cookie，其分区键将是顶级网站，并且该 Cookie 将无法供同样使用该服务的其他网站使用。

Related Website Set 设计依赖于 Storage Access API，并且不与 CHIPS 分区集成。如果您有依赖于 RWS 中跨网站的共享 Cookie 分区的用例，可以在 GitHub 问题中提供示例和反馈。

演示

此演示将引导您了解分区 Cookie 的工作方式，以及如何在开发者工具中检查分区 Cookie。

网站 A 嵌入了网站 B 的 iframe，该 iframe 使用 JavaScript 设置了两个 Cookie：一个分区 Cookie 和一个未分区 Cookie。网站 B 使用 document.cookie 显示可从该位置访问的所有 Cookie。

当第三方 Cookie 被屏蔽时，网站 B 将只能在跨网站情境中设置和访问具有 Partitioned 属性的 Cookie。

如果允许使用第三方 Cookie，网站 B 也能够设置和访问未分区的 Cookie。

前提条件

1. Chrome 118 或更高版本。
2. 前往 chrome://flags/#test-third-party-cookie-phaseout 并启用此设置

使用开发者工具检查分区 Cookie

1. 访问 https://chips-site-a.glitch.me。
2. 按 Control+Shift+J（在 Mac 上，按 Command+Option+J）打开开发者工具。
3. 点击应用标签页。
4. 依次前往应用 > 存储空间 > Cookie。
5. 点击 https://chips-site-b.glitch.me。

开发者工具将显示所选来源的所有 Cookie。

网站 B 只能在跨网站上下文中设置分区 Cookie，未分区的 Cookie 将被阻止：

• 您应该会看到 __Host-partitioned-cookie，其中包含顶级网站 https://chips-site-a.glitch.me 的分区键。

1. 点击前往网站 B。
2. 在开发者工具中，依次前往应用 > 存储空间 > Cookie。
3. 点击 https://chips-site-b.glitch.me。

在此场景中，由于您位于顶级上下文中的网站 B 上，因此可以设置和访问以下两个 Cookie：

• unpartitioned-cookie 具有空分区键。
• __Host-partitioned-cookie cookie 具有分区键 https://chips-site-b.glitch.me。

如果您返回到网站 A，unpartitioned-cookie 现在会存储在浏览器中，但无法从网站 A 访问。

1. 点击前往网站 A。
2. 点击网络标签页。
3. 点击 https://chips-site-b.glitch.me。
4. 点击 Cookies 标签。

在网站 A 上，您应该会看到 __Host-partitioned-cookie，其中包含顶级网站的分区键 https://chips-site-a.glitch.me。

如果您勾选显示过滤掉的 Cookie 请求，DevTools 会显示未分区的 Cookie 已被屏蔽，并以黄色突出显示，同时显示以下提示：此 Cookie 因用户偏好设置而被屏蔽。

在 Application > Storage > Cookies 中，点击 https://chips-site-b.glitch.me 将显示：

• 将 unpartitioned-cookie 替换为空分区键。
• 具有分区键 https://chips-site-a.glitch.me 的 __Host-partitioned-cookie Cookie。

清除 Cookie

如需重置演示，请清除该网站的所有 Cookie：

• 按 Control+Shift+J（在 Mac 上，按 Command+Option+J）打开开发者工具。
• 点击应用标签页。
• 依次前往应用 > 存储空间 > Cookie。
• 右键点击 https://chips-site-b.glitch.me。
• 点击清除。

资源

• GitHub：阅读解释器，提出问题并关注讨论。
• 开发者支持：在 Privacy Sandbox 开发者支持代码库中提问和参与讨论。