第三方 cookie
本文解释了什么是第三方 Cookie，描述了与之相关的问题，并说明了如何解决这些问题。
什么是第三方 Cookie？
Cookie 与特定域名和方案（通常是 https）相关联，如果设置了 Set-Cookie Domain 属性，则可能也与子域名相关联。
- 如果 Cookie 域名和方案与用户当前正在查看的页面（浏览器地址栏中显示的 URL）匹配，则该 Cookie 被视为与页面来自同一站点，并被称为第一方 Cookie。
- 如果域名和方案不同，则该 Cookie 不被视为来自同一站点，并被称为第三方 Cookie。
注意：第三方 Cookie 有时被称为跨站点 Cookie。这可以说是一个更准确的名称，因为第三方 Cookie 暗示由第三方公司或组织拥有。然而，无论您是否拥有所有相关站点，行为和潜在问题都是相同的。例如，一个站点可能会从其拥有的不同域访问资源，例如图像。
当用户首次访问页面、点击同一站点上的内部链接到另一个页面，或请求驻留在同一站点上的资源（例如，嵌入的图像、网络字体或 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 问题。
- 如果启用了增强跟踪保护（默认情况下已启用），Firefox 会启用全面 Cookie 保护。这为第三方 Cookie 提供了每个站点独立的 Cookie 罐，从而防止了跨站点跟踪。
- Safari 也有类似的跟踪预防策略；遵循此策略导致了一系列类似的默认启用的第三方 Cookie 保护措施；有关详细信息，请参阅智能跟踪预防 (ITP)。
- 在撰写本文时，Google Chrome 默认只在隐身模式下阻止第三方 Cookie，尽管用户可以通过
chrome://settings根据需要将其设置为始终阻止第三方 Cookie。Google 已开始为有限比例的 Chrome 用户禁用第三方 Cookie，以测试其影响，同时开发无需第三方 Cookie 即可实现关键用例的技术。有关详细信息，请参阅替换第三方 Cookie。 - Edge 默认阻止来自未访问站点的跟踪器，并阻止已知有害的跟踪器。在撰写本文时，微软也开始探索默认在 Edge 中阻止第三方 Cookie。有关更多信息，请参阅跟踪预防。
- Brave 浏览器默认阻止跟踪 Cookie。
可以通过浏览器设置在 Firefox 中逐案允许使用第三方 Cookie。然而，在 Safari 中，控制更为有限——您可以关闭跨站点跟踪预防，但只能通过 Storage Access API 在代码级别允许访问每个框架的第三方 Cookie。
注意：第三方 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，或在浏览器开发者工具中检查存储的SameSite=NoneCookie（例如，在 Firefox 存储检查器中）来识别第三方 Cookie。Chrome 的问题面板也报告第三方 Cookie 阻止问题以及受影响的 Cookie 列表。 - 在阻止第三方 Cookie 的情况下测试您的功能，看看哪些会中断。您可能会发现某些 Cookie 不再需要。
- 至少在开始阶段，您可以让您的代码更具弹性，以便在第三方 Cookie 数据不可用时提供不太个性化的体验，而不是完全中断。遵循优雅降级的原则。
- 通过替代方式（例如用户调查或测验）收集数据，或查看您已有的数据以推断趋势（例如，产品订单历史记录）。
- 使用替代的客户端存储机制（例如 Web 存储）来持久化数据，或考虑服务器端解决方案。
- 如果您的第三方 Cookie 仅用于少数相关的已知网站，您可以使用 Storage Access API 和/或 Related Website Sets 仅允许这些特定站点进行跨站点 Cookie 访问。Storage Access 会提示用户允许站点按帧使用第三方 Cookie。
- 如果您已经为 Firefox 或 Safari 实现了使用 Storage Access API 的解决方案，那么现在是根据 Chrome 的行为检查您的实现的好时机，Chrome 的行为已更新以在版本 119 中提供全面支持。
- 相关网站集可以被认为是 Storage Access API 的渐进增强：API 可以以同样的方式使用，但集合中的网站不会提示用户允许访问第三方 Cookie。
- 如果您的第三方 Cookie 以 1:1 的方式与生成它们的顶级站点一起使用，您可以使用具有独立分区状态的 Cookie (CHIPS，也称为可选分区 Cookie) 来选择将您的 Cookie 存储在分区存储中，每个顶级站点一个独立的 Cookie 罐。这只需要在您现有的跨站点 Cookie 中添加
partitioned属性。然后它们可以不受限制地使用，但不能与其他站点共享。
替换第三方 Cookie
开发人员可以使用多种功能，以停止使用第三方 Cookie，尊重用户隐私并最大限度地减少跟踪，同时继续实现相关用例。其中一些功能处于早期实验阶段，但随着您开始为未来做准备，它们值得考虑。
您可以开始探索 Google 隐私沙盒项目中的不同功能，看看它们是否适合您的用例（这些功能目前是实验性的，仅限于 Chromium）：
- 联合身份管理 (FedCM) API：启用联合身份服务，允许用户登录多个站点和服务。
- 私有状态令牌：通过在站点之间交换有限的非识别信息来启用反欺诈和反垃圾邮件。
- 主题 API：启用基于兴趣的广告和内容个性化。
- Protected Audience API：当用户访问其他应用或站点时，使用来自一个应用或站点的数据来帮助选择广告。
- 归因报告 API：启用广告展示和转化的衡量。