欢迎阅读 10 月份的“Privacy Sandbox 进展”专栏，了解我们在逐步淘汰 Chrome 中的第三方 Cookie 并致力于打造更注重隐私保护的网络的过程中取得了哪些里程碑成就。我们每个月都会分享 Privacy Sandbox 时间表的最新动态概览，以及该项目的最新资讯。
事件
从 11 月 3 日起，我们将举办 Chrome 开发者大会。您将能够在主题演讲中了解 Privacy Sandbox 的最新动态，并有机会在问答环节中向领导团队提问，还可以在办公时间向工程团队提出更详细的问题。立即注册，我们期待与您在活动中相见！
本月还举办了 W3C 年度会议（通常称为 TPAC），W3C 的所有各个群体都会齐聚一堂，讨论整个网络的各种主题。您可以查看分论坛的会议摘要和视频，下面列出了包括 Privacy Sandbox 主题在内的具体会议。
在会议季继续进行之际，IETF（互联网工程任务组）将举办其定期的 112 次在线技术全体会议。与 TPAC 类似，我们还将举办一系列单独的会议，讨论 Privacy Sandbox 主题，例如 PRIV（注重隐私保护的价值纳入）、PEARG（隐私保护增强和评估研究组）和 MASQUE（基于 QUIC 加密的多路复用应用底板）工作组。这些会议将深入探讨协议设计方面的技术问题。如果您拥有相关专业知识，并且有兴趣参与这些讨论，请考虑加入。
增强跨网站隐私边界
第三方 Cookie 是实现跨网站跟踪的关键机制。能够逐步淘汰它们是一项重大里程碑，但我们还需要解决其他形式的跨网站存储或通信问题。
Federated Credentials Management API
联邦凭据管理 (FedCM) 提案是 WebID 的新名称，更具意义。联合身份是 Web 的一项关键服务，但鉴于其明确涉及与其他网站共享身份信息的各个方面，因此在实现细节方面与跨网站跟踪有重叠之处。
联邦身份凭据管理提案探讨了一系列选项，从现有解决方案的简单迁移路径到更私密的连接到服务的方法，以尽可能少地共享信息。
此提案仍处于早期阶段，您可以在 W3C 的联邦身份社区群组中跟进相关讨论。该团队还在 TPAC 举办了分组讨论 会话，简要介绍了该提案。Chrome 89 中还提供了该 API 的非常早期原型版本，但这仅供实验之用，随着讨论的深入，该版本会发生变化。
Cookie
随着与 Cookie 相关的提案的推进，您应审核自己的 SameSite=None 或跨网站 Cookie，并规划您需要在自己的网站上采取的措施。
CHIPS
如果您设置的 Cookie 在跨网站情境中发送，但存在 1:1 关系（例如 iframe 嵌入或 API 调用），则应遵循 CHIPS 提案或具有独立分区状态的 Cookie。这样，您就可以将 Cookie 标记为“分区”，将其放入每个顶级网站的单独 Cookie Jar 中。
我们正在推进 CHIPS 的开发工作，虽然该功能在启用 chrome://flags/#partitioned-cookies 和 --partitioned-cookies CLI 标志后可用，但尚未处于完全可测试的状态。实现更加完善后，我们会提供更新后的测试和调试详细信息。
First-Party Set
如果您为跨网站情境设置 Cookie，但仅在您拥有的网站上设置（例如，您在 .com 上托管了 .co.uk 使用的服务），则应遵循第一方 Cookie 集。此提案定义了一种声明要组成集合的网站的方法，然后将 Cookie 标记为“SameParty”，以便仅针对该集合内的上下文发送这些 Cookie。
第一方集可供本地开发者测试，位于 chrome://flags/#use-first-party-set 和 chrome://flags/#sameparty-cookies-considered-first-party 标志后面，可让您指定自己的一组相关网站，并对这些网站上的 Cookie 行为进行实验。
存储分区
该网站平台包含可能支持跨网站跟踪的其他存储形式。关于浏览器存储分区状态的 TPAC 分组会议概要介绍了 Chrome 的进展，并包含其他浏览器供应商的讨论。
开发者无需立即采取行动，但如果您使用 SharedWorker、Web Storage、IndexedDB、CacheStorage、FileSystem API、BroadcastChannel、Web Locks API、存储分区或其他形式的存储或通信 API，并且需要跨多个网站访问这些数据，则应跟踪此主题以了解后续动态。
防范隐蔽跟踪
随着我们减少了显式跨网站跟踪选项，我们还需要解决网络平台中会泄露可用于对用户进行指纹识别或隐式跟踪的身份信息的方面。
用户代理字符串缩减和用户代理客户端提示
我们扩大了用于测试Chrome 的缩减版 User-Agent 格式的来源试用范围，纳入了第三方嵌入。如果您主要为其他服务提供跨网站内容，则可以在注册参与源代码试用计划时启用第三方选项，以便在收到对您资源的请求时接收缩减格式的内容。
您可以跟踪缩减 Chrome 用户代理的完整时间轴，以及有关发布阶段的更多示例和详细信息。如果您依赖于当前 User-Agent 格式的平台版本、设备或完整 build 版本信息，则还需要迁移到 User-Agent Client Hints (UA-CH)。
我们将继续对客户端提示的现有名称进行标准化，在缺少 Sec-CH- 标头前缀时添加该前缀。我们希望扩大 UA-CH 的 GREASE 字符范围，但此功能尚待批准。
展示相关的内容和广告
随着我们逐步淘汰第三方 Cookie，我们需要引入一些 API，以允许依赖于第三方 Cookie 的应用场景，但不允许跨网站跟踪。
FLoC
FLoC 是一种提案，旨在实现基于兴趣的广告投放，而无需进行个性化跨网站跟踪。在推进进一步的生态系统测试之前，我们一直在评估 FLoC 早期源试用获得的反馈。虽然我们仍在继续研究 FLoC 的后续步骤和决策，但您应该很快就会在 Chromium 代码库中看到一些围绕主题概念（之前提及）的探索性代码。由于 Chrome 的所有开发工作都是公开进行的，因此这项工作将会公开，但开发者无法立即对其进行测试（这也不适用于用户）。我们希望继续在新的 PATCG（私人广告技术社区群组）中分享这些讨论和更新。
衡量数字广告的效果
为了配合在不进行跨网站跟踪的情况下展示广告，我们需要使用可保护隐私的机制来衡量这些广告的效果。
Attribution Reporting API
借助 Attribution Reporting API，您无需启用跨网站跟踪，即可衡量导致另一个网站上发生转化的某个网站上的事件（例如点击或查看广告）。
我们希望继续测试 Attribution Reporting API，并计划延长源试用，直至 Chrome 97。当前的来源试用令牌已于 10 月 12 日过期，因此您需要申请更新后的令牌才能继续测试。
防范网络上的垃圾内容和欺诈行为
在减少可用于跨网站跟踪的途径时，我们还面临另一个挑战，即这些相同的指纹识别技术通常用于防范垃圾内容和欺诈行为。我们也需要在此类场景中提供可保护隐私的替代方案。
信任令牌
信任令牌 API 是一项提案，允许一个网站分享有关访问者的声明（例如“我认为他们是真人”），并允许其他网站验证该声明，而无需识别个人身份。
信任令牌是打击网络垃圾内容和欺诈行为的整体策略的一部分。在 TPAC 大会的“网络防欺诈”专题讨论中，来自整个生态系统的代表讨论了一些当前的挑战和方法。
反馈
我们将继续每月发布这些更新，并逐步推进 Privacy Sandbox 的整体发展，希望确保您作为开发者能够获得所需的信息和支持。如果您认为本系列课程有任何需要改进的地方，请通过 @ChromiumDev Twitter 与我们联系。我们会根据您的反馈继续改进此格式。
我们还添加了 Privacy Sandbox 常见问题解答，并会根据您向开发者支持代码库提交的问题不断扩充该部分的内容。如果您对任何方案的测试或实现有任何疑问，欢迎随时与我们联系。