Verwandte Website-Sets: Entwicklerleitfaden

Related Website Sets (RWS) ist ein Webplattformmechanismus, der Browsern hilft, die Beziehungen zwischen einer Gruppe von Domains zu verstehen. So können Browser wichtige Entscheidungen treffen, um bestimmte Websitefunktionen zu aktivieren (z. B. ob der Zugriff auf websiteübergreifende Cookies erlaubt werden soll) und diese Informationen den Nutzern zu präsentieren.

Durch die Einstellung von Drittanbieter-Cookies in Chrome soll es weiterhin möglich sein, wichtige Anwendungsfälle im Web zu nutzen und gleichzeitig den Datenschutz für Nutzer zu verbessern. Viele Websites nutzen beispielsweise mehrere Domains, um eine einheitliche Nutzererfahrung zu bieten. Organisationen können verschiedene Top-Level-Domains für mehrere Anwendungsfälle verwalten, z. B. länderspezifische Domains oder Dienstdomains zum Hosten von Bildern oder Videos. Mit ähnlichen Website-Sets können Websites Daten mithilfe bestimmter Steuerelemente über Domains hinweg freigeben.

Was ist eine Gruppe ähnlicher Websites?

Eine Gruppe ähnlicher Websites besteht aus einer Sammlung von Domains, für die es eine einzelne „primäre Website“ und möglicherweise mehrere „Set-Mitglieder“ gibt.

Im folgenden Beispiel wird in primary die primäre Domain und in associatedSites die Domains aufgeführt, die die Anforderungen der verknüpften Teilmenge erfüllen.

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

Die kanonische Liste der Sets mit ähnlichen Websites ist eine öffentlich einsehbare Liste im JSON-Dateiformat, die im GitHub-Repository für Sets mit ähnlichen Websites gehostet wird. Sie dient als vertrauenswürdige Quelle für alle Sets. Chrome verwendet diese Datei, um sein Verhalten anzupassen.

Nur Nutzer mit Administratorzugriff auf eine Domain können einen Satz mit dieser Domain erstellen. Einreichende müssen die Beziehung zwischen jedem „Set-Mitglied“ und seinem „Set-Primärelement“ angeben. Die Mitglieder eines Sets können verschiedene Domaintypen umfassen und müssen Teil eines auf einem Anwendungsfall basierenden Teilsatzes sein.

Wenn Ihre Anwendung auf den Zugriff auf websiteübergreifende Cookies (auch Drittanbieter-Cookies genannt) auf Websites innerhalb desselben Sets ähnlicher Websites angewiesen ist, können Sie die Storage Access API (SAA) und die requestStorageAccessFor API verwenden, um Zugriff auf diese Cookies anzufordern. Je nach Teilmenge, zu der die jeweilige Website gehört, wird die Anfrage vom Browser möglicherweise unterschiedlich verarbeitet.

Weitere Informationen zum Einreichen von Sets und zu den Anforderungen findest du in den Einreichungsrichtlinien. Eingereichte Sets werden verschiedenen technischen Prüfungen unterzogen, um die Einreichungen zu validieren.

Anwendungsfälle für Gruppen ähnlicher Websites

Gruppen ähnlicher Websites eignen sich gut für Fälle, in denen eine Organisation eine gemeinsame Identität für verschiedene Websites der obersten Ebene benötigt.

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

• Anpassung nach Land Sie nutzen lokalisierte Websites und gleichzeitig eine gemeinsame Infrastruktur (beispiel.de kann auf einen von beispiel.de gehosteten Dienst zurückgreifen).
• Integration der Dienstdomain Dienstdomains, 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 Sie inaktive von Nutzern hochgeladene Inhalte bereitstellen, können Sie sie unter Umständen auch sicher auf derselben Domain hosten, indem Sie die Best Practices befolgen.
• Eingebettete authentifizierte Inhalte Unterstützung von eingebetteten Inhalten aus verbundenen Properties (Videos, Dokumente oder Ressourcen, die auf den Nutzer beschränkt sind, der auf der Website der obersten Ebene angemeldet ist)
• Melden Sie sich an. Unterstützung der Anmeldung in verbundenen Properties Die FedCM API kann für einige Anwendungsfälle ebenfalls geeignet sein.
• Analytics Analysen und Messungen der User Journeys in Partner-Properties einführen, um die Qualität der Dienste zu verbessern

Details zur Integration von Gruppen ähnlicher Websites

Storage Access API

Die Storage Access API (SAA) bietet eingebetteten plattformübergreifenden Inhalten Zugriff auf den Speicher, auf den sie normalerweise nur in einem selbst erhobenen Kontext zugreifen könnten.

Eingebettete Ressourcen können SAA-Methoden verwenden, um zu prüfen, ob sie derzeit Zugriff auf den Speicher haben, und um Zugriff vom User-Agent anzufordern.

Wenn Drittanbieter-Cookies blockiert, aber Sets ähnlicher Websites (Related Website Sets, RWS) aktiviert sind, gewährt Chrome die Berechtigung automatisch in Kontexten innerhalb von RWS. Andernfalls wird dem Nutzer eine Aufforderung angezeigt. Ein „intra-RWS-Kontext“ ist ein Kontext wie ein iFrame, dessen eingebettete Website und Website der obersten Ebene sich im selben RWS befinden.

Speicherzugriff prüfen und anfordern

Eingebettete Websites können die Methode Document.hasStorageAccess() verwenden, um zu prüfen, ob sie derzeit Zugriff auf den Speicher haben.

Die Methode gibt ein Versprechen zurück, das in einen booleschen Wert aufgelöst wird, der angibt, ob das Dokument bereits Zugriff auf seine Cookies hat oder nicht. Das Promise gibt auch „true“ zurück, wenn der Iframe dieselbe Quelle wie der oberste Frame hat.

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

Die requestStorageAccess() API soll innerhalb eines iFrames aufgerufen werden. Dieser IFrame muss gerade eine Nutzerinteraktion (eine Nutzergeste, die in allen Browsern erforderlich ist) erhalten haben. In Chrome ist außerdem erforderlich, dass der Nutzer in den letzten 30 Tagen die Website besucht hat, zu der der IFrame gehört, und speziell mit dieser Website interagiert hat – als Dokument auf oberster Ebene, nicht in einem IFrame.

requestStorageAccess() gibt ein Versprechen zurück, das erfüllt wird, wenn der Zugriff auf den Speicher gewährt wurde. Wenn der Zugriff aus irgendeinem Grund verweigert wurde, wird das Versprechen mit dem entsprechenden Grund abgelehnt.

requestStorageAccessFor in Chrome

Die Storage Access API erlaubt eingebetteten Websites nur, den Zugriff auf den Speicher innerhalb von <iframe>-Elementen anzufordern, die eine Nutzerinteraktion erhalten haben.

Das stellt eine Herausforderung bei der Implementierung der Storage Access API für Websites der obersten Ebene dar, die websiteübergreifende Bilder oder Script-Tags verwenden, für die Cookies erforderlich sind.

Um dieses Problem zu beheben, hat Chrome eine Möglichkeit implementiert, mit der Websites der obersten Ebene den Speicherzugriff im Namen bestimmter Ursprünge mit Document.requestStorageAccessFor() (rSAFor) anfordern können.

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

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

Berechtigungen für den Speicherzugriff prüfen

Der Zugriff auf einige Browserfunktionen wie Kamera oder Standort basiert auf vom Nutzer gewährten Berechtigungen. Mit der Permissions API können Sie den Berechtigungsstatus für den Zugriff auf eine API prüfen – ob er gewährt oder abgelehnt wurde oder ob eine Nutzerinteraktion erforderlich ist, z. B. das Klicken auf einen Prompt oder die Interaktion mit der Seite.

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

Wenn Sie die Berechtigung für den Speicherzugriff für den aktuellen Kontext prüfen möchten, müssen Sie den String 'storage-access' übergeben:

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

Wenn Sie die Berechtigung für den Speicherzugriff für einen bestimmten Ursprung prüfen möchten, 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 nur Berechtigungen geprüft, die über document.requestStorageAccessFor vom übergeordneten Dokument 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.

Für jeden neuen Frame muss der Speicherzugriff einzeln angefordert werden. Der Zugriff wird dann automatisch gewährt. Nur für die erste Anfrage ist eine Nutzeraktion erforderlich. Alle nachfolgenden Anfragen, die vom Iframe initiiert werden, z. B. Navigation oder Unterressourcen, müssen nicht auf eine Nutzeraktion warten, da diese für die Browser-Sitzung durch die erste Anfrage gewährt wird.

Wenn du den iframe aktualisierst, neu lädst oder anderweitig neu erstellst, musst du den Zugriff noch einmal anfordern.

Cookie-Anforderungen

Für Cookies müssen sowohl das SameSite=None- als auch das Secure-Attribut angegeben werden, da rSA nur Zugriff für Cookies gewährt, die bereits für die Verwendung in websiteübergreifenden Kontexten gekennzeichnet sind.

Cookies mit SameSite=Lax, SameSite=Strict oder ohne SameSite-Attribut sind nur für die Verwendung durch selbst erhobene Daten bestimmt und werden unabhängig von der responsiven Suchanzeige niemals in einem websiteübergreifenden Kontext weitergegeben.

Sicherheit

Für rSAFor sind für Unterressourcen-Anfragen CORS-Header (Cross-Origin Resource Sharing) oder das crossorigin-Attribut auf den Ressourcen erforderlich, um ein explizites Opt-in zu ermöglichen.

Implementierungsbeispiele

Zugriff auf den Speicher über ein eingebettetes ursprungsübergreifendes iFrame anfordern

Prüfen, ob Sie Speicherzugriff haben

Mit document.hasStorageAccess() können Sie prüfen, ob Sie bereits Speicherzugriff haben.

Wenn das Versprechen wahr ist, können Sie im websiteübergreifenden Kontext auf den Speicher zugreifen. Wenn der Wert „false“ zurückgegeben wird, müssen Sie den Zugriff auf den Speicher 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 den Speicherzugriff anfordern möchten, prüfen Sie zuerst die Berechtigung für den Speicherzugriff navigator.permissions.query({name: 'storage-access'}), um festzustellen, ob dafür eine Nutzergeste erforderlich ist oder sie automatisch gewährt werden kann.

Wenn die Berechtigung granted ist, können Sie document.requestStorageAccess() aufrufen. Dies sollte ohne Nutzerinteraktion funktionieren.

Wenn der Berechtigungsstatus prompt ist, musst du den document.requestStorageAccess()-Aufruf nach einer Nutzeraktion wie einem Klick auf eine Schaltfläche starten.

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
      }
    );
  }
}

Für nachfolgende Anfragen innerhalb des Frames, Navigationen oder untergeordneten Ressourcen gilt automatisch die Berechtigung zum Zugriff auf websiteübergreifende Cookies. hasStorageAccess() gibt „wahr“ zurück und websiteübergreifende Cookies aus demselben Set mit ähnlichen Websites werden bei diesen Anfragen ohne zusätzliche JavaScript-Aufrufe gesendet.

Websites der obersten Ebene, die im Namen von websites mit unterschiedlichen Ursprüngen den Cookie-Zugriff anfordern

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

hasStorageAccess() prüft nur, ob die Website, die es aufruft, Speicherzugriff hat. Eine Website auf oberster 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 Speicherzugriff dem angegebenen Ursprung bereits gewährt wurde.

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

Wenn die Berechtigung prompt ist, müssen Sie den document.requestStorageAccessFor('https://target.site')-Aufruf an die Nutzergeste koppeln, z. B. an einen Klick 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, wenn sie CORS oder das Attribut „crossorigin“ enthalten. Daher sollten Websites warten, bevor sie eine Anfrage auslösen.

Die Anfragen müssen die Option credentials: 'include' verwenden 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
      });
  }

Lokal testen

Vorbereitung

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

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. Starten Sie den Browser neu, nachdem Sie die Flags geändert haben.

Chrome mit einer lokal verknüpften Website starten

Wenn Sie Chrome mit einem lokal deklarierten Set ähnlicher Websites starten möchten, erstellen Sie ein JSON-Objekt mit URLs, die Mitglieder eines Sets 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 Sets mit ähnlichen 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 und dem JSON-Objekt mit den URLs starten, die zu einem Set gehören.

--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) von den zu testenden Websites auf und prüfen Sie den Zugriff auf die websiteübergreifenden Cookies.

Einreichen von Gruppen ähnlicher Websites

Führen Sie die folgenden Schritte aus, um die Beziehung zwischen Domains zu deklarieren und anzugeben, zu welcher Teilmenge sie gehören.

1. RWS identifizieren

Geben Sie die relevanten Domains an, einschließlich der primären und Mitglieder, die zur Gruppe ähnlicher Websites gehören sollen. Geben Sie auch an, zu welchem Untermengentyp jedes Setmitglied gehört.

2. RWS-Einreichung erstellen

Erstellen Sie eine lokale Kopie (Klon oder Fork) des GitHub-Repositories. Nehmen Sie in einem neuen Branch die Änderungen an der Datei related_website_sets.JSON vor, um sie an Ihre Gruppe anzupassen. Mit dem JSON-Generator können Sie dafür sorgen, dass Ihr Set die richtige JSON-Formatierung und -Struktur hat.

3. Prüfen, ob Ihre RWS die technischen Anforderungen erfüllt

Die Anforderungen an die Zusammenstellung von Sets und die Anforderungen an die Validierung von Sets müssen erfüllt sein.

4. RWS lokal testen

Bevor du einen Pull-Request (PR) erstellst, um dein Set einzureichen, teste deinen Beitrag lokal, um sicherzustellen, dass er alle erforderlichen Prüfungen besteht.

5. RWS einreichen

Reichen Sie das Set mit ähnlichen Websites ein, indem Sie einen PR für die Datei related_website_sets.JSON erstellen, in der Chrome die kanonische Liste der Sets mit ähnlichen Websites hostet. (Zum Erstellen von Pull-Anfragen ist ein GitHub-Konto erforderlich und Sie müssen eine Lizenzvereinbarung für Mitwirkende (Contributor's License Agreement, CLA) unterzeichnen, bevor Sie zur Liste beitragen können.)

Nachdem der PR erstellt wurde, werden eine Reihe von Prüfungen durchgeführt, um sicherzustellen, dass die Anforderungen aus Schritt 3 erfüllt sind. Dazu gehört beispielsweise, dass Sie die CLA unterzeichnet und die .well-known-Datei gültig ist.

Wenn der Vorgang erfolgreich war, wird im PR angezeigt, dass die Prüfungen bestanden wurden. Genehmigte PRs werden einmal pro Woche (Dienstags um 12:00 Uhr EST) manuell in Batches in die kanonische Liste der Gruppen ähnlicher Websites zusammengeführt. Wenn eine der Prüfungen fehlschlägt, wird der Einreicher über einen PR-Fehler auf GitHub benachrichtigt. Der Einreicher kann die Fehler beheben und den PR aktualisieren. Beachten Sie dabei Folgendes:

• Wenn die PR fehlschlägt, enthält eine Fehlermeldung weitere Informationen dazu, warum die Einreichung möglicherweise fehlgeschlagen ist. (Beispiel)
• Alle technischen Prüfungen für Seteinreichungen werden auf GitHub durchgeführt. Daher sind alle Einreichungsfehler, die auf technische Prüfungen zurückzuführen sind, auf GitHub zu sehen.

Unternehmensrichtlinien

Chrome bietet zwei Richtlinien, die den Anforderungen von Unternehmensnutzern gerecht werden:

• Für Systeme, die nicht in der Lage sind, mit Sets ähnlicher Websites zu interagieren, können Sie die Funktion „Sets ähnlicher Websites“ mit der RelatedWebsiteSetsEnabled-Richtlinie in allen Enterprise-Instanzen von Chrome deaktivieren.
• Einige Unternehmenssysteme haben nur interne Websites (z. B. ein Intranet) mit registrierbaren Domains, die sich von den Domains im Set mit ähnlichen Websites unterscheiden. Wenn diese Websites als Teil der Gruppe ähnlicher Websites behandelt werden müssen, ohne dass sie öffentlich zugänglich sind (da die Domains vertraulich sind), kann die öffentliche Liste der Gruppen ähnlicher Websites mit der RelatedWebsiteSetsOverrides-Richtlinie ergänzt oder überschrieben werden.

Chrome löst Überschneidungen zwischen den öffentlichen und Enterprise-Sätzen auf eine von zwei Arten auf, je nachdem, ob replacemements oder additions angegeben ist.

Beispiel für die öffentliche Gruppe {primary: A, associated: [B, C]}:

Fehlerbehebung bei Gruppen ähnlicher Websites

„Nutzeraufforderung“ und „Nutzergeste“

„Nutzeraufforderung“ und „Nutzergeste“ sind zwei verschiedene Dinge. Chrome zeigt Nutzern für Websites, die sich im selben Set ähnlicher Websites befinden, keinen Berechtigungsaufforderung an. Chrome erfordert jedoch weiterhin, dass der Nutzer mit der Seite interagiert hat. Bevor Chrome die Berechtigung gewährt, ist eine Nutzergeste erforderlich, die auch als „Nutzerinteraktion“ oder „Nutzeraktivierung“ bezeichnet wird. Das liegt daran, dass die Verwendung der Storage Access API außerhalb des Kontexts eines Sets mit verknüpften Websites (nämlich requestStorageAccess()) aufgrund der Designprinzipien für Webplattformen ebenfalls eine Nutzergeste erfordert.

Auf Cookies oder Speicherplatz anderer Websites zugreifen

Mit ähnlichen Website-Sets wird der Speicherplatz für verschiedene Websites nicht zusammengeführt. Es werden lediglich einfachere (promptfreie) requestStorageAccess()-Aufrufe ermöglicht. Mithilfe von Website-Sets können Sie die Nutzung der Storage Access API für Nutzer vereinfachen. Sie legen damit jedoch nicht fest, was nach der Wiederherstellung des Zugriffs geschehen soll. Wenn A und B unterschiedliche Websites im selben Set ähnlicher Websites sind und A B einbettet, kann B requestStorageAccess() aufrufen und ohne Aufforderung des Nutzers auf den Speicher von selbst erhobenen Daten zugreifen. Bei Gruppen ähnlicher Websites findet keine websiteübergreifende Kommunikation statt. Wenn Sie beispielsweise ein Set mit ähnlichen Websites einrichten, werden die Cookies, die zu B gehören, nicht an A gesendet. Wenn Sie diese Daten freigeben möchten, müssen Sie dies selbst tun, z. B. indem Sie ein window.postMessage von einem B-Frame an einen A-Frame senden.

Standardmäßig nicht partitionierter Cookie-Zugriff

Für ähnliche Website-Sets ist kein impliziter Zugriff auf nicht partitionierte Cookies ohne Aufruf einer API zulässig. Websiteübergreifende Cookies werden standardmäßig nicht im Set verfügbar gemacht. Mit ähnlichen Website-Sets können Websites innerhalb des Sets nur die Aufforderung zur Berechtigung für die Storage Access API überspringen. Ein iFrame muss document.requestStorageAccess() aufrufen, wenn es auf seine Cookies zugreifen möchte. Alternativ kann die Seite der obersten Ebene document.requestStorageAccessFor() aufrufen.

Feedback geben

Wenn du einen Datensatz auf GitHub einreichst und mit der Storage Access API und der requestStorageAccessFor API arbeitest, kannst du deine Erfahrungen mit dem Prozess und etwaige Probleme teilen.

So nehmen Sie an Diskussionen zu Gruppen ähnlicher Websites teil:

• Treten Sie der öffentlichen Mailingliste für Gruppen ähnlicher Websites bei.
• Sie können Probleme melden und die Diskussion im GitHub-Repository für ähnliche Website-Sets verfolgen.