今天，我们分享了更新后的 Privacy Sandbox for the Web 计划和时间表，以及逐步淘汰第三方 Cookie 的路径。作为 Web 开发者和网站所有者，您的反馈对我们来说至关重要，它有助于我们认识到，花更多时间来完善方案并确保有足够的机会测试、集成和优化新解决方案的重要性。本文将详细介绍测试计划，包括我们打算在 8 月增加统一 Privacy Sandbox 相关性和效果衡量来源测试中的流量，并延长测试期限。
Privacy Sandbox 项目代表了一项广泛而雄心勃勃的变革，旨在解决整个网络的跨网站跟踪问题。它提出了人人都可以实现的开放标准，而不是浏览器专用功能，同时确保网站能够以安全且私密的方式使用第三方服务。虽然逐步淘汰第三方 Cookie 是整个项目进程中的一个重要里程碑，但解决所有形式的跨网站跟踪的目标更为广泛！您仍应预计在整个过程中推出各项提案和功能。您的网站可能会受到某种影响；因此，您需要确保了解自己的网站和服务受到了哪些影响，以及应遵循哪些建议和功能。
我们来详细了解一下当前状态，并了解您需要了解哪些信息，才能继续测试、提供反馈，以及为即将发布的功能做好准备。
扩大 Privacy Sandbox 相关性和效果衡量来源试用范围
借助 Privacy Sandbox 相关性和衡量来源试用版，整个生态系统可以针对 Attribution Reporting、Protected Audience、Topics、fenced frames 运行统一测试，以确保技术稳定性和开发者体验。我们很快就会添加 Shared Storage。目前，50% 的 Chrome Beta 版用户已启用此试用功能，这有助于我们积极解决早期开发者反馈和问题，同时不会过多干扰用户。
随着来源测试的推进，我们希望让开发者有机会使用有意义比例的真实流量来测试 API 的实用性和有效性。随着 Chrome 104 稳定版于 8 月初发布，我们将面向 Chrome 稳定版桌面用户扩大试用范围。我们计划从 Android 版 Chrome 105 稳定版开始，将试用范围扩大到移动用户。源试用计划在 Chrome 104 稳定版周期结束时结束。我们请求延长试用期限，将其延长至 Chrome 107（10 月底），以便进行进一步测试。这遵循了标准做法，即以三个里程碑为增量申请来源试用期延期。我们会全程提供支持，从测试到正式发布 API。
您可以按照官方请求延长实验意向 (I2E) 的有效期。我们还将更新 Privacy Sandbox 文档，在其中添加实现和测试指南。
如果您提供这些 API 提供的任何服务，那么您参与来源测试并提供反馈非常重要。随着我们开始进行更大规模的测试，您可以借此机会验证哪些方案符合您的需求。您无需具备 Web 标准或浏览器开发方面的专业知识，只需利用您在自己领域的现有经验即可。
当核心功能完善且成熟时，我们计划开始发布这些 API 以供正式使用，可能在 2023 年年初至年中。从设计上讲，在源试用期间，API 可以根据测试和反馈进行演变。在整个来源测试仍在进行期间，可能会推出个别功能。发布后，我们将在进行初始采用和长期测试的过程中继续优化这些 API。
更新 Cookie 行为
具有独立分区状态的 Cookie (CHIPS) 和 First-Party Set 提案提供了一种途径，可在不涉及跟踪的跨站点环境中支持 Cookie。
CHIPS
CHIPS 允许开发者选择将 Cookie 存储在“分区”存储空间中，每个顶级网站都有单独的 Cookie Jar。根据当前源试用期间开发者的反馈，我们进行了大量修复和改进，并将试用期延长至 8 月底 Chrome 稳定版 104 结束。具体而言，我们移除了对 __Host- 前缀和无 Domain 属性的更严格要求，以便网站更轻松地迁移跨子网域使用的 Cookie（例如 shop.example.com 和 blog.example.com）。
我们收到了对此提案和试用计划的积极反馈，因此希望在试用计划结束后发布 CHIPS。根据官方流程，您可以关注 blink-dev 邮寄名单，以便在我们发布发货意向 (I2S) 消息时及时了解。
这是一个令人振奋的里程碑，因为在许多用例中，您需要向其他网站（例如 widget 或 API）提供嵌入式自包含服务，这样一来，您就可以在第三方 Cookie 逐步淘汰之前妥善完成更新！
First-Party Set
First-Party Set 提供了一种用于对关联网站进行分组的方法，旨在让拥有多个网站（例如不同的国家/地区级网域）的组织能够在这些特定的跨网站但第一方情境中继续使用自己的 Cookie。
根据我们在讨论和测试该功能期间收到的反馈，我们提议了一些更改，旨在解决这些问题，同时满足生态系统的需求。具体而言，我们提议以特定于用例的“子集”来定义集。我们还建议网站使用 Storage Access API 以及可能的扩展程序来请求跨网站 Cookie 访问权限。这将取代 SameParty 属性的提案。
随着工作进展，我们会更新开发者指南。如果您已经在尝试使用第一方组，或者该用例符合您的需求，不妨关注相关讨论并参与其中。
缩减发货用户代理
我们目前正在减少 Chrome 用户代理字符串中的信息。自 2022 年 4 月的 Chrome 101 起，次要版本或 build 版本已替换为零。即将推出的阶段还将将操作系统/平台版本和设备型号替换为固定值。桌面版将从 2022 年 10 月的 Chrome 107 开始弃用，移动版将从 2023 年 1 月的 Chrome 110 开始弃用。此时间表保持不变，不受第三方 Cookie 逐步淘汰时间表变更的影响，我们将于 2023 年初全面减少用户代理。
对字符串所做的更改旨在向后兼容，因此，如果您不需要这些特定值，则不会受到影响。不过，如果您确实解析用户代理字符串以提取浏览器的次要/build 版本、操作系统/平台版本或设备型号，则需要迁移到 User-Agent Client Hints。
存储分区
Cookie 是用于跨网站跟踪的最常见功能，但 Privacy Sandbox 旨在从整体上解决跨网站跟踪问题，包括所有形式的跨网站存储。与我们在 2020 年对 HTTP 缓存进行分区的方式类似，我们还打算对存储 API（例如 IndexedDB 和 localStorage）进行分区、对通信 API（例如 BroadcastChannel 和 SharedWorker）进行分区，以及对同时属于这两类的功能（例如 ServiceWorker）进行分区。
我们已发送此工作原型设计 intent (I2P)，这意味着我们正在推进各种 API 的设计和初始代码。在当前的 Chrome 105 Canary 版中，我们计划提供一个用于启用本地开发者测试的标志。我们预计这些更改将在完成工作后（预计在 2023 年初）通过标准 Chrome 开发流程进行，这早于全面停用第三方 Cookie。
开发者文档和支持
为帮助您全面了解 Privacy Sandbox，我们提供了 privacysandbox.com，其中介绍了 Web 版和 Android 版项目的概念、目标和时间表。在 Privacy Sandbox 上，您可以找到各个方案、演示、测试和实现指南的详细信息，以及指向更多参与资源的链接。
我们会定期举办开发者咨询时间，就各种 Privacy Sandbox 主题进行讨论。在每场会议中，我们都会邀请工程团队和产品团队参与，演示相关功能，然后解答您在实现和测试方面的疑问。我们会在 @ChromiumDev Twitter 和匹配 API 的邮寄名单上公布每场会议。我们已经在提供日语讲座，并针对不同的时区提供重播，但我们还会继续改进该计划，以便发布带字幕的演示视频，并让您更轻松地提前提交主题和问题。
我们还有 GitHub 上的开发者支持代码库。如果您遇到问题或有疑问，但不知道该在哪里提出，请在该处发布问题，我们会帮助解答或为您找到合适的参与渠道。
提供和分享反馈
虽然 Privacy Sandbox 项目是由 Google 发起的，但我们的目标是提出改变整个网络平台的提案，而不仅仅是 Chrome 中的功能变更。这是一个开放式协作过程，涉及众多群体，包括浏览器供应商、网站所有者，最重要的是使用这些网站和浏览器的用户。虽然最终的规范是用非常明确和正式的语言编写的（因为它们需要定义足够完整的实现流程），但确保规范执行正确操作的过程需要每个人的输入。
我们收到了许多公司想要了解的反馈，他们想知道还有哪些公司在进行测试，以及这些测试结果将如何分享。作为测试人员，您可以自行决定是否公开测试计划和结果，我们强烈建议您这样做！W3C、GitHub 和邮寄名单中有很多公开论坛，您可以在其中直接与其他利益相关方分享信息。这可能简单到声明您正在积极参与源代码试用，您是否拥有实现所需的所有资料，或者对测试结果进行详细分析。您还可以发布到自己的网站、博客或社交账号，尤其是在您有特定受众群体想要与之交流时。
我们的反馈页面涵盖了每种不同的路线，以及每个 API 的有效路线。您还可以通过我们的反馈表单直接向我们提供反馈。
最终，通过更改 Cookie 的行为方式，我们将改变已经在 Web 上使用了 28 年的技术。网络属于我们所有人，我们需要继续努力，在这些变化中寻找理想的组合，既能打造更注重隐私保护的环境，又能提供我们喜爱的丰富开放式生态系统。为此，我们需要您提供反馈和指导。我们期待与您携手共进，共同完成后续的旅程。