2024 年 1 月 4 日，Chrome 浏览器已开始向 1% 的用户推出跨站 Cookie 停用计划。为了更好地兼容线上服务，Chrome 推出了一系列API，为诸如身份验证、广告和欺诈检测等用例提供了以隐私为重点的替代方案。

作为网站和服务开发者和运营者，为确保您的网站在没有第三方 cookie 的情况下可以正常运行，需要做好以下准备：

• 梳理第三方 cookie 的使用情况。
• 进行破坏测试。
• 对于存储在每个网站上的跨站点 cookie（例如嵌入式 cookie），请考虑使用 CHIPS 进行分区。
• 对于在一小组相关联网站之间的跨站点 cookie，请考虑使用相关网站集。
• 对于其他第三方 cookie 的使用情况，请迁移到相关的 Web API。

1.梳理第三方 cookie 的使用情况

Chrome开发者工具的网络面板显示请求中设置和发送的Cookie。在应用程序面板中，在存储下可以看到Cookie标题。您可以浏览每个访问的站点存储的Cookie，作为页面加载的一部分。您可以按照SameSite列进行排序，以将所有None Cookie分组。

第三方 cookie 可以通过其 SameSite=None 值来识别。您应该搜索代码以查找将 SameSite 属性设置为此值的实例。如果您在 2020 年左右之前对添加 SameSite=None 到您的 Cookie 进行了更改，那么这些更改可能是一个很好的起点。

Chrome DevTools 网络面板显示根据请求设置和发送的 cookie。在 Application 面板中，您可以在 Storage 下看到 Cookie。您可以浏览为页面加载过程中访问的每个站点存储的 cookie。您可以按列 SameSite 排序以对所有 None 值的 cookie 进行分组。

从 Chrome 118 开始，DevTools 问题选项卡显示了重大更改问题："跨站点上下文中发送的 Cookie 将在未来的 Chrome 版本中被阻止", 该问题列出了当前页面可能受影响的 cookie。

如果您发现第三方设置的 cookie，您应该与这些提供商核实，看看他们是否有逐步淘汰第三方 cookie 的计划。例如，您可能需要升级正在使用的库的版本、更改服务中的配置选项，或者如果第三方正在自行处理必要的更改，则不采取任何操作。

2.进行破坏测试

您可以使用 --test-third-party-cookie-phaseout 命令行标志或从 Chrome 118 开始，使用 chrome://flags/#test-third-party-cookie-phaseout 启用。这将设置 Chrome 阻止第三方 Cookie，并确保新功能和缓解措施处于活动状态，以最佳模拟淘汰后的状态。

您也可以尝试通过 chrome://settings/cookies 阻止第三方 Cookie 进行浏览，但请注意，该标志也确保了新功能和更新功能的启用。阻止第三方 Cookie 是检测问题的好方法，但并不一定能验证您已经修复了问题。

如果您为您的网站保持一个活跃的测试套件，那么您应该进行两次并行运行：一次是使用常规设置运行的 Chrome，一次是使用启用--test-third-party-cookie-phaseout 标志启动的相同版本的 Chrome。第二次运行中的任何测试失败而第一次运行中没有的都是需要调查的第三方cookie依赖的好候选项。请确保报告您发现的问题。

一旦您确定了存在问题的 Cookie并了解了它们的用例，您可以通过以下选项来选择必要的解决方案。

3.将 Partitioned Cookie 与 CHIPS 结合使用

如果您的第三方 Cookie 在与顶级站点进行 1:1 嵌入的上下文中使用，则可以考虑使用带有独立分区状态的 Cookie（CHIPS）的分区属性，以允许使用每个站点使用的单独的 Cookie 进行跨站点访问。

要实现 CHIPS，您需要将 Partitioned 属性添加到您的 Set-Cookie 头中：

通过设置 Partitioned，该网站选择将 cookie 存储在由顶级网站分隔的单独的 cookie 存储区。在上面的示例中，cookie 来自store-finder.site，该网站托管了一个店铺地图，用户可以保存他们喜欢的店铺。通过使用 CHIPS，当 brand-a.site 嵌入store-finder.site 时，fav_store cookie 的值为123。然后，当 brand-b.site 也嵌入 store-finder.site 时，他们将设置并发送自己分隔的fav_store cookie 实例，例如值为456。

这意味着嵌入式服务仍然可以保存状态，但没有允许跨站点跟踪的共享跨站点存储。

潜在的使用案例：第三方聊天嵌入、第三方地图嵌入、第三方支付嵌入、子资源内容分发网络（CDN）负载均衡、无头内容管理系统提供商、用于提供不受信任的用户内容的沙盒域名、使用 Cookie 进行访问控制的第三方 CDN、需要在请求中添加 Cookie 的第三方 API 调用、按发布商进行状态范围的嵌入广告。

4.使用相关网站集

当仅在一小部分相关网站上使用第三 Cookie 时，您可以考虑使用相关网站集合（RWS），以便在这些定义的网站上上下文中允许跨站点访问该Cookie。

要实施 RWS，您需要定义并提交网站组。为确保这些网站之间存在有意义的关联，有效集合的策略要求按以下方式对这些网站进行分组：具有可见关联的相关网站（如公司产品的变体）、服务域（如 API、CDN）或国家代码域（如 .uk、.jp）。

网站可以使用 Storage Access API 来请求跨站点的 Cookie 访问权限，使用 requestStorageAccess() 方法或使用requestStorageAccessFor() 方法委派访问权限。当网站在同一组中时，浏览器会自动授予访问权限，并且跨站点的 Cookie将可用。

这意味着相关网站的组仍然可以在有限的上下文中使用跨站点的 Cookie，但不会冒着以允许跨站点追踪的方式在不相关的站点之间共享第三方cookie的风险。

潜在的用例包括：特定于应用程序的域，特定于品牌的域，特定于国家的域，用于提供不受信任的用户内容的沙盒域，用于API的服务域，CDN。

5.迁移到相关的 Web API

CHIPS 和 RWS 能够在保护用户隐私的同时实现特定类型的跨站点 Cookie访问，但是其他使用第三方 Cookie 的实例必须迁移到以隐私为重点的替代方案。

Privacy Sandbox 提供了一系列针对特定用例的专用API，无需使用第三方cookie：

• 联合身份管理(FedCM)允许用户登录到站点和服务。
• 私有状态令牌通过在站点之间交换有限的、非识别信息，实现反欺诈和反垃圾邮件功能。
• 主题功能实现基于兴趣的广告和内容个性化。
• 受保护的受众功能实现再营销和自定义受众。
• 属性报告功能实现广告展示和转化的测量。

此外，Chrome 还支持 Storage Access API (SAA)，用于用户交互框架中的使用。SAA 已经在 Edge，Firefox 和 Safari 上得到支持。我们认为它在保持用户隐私的同时，仍然能够实现关键的跨站点功能，并具有跨浏览器的兼容性。

请注意，Storage Access API (SAA) 将向用户显示浏览器权限提示。为了提供最佳的用户体验，只有在调用 requestStorageAccess() 的站点与嵌入页面进行交互并之前在顶级上下文中访问过第三方站点时，才会提示用户。成功授权将允许该站点在 30 天内跨站点访问 Cookie。可能的用例包括认证的跨站点嵌入，如社交网络评论小部件、支付提供商、订阅视频服务。快速了解 Storage Access API

最后，如果您仍然有未被这些选项覆盖的第三方 Cookie 用例，您应该向 Chrome 团队报告该问题，并考虑是否有不依赖于启用跨站点跟踪的功能的替代实现。