Verwandte Website-Sets

Nicht standardisiert: Diese Funktion ist nicht standardisiert. Wir raten davon ab, nicht-standardisierte Funktionen auf produktiven Webseiten zu verwenden, da sie nur von bestimmten Browsern unterstützt werden und sich in Zukunft ändern oder entfernt werden können. Unter Umständen kann sie jedoch eine geeignete Option sein, wenn es keine standardisierte Alternative gibt.

Warnung: Dieses Feature wird derzeit von zwei Browseranbietern abgelehnt. Siehe den Abschnitt Standards-Positionen unten für Details zur Ablehnung.

Verwandte Website-Sets sind ein Mechanismus zur Definition einer Gruppe von verwandten Websites, die vertrauenswürdige Inhalte teilen. Infolgedessen können Browser diesen Websites standardmäßig Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand gewähren, wenn sie Inhalte in anderen Setmitgliedern eingebettet haben, ohne dass Benutzer den Zugriff auf die Storage Access API über eine Berechtigungsaufforderung gewähren müssen.

Konzepte und Nutzung

Betrachten wir Situationen, in denen Sie eine Reihe von verwandten Websites mit unterschiedlichen Domainnamen haben und Sie den Zugriff auf Drittanbieter-Cookies und unpartitionierten Zustand ermöglichen möchten, wenn diese in einem Drittanbieter-Kontext innerhalb anderer verwandter Websites geladen werden (d.h. eingebettet in ein <iframe>). Typische Anwendungsfälle sind:

App-Websites: Eine einzelne Anwendung kann über mehrere Websites bereitgestellt werden, um Benutzern eine nahtlose Navigation zwischen ihnen in einer einzigen Sitzung zu ermöglichen.
Marken-Websites: Ein Satz von Markeninhalten kann in einer einzelnen Website enthalten sein, aber dann über mehrere Domains bereitgestellt werden, einschließlich Sitzungsdaten im Zusammenhang mit Benutzerpräferenzen, Anpassungen usw.

Der Zugriff auf Drittanbieter-Cookies und unpartitionierte Zustände wird häufig durch Browser-Richtlinien blockiert. Sie können dies jedoch umgehen, indem Sie die Storage Access API verwenden — siehe Verwendung der Storage Access API für Details.

Verwandte Websites sind ein Mechanismus der progressiven Verbesserung, der zusammen mit der Storage Access API funktioniert. Unterstützende Browser gewähren Drittanbieter-Cookies und unpartitionierten Zustandzugang zwischen Websites im selben Set ohne den gewöhnlichen Benutzerberechtigungs-Workflow durchlaufen zu müssen, sobald Document.requestStorageAccess() (oder Document.requestStorageAccessFor()) aufgerufen wird. Dies führt zu einem benutzerfreundlicheren Erlebnis für die Nutzer der Websites im Set.

Sie sollten folgendes beachten:

Die Chrome-exklusive Methode Document.requestStorageAccessFor() — die es Top-Level-Websites ermöglicht, Speicherzugriff im Namen eingebetteter Ursprungsinhalte anzufordern — wird nur auf Domains innerhalb eines verwandten Website-Sets unterstützt. Siehe Verwendung der Storage Access API für ein Beispiel.
Als Chrome erstmals die Standard-Storage-Access-API unterstützte (d.h. die Methoden Document.hasStorageAccess() und Document.requestStorageAccess()), erforderte es, dass die aufrufenden Websites Teil eines verwandten Website-Sets sind. Dies ist nicht mehr der Fall.

Wie funktioniert RWS?

Ein verwandtes Website-Set besteht aus einer primären Website und bis zu fünf zugehörigen Websites.

JSON-Struktur

Ein Set wird durch eine JSON-Struktur dargestellt. Ein hypothetisches Beispiel sieht wie folgt aus:

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

Hinweis: Die Erklärungen zur Zugehörigkeit müssen eine klare Beschreibung enthalten, wie die Zugehörigkeit zur primären Website den Nutzern dieser Websites präsentiert wird.

Um ein Set zu verwenden, muss dessen JSON zur Datei related_website_sets.JSON hinzugefügt werden, die im Related Website Sets GitHub-Repository verfügbar ist und die Chrome dann verwendet, um die Liste der Sets zu erhalten, auf die das RWS-Verhalten angewendet werden soll.

`.well-known` Dateien

Jede Website im Set muss auch eine .well-known-Datei unter /.well-known/related-website-set.json bereitstellen, die dient, um die Setstruktur und die Beziehung zwischen den Websites im Set zu überprüfen.

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

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

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

json

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

Für vollständige Details zum Prozess, zur JSON-Syntax und zu weiteren Anforderungen für die Einreichung von Sets siehe die Einreichungsrichtlinien. Nur Domain-Administratoren können ein Set erstellen, das ihre Websites enthält.

Bedenken Sie, dass die .well-known-Dateien auch als Teil des Einreichungsprozesses überprüft werden, also müssen sie bereitgestellt werden, bevor das zugehörige Set eingereicht wird.

Vorteile eines aktiven Sets

Sobald ein Set aktiv ist:

Anfragen von Websites im Set (über Document.requestStorageAccess()), um auf Drittanbieter-Cookies und unpartitionierten Zustand zuzugreifen, der zu Websites im Set gehört, werden automatisch gewährt, und es ist kein Benutzerberechtigungsschritt erforderlich.
Document.requestStorageAccessFor()-Aufrufe können von Top-Level-Websites im Set durchgeführt werden, um Drittanbieter-Cookie-Zugang für andere Websites im Set anzufordern.

RWS-Sicherheit

RWS wurde mit Sicherheitsaspekten im Hinterkopf entwickelt. Es wäre katastrophal, wenn eine böswillige Website behaupten könnte, Teil eines Sets zu sein und die damit verbundenen Privilegien zu erlangen. Betrachten wir eine theoretische bösartige Website, evilsite.example.com, und schauen uns einige Beispiele für Angriffe an, die sie versuchen könnte, von denen alle scheitern würden:

evilsite.example.com behauptet, eine zugehörige Website in einem anderen Set zu sein: Wenn eine Website, die behauptet, in einem Set zu sein (d.h. durch Auflisten einer primären in einer .well-known-Datei), nicht in der Seteinreichung und/oder der .well-known-Datei der primären enthalten ist, wird sie nicht die Vorteile erhalten, im Set zu sein.
evilsite.example.com behauptet, eine primäre Website zu sein, und reicht ein Set ein, das einige potenzielle Opferwebsites enthält: Der Einreichungsprozess erfordert, dass .well-known-Dateien, die von nicht-primären Websites gehostet werden, ihre primäre explizit auflisten. Wenn diese primäre nicht mit der Seteinreichung übereinstimmt (d.h. wenn die zugehörigen/Dienst-Websites erwarten, eine andere primäre zu haben oder überhaupt nicht in einem Set zu sein), wird die Einreichung abgelehnt.
site1.example.com und site2.example.com sind absichtlich im selben Set, aber site1.example.com wird von evilsite.example.com gehijackt: Der Einfluss eines Website-Hijacking-Angriffs innerhalb eines Sets ist nicht schlimmer als üblich, sobald 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, sodass site2.example.com sich entscheiden könnte, nicht mit den entsprechenden CORS-Headern zu antworten, wenn Netzwerkanfragen von site1.example.com kommen, wodurch ein CSRF-Angriff vermieden wird.

Beispiele

Für Codebeispiele siehe Verwandte Website-Sets: Entwicklerleitfaden auf privacysandbox.google.com (2024)

Spezifikationen

Specification
User Agent Interaction with Related Website Sets

Standards-Positionen

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

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

Siehe auch

Storage Access API
Verwandte Website-Sets auf privacysandbox.google.com (2023)

Help improve MDN

Learn how to contribute Diese Seite wurde automatisch aus dem Englischen übersetzt.

Übersetzung auf GitHub anzeigen • Fehler mit dieser Übersetzung melden