2024 年告别第三方 Cookie

Cookie 在 Web 上已经存在了很长时间。简而言之，其理念是，在请求资源后，网站可以通过 Set-Cookie 响应标头在用户的浏览器上设置 Cookie。此 Cookie 可以包含网站所有者希望的任何数据字符串，通常用于为网站提供状态。

例如，Cookie 允许网站检索信息，例如用户是否之前登录过、他们在购物车中添加了什么、他们的主题偏好和其他个性化设置、保存的游戏状态等。

上述用例都可以通过为与浏览器中加载的 URL 相同域的文档设置的 Cookie 来实现。这些称为第一方 Cookie。

当为与嵌入文档不同的域（例如图像或通过 <iframe> 嵌入的其他文档）中的组件设置 Cookie 时，就会出现问题。这些跨站点 Cookie 通常被称为第三方 Cookie，但无论您是否拥有所有相关的站点，其行为和潜在问题都是一样的。

第三方组件可以在它们嵌入的任何文档中将其 Cookie 中存储信息。然后，原始第三方域可以访问所有这些第三方 Cookie，并从每个 Cookie 中聚合信息。这乍看起来可能无害，而且第三方 Cookie 有很多合法用途，例如，公司可能希望在其位于不同域的多个网站上共享用户登录状态和个人资料信息，或者记录其不同属性上的分析，以调查用户旅程并构建更易用的体验。广告技术公司可能希望从用户访问的网站中推断用户的兴趣，以向他们提供更相关的广告。

但是，在最坏的情况下，第三方 Cookie 用于跟踪用户在网络上的活动，构建详细的用户资料，其中可能包括兴趣，也可能包括非常私人的信息，例如性别、性取向、宗教、政治立场等。这些信息可用于构建令人毛骨悚然、具有侵入性的在线体验，并被出售给其他第三方。在这种情况下，它们被称为跟踪 Cookie。

《通用数据保护条例》（GDPR）等欧洲联盟立法和《加州消费者隐私法案》（CCPA）已经通过要求公司对其设置的 Cookie 和收集的信息保持透明来提供帮助，例如，要求客户选择加入此类数据收集，允许他们查看公司掌握的有关他们的数据，并允许他们在需要时删除数据。但是，对于客户来说，他们的数据如何使用仍然并不总是很清楚。

Mozilla 和 Apple 等浏览器供应商提供了一般默认设置，用于阻止第三方 Cookie，同时还在其源代码中包含例外和启发式算法，以解决流行网站上长期存在的第三方 Cookie 问题。

例如

• Mozilla 的反跟踪策略导致 Firefox 默认情况下阻止来自已知跟踪器的第三方 Cookie（参见Firefox 跟踪保护和增强型跟踪保护）。Firefox 还为每个站点提供了单独的 Cookie 罐，以便第三方 Cookie 无法用于跟踪用户跨站点活动（参见全面 Cookie 保护）。
• Apple 也有一项类似的跟踪预防策略；遵循此策略导致了一系列类似的第三方 Cookie 保护措施，这些措施默认情况下处于启用状态；有关详细信息，请参见智能跟踪预防（ITP）。
• Brave 浏览器默认情况下也会阻止跟踪 Cookie。

可以通过浏览器设置在 Firefox 中按需允许使用第三方 Cookie。但是，Safari 中的控制更有限，您可以关闭跨站点跟踪预防，但只能通过代码级别（通过存储访问 API）在每个框架中允许访问第三方 Cookie。

这使我们谈到了 Google，从表面上看，在第三方 Cookie 保护方面，Google 似乎比其他浏览器行动缓慢。在撰写本文时，仅当处于隐身模式时，第三方 Cookie 才会默认被阻止，尽管用户可以根据需要将 Chrome 设置为始终阻止第三方 Cookie。

Google 似乎响应缓慢，这是因为它对第三方 Cookie 的商业用途有着既得利益，其中包括 Google 本身以及各种其他组织的广告，以及第三方身份验证服务和许多其他用途。Chrome 还在浏览器市场中占据很大份额，这加剧了人们对其可能破坏用户群的关键旅程的担忧，例如登录政府服务或购买食品杂货。

Google 并没有很快采取全面禁用选项，而是选择了一种更细致入微的解决方案，即更缓慢地逐步淘汰第三方 Cookie，同时开发新的技术，以确保在第三方 Cookie 默认情况下被禁用后，有效的用例仍能以隐私为重点的方式向前发展，而不是可能促使网站转向更隐蔽的跟踪形式或将内容隐藏在登录和付费墙后面。

这些新的 Web 平台功能被归类为隐私沙箱项目，并且已经经过了大量开发和测试。有些功能现在已经获得了跨浏览器支持，例如存储访问 API，为处理跨站点 Cookie 的更好跨浏览器一致性铺平了道路。

这些功能现在已经达到了 Google 认为它们已足够成熟以支持其预期用例的程度，这使得 Google 可以开始禁用第三方 Cookie。

从 2024 年第一季度开始，Chrome 将为 1% 的用户禁用第三方 Cookie，以方便测试，并从 2024 年第三季度开始逐步扩展到 100% 的用户。达到 100% 的目标取决于 Google 是否解决英国竞争与市场管理局（CMA）提出的任何剩余竞争问题。

由于此更改，Web 开发人员可能会遇到其 Web 属性上更多用户体验问题，尤其是在他们直接设置第三方 Cookie 或使用设置第三方 Cookie 的第三方服务的情况下。

为了解决此类问题，建议您

1. 审核您的第三方 Cookie 用法。第三方 Cookie 具有SameSite=None 值设置；因此，您应该可以通过在浏览器 DevTools 中搜索此设置来识别它们，例如在Firefox 存储检查器或Chrome 应用程序面板中。
2. 测试使用第三方 Cookie 的功能是否存在故障。您可以在浏览器设置中将其设置为阻止第三方 Cookie。Chrome 118+ 还具有一个标志chrome://flags/#test-third-party-cookie-phaseout，启用此标志后，Chrome 将设置阻止第三方 Cookie，并确保新的功能和缓解措施处于活动状态，以便最大程度地模拟淘汰后的状态。
   • 您应该验证您的 SameSite=None Cookie 是否确实仍然需要。它们可能曾经被标记为这样是为了提供快速修复。
3. 修复关键功能故障。有各种可供您使用的替代方法，例如
   • 至少在最初，您可以使代码更具弹性，以便在没有第三方 Cookie 数据可用时提供不太个性化的体验，而不是完全出现故障。遵循优雅降级原则。
   • 您可以选择通过其他方式收集此类数据，例如用户调查或测验，或查看您已经拥有的数据，例如产品订单历史记录，以推断趋势。
   • 如果您使用的第三方 Cookie 只在少量相关且已知的网站之间使用，您可以使用 存储访问 API 和/或 相关网站集 来允许仅针对特定网站的跨站点 Cookie 访问。存储访问 API 会提示用户，让他们授权网站在每个帧的基础上使用第三方 Cookie。
     • 如果您已经为 Firefox 或 Safari 实现了一个使用存储访问 API 的解决方案，那么现在是检查您的实现是否符合 Chrome 行为的好时机。Chrome 版本 119 已更新，提供了对该 API 的完全支持。
     • 相关网站集可以被视为存储访问 API 的渐进增强：API 的使用方式相同，但集内的网站不会提示用户授权访问第三方 Cookie。
   • 如果您的第三方 Cookie 在一对一的基础上与生成它们的顶级网站一起使用，您可以使用 具有独立分区状态的 Cookie (CHIPS) 或分区 Cookie，将您的 Cookie 选择加入分区存储，每个顶级网站都有一个单独的 Cookie 罐。这只需要在您现有的跨站点 Cookie 中添加 partitioned 属性。然后，这些 Cookie 就可以不受限制地使用，但不能与其他网站共享。请注意，CHIPS 目前仅限于 Chromium。
   • 您可以开始探索 Google 隐私沙盒项目中提供的各种功能，看看它们是否适合您的用例（这些功能目前也仅限于 Chromium）。例如
     • 联邦身份管理 (FedCM) API：启用联邦身份服务，允许用户登录网站和服务。
     • 私有状态令牌：通过在网站之间交换有限的、非识别信息来启用反欺诈和反垃圾邮件。
     • 主题 API：启用基于兴趣的广告和内容个性化。
     • 受保护的受众 API：启用再营销和自定义受众。
     • 归因报告 API：启用广告展示次数和转化的衡量。

从网络中消除第三方 Cookie 已经由来已久，这项工作还没有结束。然而，Chrome 的公告是朝着实现这一目标迈出的重要一步。您可以提供帮助 - 使用上面的资源检查您的网站和应用程序是否可以通过今天提供的功能从使用第三方 Cookie 迁移。将此消息传播出去，鼓励其他人也这样做。并向浏览器供应商提供有关仍然缺失功能的反馈。

注意：developer.chrome.com 文章 为第三方 Cookie 的终结做好准备 提供了更多有关从 Chrome 的角度进行测试的信息，以及如何使用隐私沙盒技术解决您的问题。