相关网站集

概念与用法

我们来考虑一下您拥有一系列具有不同域名但相互关联的网站的情况，并且您希望在这些网站的内容被加载到其他相关网站的第三方上下文中时（即嵌入到<iframe>中），给予其访问第三方 Cookie 和未分区状态的权限。典型用例包括：

• 应用网站：单个应用程序可以部署在多个网站上，目的是允许用户在同一会话中无缝地在它们之间导航。
• 品牌网站：一组品牌资产可以包含在单个网站中，然后部署在多个域上，包括与用户偏好、自定义等相关的会话数据。

通常，第三方 Cookie 和未分区状态的访问会被浏览器策略阻止。不过，您可以使用 Storage Access API 来规避此问题 — 有关详细信息，请参阅使用 Storage Access API。

相关网站是一种渐进式增强机制，它与 Storage Access API 一起工作。支持的浏览器在同一集内的网站之间授予第三方 Cookie 和未分区状态的访问权限，无需经过通常的用户权限提示工作流，一旦调用了Document.requestStorageAccess()（或Document.requestStorageAccessFor()）。这为集内网站的用户提供了更友好的体验。

您应该牢记：

• 仅限 Chrome 的 Document.requestStorageAccessFor() 方法 — 该方法允许顶级网站代表嵌入的源内容请求存储访问 — 仅在相关网站集内的域上受支持。有关示例，请参阅使用 Storage Access API。
• 当 Chrome 最初支持标准的 Storage Access API（即 Document.hasStorageAccess() 和 Document.requestStorageAccess() 方法）时，它要求调用站点必须属于相关网站集。现在情况不再如此。

RWS 如何工作？

一个相关网站集由一个主网站和最多五个关联网站组成。

JSON 结构

一个集合由 JSON 结构表示。一个假设的示例如下：

{
  "sets": [
    {
      "contact": "email address or group alias if available",
      "primary": "https://primary1.com",
      "associatedSites": [
        "https://associateA.com",
        "https://associateB.com",
        "https://associateC.com"
      ],
      "serviceSites": ["https://servicesiteA.com"],
      "rationaleBySite": {
        "https://associateA.com": "Explanation of affiliation with primary site",
        "https://associateB.com": "Explanation of affiliation with primary site",
        "https://associateC.com": "Explanation of affiliation with primary site",
        "https://serviceSiteA.com": "Explanation of service functionality support"
      },
      "ccTLDs": {
        "https://associateA.com": [
          "https://associateA.ca",
          "https://associateA.co.uk"
        ],
        "https://associateB.com": [
          "https://associateB.ru",
          "https://associateB.co.kr"
        ],
        "https://primary1.com": ["https://primary1.co.uk"]
      }
    }
  ]
}

要使用一个集合，其 JSON 必须添加到 Related Website Sets GitHub 仓库上的 related_website_sets.JSON 文件中，Chrome 然后会使用该文件来获取要应用 RWS 行为的集合列表。

.well-known 文件

集合中的每个网站还必须在 /.well-known/related-website-set.json 处提供一个 .well-known 文件，该文件用于验证集合结构以及集合中网站之间的关系。

主网站的 .well-known 文件必须明确列出完整的集合结构。上述示例中的 https://primary1.com 需要一个 https://primary1.com/.well-known/related-website-set.json 文件，其内容类似如下：

{
  "primary": "https://primary1.com",
  "associatedSites": [
    "https://associateA.com",
    "https://associateB.com",
    "https://associateC.com"
  ],
  "serviceSites": ["https://servicesiteA.com"],
  "rationaleBySite": {
    "https://associateA.com": "Explanation of affiliation with primary site",
    "https://associateB.com": "Explanation of affiliation with primary site",
    "https://associateC.com": "Explanation of affiliation with primary site",
    "https://serviceSiteA.com": "Explanation of service functionality support"
  },
  "ccTLDs": {
    "https://associateA.com": [
      "https://associateA.ca",
      "https://associateA.co.uk"
    ],
    "https://associateB.com": [
      "https://associateB.ru",
      "https://associateB.co.kr"
    ],
    "https://primary1.com": ["https://primary1.co.uk"]
  }
}

每个关联网站和辅助网站都需要在其 .well-known 文件中指定其主网站。上述示例中的每个非主网站（例如 https://associateA.com）都需要一个 /.well-known/related-website-set.json 文件，如下所示：

{
  "primary": "https://primary1.com"
}

有关提交集合的流程、JSON 语法和其他要求的完整详细信息，请参阅提交指南。只有域名管理员才能创建包含其网站的集合。

请记住，.well-known 文件在提交过程中也会被验证，因此它们需要在关联集合提交之前到位。

活跃集合的好处

集合一旦激活

• 来自集合内网站（通过 Document.requestStorageAccess()）的访问集合内网站的第三方 Cookie 和未分区状态的请求将自动获得批准，并且无需进行用户权限步骤。
• 来自集合中顶级网站的 Document.requestStorageAccessFor() 调用可以用来为集合中的其他网站请求第三方 Cookie 访问权限。

RWS 安全性

RWS 在设计时就考虑了安全性。如果恶意网站能够声称自己是集合的一部分并获得相应的权限，那将是灾难性的。让我们考虑一个理论上的恶意网站 evilsite.example.com，并看一些它可能尝试进行的攻击示例，所有这些都会失败：

• evilsite.example.com 声称是另一个集合中的关联网站：如果一个声称属于某个集合的网站（即通过在 .well-known 文件中列出主网站）未包含在集合提交中和/或主网站的 .well-known 文件中，它将无法获得该集合的好处。
• evilsite.example.com 声称是主网站，并提交包含一些潜在受害者网站的集合：提交过程要求非主网站托管的 .well-known 文件明确列出其主网站。如果此主网站与集合提交不匹配（即，如果关联/辅助网站期望拥有不同的主网站，或者根本不期望属于集合），则提交将被拒绝。
• site1.example.com 和 site2.example.com 被故意放在同一个集合中，但 site1.example.com 被 evilsite.example.com 劫持：在集合内的网站劫持攻击的影响不会比通常情况更糟，一旦其他网站相应地更新。
  • 常规的 Storage Access API 要求被嵌入网站主动选择加入，因此 site2.example.com 在嵌入到 site1.example.com 时可以停止调用 document.requestStorageAccess()，从而避免 CSRF 攻击。
  • 使用 requestStorageAccessFor() 需要 CORS，因此 site2.example.com 可以选择不响应来自 site1.example.com 的网络请求的适当 CORS 标头，从而避免 CSRF 攻击。

示例

有关代码示例，请参阅 privacysandbox.google.com 上的相关网站集：开发者指南（2024 年）。

规范

标准立场

两个浏览器供应商反对此规范。已知立场如下：

• Mozilla (Firefox): 否定
• Apple (Safari): 否定

另见

• Storage Access API
• 相关网站集（2023 年）在 privacysandbox.google.com 上。