Privacy Sandbox 中的提案生命周期

创建 Web 平台功能所需的许多步骤中，首先就要完成 Privacy Sandbox 提案。

这些 Web 平台功能可能会成为 Web 标准（也称为规范或规范），属于技术文档，详细说明 Web 技术应如何运作并定义工程师如何在网络浏览器中实现这些技术。例如，无障碍丰富互联网应用 (WAI-ARIA) 标准（通常称为“ARIA”）定义了可让残障人士更方便地访问网络的技术方法。这些规范是专为万维网联盟 (W3C)（一个拥有全职员工和成员组织并接收公众反馈的国际社区）制定的。

经过讨论、测试和大规模采用，某些 Privacy Sandbox 提案和 API 将成为规范。我们必须收到开发者和行业领军者（无论是否了解 Web 技术）的反馈，以确保为用户打造长效型 Web 功能，并提供广泛的实用性和强大的隐私保护。

功能会经历一个从开发和测试时间表到正式发布的整个过程。
图 1：从开发和测试时间表到正式版推出的整个功能进度。intent 是硬性边界，在执行某些操作之前必须满足此硬性边界。例如，在发布意图实验并获得批准之后，才能开始测试。详细了解这些要求。

Chromium（许多现代浏览器背后的开源项目）针对旨在成为 Web 标准的所有技术撰写了关于功能开发流程的文章。由于 Web 上隐私和安全性的重要性，我们期望并鼓励在开始测试之前进行大量讨论和反馈。

从提案到 Web 标准

在开发的每个阶段，生态系统都会提供关键反馈，这些反馈会塑造 Privacy Sandbox。此过程对 Web 开发者可能很熟悉，但对于将使用这些专门构建的 API 并且其专业知识对该计划至关重要的其他行业相关方来说可能不熟悉。

开始讨论

“原型设计”意图可开启对话。
图 2：原型设计 intent 启动对话。

过去几年里，Chrome 团队和其他公司提供了数十个隐私保护提案。您可以查看这些提案、提出问题、提出改进建议，并查看其他人的意见。

您可以根据您感兴趣的使用场景，加入或监控多个 W3C 群组：

讨论阶段可能参与得非常频繁。

例如，Protected Audience（以前称为 FLEDGE）提案支持在不进行跨网站跟踪的情况下针对用户兴趣投放广告。得益于隐私保护倡导者和许多行业利益相关方的意见，Protected Audience API 从之前的两项提案（PIGIN 和 TURTLEDOVE）演变而来。超过 100 人参加了 W3C 会议以帮助优化当前版本，此外还有超过 300 个在线讨论会话。

此外，其他公司还在同一解决方案领域提供了六十多种其他提案。我们希望通过持续的合作 确定一条下一步的发展之路

测试 Protected Audience 和其他 API 时提供 Chrome 标志，因此开发者可以提早访问这些 API。

并非每个提案都会像 Protected Audience 那样经历严格的孵化期，有些提案的行动速度要快得多，但每个 API 都会接收来自整个生态系统的输入。这些是新的想法 可能需要大量精力才能落实到位

开发者测试并分享反馈

实验意图用于功能和规模测试。
图 3：意向实验适用于功能和规模化测试。

我们依靠开发者提供有关改进这些技术的反馈，并分享可能需要对 API 设计和实现进行更改的问题。许多 Privacy Sandbox 技术可用于测试，并提供各种选项。例如，如需测试 Topics API，您可以使用 Chrome 标志设置周期长度和其他参数。

Chrome 工程师通常会在标志后面实现功能，以便进行本地测试，而默认情况下，该功能不会跨浏览器提供。开发者必须启用某项功能才能试用，是否可用取决于 Chrome 版本。随着开发的继续进行，开发者可能会遇到一些问题。

借助 Chrome 源试用，开发者可以为有限的 Chrome 用户启用该功能。若要参与该计划，开发者可以进行注册，以选择加入您的网站或服务。这样您就有机会针对生产流量试用该功能，并针对实际体验提供反馈。

Privacy Sandbox 针对相关性和效果衡量 API 运行了统一的源试用，该试验现已完成。

当一项功能最初可供测试时，通常侧重于功能测试或技术测试。使用新代码时，贡献者应能发现和报告 bug，并为这些 bug 提供修复。这意味着在此期间，功能的稳定性和形状可能会快速变化。接收关于集成和开发者体验的反馈至关重要，这样可确保与该功能一起创建调试和工具支持。

随着开发的进行以及功能的稳定性变得越来越稳定，关注的重点会转移到更广泛的效果或实用性测试上。实用性测试的目的是大规模地了解该功能针对其预期用例的性能。在这一阶段，我们会增加参与实验的 Chrome 用户群体，以获取更大、更具代表性的样本。在此阶段，我们希望网站能够针对自己的更大一部分流量运行长期测试，根据其业务需求验证该功能。

这个过程的成功取决于开发者先执行这些测试，然后分享从中学到的心得。此外，我们还在每个阶段同时进行测试，并通过各种单独的项目渠道定期汇总项目结果，如 Privacy Sandbox 博客系列和季度反馈报告（这是 CMA 承诺的一部分）。

无论您是在 W3C、反馈表等公共场所分享测试，还是通过直接的合作伙伴渠道分享您的测试，我们都希望收到您的反馈意见。

在浏览器中通过功能标志或源试用进行测试并不是探索新技术可能如何运作的唯一方式。一些公司也在基于 Privacy Sandbox 概念构建模拟。

开始大规模采用

“发货意向”表示请求让某个 API 可供大规模采用。
图 4：“发货意向”表示请求让某个 API 可供大规模采用。

一旦某个 API 经过测试并可在 Chrome 中正式发布，我们便会宣布推出相应 API，并确保公开文档已准备就绪，可支持相应生态系统大规模采用。

我们已经发布了许多重要的里程碑，还会有更多即将到来的里程碑。现已推出以下技术：

  • 减少用户代理：限制被动共享浏览器数据，以减少导致数字“指纹”收集行为的敏感信息量。我们从 2022 年 5 月开始减少这些值，并计划在 2023 年 5 月完成。
  • CHIPS：允许开发者选择将 Cookie 用于分区存储，并为每个顶级网站提供单独的 Cookie jar。CHIPS 已于 2023 年 2 月在稳定版中推出。
  • First-Party Set：使用 Storage Access API 声明网站之间的关系，以允许进行有限的跨网站 Cookie 访问。本周，Chrome 稳定版 113 将逐步推出 First-Party Set。
  • 联合凭据管理 (FedCM)：支持联合身份，而无需与第三方服务或网站共享用户的电子邮件地址或其他身份信息，除非用户明确同意。FedCM 已于 2022 年 11 月推出。

2023 年 7 月，相关性和效果衡量 API 可供大规模采用。这意味着，这些 API 默认在 Chrome 中可用。开发者现在可以使用这些技术，而无需浏览器标记或参与源试用。

简而言之，这些 API 已在生产环境中大规模提供给 99% 的用户。

分阶段发布

部分技术是逐步提供的。这有助于我们的团队和开发者监控并解决潜在问题。此外，完全可用性并不意味着所有流量都启用了 API。

例如，Chrome 中的用户代理客户端提示 (UA-CH) 已于 2021 年分阶段推出。用户代理缩减已于 2022 年 4 月开始，并于 2023 年 3 月完成。这让开发者有充足的时间来转换其网站依赖于用户代理字符串的方式。

API 控件

某些 API（如相关性和效果衡量 API）为用户提供了配置选项。这包括启用和停用这些 API 的功能。

请务必构建适当的特征检测。功能检测有助于确定浏览器是否支持特定代码，并允许您提供替代代码。这可确保您的网站继续按预期运行，即使 API 被用户停用，或者用户所用的浏览器不支持特定技术，也是如此。

请考虑使用权限政策来控制第一方和第三方对浏览器功能的访问权限。

分享反馈

我们将继续解释发生的情况，尽可能向前介绍用户，鼓励您参与进来，并听取您的意见。