相关网站集

警告： 此功能目前遭到两家浏览器供应商的反对。有关反对意见的详细信息，请参阅下面的 标准立场 部分。

相关网站集是一种机制，用于定义一组共享可信内容的相关站点。因此，浏览器可以授予这些站点默认访问权限，以访问 第三方 Cookie 和 未分区状态，当它们在其他集合成员中嵌入内容时，无需要求用户通过权限提示授予 存储访问 API 的访问权限。

概念和用法

让我们考虑一下，您有一系列具有不同域名名的相关网站，并且您希望在其他相关站点（例如，嵌入在 <iframe> 中）的第三方上下文中加载时，为站点内容提供访问第三方 Cookie 和未分区状态的权限。典型的用例是

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

浏览器策略通常会阻止第三方 Cookie 和未分区状态访问。但是，您可以使用存储访问 API 绕过它 - 有关详细信息，请参阅 使用存储访问 API。

相关网站是一种渐进式增强机制，与存储访问 API 协同工作。支持的浏览器会在同一集合中的网站之间授予第三方 Cookie 和未分区状态访问权限，无需 经过通常的用户权限提示工作流程，只要调用了 Document.requestStorageAccess()（或 Document.requestStorageAccessFor()）。这为集合中站点的用户带来更加友好的体验。

您应该牢记

RWS 如何工作？

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

JSON 结构

集合由 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 必须添加到 相关网站集 GitHub 存储库 上可用的 related_website_sets.JSON 文件中，Chrome 随后会使用该文件来获取要应用 RWS 行为的集合列表。

.well-known 文件

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

主站点的 .well-known 文件必须明确列出整个集合结构。上面的示例中的 https://primary1.com 需要一个类似于以下内容的 https://primary1.com/.well-known/related-website-set.json 文件

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 文件

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 劫持：一旦其他站点相应更新，站点劫持攻击在集合中的影响与通常情况下一样糟糕
    • 常规 存储访问 API 需要嵌入站点的主动选择加入，因此 site2.example.com 可以停止在嵌入 site1.example.com 时调用 document.requestStorageAccess()，从而避免 CSRF 攻击。
    • requestStorageAccessFor() 的使用需要 CORS，因此 site2.example.com 可以选择在网络请求来自 site1.example.com 时不以适当的 CORS 标头响应，从而避免 CSRF 攻击。

示例

规范

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

标准立场

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

另请参阅