允许开发者选择将 Cookie 放入“分区”存储，并为每个顶级网站使用单独的 Cookie jar。
实现状态
- Chrome 114 及更高版本默认支持。
- Chrome 100 至 Chrome 116 已有一项源试用现已结束，
- 阅读实验意图和发布意图。
什么是 CHIPS？
借助具有独立分区状态 (CHIPS) 的 Cookie，开发者可以选择将 Cookie 放入分区存储，并为每个顶级网站使用单独的 Cookie JAR，从而加强用户隐私保护和安全性。
在不进行分区的情况下，第三方 Cookie 可让服务跟踪用户，并联接来自多个不相关的顶级网站的用户信息。这就是所谓的跨网站跟踪。
浏览器正在逐步淘汰未分区的第三方 Cookie，因此当第三方 Cookie 被屏蔽时，CHIPS、Storage Access API 和 Related Website Set 将成为从跨网站环境（例如 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 时，当用户访问网站 A 且来自网站 C 的嵌入内容使用 Partitioned 属性设置 Cookie 时，此 Cookie 将保存在一个分区 jar 中，专门用于网站 C 在嵌入网站 A 时设置的 Cookie。只有当顶级网站为 A 时，浏览器才会发送该 Cookie。
当用户访问新网站（例如网站 B）时，嵌入的 C 框架将不会收到在网站 A 中嵌入时设置的 Cookie。
如果用户将网站 C 作为顶级网站进行访问，那么 C 在嵌入 A 时设置的分区 Cookie 也不会在该请求中发送。
用例
例如，retail.example 网站可能想与第三方服务 support.chat.example 合作，在其网站上嵌入支持聊天框。如今，许多嵌入式聊天服务依赖 Cookie 来保存状态。
support.chat.example 的顶级网站 retail.example。如果无法设置跨网站 Cookie，support.chat.example 将需要寻找替代方法（通常更为复杂）来存储状态。或者，需要将脚本嵌入到会带来风险的顶级页面中，因为这会让 support.chat.example 脚本获得对 retail.example 的提升权限，例如能够访问身份验证 Cookie。
CHIPS 可让您更轻松地继续使用跨网站 Cookie，而不会产生与未分区 Cookie 相关的风险。
CHIPS 应用场景包括：跨网站子资源需要某些会话或持久状态的概念，且范围限定为用户在单个顶级网站上的活动，例如：
- 第三方聊天嵌入内容
- 第三方地图嵌入
- 第三方付款嵌入
- 子资源 CDN 负载均衡
- 无头 CMS 提供商
- 用于提供不受信任的用户内容（例如 googleusercontent.com 和 githubusercontent.com）的沙盒网域
- 使用 Cookie 投放受第一方网站上的身份验证状态控制的内容（例如，在第三方 CDN 上托管的社交媒体网站上的个人资料照片）的第三方 CDN
- 依赖于远程 API 的前端框架，这些 API 在其请求中使用 Cookie
- 需要按发布商限定状态的嵌入式广告（例如，捕获用户对相应网站的广告偏好设置）
CHIPS 为何使用自选分区模型
随着浏览器逐步淘汰未分区的第三方 Cookie，我们还尝试了几种其他分区方法。
Firefox 宣布会在 ETP 严格模式和无痕浏览模式下默认对所有第三方 Cookie 进行分区，因此所有跨网站 Cookie 都会按顶级网站进行分区。然而，在没有第三方选择启用 Cookie 的情况下对 Cookie 进行分区可能会导致意外错误，因为某些第三方服务构建的服务器需要未分区的第三方 Cookie。
Safari 之前尝试过根据启发词语对 Cookie 进行分区，但最终选择完全阻止所有这些 Cookie，这是造成开发者混淆的原因之一。最近，Safari 曾对启用基于“选择启用”的模式表现出兴趣。
CHIPS 与分区 Cookie 的现有实现不同，在于第三方选择启用。在第三方 Cookie 被淘汰（未分区）后，必须使用新属性设置 Cookie，才能针对跨多方请求发送 Cookie。
虽然第三方 Cookie 仍然存在，但 Partitioned 属性可让您选择启用一种限制性更强、更安全的 Cookie 行为。CHIPS 是一个重要步骤，可帮助服务顺利过渡到不使用第三方 Cookie 的未来。
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")
条状标签之后
key={("support.chat.example"),("https", "retail.example")}
安全设计
为鼓励良好的安全做法，采用 CHIPS 时，Cookie 只能由安全协议设置和通过安全协议发送。
- 必须使用
Secure设置分区 Cookie。 - 建议在设置分区 Cookie 时使用
__Host前缀，以便将其绑定到主机名（而非可注册网域）。
例如：
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
CHIPS 的替代方案
Storage Access API 和关联的 Related Website Sets (RWS) 是网络平台机制，用于针对特定面向用户的特定目的，启用受限的跨网站 Cookie 访问权限。
这些是 CHIPS 分区的替代方案，需要访问跨站、未分区的烹饪。
如果您需要将同一 Cookie 用于嵌入多个相关网站的服务，可以考虑使用 Storage Access API 和 Related Website Set。
CHIPS 能够让服务充当多个网站的独立组件，而无需在多个网站上提供相同的 Cookie。如果该服务设置了分区 Cookie，其分区键将是顶级网站，并且该 Cookie 无法供同样使用该服务的其他网站使用。
Related Website Set 设计依赖于 Storage Access API，并且未与 CHIPS 分区集成。如果您的某个应用场景依赖于 RWS 中跨网站共享 Cookie 分区，您可以提供有关 GitHub 问题的示例和反馈。
演示
此演示将向您介绍分区 Cookie 的工作原理，以及如何在开发者工具中检查分区 Cookie。
网站 A 嵌入了来自网站 B 的 iframe，而网站 B 使用 JavaScript 设置两个 Cookie：分区 Cookie 和未分区 Cookie。网站 B 使用 document.cookie 显示从该位置访问的所有 Cookie。
屏蔽第三方 Cookie 后，网站 B 将只能在跨网站环境中使用 Partitioned 属性设置和访问 Cookie。
允许使用第三方 Cookie 时，网站 B 也能设置和访问未分区的 Cookie。
前提条件
- Chrome 118 或更高版本。
- 访问
chrome://flags/#test-third-party-cookie-phaseout并启用此设置
使用开发者工具检查分区 Cookie
- 访问 https://chips-site-a.glitch.me。
- 按
Control+Shift+J（在 Mac 上，按Command+Option+J）即可打开开发者工具。 - 点击 Application（应用）标签页。
- 依次转到 Application > Storage > Cookies。
- 点击
https://chips-site-b.glitch.me。
DevTools 会显示来自所选来源的所有 Cookie。
网站 B 只能在跨网站上下文中设置分区 Cookie，系统会屏蔽未分区 Cookie：
- 您应该会看到带有顶级网站
https://chips-site-a.glitch.me的分区键的__Host-partitioned-cookie。
- 点击前往网站 B。
- 在开发者工具中，导航至 Application > Storage > Cookies。
- 点击
https://chips-site-b.glitch.me。
在这种情况下，由于您在顶级上下文中位于网站 B，因此它可以设置和访问这两个 Cookie：
unpartitioned-cookie具有空的分区键。__Host-partitioned-cookieCookie 的分区键为https://chips-site-b.glitch.me。
如果您返回到网站 A，unpartitioned-cookie 现在会存储在浏览器中，但无法从网站 A 访问。
- 点击前往网站 A。
- 点击网络标签页。
- 点击
https://chips-site-b.glitch.me。 - 点击 Cookies 标签。
在网站 A 上，您应该会看到 __Host-partitioned-cookie 以及顶级网站 https://chips-site-a.glitch.me 的分区键。
如果您选中显示已过滤的 Cookie 请求，则开发者工具会显示未分区的 Cookie 已被屏蔽，并会以黄色突出显示，并附有提示：“此 Cookie 因用户偏好设置而被屏蔽”。
在 Application > Storage > Cookies 中，点击 https://chips-site-b.glitch.me 将显示：
unpartitioned-cookie替换为空分区键。- 具有分区键
https://chips-site-a.glitch.me的__Host-partitioned-cookieCookie。
__Host-partitioned-cookie Cookie 的分区键为 https://chips-site-a.glitch.me。unpartitioned-cookie，但是当网站 B 的 iframe 嵌入到网站 A 中时，该网站 B 的 iframe 将无法访问。清除 Cookie
要重置演示，请清除该网站的所有 Cookie：
- 按
Control+Shift+J（在 Mac 上，按Command+Option+J）即可打开开发者工具。 - 点击 Application（应用）标签页。
- 依次转到 Application > Storage > Cookies。
- 右键点击
https://chips-site-b.glitch.me。 - 点击清除。
资源
- GitHub：阅读说明文档、提出问题并关注讨论。
- 开发者支持：在 Privacy Sandbox 开发者支持代码库中提问并加入讨论。