Privacy Sandbox 提案是创建 Web 平台功能所需的众多步骤中的第一步。
这些 Web 平台功能可能会成为 Web 标准（也称为规范或 spec），这些标准是详细说明 Web 技术应如何运作的技术文档，并定义了工程师应如何在 Web 浏览器中实现这些技术。例如，无障碍丰富互联网应用 (WAI-ARIA) 标准（通常称为“ARIA”）定义了多种技术方法，可让残障人士更轻松地访问网络。这些规范是由万维网联盟 (W3C)（一个由全职员工、成员组织和公众反馈组成的国际社区）制定并为其服务的。
经过讨论、测试和大规模采用后，部分 Privacy Sandbox 提案和 API 将成为规范。我们必须接收开发者和行业领导者（无论是否具备 Web 技术知识）的反馈，才能确保我们打造出实用性广泛且能为用户提供强大隐私保护的持久性 Web 功能。
Chromium（许多现代浏览器背后的开源项目）撰写了有关所有旨在成为 Web 标准的技术的功能开发流程。由于网络上的隐私和安全至关重要，我们希望并鼓励在测试开始之前进行大量讨论并收集反馈。
从提案到 Web 标准
在开发过程的每个阶段，生态系统都会提供关键反馈，从而影响 Privacy Sandbox 的发展。对于 Web 开发者来说，此流程可能很熟悉，但对于将使用这些专用 API 的其他行业利益相关者来说，此流程可能很新颖，而这些利益相关者的专业知识对于此计划至关重要。
从讨论开始
在过去几年中，Chrome 和其他方提出了数十项可保护隐私的提案。您可以阅读这些提案、提出问题、提供改进建议，并查看其他人的意见。
您可以加入或监控多个 W3C 群组，具体取决于您感兴趣的用例：
- 改进了 Web 广告业务群组
- Private Advertising Technology Community Group
- Privacy Community Group
- Web Platform Incubator Community Group
- Federated Identity Community Group
讨论阶段可能需要高度参与。
例如，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 中正式使用后，我们会宣布该 API 的发布，并确保公共文档已准备就绪，可供大规模生态系统采用。
我们已经实现了许多重要的里程碑，未来还将实现更多里程碑。以下技术现已推出：
- 用户代理缩减：限制被动共享的浏览器数据，以减少会导致数字“指纹”收集的敏感信息量。我们已于 2022 年 5 月开始减少这些值，并计划于 2023 年 5 月完成。
- CHIPS：允许开发者选择将 Cookie 纳入分区存储，每个顶级网站都有单独的 Cookie Jar。CHIPS 于 2023 年 2 月在稳定版中推出。
- First-Party Set：声明网站之间的关系，以便使用 Storage Access API 允许有限的跨网站 Cookie 访问。First-Party Sets 将于本周随 Chrome 稳定版 113 逐步推出。
- Federated Credential Management (FedCM)： 支持联合身份，但不会与第三方服务或网站分享用户的电子邮件地址或其他身份识别信息，除非用户明确同意这样做。FedCM 于 2022 年 11 月发布。
2023 年 7 月，相关性和效果衡量 API可供大规模采用。这意味着这些 API 在 Chrome 中默认可用。现在，开发者无需使用浏览器标志或参与源试用，即可使用这些技术。
简而言之，这些 API 已准备好在生产环境中大规模供 99% 的用户使用。
分阶段发布
部分技术会逐步推出。这样一来，我们的团队和开发者就可以监控并解决潜在问题。此外，完全可用性并不意味着 100% 的流量都已启用这些 API。
例如，Chrome 中用户代理客户端提示 (UA-CH) 的分阶段发布始于 2021 年。用户代理缩减于 2022 年 4 月开始，于 2023 年 3 月完成。这让开发者有充足的时间来调整其网站对 User-Agent 字符串的依赖方式。
API 控件
某些 API（例如相关性和效果衡量 API）具有面向用户的配置选项。这包括启用和停用这些 API 的权限。
构建适当的功能检测非常重要。功能检测有助于确定浏览器是否支持特定代码，并允许您提供替代代码。这样可以验证您的网站是否继续按预期运行，即使 API 已被用户关闭，或者用户使用的浏览器不支持特定技术也是如此。
考虑使用权限政策来控制第一方和第三方对浏览器功能的访问权限。
分享您的反馈
我们将继续说明情况，尽可能提前告知您相关信息，鼓励您参与其中，并听取您的意见。
- 了解您可以通过多种方式提供反馈。
- 阅读技术详情和实现指南。
- 欢迎在 Twitter 上向@ChromiumDev 分享您的反馈。
- 向开发者支持代码库提交问题。