相關網站集

概念與用法

我們來考慮一下您擁有一系列具有不同域名但相互關聯的網站的情況，並且您希望在這些網站的內容被載入到其他相關網站的第三方上下文中時（即嵌入到<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 上。