许多 Privacy Sandbox API 在 Chrome 稳定版中逐步推出正式版 (GA)，为从 2024 年开始弃用第三方 Cookie 做好准备。其中一些 API 有助于保留重要的跨网站 Cookie 用例，例如 CHIPS 和当前称为 First-Party Set (FPS) 的 API。在这篇博文中，我们介绍了 FPS 的新名称 Related Website Sets (RWS)，该名称更好地体现了其用途。此外，我们还对关键用例进行了回顾，并更新了相关子集网域限制。
保留关键用户历程
当 Chrome 开始默认限制对第三方 Cookie 的访问后，RWS 可最大限度地减少对面向用户的某些功能的干扰。我们的目标是让用户能够在浏览网页时最大限度地减少对网页造成的干扰，同时仍能实现 Privacy Sandbox 的隐私保护目标。为了实现这种平衡，自适应网页设计面向与网站功能相关的特定用例：
- ccTLD 用例旨在解决与公开跟踪中的登录示例一样的破坏问题。此类情况通常在生态系统中通过基于启发法的例外情况来解决（请参阅参考 1）。
- 服务网域用例解决了将敏感功能（如支持身份验证流程）与面向用户的网域隔离开来的常见开发者做法。对于此类情况，可以通过针对性的例外情况在生态系统中得到解决（请参阅参考 2）。
- 对于可能需要第三方 Cookie 访问关键用户历程的网域类型，关联网域用例提供了更大的灵活性（请参阅参考 3）。虽然 ccTLD 和服务网域用例会根据网域特征执行严格的技术检查以尽可能减少滥用，但关联的网域设有数字限制。如需了解详情，请参阅下一部分。
关联网域的数量上限已增加至 5 个
Chrome 之前曾提议将关联的子集（以及 1 个主网域）的数量限制为三个网域，这是我们防范大范围的滥用跟踪的目标。我们收到了网络标准参与者的反馈，他们指出对于不同类型的应用场景而言，该上限过低。
我们已决定将相关网域数量上限提高到五个网域（外加 1 个主域名），这是另一个主要浏览器提供的具有最相似性的实现方案（请参阅参考 4）。此设置将从 Chrome 117 开始生效。
由于 RWS 并不是作为广告解决方案而设计的，因此我们不会考虑有关如何改进 RWS 以更好地投放广告的用例的反馈。对于广告用例，开发者应探索如何使用 Topics API、Protected Audience API 和 Attribution Reporting API，并相应地提供反馈。
用户可以在 5 个关联网域之外进行扩展用例
对于不受此限制支持且对用户有影响的体验，Chrome 正在制定用户提示流程，该流程还利用了其他浏览器采用的标准 Storage Access API (SAA)。对于需要 5 个以上关联网域的用例，我们建议开发者评估如何在非 RWS 环境中支持 SAA。我们正在按照 Blink 的发布流程，单独提供此功能，此功能将从 Chrome 117 开始，在桌面版 Chrome 中逐步推出。
后续步骤
我们非常感谢生态系统的反馈，这些反馈一直以来帮助我们完善此 API。为了给开发者提供可预测性、控制力和可动性，为他们所构建的网站提供持续的用户体验，我们投资开发了自适应网页解决方案。我们期待看到开发者逐步采用和使用 RWS。提交流程现已上线，RWS JSON 生成器工具是帮助提交项目的绝佳起点。
请按照 Intent to Ship（“要发货”会话）跟踪进度，并查看这些资料以获取实现指南。
参考
- 各个浏览器普遍都认为有必要使用跨网站 Cookie，但它们采取了不同的方法来实现这些功能。Firefox（代码）和 Safari（代码）都实现了弹出式窗口启发法，解决了所观察到的破坏问题，例如在任天堂登录流程中就发现的问题。
- 另外，为了尽量减少对用户的干扰，浏览器会硬编码例外情况。Firefox 授予了对 Microsoft Teams 和 login.microsoftonline.us 之间的重定向流程的访问权限。
- 当用户在 instagram.com 上登录时，Firefox 提供了一个“shim”会代表 facebook.com 调用 requestStorageAccessForOrigin。网站分组的示例也可以在 Safari 的硬编码异常中查看，用于对多个网域的存储空间访问提示进行分组。
- Firefox 自动授予用户之前访问过的第三方网站的前 5 次 requestStorageAccess 调用（代码）。在 Chrome 中，关联的子集中列出的前五个网域和同一组的主域名将自动通过 RWS 自动授予第三方 Cookie 访问权限。