跳转到主要内容

category

本文解释了什么是第三方cookie,描述了与它们相关的问题,并解释了如何解决这些问题。

什么是第三方cookie?


cookie与特定的域[domain ]和方案[scheme ](通常为https)相关联,如果设置了“设置cookie域”属性,则也可能与子域相关联。

  • 如果cookie域和方案与用户正在查看的当前页面(浏览器地址栏中显示的URL)匹配,则cookie被认为与页面来自同一网站,并被称为第一方cookie。
  • 如果域和方案不同,则cookie不被视为来自同一网站,并被称为第三方cookie。

 

注意:第三方cookie有时被称为跨站点cookie。这可以说是一个更准确的名称,因为第三方cookie意味着第三方公司或组织的所有权。然而,无论您是否拥有所有相关网站,行为和潜在问题都是相同的。例如,一个网站可能会访问来自其拥有的不同域的资源,例如图像。

当用户第一次访问页面、跟随到同一网站上的另一页面的内部链接或请求驻留在同一网站的资源(例如,嵌入式图像、网页字体或JavaScript文件)时,可以设置第一方cookie。

第三方cookie在以下常见情况下发送:

  1. 单击一个网站上的链接以导航到另一个网站时。
  2. 当一个页面嵌入来自其他网站的组件时,例如嵌入<iframe>s中的图像或其他文档(通常称为第三方内容)。除了对组件的原始请求外,这些组件还可能生成设置更多第三方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被称为跟踪cookie

注:通过非法手段获得的用户信息也经常被出售给其他第三方,使问题进一步加剧。

欧盟的《通用数据隐私条例》(GDPR)和《加利福尼亚州消费者隐私法》(CCPA)等立法有助于将公司设置的cookie和收集的信息透明化作为法律要求。例如,要求客户选择进行此类数据收集,允许他们查看公司掌握的数据,并在他们愿意的情况下删除这些数据。然而,客户并不总是清楚他们的数据是如何使用的。

浏览器如何处理第三方cookie?


浏览器供应商知道用户不喜欢上述行为,因此他们都开始默认屏蔽第三方cookie,同时在源代码中包含异常和启发式,以解决流行网站中长期存在的第三方cookie问题。

  • Mozilla的反跟踪政策导致Firefox默认情况下阻止来自已知跟踪器的第三方cookie(请参阅Firefox跟踪保护和增强的跟踪保护)。Firefox还为每个网站提供了一个单独的cookie罐,因此它们不能用于跨网站跟踪用户(请参阅cookie总保护)。
  • 苹果公司也有类似的追踪预防政策;随之而来的是一组类似的默认启用的第三方cookie保护;有关详细信息,请参阅智能跟踪预防(ITP)。
  • 在撰写本文时,默认情况下,谷歌Chrome仅在隐姓埋名模式下屏蔽第三方cookie,尽管用户可以通过chrome://settings.谷歌已开始为有限比例的Chrome用户禁用第三方cookie,以测试其影响,同时开发技术,在不需要第三方Cookie的情况下启用关键用例。有关详细信息,请参阅更换第三方cookie。
  • Edge会阻止未访问网站的跟踪器,默认情况下会阻止已知的有害跟踪器。在撰写本文时,微软也开始探索默认情况下在Edge中屏蔽第三方cookie。有关详细信息,请参阅跟踪预防。
  • Brave浏览器默认情况下会阻止跟踪cookie。

允许通过浏览器设置在Firefox中根据具体情况使用第三方cookie。然而,在Safari中,控制更为有限-您可以关闭跨站点跟踪防止,但允许访问每帧第三方Cookie只能在代码级别通过Storage access API[Storage Access API]完成

注意:第三方cookie(或仅跟踪cookie)也可能被浏览器扩展阻止。

Cookie阻止可能会导致一些第三方组件(如社交媒体小部件)无法正常工作。随着浏览器对第三方cookie施加进一步的限制,开发人员应该开始寻找减少对它们依赖的方法:请参阅替换第三方Cookie。

使用第三方cookie


使用SameSite启用第三方cookie


SameSite属性允许服务器指定是否/何时发送第三方cookie。如果您没有在Set Cookie标头中指定SameSite,则使用默认值Lax。这指示浏览器不要发送第三方cookie,除非用户从其他站点导航到cookie的原始站点。当你想在用户从另一个网站导航到你的网站后立即发送cookie时,这很有用,例如,当他们到达网站后,你就可以个性化体验。

然而,如果您想在<iframe>的内部跨多个站点嵌入跨站点内容,并依赖第三方cookie来实现功能,例如,在我们上面看到的登录示例中,这是不好的。在这种情况下,您需要明确设置SameSite=None,以允许浏览器传递这些cookie:

HTTP
 

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被阻止的浏览器中的破坏:

  1. 审核您的第三方cookie使用情况。Cookie必须设置SameSite=None属性才能在跨站点上下文中使用。因此,您可以通过在代码中搜索SameSite=None,或在浏览器DevTools(例如Firefox Storage Inspector)中检查存储的SameSite=None cookie来识别第三方cookie。Chrome的问题面板还报告了第三方cookie屏蔽的问题,以及受影响的cookie列表。
  2. 用被阻止的第三方cookie测试您的功能,看看有什么中断。您可能会发现不再需要某些cookie。
  3. 至少在最初,你可以让你的代码更有弹性,这样当第三方cookie数据不可用时,它就可以提供不那么个性化的体验,而不是完全破坏它。遵循优雅堕落的原则。
  4. 通过用户调查或测验等替代方式收集数据,或者查看您已经掌握的数据来推断趋势(例如,产品订单历史记录)。
  5. 使用另一种客户端存储机制(如Web存储)来持久化数据,或者考虑使用服务器端解决方案。
  6. 如果您的第三方cookie仅在少数相关的已知网站上使用,则您可以使用Storage Access API和/或相关网站集,仅允许对这些特定网站进行跨站点cookie访问。存储访问会提示用户为网站提供按帧使用第三方cookie的权限。
    1. 如果您已经使用适用于Firefox或Safari的Storage Access API实现了一个解决方案,那么现在是检查您的实现是否符合Chrome的行为的好时机,Chrome已更新为在版本119中提供完全支持。
    2. 相关网站集可以被视为存储访问API的渐进增强:API可以以同样的方式使用,但集中的网站不会提示用户访问第三方Cookie的权限。
  7. 如果您的第三方cookie与生成它们的顶级网站以1:1的比例使用,您可以使用具有独立分区状态的cookie(CHIPS,又称分区cookie),将您的cookie选择到每个顶级网站的单独cookie罐的分区存储中。这只需要将分区属性添加到现有的跨站点cookie中。它们可以不受限制地使用,但不能与其他网站共享。请注意,芯片目前仅为Chromium。

更换第三方cookie


希望停止使用第三方cookie的开发人员可以使用一些功能,以尊重用户隐私并最大限度地减少跟踪,同时继续实施相关用例。其中一些功能还处于早期实验阶段,但在您开始为未来做准备时,它们值得考虑。

你可以开始探索谷歌隐私沙盒项目中的不同功能,看看它们是否适合你的用例(这些功能目前是实验性的,仅限于Chromium):

  • 联合凭据管理(FedCM)API:启用联合身份服务,允许用户登录多个站点和服务。
  • Private State Tokens:通过在网站之间交换有限的非身份信息,实现反欺诈和反垃圾邮件。
  • 主题API:启用基于兴趣的广告和内容个性化。
  • 受保护的受众API:当用户访问另一个应用程序或网站时,使用一个应用或网站的数据来帮助选择广告。
  • 归因报告API:能够测量广告印象和转化率。

另请参阅