用户代理与相关网站集的交互

社区组报告草案，

本版本：
https://wicg.github.io/first-party-sets/
问题跟踪：
GitHub
规范内联
编辑：
(Google)
(Google)
(Google)

Copyright © 2025 the Contributors to the User Agent Interaction with Related Website Sets Specification, published by the Web Platform Incubator Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

摘要

用户代理应如何与相关网站集集成，相关网站集是一种将一组相关 域名声明为属于同一相关网站集的机制。

本文档的状态

本规范由Web 平台孵化器 社区组发布。 它既不是 W3C 标准，也未处于 W3C 标准制定流程中。 请注意，根据 W3C 社区 贡献者许可协议（CLA），存在有限的退出机制，并适用其他条件。 进一步了解 W3C 社区组与商业组。

1. 引言

本节内容为非规范性内容。

相关网站集（“RWS”）为开发者提供了一个声明站点之间关系的框架， 使得用户代理可以出于面向用户的目的允许有限地访问跨站数据（例如 Cookie）。 这是通过使用 存储访问 API 实现的。

本文档定义了用户代理应如何与相关 网站集列表集成。关于 RWS 列表结构以及 提交时所运行的技术验证的规范参考，请参阅相关 网站集提交指南。

2. 基础设施

本规范依赖于 Infra 标准。[INFRA]

3. 列表消费

用户代理应定期消费规范的相关 网站集列表（例如每 2 周一次），并将其作为可更新组件 交付给各个客户端（例如浏览器应用程序）。

我们能否在此处 就更新间隔给出建议？ href="https://github.com/wicg/first-party-sets/issues/122">[wicg/first-party-sets Issue #122]

各个客户端必须在重启时，或在启动时（如果是新下载的），构建相关网站集列表。客户端不得在任何其他时间点 重新构建该列表。

RWS 列表是一个 UTF-8 编码的文件，其内容可解析为一个 JSON 对象，并符合 相关 网站集提交指南中所描述的 [JSON-SCHEMA]。

注意： 对该模式的符合性在 提交时进行验证。因此，用户代理无需在客户端再次验证符合性。 本规范中的算法描述了用户代理应如何解析 RWS 列表，以及 何时应从客户端的角度认为某个特定的集是有效的。

在公共后缀 列表版本在服务器与客户端之间存在差异的情况下，可能 需要进行客户端验证。 href="https://github.com/wicg/first-party-sets/issues/125">[wicg/first-party-sets Issue #125]

要从一个 JSON data-link-type="dfn" href="https://infra.spec.whatwg.org/#byte-sequence" id="ref-for-byte-sequence">字节 序列 bytes 构建相关网站集列表，用户代理应运行以下步骤：

  1. 令 json 为以 bytes 对 将 JSON 字节解析为 infra 值 的结果。

  2. 如果 json 是一个解析异常，或者 json 不是一个 有序映射，或者 json[“sets”] 不存在，则返回，并可选择重试获取该列表，或执行 其他错误恢复任务。

  3. 对于 json 的每个 entry：

    1. 令 set 为一个相关网站集。

    2. 如果 entry[“primary”] 不存在，则继续。

本规范 目前建议跳过无效的集（缺少 primary 条目）而不是拒绝整个列表。 然而，鉴于服务器应始终持有有效信息，进行完全拒绝 可能会有好处。 href="https://github.com/wicg/first-party-sets/issues/126">[wicg/first-party-sets Issue #126]

  1. 将 set 的 primary 设置为 entry[“primary”]。

  2. 令 ccTLDs 为从 entry[“ccTLDs”] 解析等价映射 的结果。如果 ccTLDs 是失败，则继续。

  3. 将 set 的 ccTLDs 设置为 ccTLDs。

  4. 令 serviceSites 为从 entry[“serviceSites”] 解析子集 的结果。如果 结果是失败，则继续。

  5. 将 set 的 serviceSites 设置为 serviceSites。

  6. 令 associatedSites 为从 entry[“associatedSites”] 解析子集 的结果。如果 结果是失败，则继续。

  7. 将 set 的 associatedSites 设置为 associatedSites。

  8. 将 set 添加到用户代理的相关网站集列表中。

用户代理可以选择在交付给客户端之前将列表预处理为不同的格式（例如出于 优化原因），只要它们确保客户端最终持有本规范中定义的有效 data-link-type="dfn" href="#list-of-related-website-sets" id="ref-for-list-of-related-website-sets①">相关网站集列表即可。

4. 数据结构

用户代理维护一个全局的相关网站集列表，它是一个由相关网站集组成的列表。

相关网站集 是一个结构体， 具有以下项：

primary：一个代表该集的主域名的站点。

ccTLDs：一个等价映射，代表由提交者指定的该集的等价 国家代码顶级域名。

associatedSites：关联子集中的站点的列表。

serviceSites：服务子集中的站点的列表。

注意： 关于这些字段含义的 更多背景信息，请参阅相关 网站集提交指南。

等价映射是 一个从站点到 data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/browsers.html#site" id="ref-for-site④">站点列表的有序映射。

要从一个字符串 input 解析并 验证一个站点，运行以下步骤：

  1. 令 url 为对 input 进行基本 URL 解析的结果。如果结果是 失败，则返回失败。

  2. 如果 url 的 scheme 不是 "https"，则返回失败。

  3. 令 site 为从 url 的源获取站点的结果。

  4. 返回 site。

要从一个列表 input 解析子集，运行以下步骤：

  1. 令 list 为一个空列表。

  2. 对于 input 的每个 item：

    1. 令 site 为从 item 解析并 验证一个站点的结果。

    2. 如果 site 是失败，则返回失败。

    3. 将 site 添加到 list。

  3. 返回 list。

要从一个有序映射 input 解析 等价映射，运行以下步骤：

  1. 令 map 为一个空等价映射。

  2. 对于 input 的每个 key → value：

    1. 令 keySite 为从 key 解析并 验证一个站点的结果。如果结果是失败，则返回失败。

    2. 令 equivalents 为一个空列表。

    3. 对于 value 中的每个 equivalent：

      1. 令 equivalentSite 为从 equivalent 解析并验证一个站点的结果。如果结果是失败，则返回失败。

      2. 将 equivalentSite 添加到 equivalents。

    4. 将 map[keySite] 设置为 equivalents。

  3. 返回 map。

5. 验证相关网站集的纳入

在 RWS 下，给定一个等价映射 equivalents，若 equivalents[site1] 包含 site2 或 equivalents[site2] 包含 site1，则站点 site1 被视为等价于另一个站点 site2。

是否应将其重命名 以避免与数学上的等价关系相混淆？ href="https://github.com/wicg/first-party-sets/issues/123">[wicg/first-party-sets Issue #123]

要确定 成员类型，即给定一个相关网站集 set 中给定站点 site 的成员类型，运行以下步骤：

  1. 如果给定 set 的 ccTLDs，site 等价于 set 的 primary， 则返回 “primary”。

  2. 对于 set 的 associatedSites 中的每个 associatedSite：

    1. 如果给定 set 的 ccTLDs，site 等价于 associatedSite， 则返回 “associated”。

  3. 对于 set 的 serviceSites 中的每个 serviceSite：

    1. 如果给定 set 的 ccTLDs，site 等价于 serviceSite， 则返回 “service”。

  4. 返回 “none”。

要为给定的站点 site 查找一个相关 网站集，运行以下步骤：

  1. 对于用户代理的相关 网站集列表中的每个 set：

    1. 令 type 为 site 在 set 中的成员类型。

    2. 如果 type 不是 “none”，则返回 set。

  2. 返回 null。

注意： 相关 网站集提交指南要求每个站点最多只能出现在一个 相关网站集中，这在提交时进行验证。因此，用户代理在执行这些步骤时无需 关注相关网站集列表的顺序。

将单个相关网站集内的关联站点 上限定义为一个由实现定义的值，建议为 3。

注意： 此上限在确定关联站点资格时使用， 以便仅考虑列在关联子集顶部的站点。它旨在 阻止滥用，并帮助用户和用户代理理解为什么某个特定的相关网站集需要 存在。用户代理可以基于此目标选择不同的数字。

如果以下步骤返回 true，则站点 embeddedSite 在嵌入于站点 topLevelSite 内时有资格获得同方 成员资格：

  1. 令 set 为为 topLevelSite 查找一个相关网站集的结果。

  2. 如果 set 是 null，则返回 false。

  3. 令 topLevelType 为 topLevelSite 在 set 中的成员类型。

  4. 如果 topLevelType 是 “associated” 且给定 topLevelSite 和 set 确定 关联站点资格的结果为 false，则返回 false。

  5. 如果 topLevelType 是 “service”，则返回 false。

  6. 令 type 为 embeddedSite 在 set 中的成员类型。

  7. 如果 type 是 “none”，则返回 false。

  8. 如果 type 是 “associated”，则返回给定 embeddedSite 和 set 确定 关联站点资格的结果。

  9. 返回 true。

要给定一个站点 site 和一个相关网站集 set 确定关联站点资格，运行以下步骤：

  1. 如果 set 的 associatedSites 不包含 site，则返回 false。

  2. 令 index 为 site 在 set 的 associatedSites 中的索引。

  3. 如果 index 大于或等于关联站点 上限，则返回 false。

  4. 返回 true。

如果以下步骤返回 true，则给定的环境设置对象 settings 与其顶级嵌入者 同方：

  1. 令 topLevelSite 为从 settings 的 data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin" id="ref-for-concept-environment-top-level-origin">顶级源获取站点的结果。

  2. 令 embeddedSite 为从 settings 的 data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-origin" id="ref-for-concept-settings-object-origin">源获取站点的结果。

  3. 返回 embeddedSite 在嵌入于 topLevelSite 内时是否有资格获得同方 成员资格。

如果以下步骤返回 true，则给定的环境设置对象 settings 和 data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/browsers.html#concept-origin" id="ref-for-concept-origin">源 origin 在嵌入上下文中是同方：

  1. 令 topLevelSite 为从 settings 的 data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin" id="ref-for-concept-environment-top-level-origin①">顶级源获取站点的结果。

  2. 令 embeddedSite 为从 origin 获取站点的结果。

  3. 返回 embeddedSite 在嵌入于 topLevelSite 内时是否有资格获得同方 成员资格。

6. 与存储访问 API 的集成

修改 requestStorageAccess() 以在步骤 13.5 之前（即在请求使用权限之前）插入以下步骤：

  1. 令 settings 为 doc 的相关设置对象。

  2. 如果 settings 与其顶级嵌入者 同方，用户代理可以以 data-link-type="dfn" href="https://w3c.github.io/permissions/#dfn-granted" id="ref-for-dfn-granted">已授予运行处理权限状态并中止剩余步骤。

修改 requestStorageAccessFor(requestedOrigin) 以在步骤 13.8 之前（即在请求使用权限之前）插入以下步骤：

  1. 令 settings 为 doc 的相关设置对象。

  2. 如果 settings 和 requestedOrigin 在嵌入上下文中是同方， 用户代理可以给定 global 在权限任务源上排队一个全局任务以 data-link-type="dfn" href="https://webidl.spec.whatwg.org/#resolve" id="ref-for-resolve">解决 p 并中止剩余步骤。

7. 处理相关网站集的变更

当一个站点 site 由于构建新的相关网站集列表而离开一个相关网站集时，用户代理必须通过运行以下步骤确保 它不会保留对该相关网站集中其他站点所持有的数据或共享标识符的任何 访问权限：

  1. 断言 site 不是一个不透明源。

  2. 令 domain 为 site 的主机。

  3. 对于用户代理已知的每个其主机的注册域名为 domain 的 origin：

    1. 清除该源的缓存。

    2. 清除该源的 Cookie。

    3. 清除该源的 DOM 可访问存储。

    4. 令 descriptor 为一个新创建的 PermissionDescriptor， 其 name 初始化为 “storage-access”。

    5. 对于 descriptor，移除所有 key[0] 为 site 或 key[1] 为 origin 的权限存储条目。

    6. 运行额外的由实现定义的步骤，以确保从 origin 中移除任何 网络可访问的存储。

本节应 提供更多关于用户代理如何确定站点何时离开 RWS 的细节。 href="https://github.com/wicg/first-party-sets/issues/124">[wicg/first-party-sets Issue #124]

8. 与其他特性的集成

用户代理可以将通过 RWS 声明的域名关系用于其他由实现定义的目的， 在这种情况下，它们仍必须遵循本规范的其余部分来消费和存储 RWS 列表 以及检查同方成员资格的资格。

注意： 例如， href="https://github.com/GoogleChrome/ip-protection">Chrome 的 IP 保护提案包括 依赖 RWS 来确定第一方和第三方上下文。

9. 隐私考量

9.1. 提供用户透明度与控制

使用 RWS 来推断两个站点之间关系的用户代理应确保其用户被 告知此用户代理选择，并让用户有机会查看和控制用户代理所做的 选择。

9.2. 确保与非 RWS 环境的兼容性

某些用户代理可能选择在特定环境中（例如隐私浏览模式）不支持 RWS，或 完全不支持。所有用户代理和规范应在其自身的 API 集成中注意这一点，并力求 为用户和开发者优雅地回退到一个可用的解决方案。

对于提供跨站 Cookie 的访问，本规范旨在通过使用存储访问 API来确保与非 RWS 环境的兼容性，该 API 为开发者提供了一个接口来处理对请求的拒绝，并赋予用户代理灵活性， 以采用诸如提示或启发式方法等机制作为 RWS 的替代方案。

9.3. 防止因列表变更导致的隐私泄露

开发者可以提交对其集的更改以添加或移除站点。由于集中的成员资格可能通过 存储访问 API 的自动授予提供对跨站 Cookie 的 访问，因此我们需要注意这些转换，使其不会跨越用户历史上所属的所有 RWS 来 关联用户身份。特别是，我们必须确保某个域名在更改其集成员资格时，不能将一个用户标识符从一个 相关网站集转移到另一个。虽然一个集成员可能并不总是请求 并被授予对跨站 Cookie 的访问，但为了简化集转换的处理，我们 提议将此类访问视为始终被授予。

因此，本规范要求用户代理在某个站点从一个集中被移除时，于开始任何依赖 这些权限或站点数据的获取之前，清除该给定站点的任何站点数据和存储访问 权限。

注意： 大多数获取并不依赖于需要 被清除的数据，因此建议用户代理针对请求延迟进行优化。

10. 安全考量

10.1. 避免削弱新的及现有的安全边界

为提升隐私而收紧边界的 Web 平台变更往往对安全也有正面 影响。例如，缓存分区限制了缓存探测攻击，而 第三方 Cookie 阻止则默认使得执行跨站请求伪造（CSRF） 变得困难得多。当用户代理打算使用相关网站集来替换或扩展 Web 上基于 站点或源的现有边界时，重要的是不仅要考虑对隐私的影响，还要考虑对 安全的影响。

共属一个 RWS 的站点可能具有差异极大的安全要求，例如，一个集可能包含一个 存储用户凭据的站点和另一个托管不受信任的用户数据的站点。即使在同一个集内，站点仍依赖 于跨站和跨源限制来保持对数据暴露的控制。在合理范围内， RWS 中一个被入侵的站点不应能够影响集中其他站点的完整性。

这一考量将始终涉及一个必要的权衡，即在诸如性能或 互操作性等收益与对用户和站点的风险之间。用户代理应促成额外的机制，例如 按源的选择加入或选择退出，以管理这一权衡。

致谢 class="self-link" href="#acknowledgements">

W3C 隐私社区组的其他成员此前曾建议使用存储访问 API，或 一个等价的 API；以替代 SameParty Cookie。感谢 @jdcauley（ href="https://github.com/WICG/first-party-sets/issues/14#issuecomment-785144990">1）、 @arthuredelstein（2）以及 @johnwilander（ href="https://lists.w3.org/Archives/Public/public-privacycg/2022Jun/0001.html">3）。

浏览器供应商、Web 开发者以及 Web 社区的成员在本提案 于 W3C 隐私社区组孵化期间提供了宝贵的反馈。

本提案包含来自前任共同编辑 David Benjamin 和 Harneet Sidhana 的重大贡献。

我们也感谢 Chris Fredrickson 和 Shuran Huang 的贡献。

一致性

文档 约定

一致性要求通过描述性断言 和 RFC 2119 术语的组合来表达。 规范性部分中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、 “MAY” 和 “OPTIONAL” 应按 RFC 2119 中的描述进行解释。 不过，为了可读性， 这些词在本规范中并不全部以大写字母出现。

本规范的所有文本均为规范性内容， 但明确标记为非规范性的章节、示例和注释除外。 用于在 RFC 中指示 要求级别的关键词

本规范中的示例以 “for example” 一词引入， 或通过 class="example" 与规范性文本分开， 如下所示：

这是资料性示例的一个示例。

资料性注释以 “Note” 一词开始， 并通过 class="note" 与规范性文本分开， 如下所示：

Note，这是一个资料性注释。

索引

本 规范定义的术语

由 引用定义的术语

参考文献

规范性参考文献

[CLEAR-SITE-DATA]
Mike West. Clear Site Data. URL: https://w3c.github.io/webappsec-clear-site-data/
[ENCODING]
Anne van Kesteren. Encoding Standard. 现行 标准。URL: https://encoding.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. 现行标准。URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. 现行标准。URL: https://infra.spec.whatwg.org/
[PERMISSIONS]
Marcos Caceres; Mike Taylor. Permissions. URL: https://w3c.github.io/permissions/
[PSL]
Public Suffix List. Mozilla Foundation.
[REQUESTSTORAGEACCESSFOR]
requestStorageAccessFor API. 编辑草案。URL: https://privacycg.github.io/requestStorageAccessFor/
[RFC2119]
S. Bradner. 用于在 RFC 中 指示要求级别的关键词. 1997 年 3 月。最佳当前实践。URL: https://datatracker.ietf.org/doc/html/rfc2119
[STORAGE-ACCESS]
Storage Access API. CG 草案。URL: https://privacycg.github.io/storage-access/
[URL]
Anne van Kesteren. URL Standard. 现行标准。 URL: https://url.spec.whatwg.org/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. 现行 标准。URL: https://webidl.spec.whatwg.org/

资料性参考文献

[CACHE-PROBING]
Cache Probing. URL: https://xsleaks.dev/docs/attacks/cache-probing/
[CSRF]
Cross Site Request Forgery (CSRF). URL: https://owasp.org/www-community/attacks/csrf
[JSON-SCHEMA]
Austin Wright; et al. JSON Schema: A Media Type for Describing JSON Documents. 2022 年 6 月 10 日。Internet-Draft。URL: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema
[RWS-LIST]
Related Website Sets list. URL: https://github.com/GoogleChrome/related-website-sets/blob/main/related_website_sets.JSON
[SUBMISSION-GUIDELINES]
Related Website Sets Submission Guidelines. URL: https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md

议题索引

我们可以在这里对更新间隔提出建议吗？ [wicg/first-party-sets Issue #122] ↵
在服务器与客户端之间的 Public Suffix List 版本不同的情况下，可能需要客户端验证。 [wicg/first-party-sets Issue #125] ↵
该规范目前建议跳过无效集合（缺少 primary 条目），而不是拒绝整个列表。 然而，鉴于服务器预期始终持有有效信息，完全拒绝可能会有益。 [wicg/first-party-sets Issue #126] ↵
是否应该重命名，以避免与数学上的等价关系混淆？ [wicg/first-party-sets Issue #123] ↵
本节应提供更多细节，说明用户代理如何判断站点何时 离开 RWS。 [wicg/first-party-sets Issue #124] ↵