第三方 Cookie
本文介绍了什么是第三方 Cookie，描述了与之相关的问题，并说明了如何解决这些问题。
什么是第三方 Cookie？
一个 Cookie 与特定的域和方案（通常为 https）相关联，如果设置了 Set-Cookie 的 Domain 属性，则也可能与子域相关联。
- 如果 Cookie 的域和方案与用户正在查看的当前页面（浏览器地址栏中显示的 URL）匹配，则该 Cookie 被认为来自与页面相同的站点，并称为第一方 Cookie。
- 如果域和方案不同，则该 Cookie 不被认为来自相同的站点，并称为第三方 Cookie。
注意：第三方 Cookie 有时也称为跨站点 Cookie。这可能是一个更准确的名称，因为第三方 Cookie暗示了第三方公司或组织的所有权。但是，无论您是否拥有所有相关的站点，其行为和潜在问题都是相同的。例如，一个站点可能会访问来自其拥有的不同域的资源，例如图像。
当用户首次访问页面、遵循同一站点上的另一个页面的内部链接或请求驻留在同一站点上的资源（例如嵌入的图像、Web 字体或 JavaScript 文件）时，可能会设置第一方 Cookie。
在以下常见情况下会发送第三方 Cookie
- 当点击一个站点上的链接以导航到另一个站点时。
- 当页面嵌入来自其他站点的组件时，例如嵌入在
<iframe>中的图像或其他文档（通常称为第三方内容）。除了对组件的原始请求外，这些组件还可能会生成进一步的请求，从而设置更多第三方 Cookie。
第三方 Cookie 用于什么？
点击链接到其他站点的链接时设置的第三方 Cookie 用于各种目的。例如，您可能有一个指向合作伙伴站点的关联链接，并在用户点击该链接时设置 Cookie，以便在购买特定产品时可以显示带有折扣的奖励横幅，或者可以将佣金支付给推荐人。
设置 Cookie 的第三方内容也有许多不同的用途。例如，您可能在多个不同但相关的站点上嵌入了登录小部件，该小部件在所有站点之间共享 Cookie 以确认用户已登录，因此他们无需在每个站点上再次登录。
第三方 Cookie 的其他用例包括
- 在多个站点之间共享用户偏好或主题信息。
- 跨多个站点收集分析数据。
- 计算广告展示次数，并记录用户兴趣，以使广告技术平台能够投放更相关的广告。
让我们用一家虚构的公司进一步说明上面提到的登录小部件示例，该公司为其在线商店 (shop.site)、社区讨论论坛 (forum.site) 和客户服务与退货 (service.site) 设置了单独的域。
这三个站点中的每一个都嵌入了登录小部件，托管在 auth.site 上，以在站点之间持久保存登录状态。用户可以登录到任何这些站点，在浏览器中为 auth.site 创建一个包含会话 ID 的 Cookie。当用户转到其他站点之一时，嵌入的 auth.site 实例将可以访问用户在第一个站点上登录时设置的会话 ID Cookie。它可以将其发送到服务器，检查它是否仍然有效，并立即登录到该站点。
第三方 Cookie 的问题是什么？
上述用例听起来足够无害。但是，第三方 Cookie 也可以用于未经用户同意的不正当目的，这些目的在技术上与有效用例无法区分。
点击指向第三方的链接或与嵌入在 <iframe> 中的第三方内容交互（例如，填写表单或点击按钮）可能会导致设置 Cookie，从而将用户信息交到他们意想不到的人手中。这些信息可用于
- 在用户搜索特定产品信息时，使用目标广告在网络上追踪他们。
- 向用户发送垃圾邮件或电话。
- 操纵他们的行为，让他们选择某些选项以增加关联收入或操纵统计数据。
单独来看，这些情况已经够糟糕了，但情况会变得更糟。第三方服务器可以将跨不同站点设置的多个第三方 Cookie 中的信息组合起来，以创建用户浏览历史记录、兴趣、习惯和个人信息的详细资料。这可用于创建令人毛骨悚然的、侵入性的用户体验，欺骗用户，甚至实施身份盗窃。
在这种情况下，第三方 Cookie 被称为跟踪 Cookie。
注意：通过不正当手段获得的用户数据也经常出售给其他第三方，从而进一步加剧了问题。
诸如欧盟的 通用数据保护条例 (GDPR) 和 加州消费者隐私法 (CCPA) 等法律通过要求公司对其设置的 Cookie 和收集的信息保持透明来提供帮助。例如，要求客户选择加入此类数据收集，允许他们查看公司掌握的关于他们的数据，以及如果他们希望删除这些数据。
浏览器如何处理第三方 Cookie？
浏览器供应商知道用户不喜欢上面描述的行为，因此都开始默认阻止第三方 Cookie，同时还在其源代码中包含例外情况和启发式方法，以解决流行网站上长期存在的第三方 Cookie 问题。
- Mozilla 的 反跟踪策略 已导致 Firefox 默认阻止来自已知跟踪程序的第三方 Cookie（请参阅 Firefox 跟踪保护 和 增强型跟踪保护）。Firefox 还为每个站点提供一个单独的 Cookie 存储，因此它们无法用于跨站点跟踪用户（请参阅 全面 Cookie 保护）。
- Apple 也有一项类似的 跟踪预防策略；遵循此策略导致了一系列类似的第三方 Cookie 保护措施，这些措施默认启用；有关详细信息，请参阅 智能跟踪预防 (ITP)。
- 在撰写本文时，Google Chrome 仅默认在隐身模式下阻止第三方 Cookie，尽管用户如果愿意，可以通过
chrome://settings将其设置为始终阻止第三方 Cookie。Google 已开始为一小部分 Chrome 用户禁用第三方 Cookie 以测试其影响，同时开发技术以在不需要第三方 Cookie 的情况下启用关键用例。有关详细信息，请参阅 替换第三方 Cookie。 - Edge 阻止来自未访问站点的跟踪程序，并默认阻止已知的恶意跟踪程序。在撰写本文时，Microsoft 也开始探索默认在 Edge 中阻止第三方 Cookie。有关更多信息，请参阅 跟踪预防。
- Brave 浏览器 默认阻止跟踪 Cookie。
可以通过 Firefox 的浏览器设置在逐个案例的基础上允许使用第三方 Cookie。但在 Safari 中，控制权限更有限——您可以关闭跨站点跟踪预防，但允许每个框架访问第三方 Cookie 只能在代码级别通过 存储访问 API 完成。
注意：第三方 Cookie（或仅跟踪 Cookie）也可能被浏览器扩展阻止。
Cookie 阻止可能会导致某些第三方组件（例如社交媒体小部件）无法按预期工作。随着浏览器对第三方 Cookie 实施更多限制，开发人员应开始寻找减少对它们的依赖的方法：请参阅 替换第三方 Cookie。
使用第三方 Cookie
使用 SameSite 启用第三方 Cookie
使用 SameSite 属性，服务器可以指定是否/何时发送第三方 Cookie。如果您未在 Set-Cookie 标头中指定 SameSite，则使用默认值 Lax。这指示浏览器不要发送第三方 Cookie，除非用户从其他站点导航到 Cookie 的源站点。当您希望在用户从其他站点导航到您的站点后立即发送 Cookie 时，这很有用，例如，在他们到达后立即个性化体验。
但是，如果您想在多个站点中嵌入 <iframe> 内的跨站点内容并依赖于第三方 Cookie 来实现功能，例如在上面我们看到的登录示例中，这将不起作用。在这种情况下，您需要显式设置 SameSite=None 以允许浏览器传递这些 Cookie
Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly
请注意，如果设置了SameSite=None，则也必须设置Secure属性——SameSite=None需要安全上下文。在上面的示例中，我们还设置了HttpOnly属性，以禁用 JavaScript 访问 cookie（例如，通过Document.cookie）。存储敏感信息的 Cookie 应始终设置HttpOnly属性——将其提供给 JavaScript 会非常不安全。此预防措施有助于缓解跨站脚本 (XSS) 攻击。
注意：用于敏感信息的 Cookie 还应具有较短的生命周期。
从第三方 Cookie 过渡
有多种策略可以帮助网站最大程度地减少在阻止第三方 Cookie 的浏览器中出现故障。
- 审核您的第三方 Cookie 使用情况。Cookie 必须设置
SameSite=None属性才能在跨站点上下文中使用。因此，您可以通过在代码中搜索SameSite=None或检查浏览器 DevTools 中存储的SameSite=NoneCookie 来识别第三方 Cookie，例如在Firefox 存储检查器中。Chrome 的问题面板也报告了与第三方 Cookie 阻止相关的问题以及受影响 Cookie 的列表。 - 在阻止第三方 Cookie 的情况下测试您的功能，以查看哪些功能出现故障。您可能会发现某些 Cookie 不再需要。
- 至少在最初，您可以使您的代码更具弹性，以便在第三方 Cookie 数据不可用时提供不太个性化的体验，而不是完全中断它。遵循优雅降级原则。
- 通过其他方式（如用户调查或测验）收集数据，或查看您已有的数据以推断趋势（例如，产品订单历史记录）。
- 使用替代的客户端存储机制，例如Web 存储来持久化数据，或考虑使用服务器端解决方案。
- 如果您的第三方 Cookie 仅在少量相关的已知网站之间使用，则可以使用存储访问 API和/或相关网站集仅允许这些特定网站访问跨站点 Cookie。存储访问会提示用户授予站点在每个框架中使用第三方 Cookie 的权限。
- 如果您已经使用存储访问 API 为 Firefox 或 Safari 实现了解决方案，那么现在是时候根据 Chrome 的行为检查您的实现，Chrome 的版本 119 已更新为提供完全支持。
- 相关网站集可以被视为存储访问 API 的渐进式增强：API 可以以相同的方式使用，但集合中的网站不会提示用户授予访问第三方 Cookie 的权限。
- 如果您的第三方 Cookie 正在与生成它们的顶级网站一对一地使用，您可以使用具有独立分区状态的 Cookie（CHIPS，也称为分区 Cookie），选择将您的 Cookie 存储到每个顶级网站的单独 Cookie 存储区中。这只需要向您现有的跨站点 Cookie 添加
partitioned属性。然后可以不受限制地使用它们，但不能与其他网站共享。请注意，CHIPS 目前仅限于 Chromium。
替换第三方 Cookie
对于希望停止使用第三方 Cookie 以尊重用户隐私并最大程度地减少跟踪同时继续实施相关用例的开发人员，可以使用多种功能。其中一些功能处于早期实验阶段，但随着您开始为未来做准备，值得考虑。
您可以开始探索 Google 的隐私沙盒项目中提供的不同功能，以查看它们是否适合您的用例（这些功能目前处于实验阶段，并且仅限于 Chromium）。