2021 年 7 月，我们分享了Privacy Sandbox 工作详细时间表。Privacy Sandbox 旨在逐步淘汰第三方 Cookie 并阻止隐秘跟踪权宜解决方法，从而朝着默认保护隐私的网络环境迈进。时间表每月更新一次，您可以使用它跟踪所有阶段和里程碑。我们还将分享相关文章和视频，以提供更多详细信息。
不过，需要跟踪的内容很多！“Privacy Sandbox 进展”旨在为您提供所有必要的标志，以便您根据自己的需求在适当的时间参与相关提案。请将本视频和即将发布的视频视为试播版。我们需要您的反馈，以确保这些每月发布的文章对您来说值得一读！
您可以通过 Twitter 上的@ChromiumDev 与该团队分享反馈，也可以在 GitHub 上通过 GoogleChromeLabs/privacy-sandbox-dev-support 提交问题。
接下来，我们来看看过去一个月的更新。
增强跨网站隐私边界
Cookie
在 Google I/O 大会上，我们分享了一张流程图，其中涵盖了相关建议，以及适用于不同 Cookie 用例的操作。
在母语日系列活动中，Maud 分享了一段法语视频概览，详细介绍了您现在可以对第一方 Cookie 做出哪些改进。
我们发布了适用于 CHIPS 的 I2P，即具有独立分区状态的 Cookie。这意味着，我们可以开始为该功能编写代码了。CHIPS 支持需要跨网站 Cookie 的用例，其中 Cookie 的使用仅限于一个顶级上下文或被划分到一个顶级上下文。例如，跨网站嵌入或 API 调用，您可能会在其中使用 Cookie 来实现某种形式的会话或保存状态。发布 I2P 意味着，您应该会在即将发布的版本中看到此功能（需要通过标志启用）。如果您认为 CHIPS 对 Cookie 有用，则应跟踪 I2P 线程或 Chrome 状态条目，了解其可用性。我们还将推出更多文章和演示，让您了解该功能的运作方式。
在“什么是 Privacy Sandbox？”系列视频中，Sam 推出了有关第一方组合的全新视频概览，探索了各项提案。
还有另一项 I2P 变更，旨在使 Chrome 的 Cookie 大小限制与 HTTP 标准保持一致，并更接近 Firefox 的行为。这只是一项小变更，因为 Chrome 已拒绝超出 4096 个字符限制的 Cookie。如果您的网站经常设置接近此值的 Cookie，那么无论如何，您都应尽量缩短该时间，但同时也应查看 I2P 的详细信息，了解确切的更改。开发者工具已显示被拒绝的 Cookie，并将根据新限制进行更新。
其他清理工作
我们打算弃用并移除（I2D / I2R）已弃用的第三方环境中的 Web SQL API，并针对已弃用的 webkitRequestFileSystem API 的“永久性”配额类型发出另一个 I2D。Chrome 使用指标较低，但如果您的网站仍在 iframe 中使用 window.openDatabase() 或 window.webkitRequestFileSystem(window.PERSISTENT, […])，请检查相关链接是否存在潜在影响。
防范隐蔽跟踪
用户代理字符串缩减和用户代理客户端提示
完整的 User-Agent 字符串是浏览器和设备高度标识信息的主要来源。去年 5 月，我们分享了 Chrome 将如何减少其用户代理字符串中的详细信息的计划。在第 1 阶段，问题已开始在开发者工具中显示，以帮助网站审核其访问 navigator.userAgent 的位置。
对于第 2 阶段，我们已分享意向开展实验 (I2E)，这意味着我们希望开展来源试用，让网站提前选择接收经过缩减的用户代理字符串。如果您在网站上以某种方式处理用户代理（通过 HTTP 标头或在 JavaScript 中），不妨考虑参与该计划，以便尽早发现您可能需要进行的任何更改。源试用计划从 Chrome 95 开始，我们将在可以注册时进行通知。
如果您需要从 User-Agent 获取更多信息，则 User-Agent 客户端提示 (UA-CH) 可为 HTTP 标头和 JavaScript 提供此功能。如需将其集成到您的网站中，请参阅迁移指南。
UA-CH 在 Chrome 稳定版中默认可用，我们会根据生态系统反馈不断改进其功能。Microsoft Edge 团队正在贡献 I2P，以改进为 Windows 提供的平台版本数据。
展示相关的内容和广告
FLoC
FLoC 是一项提案，旨在实现无需个别跨网站跟踪即可基于用户兴趣投放广告的功能。FLoC 第一版的源试用已于 7 月中旬结束，我们正在评估对 FLoC 下一版本的改进，然后再进行进一步的生态系统测试。如果您仍在为 FLoC 或其他实验性代码投放来源试用令牌，现在是清理这些令牌的好时机。
Shared Storage API
我们发布了适用于 Shared Storage API 的 I2P。这是一个相对较低级别的存储组件，旨在支持对跨网站数据进行汇总报告和内容过滤。其基本思想是，来源可以跨多个嵌入式上下文写入其存储空间，然后只能通过非常有限的接口读回。例如，为多个情境提供单个值，以便在多个情境中进行一致的 A/B 测试或覆盖面/频次上限，但不允许直接访问该标识符。
目前，这是一个热门讨论领域，因此如果您对设计阶段感兴趣，请在代码库中提出问题，但我们仍需进行进一步的测试和源代码试用。
衡量数字广告的效果
Attribution Reporting
核心 Attribution Reporting API 自 2020 年底起已以 Event-Level Conversion Measurement API 的名称开展源试用。
从 Chrome 92 开始，API 发生了一些变化，我们已发布有关从 Conversion Measurement API 迁移到 Attribution Reporting API 的指南。此外，我们还将试用期延长至 Chrome 93 稳定版。我们还延长了时间表中的“讨论”阶段，以反映我们正在持续开展的汇总报告和跨设备报告等方面的工作。
我们已发布归因报告简介和视频概览，其中介绍了该 API 的运作方式、主要用例、API 实现状态，以及与第三方 Cookie 的对比情况。
防范网络上的垃圾内容和欺诈行为
信任令牌
信任令牌是一种提案，允许一个网站分享有关用户的声明（例如“我认为该用户是真人”），并允许其他网站验证该声明，但验证方式不允许在这些网站之间建立用户关联。
在“什么是 Privacy Sandbox？”系列视频中，Sam 提供了一个简短的 Trust Tokens API 视频概览。
信任令牌的源试用自 Chrome 84 起就已开放，计划一直持续到 Chrome 94，因此您仍有时间在自己的网站上进行实验。
我们还发布了一份关于 Android 平台提供的信任令牌的 I2E，探讨了除了其他网站之外，是否有可能从更广泛的来源发放令牌。这只是一项非常有限的初始实验，旨在解决服务器端实现问题，并希望根据在此获得的经验，开展更广泛的实验。
反馈
敬请期待即将推出的试播视频，以及下个月推出的此系列的另一个版本。我们的目标是让这份汇总对您有用且切实可行，因此请记得告诉我们您认为我们可以改进的地方！