Verwandte Website-Sets: Entwicklerleitfaden

Gruppen ähnlicher Websites sind Webplattform-Mechanismen, mit deren Hilfe Browser die Beziehungen zwischen verschiedenen Domains besser verstehen können. So können Browser wichtige Entscheidungen darüber treffen, ob bestimmte Websitefunktionen aktiviert werden, z. B. ob der Zugriff auf websiteübergreifende Cookies zugelassen wird, und diese Informationen den Nutzern zur Verfügung zu stellen.

Da in Chrome Drittanbieter-Cookies eingestellt werden, besteht das Ziel darin, wichtige Anwendungsfälle im Web beizubehalten und gleichzeitig den Datenschutz für Nutzer zu verbessern. Beispielsweise sind viele Websites für eine einheitliche Nutzererfahrung auf mehrere Domains angewiesen. Organisationen können verschiedene Top-Level-Domains für verschiedene Anwendungsfälle verwalten, z. B. länderspezifische Domains oder Dienstdomains für das Hosten von Bildern oder Videos. Mit Gruppen ähnlicher Websites können Websites Daten domainübergreifend freigeben. Dabei gelten bestimmte Einstellungen.

Eine Gruppe ähnlicher Websites ist eine Sammlung von Domains, für die es eine einzelne Gruppe von „primär“ und möglicherweise mehrere „Gruppenmitglieder“ gibt.

Im folgenden Beispiel listet primary die primäre Domain und associatedSites Domains auf, die die Anforderungen der zugeordneten Teilmenge erfüllen.

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Die kanonische Liste der Gruppen ähnlicher Websites ist eine öffentlich sichtbare Liste im JSON-Dateiformat, die im GitHub-Repository für Gruppen ähnlicher Websites gehostet wird und als Datenquelle für alle Sätze dient. Chrome verwendet diese Datei, um auf ihr Verhalten anzuwenden.

Nur Personen mit administrativer Kontrolle über eine Domain können einen Satz mit dieser Domain erstellen. Einsender müssen die Beziehung zwischen jedem „Festgelegten Mitglied“ und „Primär festlegen“ deklarieren. Die Mitglieder einer Gruppe können eine Reihe verschiedener Domaintypen enthalten und müssen Teil einer Untergruppe basierend auf einem Anwendungsfall sein.

Wenn Ihre Anwendung vom Zugriff auf websiteübergreifende Cookies (auch als Drittanbieter-Cookies bezeichnet) über Websites einer Gruppe ähnlicher Websites hinweg erforderlich ist, können Sie die Storage Access API (SAA) und die requestStorageAccessFor API verwenden, um den Zugriff auf diese Cookies anzufordern. Abhängig von der Teilmenge, zu der die einzelnen Websites gehören, kann der Browser die Anfrage unterschiedlich verarbeiten.

Weitere Informationen zum Ablauf und zu den Anforderungen für die Einreichung von Sets finden Sie in den Einreichrichtlinien. Eingereichte Sets durchlaufen verschiedene technische Prüfungen, um sie zu validieren.

Gruppen ähnlicher Websites eignen sich gut für den Fall, dass ein Unternehmen eine Form der gemeinsamen Identität für mehrere Websites auf oberster Ebene benötigt.

Hier einige Beispiele für Anwendungsfälle für Gruppen ähnlicher Websites:

  • Länderanpassung: Lokalisierte Websites mit gemeinsam genutzter Infrastruktur nutzen (beispiel.de basiert möglicherweise auf einem von example.ca gehosteten Dienst).
  • Integration von Dienstdomains: Dienstdomains verwenden, mit denen Nutzer nie direkt interagieren, aber Dienste auf den Websites derselben Organisation bereitstellen (beispiel-cdn.com).
  • Trennung von Nutzerinhalten: Zugriff auf Daten in verschiedenen Domains, die von Nutzern hochgeladene Inhalte aus Sicherheitsgründen von anderen Websiteinhalten trennen, während der Sandbox-Domain Zugriff auf Authentifizierungs- und andere Cookies gewährt wird. Wenn inaktive, von Nutzern hochgeladene Inhalte bereitgestellt werden, kannst du sie möglicherweise auch sicher auf derselben Domain hosten, indem du die Best Practices befolgst.
  • Eingebettete authentifizierte Inhalte: Unterstützung eingebetteter Inhalte aus verknüpften Properties (Videos, Dokumente oder Ressourcen, die auf den Nutzer beschränkt sind, der auf der Website der obersten Ebene angemeldet ist).
  • Anmelden Die Anmeldung für verknüpfte Properties unterstützen. Für einige Anwendungsfälle kann auch die FedCM API geeignet sein.
  • Analytics: Mithilfe von Analysen und Messungen von Kaufprozessen können Sie die Qualität der Dienstleistungen für zugehörige Properties verbessern.

Storage Access API

Unterstützte Browser

  • 119
  • 85
  • 65
  • 11.1

Quelle

Die Storage Access API (SAA) bietet eine Möglichkeit für eingebettete ursprungsübergreifende Inhalte, auf den Speicher zuzugreifen, auf den sie normalerweise nur in einem Erstanbieter-Kontext Zugriff haben würden.

Eingebettete Ressourcen können mithilfe von SAA-Methoden prüfen, ob sie derzeit Zugriff auf den Speicher haben, und den Zugriff vom User-Agent anfordern.

Wenn Drittanbieter-Cookies blockiert, aber Gruppen ähnlicher Websites (RWS) aktiviert sind, gewährt Chrome im Intra-RWS-Kontext automatisch Berechtigungen. Andernfalls wird dem Nutzer eine Aufforderung angezeigt. Ein „Intra-RWS-Kontext“ ist ein Kontext, z. B. ein iFrame, dessen eingebettete Website und Website der obersten Ebene sich in derselben RWS-Website befinden.

Speicherzugriff prüfen und anfordern

Eingebettete Websites können mit der Document.hasStorageAccess()-Methode prüfen, ob sie derzeit Zugriff auf den Speicher haben.

Die Methode gibt ein Promise zurück, das mit einem booleschen Wert aufgelöst wird, der angibt, ob das Dokument bereits Zugriff auf seine Cookies hat oder nicht. Das Versprechen gibt auch „true“ zurück, wenn der iFrame am selben Ursprung wie der oberste Frame ist.

Um den Zugriff auf Cookies in einem websiteübergreifenden Kontext anzufordern, können eingebettete Websites Document.requestStorageAccess() (rSA) verwenden.

Die requestStorageAccess() API soll in einem iFrame aufgerufen werden. Der iFrame muss gerade eine Nutzerinteraktion erhalten haben, d. h. eine Nutzergeste, die von allen Browsern erforderlich ist. Chrome verlangt jedoch außerdem, dass der Nutzer in den letzten 30 Tagen die Website, zu der dieser iFrame gehört, besucht und mit dieser Website interagiert hat – als Dokument auf oberster Ebene und nicht als iFrame.

requestStorageAccess() gibt ein Promise zurück, das aufgelöst wird, wenn der Zugriff auf den Speicher gewährt wurde. Das Promise wird unter Angabe des Grunds abgelehnt, wenn der Zugriff aus irgendeinem Grund verweigert wurde.

„requestStorageAccessFor“ in Chrome

Unterstützte Browser

  • 119
  • 119
  • x
  • x

Quelle

Mit der Storage Access API können eingebettete Websites nur über <iframe>-Elemente, die eine Nutzerinteraktion erhalten haben, Zugriff auf den Speicher anfordern.

Dies stellt eine Herausforderung bei der Einführung der Storage Access API für Top-Level-Websites dar, die websiteübergreifende Bilder oder Skript-Tags verwenden, für die Cookies erforderlich sind.

Aus diesem Grund hat Chrome eine Möglichkeit für Websites auf oberster Ebene implementiert, mit Document.requestStorageAccessFor() (rSAFor) Speicherzugriff im Namen bestimmter Ursprünge anzufordern.

 document.requestStorageAccessFor('https://target.site')

Die requestStorageAccessFor() API soll von einem Dokument auf oberster Ebene aufgerufen werden. Das Dokument muss auch gerade eine Nutzerinteraktion erhalten haben. Im Gegensatz zu requestStorageAccess() prüft Chrome jedoch nicht in den letzten 30 Tagen auf eine Interaktion in einem Dokument auf oberster Ebene, da sich der Nutzer bereits auf der Seite befindet.

Berechtigungen für den Speicherzugriff prüfen

Der Zugriff auf einige Browserfunktionen wie die Kamera oder die Standortbestimmung hängt von den Berechtigungen ab, die der Nutzer erteilt hat. Mit der Permissions API kann der Berechtigungsstatus für den Zugriff auf eine API geprüft werden. Dabei spielt es keine Rolle, ob die API gewährt oder abgelehnt wurde oder eine Nutzerinteraktion erforderlich ist, z. B. das Anklicken einer Aufforderung oder die Interaktion mit der Seite.

Sie können den Berechtigungsstatus mit navigator.permissions.query() abfragen.

Zum Prüfen der Speicherzugriffsberechtigung für den aktuellen Kontext müssen Sie den String 'storage-access' übergeben:

navigator.permissions.query({name: 'storage-access'})

Zum Prüfen der Speicherzugriffsberechtigung für einen bestimmten Ursprung müssen Sie den String 'top-level-storage-access' übergeben:

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

Zum Schutz der Integrität des eingebetteten Ursprungs werden damit nur Berechtigungen geprüft, die vom übergeordneten Dokument mit document.requestStorageAccessFor gewährt wurden.

Je nachdem, ob die Berechtigung automatisch gewährt werden kann oder eine Nutzergeste erforderlich ist, wird prompt oder granted zurückgegeben.

Modell pro Frame

rSA-Berechtigungen gelten pro Frame. rSA- und rSAFor-Berechtigungen werden als separate Berechtigungen behandelt.

Jeder neue Frame muss den Speicherzugriff einzeln anfordern und erhält automatisch Zugriff. Nur die erste Anfrage erfordert eine Nutzergeste. Nachfolgende Anfragen, die vom iFrame initiiert werden, z. B. Navigation oder Unterressourcen, müssen nicht auf eine Nutzergeste warten, da diese von der ersten Anfrage für die Browsersitzung gewährt wird.

Wenn Sie den iFrame aktualisieren, neu laden oder anderweitig neu erstellen, muss der Zugriff noch einmal angefordert werden.

In Cookies müssen die Attribute SameSite=None und Secure angegeben werden, da der rSA nur Zugriff auf Cookies bietet, die bereits für die Verwendung im websiteübergreifenden Kontext gekennzeichnet sind.

Cookies mit SameSite=Lax, SameSite=Strict oder ohne SameSite-Attribut sind nur für eigene Zwecke gedacht und werden nie unabhängig vom rSA für einen websiteübergreifenden Kontext freigegeben.

Sicherheit

Für rSAFor-Anfragen für Unterressourcen sind Header Cross-Origin Resource Sharing (CORS) oder das Attribut crossorigin für die Ressourcen erforderlich, um eine explizite Zustimmung zu gewährleisten.

Implementierungsbeispiele

Zugriff auf Speicher von einem eingebetteten ursprungsübergreifenden iFrame anfordern

Diagramm, das eine eingebettete Website auf einer Top-Level-Website zeigt
requestStorageAccess() in einer Einbettung auf einer anderen Website verwenden

Speicherzugriff prüfen

Wenn du prüfen möchtest, ob du bereits Zugriff auf den Speicher hast, verwende document.hasStorageAccess().

Wenn das Versprechen aufgelöst wird, können Sie im websiteübergreifenden Kontext auf den Speicher zugreifen. Wird der Fehler als „false“ behoben, müssen Sie Speicherzugriff anfordern.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

Speicherzugriff anfordern

Wenn Sie Speicherzugriff anfordern müssen, prüfen Sie zuerst die Speicherzugriffsberechtigung navigator.permissions.query({name: 'storage-access'}), um festzustellen, ob dafür eine Nutzergeste erforderlich ist oder ob sie automatisch gewährt werden kann.

Wenn die Berechtigung granted ist, kannst du document.requestStorageAccess() aufrufen. Der Vorgang sollte ohne Nutzergeste erfolgreich sein.

Wenn der Berechtigungsstatus prompt lautet, musst du den document.requestStorageAccess()-Aufruf nach einer Nutzergeste starten, z. B. nach dem Klicken auf eine Schaltfläche.

Beispiel:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Nachfolgende Anfragen aus dem Frame, Navigationen oder Unterressourcen haben automatisch die Berechtigung für den Zugriff auf websiteübergreifende Cookies. hasStorageAccess() gibt echte Cookies zurück und websiteübergreifende Cookies derselben Gruppe ähnlicher Websites werden bei diesen Anfragen ohne zusätzliche JavaScript-Aufrufe gesendet.

Diagramm, das zeigt, wie „requestStorageAccessFor()“ auf einer Website der obersten Ebene und nicht in einer Einbettung verwendet wird
requestStorageAccessFor() auf einer Website der obersten Ebene für einen anderen Ursprung verwenden

Websites der obersten Ebene können mit requestStorageAccessFor() Speicherzugriff im Namen bestimmter Ursprünge anfordern.

hasStorageAccess() prüft nur, ob die aufrufende Website Speicherzugriff hat. Eine Website der obersten Ebene kann also die Berechtigungen für einen anderen Ursprung prüfen.

Rufen Sie navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}) auf, um herauszufinden, ob der Nutzer aufgefordert wird oder ob der angegebene Ursprung bereits Speicherzugriff gewährt wurde.

Wenn die Berechtigung granted ist, können Sie document.requestStorageAccessFor('https://target.site') aufrufen. Dies sollte ohne eine Nutzergeste erfolgreich sein.

Wenn die Berechtigung prompt ist, musst du den document.requestStorageAccessFor('https://target.site')-Aufruf hinter der Nutzergeste haken, z. B. beim Klicken auf eine Schaltfläche.

Beispiel:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Nach einem erfolgreichen requestStorageAccessFor()-Aufruf enthalten websiteübergreifende Anfragen Cookies, sofern sie CORS oder das ursprungsübergreifende Attribut enthalten. Daher sollten Websites warten, bevor eine Anfrage ausgelöst wird.

In den Anfragen muss die Option credentials: 'include' verwendet werden und die Ressourcen müssen das Attribut crossorigin="use-credentials" enthalten.

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

Lokale Tests

Voraussetzungen

Wenn Sie Gruppen ähnlicher Websites lokal testen möchten, verwenden Sie Chrome 119 oder höher, das über die Befehlszeile gestartet wird, und aktivieren Sie das Chrome-Flag test-third-party-cookie-phaseout.

Chrome-Flag aktivieren

Wenn Sie das erforderliche Chrome-Flag aktivieren möchten, rufen Sie in der Adressleiste chrome://flags#test-third-party-cookie-phaseout auf und ändern Sie das Flag in Enabled. Nachdem die Flags geändert wurden, müssen Sie den Browser neu starten.

Wenn Sie Chrome mit einer lokal deklarierten Gruppe ähnlicher Websites starten möchten, erstellen Sie ein JSON-Objekt, das URLs enthält, die Mitglieder einer Gruppe sind, und übergeben Sie es an --use-related-website-set.

Weitere Informationen zum Ausführen von Chromium mit Flags

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Beispiel

Wenn Sie Gruppen ähnlicher Websites lokal aktivieren möchten, müssen Sie test-third-party-cookie-phaseout in chrome://flags aktivieren und Chrome über die Befehlszeile mit dem Flag --use-related-website-set mit dem JSON-Objekt starten, das die URLs einer Gruppe enthält.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Prüfen, ob Sie Zugriff auf websiteübergreifende Cookies haben

Rufen Sie die APIs (rSA oder rSAFor) der getesteten Websites auf und validieren Sie den Zugriff auf die websiteübergreifenden Cookies.

So deklarieren Sie die Beziehung zwischen Domains und geben an, zu welcher Teilmenge sie gehören:

  1. Geben Sie die relevanten Domains an. Dazu gehören die festgelegten primären Domains und die festgelegten Mitglieder, die zur Gruppe ähnlicher Websites gehören. Geben Sie außerdem an, zu welchem Untergruppentyp die einzelnen Satzmitglieder gehören.
  2. Prüfen Sie, ob die Festlegungsanforderungen und festgelegten Validierungsanforderungen vorhanden sind.
  3. Deklarieren Sie die Gruppe ähnlicher Websites im richtigen JSON-Format.
  4. Reichen Sie die Gruppe ähnlicher Websites ein, indem Sie eine Pull-Anfrage an die related_website_sets.JSON erstellen, in der Chrome die kanonische Liste der Gruppen ähnlicher Websites hostet. Zum Erstellen von PRs ist ein GitHub-Konto erforderlich. Außerdem musst du eine Lizenzvereinbarung für Beitragende unterzeichnen, wenn du zur Liste beitragen möchtest.

Nachdem die PR erstellt wurde, wird anhand einer Reihe von Prüfungen bestätigt, dass die Anforderungen aus Schritt 2 erfüllt sind.

Wenn der Vorgang erfolgreich war, wird im PR-Team angezeigt, dass die Prüfungen bestanden wurden. Genehmigte PRs werden einmal pro Woche (dienstags um 12:00 Uhr Eastern Time) manuell in Batches mit der kanonischen Liste der Gruppen ähnlicher Websites zusammengeführt.

Wenn eine der Prüfungen nicht bestanden wird, wird der Antragsteller auf GitHub über ein PR-Fehler informiert. Der Absender kann die Fehler beheben und die PR-Datei aktualisieren. Beachte dabei Folgendes:

  • Wenn die PR fehlschlägt, werden in einer Fehlermeldung zusätzliche Informationen dazu angezeigt, warum die Einreichung fehlgeschlagen sein könnte (Beispiel).
  • Alle technischen Prüfungen für die Einreichung von Sets werden auf GitHub durchgeführt. Daher sind alle Übermittlungsfehler, die durch technische Prüfungen entstehen, auf GitHub einsehbar.

Unternehmensrichtlinien

Für Chrome gibt es einige Unternehmensrichtlinien, um die Anforderungen von Unternehmensnutzern zu erfüllen:

  • Für Systeme, die sich möglicherweise nicht in Gruppen ähnlicher Websites einbinden lassen, kann die Funktion für Gruppen ähnlicher Websites in allen Unternehmensinstanzen von Chrome mit der Richtlinie „RelatedWebsiteSetsEnabled“ deaktiviert werden.
  • Einige Unternehmenssysteme verfügen über rein interne Websites (z. B. ein Intranet) mit registrierierbaren Domains, die sich von den Domains in der Gruppe ähnlicher Websites unterscheiden. Wenn sie diese Websites als Teil ihrer Gruppe ähnlicher Websites behandeln möchten, ohne sie öffentlich zugänglich zu machen, weil die Domains möglicherweise vertraulich sind, können sie ihre öffentliche Liste der Gruppen ähnlicher Websites mit der Richtlinie „RelatedWebsiteSetsOverrides“ erweitern oder überschreiben.

„Nutzeraufforderung“ und „Nutzergeste“

Eine „Nutzeraufforderung“ und eine „Nutzergeste“ sind unterschiedliche Dinge. Chrome zeigt Nutzern keine Berechtigungsaufforderung für Websites an, die zur selben Gruppe ähnlicher Websites gehören. Allerdings muss der Nutzer mit der Seite interagiert haben. Bevor die Berechtigung gewährt wird, benötigt Chrome eine Nutzergeste, die auch als "Nutzerinteraktion" oder "Nutzeraktivierung" bezeichnet wird. Das liegt daran, dass die Nutzung der Storage Access API außerhalb des Kontexts einer Gruppe ähnlicher Websites (requestStorageAccess()) aufgrund der Designprinzipien für Webplattformen auch eine Nutzergeste erfordert.

Auf Cookies oder Speicher anderer Websites zugreifen

Gruppen ähnlicher Websites führen den Speicher verschiedener Websites nicht zusammen, sondern ermöglichen lediglich einfachere requestStorageAccess()-Aufrufe ohne Aufforderungen. Gruppen für ähnliche Websites erleichtern Nutzern die Nutzung der Storage Access API zwar lediglich, sie geben jedoch nicht vor, was zu tun ist, nachdem der Zugriff wiederhergestellt wurde. Wenn A und B unterschiedliche Websites in derselben Gruppe ähnlicher Websites sind und A bettet B ist, kann B requestStorageAccess() aufrufen und Zugriff auf eigenen Speicher erhalten, ohne dem Nutzer nachzufragen. Für Gruppen ähnlicher Websites erfolgt keine websiteübergreifende Kommunikation. Wenn Sie beispielsweise eine Gruppe ähnlicher Websites einrichten, werden die Cookies von B nicht automatisch an A gesendet. Wenn Sie diese Daten freigeben möchten, müssen Sie sie selbst teilen. Senden Sie beispielsweise ein window.postMessage von einem B-iFrame an einen A-Frame.

Für Gruppen ähnlicher Websites ist der implizite nicht partitionierte Zugriff auf Cookies ohne Aufruf einer API nicht möglich. Websiteübergreifende Cookies werden innerhalb der Gruppe standardmäßig nicht zur Verfügung gestellt. Gruppen ähnlicher Websites erlauben nur Websites innerhalb der Gruppe, die Berechtigungsaufforderung für die Storage Access API zu überspringen. Ein iFrame muss document.requestStorageAccess() aufrufen, wenn er auf seine Cookies zugreifen möchte, oder die Seite der obersten Ebene kann document.requestStorageAccessFor() aufrufen.

Feedback geben

Wenn Sie einen Satz auf GitHub einreichen und mit der Storage Access API und der requestStorageAccessFor API arbeiten, können Sie Ihre Erfahrungen mit dem Prozess und den Problemen, die auftreten, teilen.

So nehmen Sie an Diskussionen über Gruppen ähnlicher Websites teil: