Privacy Sandbox 提案是创建 Web 平台功能所需的众多步骤中的第一步。
这些 Web 平台功能可能会成为 Web 标准（也称为规范），这些规范是技术文档，详细说明 Web 技术应如何运作，并定义工程师应如何在 Web 浏览器中实现这些技术。例如，无障碍丰富互联网应用 (WAI-ARIA) 标准（通常称为“ARIA”）定义了一些技术方法，可让残障人士更轻松地访问网络。这些规范由 World Wide Web Consortium (W3C) 制定，并面向该组织开发。W3C 是一个国际社区，拥有全职员工、会员组织，并会收集来自公众的反馈。
经过讨论、测试和大规模采用后，部分 Privacy Sandbox 提案和 API 将成为规范。我们非常需要从开发者和行业领军者（无论是否具备 Web 技术知识）获取反馈，以确保我们打造的 Web 功能经久耐用、实用广泛，并为用户提供强大的隐私保护。
Chromium（许多新型浏览器背后的开源项目）曾针对所有旨在成为 Web 标准的技术撰写了功能开发流程。由于网络隐私和安全至关重要，我们希望并鼓励在测试开始前进行大量讨论和反馈。
从提案到 Web 标准
在开发的每个阶段，生态系统都会提供重要的反馈，这些反馈有助于塑造 Privacy Sandbox。此流程可能对 Web 开发者来说很熟悉，但对将使用这些专用 API 且其专业知识对此计划至关重要的其他行业利益相关方来说可能很陌生。
从讨论开始
过去几年，Chrome 和其他公司提出了数十项可保护隐私的方案。您可以阅读这些提案、提出问题、提供改进建议，并查看其他人的意见。
您可以加入或监控多个 W3C 组，具体取决于您感兴趣的用例：
讨论阶段可能需要高度参与。
例如，Protected Audience（以前称为 FLEDGE）是一项提案，旨在在不进行跨网站跟踪的情况下支持基于兴趣的广告投放。Protected Audience API 是根据隐私权倡导者和许多行业利益相关方的意见，从之前的两个提案（PIGIN 和 TURTLEDOVE）演变而来。超过 100 人参加了 W3C 会议，帮助优化当前版本，此外还有超过 300 个在线讨论会话。
其他公司还提供了六七个其他方案，它们都属于同一解决方案领域。我们希望通过持续合作，找到前进的方向。
Protected Audience 测试和其他 API 测试需要启用 Chrome 标志，以便开发者能够尽早使用这些 API。
并非每个提案都会经历 Protected Audience 这样密集的孵化期，有些提案的推进速度会快得多，但每个 API 都会收到来自整个生态系统的反馈。这些都是新想法，需要付出大量努力才能正确实现。
开发者测试并分享反馈
我们需要开发者就这些技术的改进提供反馈，并分享可能需要更改 API 设计和实现的问题。许多 Privacy Sandbox 技术都提供各种选项供您测试。例如，如需测试 Topics API，您可以使用 Chrome 标志设置公元纪年长度和其他参数。
通常，Chrome 工程师会通过标志实现功能，以便在本地进行测试，而不会默认在所有浏览器中提供该功能。开发者必须启用相应功能才能试用，具体可用性取决于 Chrome 版本。随着开发的继续，开发者可能会遇到一些问题。
借助 Chrome 源代码试用，开发者可以为部分 Chrome 用户启用某项功能。如需参与，开发者可以注册以选择启用您的网站或服务。这样，您就有机会在正式版流量中试用此功能，并就实际体验提供反馈。
Privacy Sandbox 针对相关性和效果衡量 API 开展了一项统一来源试用，该试用现已完成。
当一项功能首次可供测试时，一般侧重于功能测试或技术测试。对于新代码，我们希望贡献者能够发现并报告 bug，以及提供这些 bug 的修复程序。这意味着，这项功能的稳定性和特点在此期间可能会快速变化。收到有关集成和开发者体验的反馈至关重要，这有助于确保能够随功能一起创建调试和工具支持。
随着开发工作不断推进，功能稳定性逐渐提高，重心会转向规模更大的有效性或实用性测试。实用性测试旨在了解这项功能大规模用于预期用例时的效果。在此阶段，实验中包含的 Chrome 用户群体会增加，以便获得更大、更具代表性的样本。在此阶段，我们希望网站针对其自身流量的更大比例运行长期测试，以便根据其业务需求验证该功能。
在此过程中，开发者需要执行这些测试，然后分享所学到的知识，这样才能取得成功。我们还会在每个阶段同时进行测试，并通过各种各样的单独项目渠道分享测试结果，同时在 API 状态更新和季度反馈报告中定期总结整个项目的测试结果，以履行我们对 CMA 的承诺。
无论您是在 W3C 等公共场所、反馈表单还是通过直接的合作伙伴渠道分享测试结果，我们都希望收到您的反馈。
在浏览器中通过功能标志或源试用进行测试，并不是探索新技术可能运作方式的唯一方式。一些公司还在根据 Privacy Sandbox 概念构建模拟环境。
发布以实现大规模采用
当某个 API 经过测试并准备好在 Chrome 中正式使用后，我们会宣布其发布，并确保公开文档已准备好供生态系统大规模采用。
我们已经完成了一些重要的里程碑，未来还会有更多。目前支持以下技术：
- 减少用户代理：限制被动共享的浏览器数据，以减少导致数字“指纹”收集的敏感信息量。我们已于 2022 年 5 月开始降低这些值，并计划于 2023 年 5 月完成。
- CHIPS：允许开发者选择将 Cookie 存储到分区存储空间，每个顶级网站都有单独的 Cookie Jar。CHIPS 于 2023 年 2 月在稳定版中推出。
- 第一方 Set：声明网站之间的关系，以允许使用 Storage Access API 进行有限的跨网站 Cookie 访问。本周，我们将通过 Chrome 稳定版 113 逐步推出第一方集合。
- 联邦身份验证管理 (FedCM)：支持联邦身份，无需与第三方服务或网站分享用户的电子邮件地址或其他身份信息，除非用户明确同意。FedCM 于 2022 年 11 月发布。
2023 年 7 月，相关性和效果衡量 API 可供大规模采用。这意味着，这些 API 已在 Chrome 中默认提供。现在，开发者无需使用浏览器标志或参与源代码试用即可使用这些技术。
简而言之，这些 API 已准备好在生产环境中面向 99% 的用户大规模使用。
分阶段发布
部分技术会逐步推出。这样，我们的团队和开发者就可以监控和解决潜在问题。此外，完全可用并不意味着 100% 的流量都启用了这些 API。
例如，Chrome 在 2021 年开始分阶段推出用户代理客户端提示 (UA-CH)。用户代理缩减已于 2022 年 4 月开始，并将于 2023 年 3 月完成。这样一来，开发者就有充足的时间来调整其网站对 User-Agent 字符串的依赖方式。
API 控件
某些 API（例如相关性和效果衡量 API）提供了供用户使用的配置选项。这包括启用和停用这些 API 的权限。
请务必构建适当的特征检测。功能检测有助于确定浏览器是否支持特定代码，并允许您提供替代代码。这样可以确保您的网站继续按预期运行，即使用户已关闭某个 API 或用户使用的浏览器不支持特定技术，也不例外。
考虑使用权限政策来控制第一方和第三方对浏览器功能的访问权限。
分享您的反馈
我们会继续说明相关情况，尽可能提供尽可能多的前瞻性信息，鼓励您参与，并听取您的意见。
- 了解提供反馈的多种方式。
- 阅读技术详情和实现准则。
- 欢迎通过 Twitter 上的@ChromiumDev 与我们分享您的反馈。
- 将问题提交到开发者支持代码库。