如果您的网站使用了第三方 Cookie，请及时采取行动，因为我们即将弃用第三方 Cookie。为方便测试，自 2024 年 1 月 4 日起，Chrome 已限制 1% 的用户使用第三方 Cookie。Chrome 计划从 2024 年第 3 季度起逐步将第三方 Cookie 的使用限制范围扩大至 100% 的用户，但前提是要化解英国竞争和市场管理局可能尚未解决的任何竞争问题。
Privacy Sandbox 的目标是减少跨网站跟踪，同时仍实现使每个人都能免费访问在线内容和服务的功能。弃用和移除第三方 Cookie 有助于应对这一挑战，因为这些 Cookie 可实现登录、欺诈防护、广告等关键功能，并且通常能够在您的网站中嵌入丰富的第三方内容，但同时它们也是跨网站跟踪的主要驱动因素。
在我们之前的重大里程碑中，我们推出了一系列 API，为身份、广告和欺诈检测等使用场景提供以隐私保护为中心的替代方案，可取代当今的现状。有了替代方案，我们现在可以开始逐步停用第三方 Cookie。
在此 Cookie 倒计时系列视频中，我们将带您了解时间表和您可以立即采取的行动，以确保您的网站做好准备。
弃用了 1% 的第三方 Cookie 以及 Chrome 协助测试
在 privacysandbox.com 时间表上，您可以看到 2023 年第 4 季度和 2024 年第 1 季度的两个里程碑，它们是 Chrome 协助测试模式的一部分。此测试主要面向测试 Privacy Sandbox 相关性和效果衡量 API 的组织，但在此过程中，我们将为 1% 的 Chrome 稳定版用户停用第三方 Cookie。
这意味着，从 2024 年初开始，即使您未积极参与 Chrome 协助测试，在停用第三方 Cookie 的情况下，也会有更多 Chrome 用户访问您的网站。该测试期将持续到 2024 年第 3 季度。在与 CMA 协商后，为了解决与竞争相关的顾虑，我们计划开始为所有 Chrome 用户停用第三方 Cookie。
为逐步弃用第三方 Cookie 做好准备
我们已将该流程分为以下关键步骤（详见下文），以确保您的网站在没有第三方 Cookie 的情况下也能正常运行：
- 审核您的第三方 Cookie 使用情况。
- 测试破坏情况。
- 对于按网站存储数据的跨网站 Cookie（例如嵌入代码），请考虑使用采用 CHIPS 的
Partitioned。 - 如果要在少数一组有意义的关联网站上使用跨网站 Cookie，请考虑使用 Related Website Set。
- 对于其他第三方 Cookie 用例，请迁移至相关的 Web API。
1. 审核您的第三方 Cookie 使用情况
第三方 Cookie 可以通过其 SameSite=None 值来识别。您应该搜索代码，查找将 SameSite 属性设为此值的实例。如果您之前做出了更改，在 2020 年左右向您的 Cookie 添加 SameSite=None，那么这些更改可能会为您提供很好的切入点。
Chrome DevTools
Chrome DevTools 的 Network 面板会显示 Cookie 的设置和发送的请求。在“应用”面板中，您可以看到“存储”下方的“Cookie”标题。您可以浏览为网页加载过程中访问的每个网站存储的 Cookie。您可以按 SameSite 列排序，将所有 None Cookie 分组。
从 Chrome 118 开始，开发者工具的“问题”标签页会显示破坏性更改问题：“在未来的 Chrome 版本中，跨网站上下文发送的 Cookie 将被阻止”。此问题会列出当前网页上可能受影响的 Cookie。
Privacy Sandbox 分析工具 (PSAT)
我们还构建了 Privacy Sandbox Analysis Tool (PSAT)，这是一种开发者工具扩展程序，有助于分析浏览会话期间的 Cookie 使用情况。这为 Cookie 和 Privacy Sandbox 功能提供了调试途径，并提供用于详细了解 Privacy Sandbox 计划的接入点。
该扩展程序对开发者工具进行了补充，增加了专用功能，用于分析和调试与弃用第三方 Cookie 和采用新的可保护隐私的替代方案相关的情景。
您可以从 Chrome 应用商店下载该扩展程序，也可以访问 PSAT 代码库和 Wiki。
使用 Cookie 查看第三方服务
如果您发现第三方设置的 Cookie，则应与提供商联系，了解他们是否计划逐步淘汰第三方 Cookie。例如，您可能需要升级您正在使用的库版本，更改服务中的配置选项，或者在第三方自行处理必要的更改时不采取任何措施。
2. 测试损坏情况
您可以使用 --test-third-party-cookie-phaseout 命令行 flag 启动 Chrome；在 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. 通过 CHIPS 使用 Partitioned Cookie
如果您的第三方 Cookie 在顶级网站的 1 对 1 嵌入式上下文中使用，那么您可以考虑将 Partitioned 属性用作具有独立分区状态 (CHIPS) 的 Cookie 的一部分，以允许通过每个网站使用单独的 Cookie 实现跨网站访问。
如需实现 CHIPS，请将 Partitioned 属性添加到 Set-Cookie 标头中：
通过设置 Partitioned，网站选择将 Cookie 存储在按顶级网站划分的单独 Cookie jar 中。在上面的示例中，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 负载均衡、无头 CMS 提供商、用于提供不可信用户内容的沙盒网域、使用 Cookie 进行访问权限控制的第三方 CDN、要求对请求使用 Cookie 的第三方 API 调用、嵌入式广告（范围限定每个发布商的状态）。
4. 使用 Storage Access API 和 Related Website Set
如果您的第三方 Cookie 仅用于少数相关网站，那么您可以考虑使用 Related Website Sets (RWS)，允许对这些 Cookie 进行跨网站访问。
若要实施 RWS，您需要为该组定义并提交网站组。为了确保网站之间存在有意义的关联，有效集合的政策要求按以下条件对网站进行分组：彼此可见的关联网站（例如公司产品的不同款式）、服务网域（例如 API、CDN）或国家/地区代码（例如 *.uk、*.jp）。
网站可以使用 Storage Access API 使用 requestStorageAccess() 请求跨网站 Cookie 访问权限，也可以使用 requestStorageAccessFor() 委托访问权限。当多个网站包含在同一组内时，浏览器将自动授予访问权限并且可以使用跨网站 Cookie。
这意味着，相关网站群组仍然可以在有限情境下使用跨网站 Cookie，但不会承担以允许跨网站跟踪的方式在不相关的网站之间共享第三方 Cookie 的风险。
潜在用例：应用专用网域、品牌专用网域、国家/地区专用网域、用于提供不受信任的用户内容的沙盒网域、API 服务网域、CDN。
5. 迁移到相关的 Web API
CHIPS 和 RWS 支持特定类型的跨网站 Cookie 访问，同时保护用户隐私，但第三方 Cookie 的其他用例必须改用注重隐私保护的替代方案。
Privacy Sandbox 提供了一系列专为特定用例打造的 API，而无需使用第三方 Cookie：
- 联合凭据管理 (FedCM) 支持联合身份服务，允许用户登录网站和服务。
- 私密状态令牌可通过跨网站交换有限的非身份信息，实现反欺诈和反垃圾内容。
- Topics 支持针对用户兴趣投放广告和个性化内容。
- Protected Audience 支持再营销和自定义受众群体。
- Attribution Reporting 可用于衡量广告展示次数和转化次数。
此外，Chrome 支持 Storage Access API (SAA)，以便在包含用户互动的 iframe 中使用。Edge、Firefox 和 Safari 已支持 SAA。我们认为，这在维护用户隐私的同时仍然能够实现关键的跨网站功能，并受益于跨浏览器兼容性，因此可以取得很好的平衡。
请注意，Storage Access API 将向用户显示浏览器权限提示。为了提供最佳用户体验，仅当调用 requestStorageAccess() 的网站与嵌入式页面互动过，并且之前在顶级上下文中访问过第三方网站时，我们才会提示用户。如果您成功授权，该网站将允许跨网站访问 Cookie 30 天。可能的用例包括经过身份验证的跨网站嵌入，例如社交网络评论微件、付款服务机构、订阅的视频服务。
如果您仍然遇到这些选项未涵盖的第三方 Cookie 使用情形，则应向我们报告问题，并考虑是否有不依赖可启用跨网站跟踪的功能的替代实现方式。
企业支持服务
与一般网络使用方式相比，企业管理的 Chrome 始终有着独特的要求。我们将确保企业管理员能适当控制在其浏览器中弃用第三方 Cookie。
与大多数 Chrome 实验一样，在弃用第三方 Cookie 1% 后，大多数企业最终用户都会被自动排除。对于可能受影响的少数 Cookie，企业管理员可以将 BlockThirdPartyCookies 政策设为 false，在实验开始前为他们停用受管理的浏览器，并留出时间进行必要的更改，从而不再依赖此政策或第三方 Cookie。如需了解详情，请参阅 Chrome 企业版版本说明。
我们还打算提供进一步的报告和工具，以帮助识别企业网站上的第三方 Cookie 使用情况。企业浏览器在 Chrome 的使用情况指标中的可见性较低，这意味着，测试破坏情况和向我们报告问题对企业尤为重要。
企业 SaaS 集成将能够使用下述第三方弃用试用。
申请延长针对非广告用例的第三方弃用试用的时间
与之前在网络上弃用的许多工具一样，我们理解在某些情况下网站需要更多时间才能做出必要的更改。对于诸如此类的与隐私保护相关的变化，我们还必须在这些变化与网络用户的最大利益之间取得平衡。
我们计划提供弃用试用，让那些用于跨网站环境的网站或服务有机会注册并在一段时间内持续访问第三方 Cookie。
随着计划的进展，我们会分享更多详细信息，但首先要遵循几个重要原则：
- 这将是一次第三方弃用试用，可让第三方嵌入内容选择暂时继续使用第三方 Cookie。
- 注册流程需要经过审核流程，以确保弃用试用仅用于对关键用户历程产生重大影响的功能。我们会根据具体情况考虑注册流程。
- 这不会干扰根据 CMA 的规定，计划于 2024 年初进行的广告测试。因此，这意味着在弃用试用时不会考虑广告用例。
后续步骤：我们会在本月向 blink-dev 邮寄名单发布 Intent 并提供更多详细信息，并继续更新此处的文档。
保持关键用户体验
超过 25 个世纪以来，跨网站 Cookie 一直是网络的关键部分。这需要做出任何更改，尤其是破坏性更改，这是一个复杂的过程，需要协调一致的增量方法。虽然多数用例都有额外的 Cookie 属性和注重隐私保护的新 API，但我们在特定情况下希望确保不会破坏使用这些网站的用户的体验。
主要是身份验证或付款流程。在这种情况下，顶级网站会打开一个弹出式窗口或重定向到第三方网站以执行某项操作，然后再返回顶级网站，从而在返回过程中或在嵌入的上下文中使用 Cookie。我们打算提供一组临时的启发法来识别这些情况，并在限定的时间内允许第三方 Cookie，从而为网站延长实施必要更改的期限。
后续步骤：我们将在本月向 blink-dev 邮寄名单发布 intent，并提供更多详细信息，并继续更新此处的文档。
报告第三方 Cookie 问题并获取帮助
我们希望确保能够捕获网站在没有第三方 Cookie 的情况下发生故障的各种情况，以确保我们能够提供相关指导、工具和功能，让网站能够摆脱对第三方 Cookie 的依赖。如果您的网站或某项服务因第三方 Cookie 被停用而出现故障，您可以将其提交到我们的服务中断跟踪器，网址为 goo.gle/report-3pc-broken。
如果您对弃用流程和 Chrome 的方案有疑问，可以在我们的开发者支持代码库中使用“弃用第三方 Cookie”标记提出新问题。