Privacy Sandbox 的进展(2021 年 10 月)

欢迎参加 10 月版“Privacy Sandbox”活动,它跟踪了在 Chrome 中逐步停用第三方 Cookie 和努力打造更注重隐私保护的网络环境的里程碑。我们每个月都会分享 Privacy Sandbox 时间表的更新概览,以及整个项目的相关资讯。

活动

Chrome 开发者峰会,日程现已发布,11 月 3 日起可在线参加会议

自 11 月 3 日起,我们将举办 Chrome 开发者峰会。您将有机会在主旨演讲中了解 Privacy Sandbox 的最新动态,并有机会在 AMA 中向领导团队提问,在咨询交流时间,还有机会向工程团队咨询更详细的问题。立即报名,期待您的到来!

本月还举行了 W3C 的年度会议(通常称为 TPAC),其中 W3C 的各个不同小组会召开会议,讨论整个网络中的各种主题。您可以查看分组会议的分钟数和视频,下面列出了一些特定会议,包括 Privacy Sandbox 主题。

在接下来的大会季中,IETF(互联网工程任务组)将定期举办 112 场在线技术全体会议。与 TPAC 类似,许多专题演讲会讨论 Privacy Sandbox 主题,例如 PRIV(注重隐私保护的价值观)PEARG(隐私权增强和评估研究小组)MASQUE(基于 QUIC 加密的多路复用应用底层)工作组。这些是关于协议设计的深度技术讨论,如果您具备适当的专业知识,并且有兴趣参与这些讨论,不妨考虑加入。

强化跨网站隐私边界

第三方 Cookie 是实现跨网站跟踪的主要机制。能够逐步淘汰它们是一个重大里程碑,但我们还需要解决其他形式的跨站点存储或通信问题。

Federated Credentials Management API

联合凭据管理 (FedCM) 提案是对 WebID 更有意义的新名称。联合身份是 Web 的一项关键服务,但由于联合身份明确涉及与其他网站共享身份的各个方面,因此它存在与跨网站跟踪重叠的实现细节。

Federated Credentials Management 提案探索了一系列选项,包括现有解决方案的简单迁移路径,以及隐私性更强的服务连接方法(最少共享信息)。

此方案仍处于早期阶段,可在 W3C 的联合身份社区群组中进行讨论。该组织还在 TPAC 上举办了一场分组会议,探讨了相关提案的概况。Chrome 89 中的标志后面还有 API 的早期原型版本,但这仅用于实验目的,并且将随着讨论的推进而发生变化。

Cookie

随着 Cookie 相关提案的不断完善,您应该审核自己的 SameSite=None跨网站 Cookie,并规划需要在您的网站上执行的操作。

条状标签

如果您要设置在跨网站上下文中发送但采用一对一关系(例如 iframe 嵌入或 API 调用)的 Cookie,则应遵循 CHIPS 提案或具有独立分区状态的 Cookie。这样,您就可以将 Cookie 标记为“分区”,并将它们放入每个顶级网站单独的 Cookie jar 中。

我们正在 CHIPS 方面开展相关工作,虽然该功能在 chrome://flags/#partitioned-cookies--partitioned-cookies CLI 标志后面可用,但尚不处于完全可测试的状态。待实现更完善后,我们将提供更新后的测试和调试详情。

顶级网站 red.com 具有一个 red.com 的 iframe。red.com 会设置一个带有“Partitioned”属性的 Cookie。当浏览器位于 blue.com 上时,
以 red.com 作为 iframe 时,不会发送任何 Cookie!CHIPS 会为每个顶级网站创建一个分区。

First-Party Set

如果您为跨网站情境设置了 Cookie,但仅限于您拥有的网站(例如,您在 .com 上托管了 .co.uk 所使用的服务),那么您应遵循 First-Party Set 指南。此方案定义了一种方法来声明您要构建集合的网站,然后将 Cookie 标记为“SameParty”,以便仅针对该集合内的上下文发送 Cookie。

First-Party Set 可用于本地开发者测试(使用 chrome://flags/#use-first-party-setchrome://flags/#sameparty-cookies-considered-first-party 标志),从而允许您指定自己的一组相关网站,并针对这些网站的 Cookie 行为进行实验。

存储分区

网络平台包含可能实现跨网站跟踪的其他存储形式。关于浏览器存储分区状态的 TPAC 分组会议简要介绍了 Chrome 的进度以及其他浏览器供应商的讨论。

开发者无需立即采取行动,但如果您使用 SharedWorker、Web Storage、IndexedDB、CacheStorage、FileSystem API、BroadcastChannel、Web Locks API、Storage 存储分区,或依赖在多个网站上访问这些数据的其他形式的存储或通信 API,则应该跟踪此主题以备日后更新。

防止隐秘跟踪

随着我们减少用于明确跨网站跟踪的选项,我们还需要解决 Web 平台中会暴露身份信息以实现对用户进行数字“指纹”收集或隐秘跟踪的领域。

用户代理字符串缩减和用户代理客户端提示

我们扩大了源试用的覆盖范围,用于测试 Chrome 的简化用户代理格式以包含第三方嵌入。如果您主要为其他服务提供跨网站内容,则可以在注册源试用时启用第三方选项,以接收针对资源请求的简化格式。

您可以跟踪减少 Chrome 用户代理的完整时间表,并提供更多示例和发布阶段详情。如果您依赖当前 User-Agent 格式的平台版本、设备或完整 build 版本信息,则还需要迁移到 User-Agent Client Hints (UA-CH)。

通过添加 Sec-CH- 标头前缀(缺少该前缀),我们继续对 Client Hints 的现有名称进行标准化。待批准,我们希望为 UA-CH 扩展 GREASE 字符的范围

展示相关的内容和广告

随着我们逐步淘汰第三方 Cookie,我们需要引入一些 API,这些 API 既支持依赖第三方 Cookie 的用例,不允许跨网站跟踪。

FLoC

FLoC 是一种提案,无需进行单独的跨网站跟踪,即可实现针对用户兴趣的广告。我们一直在评估早期 FLoC 源试用收到的反馈,然后才会进入进一步的生态系统测试阶段。在我们继续为 FLoC 制定后续步骤和决策期间,您应该会看到一些围绕主题概念(之前提到)的探索性代码,这些代码很快便会显示在 Chromium 代码库中。由于 Chrome 的所有开发工作都是在开放环境中进行的,因此这项工作是可见的,但没有可供开发者测试立即执行操作的内容(也不适用于用户)。我们希望继续在新的 PATCG(非公开广告技术社区群组)中分享这些讨论和更新。

衡量数字广告效果

作为在没有跨网站跟踪的情况下展示广告的伴侣,我们需要借助隐私保护机制来衡量这些广告的效果。

Attribution Reporting API

借助 Attribution Reporting API,您可以衡量一个网站上促成转化的事件(例如点击或查看广告),而无需启用跨网站跟踪。

我们希望继续测试 Attribution Reporting API,并计划将源试用期限延长至 Chrome 97。当前的源试用令牌已于 10 月 12 日过期,因此您需要申请更新后的令牌才能继续测试。

打击网络上的垃圾内容和欺诈行为

我们减少可用于跨网站跟踪的途径的另一个挑战是,相同的指纹技术常常用于防范垃圾内容和欺诈。在这里,我们还需要可保护隐私的替代方案。

信任令牌

Trust Token API 是一种提案,允许一个网站共享有关访问者的声明(例如“我认为他们是真人”),并让其他网站再次验证该声明,而无需识别个人身份。

信任令牌是打击 Web 上的垃圾内容和欺诈的总体策略的一部分。在 TPAC 的“网络欺诈”分组会议中,整个生态系统的代表讨论了目前的一些挑战和方法。

反馈

随着我们不断发布这些每月更新,并通过 Privacy Sandbox 作为整体发布进展,我们希望确保您作为开发者能够获得所需的信息和支持。如果本系列有任何需要改进的方面,欢迎通过 @ChromiumDev Twitter 告诉我们。我们会参照您的意见,继续改进此广告格式。

我们还添加了 Privacy Sandbox 常见问题解答,我们会根据您提交到开发者支持代码库的问题不断扩充该常见问题解答。如果您对测试或实施任何方案有任何疑问,请联系我们。