Chrome 计划从 2024 年第一季度开始对 1% 的用户禁用第三方 Cookie，以方便大家测试。然后从 2024 年第三季度开始将禁用范围扩大到 100%。

如果你的网站还在使用第三方 Cookie，现在就该采取行动了，留给留给三方 Cookie 的时间，不多了！

三方 Cookie 为 Web 提供了跨站点跟踪的能力，它的存在为 Web 用户的个人隐私带来了巨大威胁，这就是各大浏览器纷纷开始将其弃用的原因，具体可以看我这篇文章：

当浏览器全面禁用三方 Cookie
这篇文章写于 2020 年，当时 Chrome 已经有了初步想要弃用三方 Cookie 的想法。如今三年多过去了，Chrome 才下定决心正式退出禁用计划。主要还是因为三方 Cookie 的影响太大了， 不仅仅是 Google，直接禁用会对当时的互联网广告功能带来重创，而且会影响很多网站正常的功能（例如登陆）的使用。

这三年多的时间 Chrome 一直在开发一套既能够减少跨站点跟踪，同时也能正常保障每个人都能自由访问在线内容和服务的功能，这就是 隐私沙盒：

Chrome 隐私沙盒简介

隐私沙盒提供了一系列 API，为身份、广告和欺诈检测等用例的现状提供了以隐私为基础的替代方案。有了这个替代方案，现在终于可以开始逐步淘汰第三方 Cookie 了。

审查网站的三方 Cookie 使用情况
为了弄清楚这项禁用的影响，首先我们要知道我们的网站上到底有那些地方使用了三方 Cookie。
第一个，我们可以通过 Cookie 的 SameSite 属性来进行识别，它是用于设置浏览器在发送跨站点请求时是否允许携带 Cookie 的策略。SameSite 属性有三个可能的值：
Strict（严格）：当设置为 Strict 时，浏览器将只在当前网页的域名与 Cookie 所属的域名完全一致的情况下才发送该 Cookie 。
Lax（宽松）：当设置为 Lax 时，浏览器将在导航到目标网页的情况下发送 Cookie，但仅限于顶级导航（如点击链接或通过 URL 导航）。在跨域的 POST 请求或通过 iframe 加载的请求中，浏览器将不会发送 Cookie。

None（无）：当设置为 None 时，浏览器将始终发送 Cookie，无论请求是同站点还是跨站点。但是，要使用 None 值，还需要同时设置 Secure 属性，以确保仅在使用 HTTPS 安全连接时发送 Cookie。

在 Chrome 80 版本中，将 Cookie 的 SameSite 属性默认设置为了 Lax，很多场景下，我们想要保留跨站 Cookie 的携带能力，必须要主动设置 SameSite=None，所以我们可以去代码里搜索设置了 SameSite=None 的 Cookie ，一定是三方 Cookie。

我们可以打开 Chrome DevTools 的 Application 面板，找到 Cookie ，然后按照 SameSite 进行排序：

另外，从 Chrome 118 开始，DevTools Issues 选项卡开始提示此类问题：跨站点上下文中发送的 Cookie 将在未来的 Chrome 版本中被阻止。

做个禁用测试
如果你想直接感受禁用三方 Cookie 后会给你的网站带来什么影响，可以尝试使用 --test-third-party-cookie-phaseout 命令行标志启动 Chrome，或者从 Chrome 118 启用 chrome://flags/#test-third-party-cookie-phaseout。这将设置 Chrome 直接阻止第三方 Cookie。

你还可以尝试使用通过 chrome://settings/cookies 阻止的第三方 Cookie 进行浏览：

三方 iframe 的 Cookie
三方 Cookie 一个非常常见的场景就是 iframe 嵌入。比如现在有一个通用的聊天服务，由第三方服务 support.chat.example 提供支持，我们的网站 retail.example 希望用 iframe 的方式嵌入这个聊天框。这个嵌入式的聊天服务可能会依赖 Cookie 来保存用户的交互历史记录。

像这种场景，我们就可以使用 Partitioned 属性作为具有独立分区状态 (CHIPS) 的 Cookie 的一部分，从而可以使用单独的分区进行跨站点访问。

要实现 CHIPS，我们可以将 Partitioned 属性添加到 Set-Cookie 标头中。通过设置 Partitioned，就可以将站点选择将 Cookie 存储在由顶级站点分区的单独 Cookie jar 中。比如我们在站点 A 中通过 iframe 嵌入了一个站点 C，正常情况下如果三方 Cookie 被禁用后，C 是无法在 A 站点访问到它的 Cookie 的。

如果 C 在它的 Cookie 上指定了 Partitioned 属性，这个 Cookie 将保存在一个特殊的分区 jar 中。它只会在站点 A 中通过 iframe 嵌入站点 C 时才会生效，浏览器会判定只会在顶级站点为 A 时才发送该 Cookie。当用户访问一个新站点时，例如站点 B，如果也它通过 iframe 嵌入了站点 C，这时在站点 B 下的站点 C 是无法访问到之前在 A 下面设置的那个 Cookie 的。

如果用户直接访问站点 C ，一样也是访问不到这个 Cookie 的。

下面是一些潜在的使用场景：
第三方聊天嵌入
第三方地图嵌入
第三方支付嵌入
子资源 CDN 负载平衡
用于服务不受信任的用户内容的沙箱
使用 Cookie 进行访问控制的第三方 CDN
第三方需要请求 Cookie 的 API 调用方

嵌入式广告

相关站点的 Cookie
如果我们的第三方 Cookie 仅在少数相关站点上使用，那么可以考虑使用相关网站集(RWS) 来允许在这些定义站点的上下文中跨站点访问该 Cookie。相关网站集(RWS) 听起来是个新概念，其实我在之前的文章：详解 Cookie 新增的 SameParty 属性 也有介绍过，但是当时还叫 Cookie 的第一方集。比如我们同样的网站内容，因为在不同地区提供服务，所以使用了多个域名，比如：www.17.cn.com、www.17.us.com 等等。

像这样的具有可见关系的关联站点（例如公司产品的变体）、服务域（例如 API、CDN），或国家/地区代码域（例如 *.cn、*.jp）等等，我们都可以将它们添加到相关网站集(RWS) 中来实现三方 Cookie 的共享。

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com", "https://associate4.com"],
  "serviceSites": ["https://servicesite1.com"],
  "rationaleBySite": {
    "https://associate1.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
    "https://associate2.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
    "https://associate3.com": "An explanation of how you clearly present the affiliation across domains to users and why users would expect your domains to be affiliated",
    "https://serviceSite1.com": "An explanation of how each domain in this subset supports functionality or security needs."
  },

  "ccTLDs": {
    "https://associate1.com": ["https://associate1.ca", "https://associate1.co.uk", "https://associate1.de"],
    "https://associate2.com": ["https://associate2.ru", "https://associate2.co.kr", "https://associate2.fr"],
    "https://primary.com": ["https://primary.co.uk"]
  }

站点可以使用 Storage Access API 通过 requestStorageAccess() 请求访问跨站点 Cookie ，或使用 requestStorageAccessFor() 委托访问。当站点位于同一组内时，浏览器将自动授予访问权限，并且跨站点 Cookie 是可用的。

这意味着相关网站组仍然可以在有限的上下文中使用跨网站 Cookie，但这仅限于你指定的一组互相关联且信任的站点集合，不要冒险以允许跨网站跟踪的方式跨不相关网站共享第三方 Cookie，否则这就失去了它原本的意义了。

潜在的应用场景：
特定于应用程序的域名
特定于品牌的域名
特定于国家/地区的域名
用于服务不受信任的用户内容的沙箱域名

API、CDN 的服务域名

其他场景
CHIPS 和 RWS 支持保留特定类型的跨站点 Cookie 访问，同时也保护了用户隐私，但是第三方 Cookie 的其他用例必须迁移到注重隐私的替代方案。

Privacy Sandbox 为特定用例提供了一系列专门构建的 API，无需第三方 Cookie：
Federated Credential Management (FedCM)：支持联合身份服务，允许用户登录站点和服务。
Private State Tokens：通过跨站点交换有限的非识别信息来实现反欺诈和反垃圾邮件。
Topics：支持基于兴趣的广告和内容个性化。
Protected Audience：支持再营销和自定义受众群体。
Attribution Reporting：可以衡量广告转化率。
此外，Chrome 也支持 Storage Access API (SAA) ，以便在 iframe 中与用户交互使用。Edge、Firefox 和 Safari 均已支持 SAA 。它在维护用户隐私的同时仍然启用关键的跨站点功能并具有跨浏览器兼容性的优势，取得了良好的平衡。

Storage Access API (SAA) 会主动向用户显示浏览器权限提示。为了提供最佳的用户体验，只有当网站调用requestStorageAccess() 与嵌入页面进行过交互并且之前在顶级上下文中访问过第三方网站时，才会提示用户。成功授予权限后，该网站将允许跨站点 Cookie 访问 30 天。

潜在的用例是经过身份验证的跨站点嵌入，例如社交网络评论小部件、支付提供商、订阅的视频服务等等。

最后
为了避免业务受到影响，大家尽快审查一下自己网站上的三方 Cookie ，并且迁移到合适的替代方案上吧。