第三方 Cookie 有很多用途，但它们也是跨网站跟踪的关键驱动因素。
Chrome 提议借助第三方 Cookie 为用户提供全新选择体验。如果用户选择在不使用第三方 Cookie 的情况下浏览，您的网站需要做好准备。
在本页中，您将了解适用于传统上依赖第三方 Cookie 的嵌入式场景的隐私保护解决方案，以及可帮助您选择最适合自己需求的解决方案的策略。
嵌入式服务或嵌入服务，包括第三方内容（例如视频、地图）、互动组件（例如聊天、评论系统或付款服务）、登录服务等。
大多数从第三方 Cookie 过渡的工作需要由嵌入内容开发者完成，而不是由托管嵌入内容的网站完成。本指南主要介绍面向创建嵌入式服务的开发者的解决方案。
如果您的网站依赖于使用第三方 Cookie 的嵌入代码，请务必审核和测试您的嵌入相关流程，并在发现任何损坏情况时与嵌入提供商联系。
审核并测试与嵌入相关的用户历程
要确定您的嵌入是否受到第三方 Cookie 的影响，最好的方法是在启用第三方 Cookie 测试标记的情况下测试您的第三方嵌入用户流。
限制第三方 Cookie 后，请测试以下常见的嵌入场景：
- 聊天微件：您可以发起聊天会话吗？您能否在不丢失会话的情况下刷新页面？您是否可以导航到其他页面并保持会话？
- 内容嵌入：您可以查看视频内容或其他嵌入的内容吗？语言或字幕等用户偏好设置是否会保留？您是否在按预期看到广告？例如，没有在付费订阅后看到广告？
- 登录：登录（包括任何单点登录 (SSO) 登录）是否适用于支持登录的嵌入？重新加载网页和导航到使用相同嵌入的网页后，它们是否持久保留？
- 评论微件：你可以留下、顶和顶评论吗？
- 嵌入式付款解决方案：能否成功完成付款？
在接下来的部分中，您将更具体地了解这些流可能会受到怎样的影响。
常见使用场景
有许多 API 可用于传统上依赖于第三方 Cookie 的嵌入。下表列出了一些常见的工作流程以及建议的 API，概要列出了相关的工作流程。以下部分将说明提出这些建议的原因。
| 用例 | 推荐用于第三方 Cookie 的 API |
|---|---|
| 聊天微件 | 条状标签 |
| 地图嵌入 | 条状标签 |
| 需要将状态范围按发布商确定的不受信任的用户内容 （例如 googleusercontent.com 和 githubusercontent.com）的沙盒网域 |
条状标签 |
| 需要根据发布商确定状态范围的嵌入式广告 | 条状标签 |
| 通过身份提供方登录 | FedCM |
| 嵌入在不同但相关的源上。 | Storage Access API 与 Related Website Set |
| 嵌入的内容采用基于登录的偏好设置 （例如无广告的视频内容，或语言/字幕偏好设置） |
Storage Access API |
| 需要登录的社交媒体评论微件 | Storage Access API |
选择要用于嵌入式第三方用例的 API
本部分逐步介绍了如何选择合适的替代 API，并说明了推荐的 API。
以下流程图可帮助您从可用选项中进行选择：
<ph type="x-smartling-placeholder">
该流程图提出三个主要问题，我们将更详细地探讨这些问题，并说明在每种情况下都推荐特定 API 的原因。
1. 这些 Cookie 是否专用于嵌入网站？
许多第三方嵌入代码在完全不相关的网站上独立使用。例如，客户服务的聊天微件通常需要 Cookie 才能正常运行，但无需在两个完全不同的组织之间共享这些 Cookie，因为这两个组织恰好都使用同一聊天微件解决方案。事实上，在很多此类情况下，该首选项甚至不允许共享 Cookie。
如果您向其他网站提供第三方嵌入服务，并且该服务依赖于 Cookie，请考虑这些 Cookie 是否专用于其所嵌入到网站上的服务。您在其他网站上的嵌入内容是否也会共享这些内容？
如果不需要共享 Cookie，那么使用 CHIPS 对 Cookie 进行分区是最简单的方法。此 API 会将第三方 Cookie 与顶级网站相关联，而不会允许使用同一第三方嵌入的所有网站共享这些 Cookie。CHIPS 易于实现，因为它只需要向现有 Cookie 添加一个额外的 Partitioned 属性。这样一来，嵌入的服务仍然可以保存状态，但会移除允许跨网站跟踪的共享跨网站存储空间。
网站还应检查使用 Cookie 的理由是否正确。仅当已设置 Cookie 或需要随 HTTP 请求一起发送 Cookie 时，才应使用 Cookie。如果情况并非如此，并且 Cookie 仅用作一种方便的存储选项，则应考虑使用各种存储 API。这样可以在不需要发送数据时将数据保留在本地。Storage API 已在所有主流浏览器中进行分区，其方式与 CHIPS 分区 Cookie 类似。
2. 这些 Cookie 是第三方身份提供方的 Cookie 吗？
第三方 Cookie 在嵌入中的一种常见用途是提供由第三方登录提供商（例如使用 Google 账号登录）管理的登录功能。在这种情况下，不能选择分区 Cookie。
Federated Credential Management (FedCM) 是专为此使用情形而打造的专用 API，可在没有第三方 Cookie 的情况下运行。如果 FedCM 获得身份提供方的支持，就可能不再需要第三方 Cookie。
如需详细了解如何解决第三方 Cookie 对登录流程造成的影响，请参阅身份指南。
3. Cookie 是否用于少数相关网站？
如果上述方法均不适合用于替代 Cookie，那么您需要考虑为嵌入代码重新启用第三方 Cookie 访问权限。这可以通过 Storage Access API 在特定受控用例中启用。此 API 可重新启用完整的第三方 Cookie 访问权限（受控制），因此是最强大的选项。因此，如果更严格的替代方法足以满足需求，我们的建议便是避免使用该方法。
使用 Storage Access API 需要满足一些要求：
- 用户之前必须访问过嵌入网站所在的顶级网站。例如，如果嵌入了评论系统，则用户还必须访问该评论系统的网站。
- 用户需要先与嵌入代码互动，然后才能共享 Cookie。这意味着，可能无法在用户互动之前加载完整的嵌入内容。
- 用户可能需要通过浏览器弹出式窗口批准共享 Cookie，尤其是在首次共享时以及之后定期共享时。
- 嵌入网站可能还需要设置其他沙盒属性。
这些限制可确保仅在用户和网站期望时，执行重新启用第三方 Cookie 这一有力操作。但在某些情况下，可能会跳过用户操作。例如，如果用户最近批准了访问请求，在一段时间内（由浏览器定义），可能没有必要再次提示该用户。
用户可能会预料到的另一种情况是针对相关网站。例如，有些组织会使用许多不同的源站，而浏览器将这些源站视为跨网站，因此在这些源站上使用 Cookie 将被视为第三方源。例如，在特定国家/地区拥有具体网站（例如 example.com 和 example.co.uk）的品牌或专门面向特定品牌的网站（例如 example.car 和 example.house）。
在这种情况下，如果相关网站数量很少，您可以使用 Related Website Sets。系统会将网站提交给 Chrome，以便 Chrome 知道这些网站是相关的。这样可以以更人性化的方式访问 Storage Access API，减少的用户提示。
对于实际上是第三方的不相关网站，如果因为备选 API 不够充分而需要完整的第三方 Cookie 访问权限，使用 Storage Access API 需要遵守所有要求并遵守所有提示。
各种 API 的比较
每种解决方案的特性和限制略有不同，因此它们更适合某些应用场景。下表总结了它们的主要区别：
| 条状标签 | 分区存储 | FedCM | 包含 Related WebSite Set 的 Storage Access API | Storage Access API | |
|---|---|---|---|---|---|
| 用户无需之前已作为顶级网站访问嵌入方 | |||||
| 无需用户提示用户批准访问权限 | |||||
| 不需要用户与嵌入内容互动 | （对于具有顶级访问权限的嵌入式网站，此属性也可为 true。） |
||||
| 实施工作量 | 非常低 | 低 | 高 | 中 | 中 |
| 可用于在多个顶级网站/源之间共享 Cookie | （提案正在讨论。） |
||||
| 适用于非 Chromium 浏览器 | （回退到 Storage Access API。） |
跨浏览器支持用例
如表格最后一行所述，在决定采用何种解决方案时，浏览器兼容性是主要的考虑因素之一。部分 API（CHIPS、FedCM、Related WebSite Sets）只能在 Chromium 浏览器上使用。目前仅有的两种跨浏览器解决方案是 Partition Storage API（当不需要 Cookie 时）和 Storage Access API（当需要使用 Cookie 时）。
不过，如前所述，Storage Access API 有一些可能会影响您网站上的用户体验的限制。Chrome 团队一直在努力添加其他 API，这些 API 旨在满足特定应用场景，提供类似于使用第三方 Cookie 时的体验。因此，我们建议您考虑选择最佳选项，并将其视为渐进式增强功能，为不支持的浏览器回退 Storage Access API。
由于 Cookie 遭到阻止的原因有很多（例如，浏览器设置、扩展程序），因此对 API 支持的功能检测可能还不够。最好改为测试预期的 Cookie 是否存在，如果没有，则回退到 Storage Access API 工作流以请求对第三方 Cookie 的访问权限。
立即采取行动！
如果您的第三方嵌入在不使用第三方 Cookie 的情况下无法继续运行，有多种解决方案可以解决这个问题（详见本讲）。现在是时候对您的服务进行第三方 Cookie 审核了！
鉴于 Chrome 正在测试移除第三方 Cookie，目前在嵌入代码方面遇到中断问题的用户可在迁移到本文所述的替代方案时，通过一些短期方案获得帮助。有关详情，请参阅保持关键用户体验文档。
如果您对本指南中未涵盖的第三方嵌入用例有疑问，可以通过“弃用第三方 Cookie”提出新问题标记。