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