First-Party Set 测试说明

最新版 First-Party Sets 已准备好在 Chrome 108 中进行开发者功能标志测试。我们正在积极开发第一方组合，以期尽快发布，因此在 3 月初（2023 年 3 月 7 日）发布 Chrome 111 之前，我们将考虑此开发者测试阶段的反馈。

生态系统反馈突出指出了在 Chrome 不再支持第三方 Cookie 后会受到影响的跨网站用例。“第一方集合”提案旨在审核和解决一类跨网站用例，其中相互依存的网站之间存在可向浏览器表达的关系，以便浏览器能够代表用户执行适当的操作和/或有效地向用户呈现相关信息。

更新后的提案使用两个 API（Storage Access API 和一个暂定名为 requestStorageAccessForOrigin 的新 API），为网站提供一种主动方法，用于请求对其在 First-Party Set 中的 Cookie 的跨网站访问权限。通过以下说明，您应该能够测试和验证您可能需要为网站创建的集合以及调用这两个不同 API 的正确位置。

First-Party Set 概览

第一方集 (FPS) 是一种 Web 平台机制，供开发者声明网站之间的关系，以便浏览器可以使用此信息为特定面向用户的用途启用有限的跨网站 Cookie 访问权限。Chrome 将根据这些声明的关系来决定何时允许或拒绝网站在第三方环境中访问其 Cookie。

概括来讲，First-Party Set 是一组网域，其中包含一个“set primary”和可能多个“set member”。只有网站作者才能将其网域提交到集合，并且他们需要声明每个“集合成员”与其“集合主网域”之间的关系。集合成员可以包含一系列不同的网域类型，并根据使用情形包含子集。

为了便于浏览器根据每个子集的隐私影响来处理每个子集，我们建议利用 Storage Access API (SAA) 和 requestStorageAccessForOrigin 在 FPS 中启用 Cookie 访问权限。

借助 SAA，网站可能会主动请求跨站 Cookie 访问权限。如果请求网站和顶级网站位于同一 FPS 中，Chrome 会自动授予该请求。如需了解其他浏览器如何处理对 SAA 的调用，请参阅 Storage Access API (SAA) 文档。

SAA 目前要求文档在调用 API 的方法之前获得用户激活。

这可能会导致使用需要 Cookie 的跨站图片或脚本代码的顶级网站难以采用 FPS。为了解决其中一些问题，我们提出了新 API requestStorageAccessForOrigin，以便开发者更轻松地采用这项变更。此 API 也已可供测试。

设置提交

规范 FPS 列表将是一个公开可见的 JSON 文件格式列表，存储在新建的 FPS GitHub 代码库中，并将用作所有集的权威来源。Chrome 将使用此文件来应用其行为。

如需详细了解提交套件的建议流程和要求，请参阅提交指南。您也可以尝试提交一组内容，以测试用于验证提交内容的各种技术检查。请注意，在稳定版 Chrome 中推出 FPS 之前，所有提交内容都将获得批准。

由于集合提交流程仍处于积极开发阶段，因此对于本地测试，您只能在命令行上创建集合，并将其直接传递给浏览器。对于本地测试，无需将一组标志提交到 GitHub 代码库，即可使用功能标志进行测试。

如何在本地进行测试

前提条件

如需在本地测试 FPS，请使用从命令行启动的 Chrome 108 或更高版本。

如需在 Chrome 功能正式发布前抢先试用，请下载 Beta 版或 Canary 版 Chrome。

示例

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

详细了解如何使用标志运行 Chromium。

步骤

如需在本地启用 FPS，您需要将 Chrome 的 --enable-features 选项与本部分中介绍的标志逗号分隔的列表搭配使用，并将一组相关网站声明为 JSON 对象以传递给 --use-first-party-set。

启用 FPS

FirstPartySets 会在 Chrome 中启用 FPS。

FirstPartySets

启用 Storage Access API

StorageAccessAPI

在 Chrome 中启用 Storage Access API (SAA)，以允许嵌入的 iframe 使用 requestStorageAccess() 请求在跨网站上下文中访问 Cookie，即使浏览器屏蔽了第三方 Cookie 也是如此。

请注意，调用 requestStorageAccess() 时，需要用户手势才能解析。由于 SAA 规范仍在不断发展，因此未来版本的 Chrome 可能会强加不同的要求。如需查看 Chrome 在实施 SAA 时计划进行的一系列改进，请点击此处。

StorageAccessAPIForOriginExtension

允许顶级网站使用 requestStorageAccessForOrigin() 代表特定来源请求存储空间访问权限。这对于使用需要 Cookie 的跨网站图片或脚本代码的顶级网站非常有用，并且解决了采用 SAA 时遇到的一些问题。

在本地声明集

First-Party Set 是一系列网域，其中包含一个“set primary”和可能多个“set member”。集合成员可以包含一系列不同的网域类型，并根据使用情形包含子集。

创建一个 JSON 对象，其中包含是集合的成员的网址，并将其传递给 --use-first-party-set。

在以下示例中，primary 列出了主网域，associatedSites 列出了符合关联子集要求的网域。

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

示例：

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

对于本地测试，您只能在命令行上创建集并将其直接传递给浏览器。为了进行本地测试，系统不会进行集合验证，但当 FPS 以稳定版本发布时，所有集合都需要提交到 FPS GitHub 代码库，并遵循验证条件。

启用 FPS 界面

PageInfoCookiesSubpage

允许在可通过网址栏访问的 PageInfo 部分中显示 FPS。

PrivacySandboxFirstPartySetsUI

在 Chrome 设置的“隐私和安全性”→“Cookie 及其他网站数据”下（chrome://settings/cookies），启用 FPS 界面中的“允许相关网站查看您在该群组中的活动记录”选项。

确认已屏蔽第三方 Cookie

  1. 在 Chrome 设置中，依次前往“隐私设置和安全性”→“Cookie 及其他网站数据”，或访问 chrome://settings/cookies。
  2. 在“常规”设置下，确保已启用“阻止第三方 Cookie”。
  3. 检查“允许相关网站查看您在该群组中的活动记录”子选项是否也已启用。

安全注意事项

由于 Storage Access API 允许网站在特定情况下重新获得对第三方 Cookie 的访问权限，因此可能会使 Web 应用容易受到跨网站攻击和信息泄露。在跨站上下文中依赖 Cookie 的网站应注意 CSRF 和其他攻击的风险。

计划中的改进

为了改进这一点，未来的 Chrome 版本将需要额外的安全控制措施，以确保嵌入对象明确选择启用。建议的改进包括：仅按帧授予访问权限、对使用凭据的请求要求使用 CORS，并将访问范围仅限于来源。如需了解详情，请参阅近期安全分析。

查看 Chrome 实现 SAA 的计划改进列表。

请注意，Chrome 仅在跨网站嵌入式上下文中发送标记为 SameSite=None 的 Cookie，而 Storage Access API 就适用于这种情况。不过，在所有浏览器都弃用对这些 Cookie 的默认访问权限之前，我们无法假定 Cookie 可在何处使用。不安全地假定仅允许在 FPS 内访问，网站应继续遵循标准的安全最佳实践。

互动和分享反馈

本地测试是您试用 Storage Access API 机制来启用 FPS 的机会，您可以分享反馈或遇到的任何问题。此外，在 GitHub 上测试设定的提交流程，也是一个分享您对该流程和验证步骤的体验的好机会。如需参与讨论并就更新后的提案提供反馈，请执行以下操作：