准备好迎接三方 Cookie 的终结

今天继续来为大家解读今年的 Google I/O

在这个章节我们将关注 Web 上的隐私沙箱并分享如何为三方 Cookies 的终结做好准备。 Privacy Sandbox 是一组提案，可以帮助我们解决用户身份追踪的问题，Chrome 也将在不久的未来停止支持第三方 Cookies。我们可以在 privacysandbox.com/timeline 查看最新信息（我们可以在时间性中看到，在明年的第三季度，三方 Cookie 将被禁用）。

Chrome 已经在消除 Web 中的用户追踪信息方面取得了一些进展：

• Chrome 85 中推出了 HTTP Cache Partitioning （对 HTTP 缓存的缩减）
• Chrome 92 开始逐步实施 User Agent 字符串的缩减（注意以后再也不能用 UA 精确标识一个用户了）
• Chrome 108 中推出了 Network State Partitioning（对网络状态的缩减）
• Chrome 113 中推出了 Storage Partitioning（存储分区，如果我们的站点含有依赖存储的嵌入式内容，例如 IndexedDB、Local Storage 和 Session Storage，并且可以跨多个顶级站点进行访问就可能收到影响）

不过这些信息的削减也给开发者带来了不小的负担，影响了很多正常的业务场景，我之前的文章中也有过相关的介绍：Chrome：听说你们滥用 UA? 废了它！、新的浏览器缓存策略变更：舍弃性能、确保安全

识别三方 Cookie

随着 Chrome 中三方 Cookie 终结的日益临近，Chrome 希望确保我们具备足够的知识和工具来为站点做好迁移准备工作。比如我们可以利用 First-Party Sets 和 CHIPS 来迁移和远离第三方 Cookie。特别是如果我们会负责一个或多个站点，可能在代码中很多地方使用 Cookie，其中一些 Cookie 可能是第三方 Cookie。下面会介绍一些 Chrome 的 Web 标准提案，用于替换默认和被动访问第三方 Cookie 的行为。

根据用户所在的上下文，Cookie 可以是一方或第三方。Web 上的这种一方和第三方上下文之间的区别并不总是很明显的，并且它对不同资源的影响可能会有所不同。通常，发送到跨站点上下文的 Cookie（例如，iframe 或子资源请求）被称为第三方 Cookie。

我们也可以在自己的计算机上设置阻止第三方 Cookie 并尝试浏览我们的站点，在 Network 中来识别第三方 Cookie。 三方 Cookie 在保护用户隐私方面存在很大的问题，但它们现在也是 Web 功能的关键组成部分。三方 Cookie 使内容和服务的组合更加灵活，进而为全球用户创造出更好的用户体验。

比如在线电商网站上的嵌入式地图和聊天小部件、同系列产品共享登录状态等，这些都是正常会依赖三方 Cookie 的业务场景。所以 Chrome 会希望尽量在不影响用户体验的情况下，也能禁用掉 Cookie 从而保护用户的隐私。

Chrome 为此已经专门构建了很多 API（如 Topics API 和 Federated Credential Management），以及通过一些 Web 的标准提案来限制 Cookie 的使。其中一些合作的提案现在已经在 Chrome 中推出使用了，包括 CHIPS 和 First-Party Sets，下面介绍一下这两个提案。

CHIPS

第三方库或三方的通用服务是需要使用三方 Cookie 最常见的场景。例如网站上的嵌入式地图和聊天小部件。在这种情况下，三方服务的提供者需要在每个父级网站上维护一些 Cookie 或状态，比如用户的聊天记录、选择过的商品等等。这就是 CHIPS（具有独立分区状态的 Cookie）的用处所在。

我们只需要添加一个额外的 Cookie 属性 partitioned，我们的跨站点 Cookie 就会在每个父级网站上自动获得一个不同的 Cookie Jar，从而防止用户在不同站点之间被跟踪。

使用 CHIPS 可以为用户带来更私密的体验。我们不需要等待三方 Cookie 被淘汰，现在就可以把我们的网站迁移到使用 CHIPS。如果大家以前查看过 CHIPS，在本次 Google I/O 上介绍 CHIPS 以来，Chrome 基于 Web 开发者的一些反馈进行了两项更改：

• 第一，Chrome 删除了主机前缀命名和主机名边界性的要求。虽然这个要求的原始意图是鼓励安全最佳实践，但许多开发者告诉我们，他们目前在子域中大量使用 Cookie，这个要求会给造成很大的迁移负担。
• 第二，Chrome 将以前每个分区的 Cookie 限制从 10 个更改为每个分区的动态内存限制为 10KB。

这限制了开发者可以使用少量的大型 Cookie，或者使用大量的小型 Cookie。

First-Party Sets

根据域名的不同来定义 Cookie 属于第三方有点太狭隘了，毕竟一个公司不可能只有一个域名：

但是当启用了三方 Cookie 的限制后，同一组织下不同域名的 Cookie 共享就很困难了。

First-Party Sets 是一个框架，可以用于开发者来声明域之间的关系，浏览器可以基于第三方域与第一方域之间的关系做出决策。这个框架有三个不同的子集，来满足 Web 上的一些关键用例。

• ccTLDs 域名：网站可能服务于不同的国家，在每个地区都有一个特定的域名，比如 conardli.cn、conardli.jp、conardli.en 等等；
• Service 域名：网站可能会使用特定的域名来保证安全性或者提高性能，但是这些不同域名的网站可能也需要共享用户身份。
• Associated 域名：同一个组织下可能有多个不同的子品牌，对应不同的域名，例如 bytedance.com、douyin.com 就属于这种情况。

对于这些集合，开发者需要向 Chrome 提供的公共 Gtihub 提交一个申请，并确保集合的完整性，以保证特定的技术验证检查和浏览器处理行为。

当浏览器收到 Storage Access API 发出的请求时，它会去确认这个第三方域和第一方域是否在同一集合中，并授予访问请求。

从用户的角度来看，First-Party Sets 可以被看作是同一组相关的站点，他们将能够切换控制来允许 Chrome 基于 First-Party Sets 列表做出访问的决策，同时也能够看到他们正在访问的站点是否在第一方集中，以及他们曾经访问过的其他站点是否在同一集合中。

通过使用 CHIPS 和第一方集，Chrome 团队希望在尽可能不影响用户体验的情况下保护用户隐私。如果大家正在准备迁移远离第三方 Cookie，建议仔细阅读下这些资源，并在禁用之前采取适当的措施。