今天继续来为大家解读今年的 Google I/O
在这个章节我们将关注 Web
上的隐私沙箱并分享如何为三方 Cookies
的终结做好准备。
Privacy Sandbox
是一组提案,可以帮助我们解决用户身份追踪的问题,Chrome
也将在不久的未来停止支持第三方 Cookies
。我们可以在 privacysandbox.com/timeline 查看最新信息(我们可以在时间性中看到,在明年的第三季度,三方 Cookie
将被禁用)。
Chrome
已经在消除Web
中的用户追踪信息方面取得了一些进展:
Chrome 85
中推出了 HTTP Cache Partitioning
(对 HTTP 缓存的缩减)Chrome 92
开始逐步实施 User Agent
字符串的缩减(注意以后再也不能用 UA 精确标识一个用户了)Chrome 108
中推出了 Network State Partitioning
(对网络状态的缩减)Chrome 113
中推出了 Storage Partitioning
(存储分区,如果我们的站点含有依赖存储的嵌入式内容,例如 IndexedDB、Local Storage
和 Session Storage
,并且可以跨多个顶级站点进行访问就可能收到影响)不过这些信息的削减也给开发者带来了不小的负担,影响了很多正常的业务场景,我之前的文章中也有过相关的介绍:Chrome:听说你们滥用 UA? 废了它!、新的浏览器缓存策略变更:舍弃性能、确保安全
随着 Chrome
中三方 Cookie
终结的日益临近,Chrome
希望确保我们具备足够的知识和工具来为站点做好迁移准备工作。比如我们可以利用 First-Party Sets
和 CHIPS
来迁移和远离第三方 Cookie
。特别是如果我们会负责一个或多个站点,可能在代码中很多地方使用 Cookie
,其中一些 Cookie
可能是第三方 Cookie
。下面会介绍一些 Chrome
的 Web
标准提案,用于替换默认和被动访问第三方 Cookie 的行为。
根据用户所在的上下文,Cookie
可以是一方或第三方。Web
上的这种一方和第三方上下文之间的区别并不总是很明显的,并且它对不同资源的影响可能会有所不同。通常,发送到跨站点上下文的 Cookie
(例如,iframe
或子资源请求)被称为第三方 Cookie
。
我们也可以在自己的计算机上设置阻止第三方 Cookie
并尝试浏览我们的站点,在 Network
中来识别第三方 Cookie
。
三方 Cookie
在保护用户隐私方面存在很大的问题,但它们现在也是 Web
功能的关键组成部分。三方 Cookie
使内容和服务的组合更加灵活,进而为全球用户创造出更好的用户体验。
比如在线电商网站上的嵌入式地图和聊天小部件、同系列产品共享登录状态等,这些都是正常会依赖三方 Cookie
的业务场景。所以 Chrome 会希望尽量在不影响用户体验的情况下,也能禁用掉 Cookie
从而保护用户的隐私。
Chrome
为此已经专门构建了很多 API
(如 Topics API
和 Federated Credential Management
),以及通过一些 Web
的标准提案来限制 Cookie
的使。其中一些合作的提案现在已经在 Chrome
中推出使用了,包括 CHIPS
和 First-Party Sets
,下面介绍一下这两个提案。
CHIPS
第三方库或三方的通用服务是需要使用三方 Cookie
最常见的场景。例如网站上的嵌入式地图和聊天小部件。在这种情况下,三方服务的提供者需要在每个父级网站上维护一些 Cookie
或状态,比如用户的聊天记录、选择过的商品等等。这就是 CHIPS
(具有独立分区状态的 Cookie
)的用处所在。
我们只需要添加一个额外的 Cookie
属性 partitioned
,我们的跨站点 Cookie
就会在每个父级网站上自动获得一个不同的 Cookie Jar
,从而防止用户在不同站点之间被跟踪。
使用 CHIPS
可以为用户带来更私密的体验。我们不需要等待三方 Cookie
被淘汰,现在就可以把我们的网站迁移到使用 CHIPS
。如果大家以前查看过 CHIPS
,在本次 Google I/O
上介绍 CHIPS
以来,Chrome
基于 Web
开发者的一些反馈进行了两项更改:
Chrome
删除了主机前缀命名和主机名边界性的要求。虽然这个要求的原始意图是鼓励安全最佳实践,但许多开发者告诉我们,他们目前在子域中大量使用 Cookie
,这个要求会给造成很大的迁移负担。Chrome
将以前每个分区的 Cookie
限制从 10
个更改为每个分区的动态内存限制为 10KB
。这限制了开发者可以使用少量的大型 Cookie,或者使用大量的小型 Cookie。
根据域名的不同来定义 Cookie
属于第三方有点太狭隘了,毕竟一个公司不可能只有一个域名:
但是当启用了三方 Cookie
的限制后,同一组织下不同域名的 Cookie
共享就很困难了。
First-Party Sets
是一个框架,可以用于开发者来声明域之间的关系,浏览器可以基于第三方域与第一方域之间的关系做出决策。这个框架有三个不同的子集,来满足 Web
上的一些关键用例。
ccTLDs
域名:网站可能服务于不同的国家,在每个地区都有一个特定的域名,比如 conardli.cn、conardli.jp、conardli.en
等等;Service
域名:网站可能会使用特定的域名来保证安全性或者提高性能,但是这些不同域名的网站可能也需要共享用户身份。Associated
域名:同一个组织下可能有多个不同的子品牌,对应不同的域名,例如 bytedance.com、douyin.com
就属于这种情况。
对于这些集合,开发者需要向 Chrome
提供的公共 Gtihub
提交一个申请,并确保集合的完整性,以保证特定的技术验证检查和浏览器处理行为。
当浏览器收到 Storage Access API
发出的请求时,它会去确认这个第三方域和第一方域是否在同一集合中,并授予访问请求。
从用户的角度来看,First-Party Sets
可以被看作是同一组相关的站点,他们将能够切换控制来允许 Chrome
基于 First-Party Sets
列表做出访问的决策,同时也能够看到他们正在访问的站点是否在第一方集中,以及他们曾经访问过的其他站点是否在同一集合中。
通过使用 CHIPS
和第一方集,Chrome
团队希望在尽可能不影响用户体验的情况下保护用户隐私。如果大家正在准备迁移远离第三方 Cookie
,建议仔细阅读下这些资源,并在禁用之前采取适当的措施。