Verwandte Websitemengen

Betrachten wir Situationen, in denen Sie eine Reihe verwandter Websites mit unterschiedlichen Domain-Namen haben und Sie für deren Inhalte Zugriff auf Drittanbieter-Cookies und nicht partitionierten Zustand gewähren möchten, wenn sie in einem Drittanbieter-Kontext innerhalb anderer verwandter Websites geladen werden (d.h. eingebettet in ein <iframe>). Typische Anwendungsfälle sind:

• App-Sites: Eine einzelne Anwendung kann über mehrere Websites bereitgestellt werden, um Benutzern eine nahtlose Navigation zwischen diesen in einer einzigen Sitzung zu ermöglichen.
• Marken-Websites: Eine Sammlung von Markenressourcen kann in einer einzigen Website enthalten sein, aber über mehrere Domänen bereitgestellt werden, einschließlich Sitzungsdaten zu Benutzerpräferenzen, Anpassungen usw.

Der Zugriff auf Drittanbieter-Cookies und nicht partitionierten Zustand wird häufig durch Browser-Richtlinien blockiert. Dennoch können Sie dies mit der Storage Access API umgehen – siehe Verwendung der Storage Access API für Details.

Verwandte Websitemengen sind ein Mechanismus zur progressiven Verbesserung, der zusammen mit der Storage Access API funktioniert. Unterstützende Browser gewähren Drittanbieter-Cookie- und nicht partitionierten Zustandszugriff zwischen Websites in derselben Menge ohne den üblichen Workflow zur Benutzerberechtigungsaufforderung durchlaufen zu müssen, sobald Document.requestStorageAccess() (oder Document.requestStorageAccessFor()) aufgerufen wird. Dies führt zu einer benutzerfreundlicheren Erfahrung für die Benutzer von Websites in der Menge.

Sie sollten beachten, dass:

• Die nur in Chrome verfügbare Methode Document.requestStorageAccessFor() — die es oberster Ebene ermöglicht, Speicherzugriff im Namen eingebetteter Ursprungsinhalte anzufordern — nur auf Domains innerhalb einer verwandten Websitemenge unterstützt wird. Siehe Verwendung der Storage Access API für ein Beispiel.
• Als Chrome erstmals die standardmäßige Storage Access API unterstützte (d.h. die Methoden Document.hasStorageAccess() und Document.requestStorageAccess()), erforderte es, dass aufrufende Websites Teil einer verwandten Websitemenge sind. Dies ist nicht mehr der Fall.

Eine verwandte Websitemenge besteht aus einer primären Website und bis zu fünf zugehörigen Websites.

Eine Menge wird durch eine JSON-Struktur dargestellt. Ein hypothetisches Beispiel ist wie folgt:

{
  "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"]
      }
    }
  ]
}

Um eine Menge zu verwenden, muss deren JSON zur Datei related_website_sets.JSON hinzugefügt werden, die im Related Website Sets GitHub-Repository verfügbar ist, die Chrome dann verwendet, um die Liste der Mengen zu erhalten, die das RWS-Verhalten anwenden.

Jede Website in der Menge muss auch eine .well-known-Datei unter /.well-known/related-website-set.json bereitstellen, die der Verifizierung der Mengenstruktur und der Beziehung zwischen den Websites in der Menge dient.

Die .well-known-Datei der primären Website muss explizit die vollständige Mengenstruktur auslisten. https://primary1.com im obigen Beispiel würde eine https://primary1.com/.well-known/related-website-set.json-Datei benötigen, die ähnlich wie folgt aussieht:

{
  "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"]
  }
}

Jede zugehörige und Dienst-Website muss ihre primäre Website in einer .well-known-Datei angeben. Jede Nicht-Primär-Website im obigen Beispiel (z.B. https://associateA.com) würde eine /.well-known/related-website-set.json-Datei wie diese benötigen:

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

Für vollständige Details des Prozesses, der JSON-Syntax und anderer Anforderungen zur Einreichung von Mengen siehe die Einreichungsrichtlinien. Nur Domain-Administratoren können eine Menge erstellen, die ihre Websites enthält.

Denken Sie daran, dass die .well-known-Dateien auch als Teil des Einreichungsprozesses überprüft werden, daher müssen sie vorhanden sein, bevor die zugehörige Menge eingereicht wird.

Sobald eine Menge aktiv ist:

• Anfragen von Websites in der Menge (über Document.requestStorageAccess()) für den Zugriff auf Drittanbieter-Cookies und nicht partitionierten Zustand, die zu Websites in der Menge gehören, werden automatisch gewährt, und kein Benutzergenehmigungsschritt ist erforderlich.
• Document.requestStorageAccessFor() Aufrufe können von Websites in der Menge auf oberster Ebene ausgeführt werden, um Zugriff auf Drittanbieter-Cookies für andere Websites in der Menge zu beantragen.

RWS wurde mit Hinblick auf Sicherheit entwickelt. Es wäre katastrophal, wenn eine bösartige Website vorgeben könnte, Teil einer Menge zu sein und die damit verbundenen Privilegien zu erlangen. Lassen Sie uns eine theoretische bösartige Website, evilsite.example.com, betrachten und einige Beispiele für Angriffe ansehen, die sie versuchen könnte, alle davon scheitern:

• evilsite.example.com behauptet, eine zugehörige Website in einer anderen Menge zu sein: Wenn eine Website behauptet, Teil einer Menge zu sein (z.B. durch Auflistung eines Primären in einer .well-known-Datei), aber nicht in der Mengeneinreichung und/oder in der .well-known-Datei des Primären enthalten ist, wird sie die Vorteile nicht erhalten.
• evilsite.example.com behauptet, eine primäre Website zu sein, und reicht eine Menge ein, die einige Opfer-Websites umfasst: Der Einreichungsprozess erfordert, dass .well-known-Dateien, die von Nicht-Primär-Websites gehostet werden, explizit ihren Primären auflisten. Wenn dieser Primär nicht mit der Mengeneinreichung übereinstimmt (z.B. wenn die zugehörigen/Dienst-Websites erwarten, einen anderen Primären zu haben oder nicht in einer Menge zu sein), wird die Einreichung abgelehnt.
• site1.example.com und site2.example.com sind absichtlich in derselben Menge, aber site1.example.com wird von evilsite.example.com übernommen: Die Auswirkungen eines Seitekaperns innerhalb einer Menge sind nicht schlimmer als üblich, wenn die anderen Websites entsprechend aktualisiert werden:
  • Die reguläre Storage Access API erfordert eine aktive Zustimmung der eingebetteten Website, daher kann site2.example.com aufhören, document.requestStorageAccess() aufzurufen, wenn es in site1.example.com eingebettet ist, um einen CSRF-Angriff zu vermeiden.
  • Die Verwendung von requestStorageAccessFor() erfordert CORS, daher könnte site2.example.com sich entscheiden, nicht auf die passenden CORS-Header zu antworten, wenn Netzwerkanfragen von site1.example.com kommen, um so einen CSRF-Angriff zu vermeiden.

• Die Related Website Sets Demo demonstriert, wie RWS verwendet wird.
• Siehe auch Verwendung der Storage Access API.

Zwei Browser-Anbieter lehnen diese Spezifikation ab. Bekannte Positionen sind wie folgt:

• Mozilla (Firefox): Negativ
• Apple (Safari): Negativ

• Storage Access API
• Related Website Sets auf developers.google.com (2023)
• Related Website Sets: Entwicklerleitfaden auf developers.google.com (2023)