状态分区是Firefox中一项称为Total Cookie Protection的新隐私功能的技术术语,它将在Firefox 86的ETP严格模式下可用。本文介绍了状态分区在Firefox内部的工作方式,并说明了第三方集成开发人员可以保持与最新更改兼容。
网站利用各种不同的API在浏览器中存储数据。 Cookie最著名,它通常用于建立登录会话并提供定制的用户体验。我们将这些状态API称为“有状态的API”,因为它们能够建立状态,这些状态将通过重新加载,导航和浏览器重启而保持不变。这些API可使开发人员丰富用户的Web体验,但它们也可以启用有害的Web跟踪,从而危害用户的隐私。为了防止滥用这些API,Mozilla在Firefox 86中引入了State Partitioning。
为了对抗Web跟踪,Firefox当前依赖于增强的跟踪保护(ETP),该功能基于Disconnect列表阻止来自已知跟踪器的cookie和其他共享状态。这种cookie阻止形式是停止跟踪的有效方法,但是它有其局限性。 ETP可保护用户免受3000种最常见和普遍使用的已确定跟踪器的侵害,但其保护取决于列表完整且始终是最新的事实。确保完整性非常困难,跟踪器可以尝试通过注册新域名来绕过列表。此外,识别跟踪器是一项耗时的任务,通常会在将新的跟踪域添加到列表之前增加几个月的延迟。
为了解决ETP的局限性并提供针对跟踪程序的全面保护,我们引入了一种称为“状态分区”的技术,该技术将普遍防止基于cookie的跟踪,而无需列表。
我们努力消除非传统存储机制(“超级cookie”)作为跟踪向量,例如通过对网络状态进行分区(最近已在Firefox 85中推出),从而对状态分区进行了补充。
为了解释状态分区,我们首先应该看一下有状态的Web API如何在Web上启用跟踪。尽管这些API并非为跟踪而设计,但无论网站是作为第一方加载还是作为第三方嵌入(例如以iframe或简单图像形式(“跟踪像素” )。这种共享状态允许嵌入其他网站的跟踪器通过设置cookie来在整个Web上跟踪您。
例如,如果www.tracker.com的cookie都作为第三方嵌入了www.tracker.com,则它们将在foo.com和bar.com上共享。因此,www.tracker.com可以使用cookie作为标识符来连接您在两个站点上的活动。
ETP可以通过简单地阻止对www.tracker.com嵌入式实例的共享状态的访问来防止这种情况。没有设置cookie的能力,跟踪器将无法轻松地重新识别您的身份。
相比之下,状态分区也将阻止共享第三方状态,但这样做不会完全阻止cookie访问。使用状态分区,共享状态(例如Cookie,localStorage等)将由您访问的顶级网站进行分区(隔离)。换句话说,每个第一方及其嵌入的第三方上下文都将放入一个独立的存储桶中。
Firefox使用双键来实现状态分区,这将为访问这些状态的网站的原点添加一个附加键。我们将顶级站点的方案和可注册域(也称为eTLD + 1)用作附加密钥。按照上面的示例,用于www.tracker.com的cookie将在foo.com和bar.com下被不同地键入。代替查找www.tracker.com的cookie罐,存储分区将分别使用www.tracker.com ^ http://foo.com和www.tracker.com ^ http://bar.com。
因此,在这两个顶级网站下,www.tracker.com将有两个不同的Cookie罐。
这使跟踪器无法使用Cookie和其他先前共享的状态来识别站点中的个人。现在状态是独立的(“分区”),而不是在不同的第一方域之间共享。
重要的是要了解状态分区将适用于每个嵌入式第三方资源,无论它是否是跟踪器。
这为隐私带来了巨大好处,允许我们将保护范围扩展到“断开连接”列表之外,并允许嵌入式网站继续使用其cookie和存储,只要它们不需要跨站点访问即可。在下一节中,我们将研究如果嵌入式网站有合理的跨站点共享状态需求,它们可以做什么。
鉴于国家分区为Firefox带来了基本的变化,确保Web兼容性和不间断的用户,开发人员体验是一个最重要的问题。不可避免地,国家分区将通过防止第三方国家的合法用途来破坏网站。例如,单点登录(SSO)服务依赖于第三方cookie来跨多个网站登录用户。状态划分将破坏SSO,因为SSO提供程序在嵌入另一个顶级网站中时无法访问其第一方状态,以便它无法识别登录用户。
为了解决国家分区的这些兼容性问题,我们允许状态在某些情况下未分区。当未分区正在生效时,我们将停止使用双键控并还原普通(第一方)键。
鉴于上面的示例,在解放后,顶级SSO站点和嵌入式SSO服务的Iframe将开始使用相同的存储密钥,这意味着它们都将访问相同的cookie jar。因此,iframe可以通过第三方cookie获取登录凭据。
Firefox可能有两种方案,其中允许网站无法访问允许访问第一方(跨站点)cookie和其他状态:
存储访问API是一个新提议的JavaScript API,用于处理现代浏览器中的隐私保护中的合法异常,例如在Firefox中的ETP或Safari中的智能跟踪预防。它允许受限制的第三方上下文来为自己请求第一方存储访问(访问cookie和其他共享状态)。在某些情况下,浏览器将显示权限提示来决定它们是否足够信任第三方以允许此访问。
分区的第三方上下文可以使用存储访问API来获得存储权限,该许可授予未分区访问其第一方状态。
此功能通过Document.RequestStorAgeAccess方法表示。另一种方法,document.hasstorageaccess可用于了解您当前的浏览上下文是否可以访问其第一方存储。如MDN概述,Document.RequestStorage受到许多限制,标准化以及特定于浏览器的限制,保护用户免受滥用。开发人员应该记下这些并相应地调整其网站的用户体验。
例如,Zendesk将显示一个带有呼叫动作元素的消息来处理瞬态用户激活的标准要求(例如,按钮单击)。在Safari中,它还将产生一个弹出窗口,用户必须激活,以确保满足WebKit的特定于浏览器的要求。
用户授予访问后,Firefox将记住30天的存储权限。
请注意,第三方上下文仅在已请求存储访问的顶级域下是未分区。对于其他顶级域,仍将分区第三方上下文。假设有一个跨源iframe example.com,它嵌入了foo.com。和example.com使用Storage Access API以请求Foo.com和用户允许的第一方访问。在这种情况下,example.com将在foo.com上对自己的第一方cookie有没有解放的访问权限。稍后,用户加载另一个页面栏中,也嵌入example.com。但是,这次,example.com将在Bar.com下仍然划分,因为这里没有存储许可。
document.hasstorageaccess()。然后(hasAccess => {if(!hasAccess){return document.requeststorageaccess();}})。然后(_ => {//我们现在有未来30天的未分区存储访问!// // ...})。catch(_ => {//获取存储访问权限。});
使用存储访问API的JavaScript示例从用户获取存储访问。
目前,Safari,Edge,Firefox支持存储访问API。它位于Chrome中的一个特色标志后面。
在Firefox存储访问策略中,我们已定义多个启发式方法以解决Web兼容性问题。启发式机器旨在捕获在Web上使用第三方存储的最常见场景(跟踪外部),并允许存储访问以使网站正常继续。例如,在单点登录流中,打开允许用户登录的弹出窗口,并将登录信息传输回打开弹出窗口的网站。 Firefox将检测此情况并自动授予存储访问。
请注意,这些启发式机器不是长期设计的。 使用存储访问API是需要未分区访问的网站的推荐解决方案。 我们将不断评估限制的必要性并根据适当地删除它们。 因此,开发人员不应该依靠他们现在或将来依靠它们。 我们推出了一个用于国家分区的新UI,其允许用户知道哪些第三方已经获得了未分区的存储,并提供了对存储访问的微粒控制。 Firefox将在“站点标识”面板的“权限”部分中显示未分区域。 “跨站点cookie”权限指示未分区域,用户可以通过单击“权限条目”沿着“取消”按钮直接从UI删除权限。