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 zur Aktivierung bestimmter Websitefunktionen treffen (z. B. ob der Zugriff auf websiteübergreifende Cookies zugelassen wird) und diese Informationen den Nutzern anzeigen.

Durch die Einstellung von Drittanbieter-Cookies in Chrome sollen wichtige Anwendungsfälle im Web beibehalten und gleichzeitig der Datenschutz für Nutzer verbessert werden. Beispielsweise sind viele Websites auf mehrere Domains angewiesen, um eine einzelne Nutzererfahrung zu bieten. Unternehmen möchten verschiedene Top-Level-Domains für verschiedene Anwendungsfälle verwenden, z. B. für länderspezifische Domains oder Dienstdomains zum Hosten von Bildern oder Videos. Mit Gruppen ähnlicher Websites können Websites Daten domainübergreifend mit bestimmten Einstellungen teilen.

Was ist eine Gruppe ähnlicher Websites?

Grundsätzlich ist eine Gruppe ähnlicher Websites eine Sammlung von Domains, für die es eine einzelne festgelegte „primäre“ Gruppe gibt. und möglicherweise auch mehrere „Set-Mitglieder“.

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

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

Die Liste der kanonischen Gruppen ähnlicher Websites ist eine öffentlich sichtbare Liste im JSON-Dateiformat, die im GitHub-Repository für Gruppen ähnlicher Websites gehostet wird. Es dient als zentrale Quelle für alle Sets. Chrome verwendet diese Datei, um auf ihr Verhalten anzuwenden.

Nur Nutzer mit administrativer Kontrolle über eine Domain können einen Satz mit dieser Domain erstellen. Einsender müssen die Beziehung zwischen den einzelnen „Set-Mitgliedern“ angeben. auf „Primär festlegen“. Satzmitglieder können verschiedene Domaintypen umfassen und müssen je nach Anwendungsfall Teil einer Untergruppe sein.

Wenn für Ihre Anwendung der Zugriff auf websiteübergreifende Cookies (auch als Drittanbieter-Cookies bezeichnet) in derselben Gruppe ähnlicher Websites erforderlich 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, kann der Browser die Anfrage unterschiedlich verarbeiten.

Weitere Informationen zum Ablauf und zu den Anforderungen beim Einreichen von Sets finden Sie in den Richtlinien zur Einreichung. Die eingereichten Sätze werden verschiedenen technischen Prüfungen unterzogen, um sie zu validieren.

Anwendungsfälle für Gruppen ähnlicher Websites

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

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

• Länderanpassung: Lokalisierte Websites in Verbindung mit einer gemeinsamen Infrastruktur nutzen (example.co.uk kann auf einen von example.ca gehosteten Dienst zurückgreifen).
• Integration von Dienstdomains Die Nutzung von Dienstdomains, mit denen Nutzer nie direkt interagieren, jedoch Dienste auf den Websites derselben Organisation anbieten (beispiel-cdn.com).
• Trennung von Nutzerinhalten: Zugriff auf Daten in verschiedenen Domains, durch die die von Nutzern hochgeladenen Inhalte aus Sicherheitsgründen von anderen Websitecontent getrennt sind, 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 diese möglicherweise auch sicher auf derselben Domain hosten. Beachten Sie dazu die Best Practices.
• Eingebettete authentifizierte Inhalte: Unterstützung eingebetteter Inhalte aus verknüpften Properties (Videos, Dokumente oder Ressourcen, die auf den auf der Top-Level-Website angemeldeten Nutzer beschränkt sind)
• Anmelden: Anmeldung über verknüpfte Properties hinweg Die FedCM API kann für einige Anwendungsfälle geeignet sein.
• Analytics: Analyse und Messung von Nutzerpfaden über verknüpfte Properties hinweg, um die Qualität der Dienstleistungen zu verbessern

Integrationsdetails für Gruppen ähnlicher Websites

Storage Access API

Mit der Storage Access API (SAA) können eingebettete ursprungsübergreifende Inhalte auf den Speicher zugreifen, auf den sie normalerweise nur in einem selbst erhobenen Kontext zugreifen würden.

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

Wenn Drittanbieter-Cookies blockiert sind, Gruppen ähnlicher Websites (RWS) aber aktiviert sind, gewährt Chrome in solchen Kontexten automatisch die Berechtigung. Andernfalls wird dem Nutzer eine entsprechende Aufforderung angezeigt. Ein „Intra-RWS-Kontext“ ist ein Kontext, wie z. B. ein iFrame, dessen eingebettete Website und Website auf oberster Ebene sich in derselben RWS befinden.

Speicherzugriff prüfen und anfordern

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

Die Methode gibt ein Versprechen zurück, das mit einem 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 denselben Ursprung hat wie der oberste Frame.

Wenn Sie den Zugriff auf Cookies in einem websiteübergreifenden Kontext anfordern möchten, können eingebettete Websites Document.requestStorageAccess() (rSA) verwenden.

Die requestStorageAccess() API ist für den Aufruf von innerhalb eines iFrames vorgesehen. Dieser iFrame muss gerade eine Nutzerinteraktion empfangen haben (eine Nutzergeste, die bei allen Browsern erforderlich ist). Für Chrome ist außerdem erforderlich, dass der Nutzer irgendwann in den letzten 30 Tagen die Website besucht hat, zu der dieser iFrame gehört, und speziell mit dieser Website interagiert hat – als Dokument der obersten Ebene und nicht in einem iFrame.

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

requestStorageAccessFor in Chrome

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

Dies stellt Herausforderungen bei der Implementierung der Storage Access API für Websites auf oberster Ebene dar, die websiteübergreifende Images oder Skript-Tags verwenden, die Cookies erfordern.

Deshalb hat Chrome eine Möglichkeit für Top-Level-Websites implementiert, im Namen bestimmter Ursprünge den Speicherzugriff bei Document.requestStorageAccessFor() (rSAFor) anzufordern.

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

Die requestStorageAccessFor() API soll von einem Dokument auf oberster Ebene aufgerufen werden. Dieses Dokument muss ebenfalls gerade eine User-Interaktion erhalten haben. Im Gegensatz zu requestStorageAccess() sucht Chrome jedoch nicht nach einer Interaktion in einem Dokument auf oberster Ebene der letzten 30 Tage, da der Nutzer sich bereits auf der Seite befindet.

Speicherzugriffsberechtigungen prüfen

Der Zugriff auf einige Browserfunktionen wie Kamera oder Standortbestimmung basiert auf den von den Nutzern erteilten Berechtigungen. Mit der Permissions API lässt sich der Berechtigungsstatus für den Zugriff auf eine API prüfen. Dabei spielt es keine Rolle, ob der Zugriff gewährt oder verweigert wurde oder ob eine Nutzerinteraktion erforderlich ist, z. B. das Klicken auf eine Aufforderung oder die Interaktion mit der Seite.

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

Um die Speicherzugriffsberechtigung für den aktuellen Kontext zu prüfen, müssen Sie den String 'storage-access' übergeben:

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

Um die Speicherzugriffsberechtigung für einen bestimmten Ursprung zu prüfen, 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 dabei nur Berechtigungen geprüft, die vom Dokument der obersten Ebene 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.

Pro Frame-Modell

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

Für jeden neuen Frame muss der Speicherzugriff einzeln angefordert werden und er erhält automatisch Zugriff. Nur die erste Anfrage erfordert eine Nutzergeste. Nachfolgende Anfragen, die vom iFrame initiiert werden, z. B. eine Navigation oder Unterressourcen, müssen nicht auf eine Nutzergeste warten, da diese durch die erste Anfrage für die Browsersitzung gewährt wird.

Für das Aktualisieren, erneute Laden oder anderweitige Neuerstellung des iFrames muss noch einmal der Zugriff angefordert werden.

Anforderungen an Cookies

Cookies müssen sowohl das Attribut SameSite=None als auch das Attribut Secure angeben, da „rSA“ nur Zugriff auf 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 eigene Verwendung bestimmt und werden nie in einem websiteübergreifenden Kontext unabhängig von der rSA weitergegeben.

Sicherheit

Für rSAFor-Anfragen für Unterressourcen benötigen Sie CORS-Header (Cross-Origin Resource Sharing) oder das Attribut crossorigin für die Ressourcen. Damit ist eine ausdrückliche Aktivierung erforderlich.

Implementierungsbeispiele

Zugriff auf Speicher von einem eingebetteten ursprungsübergreifenden iFrame anfordern

Prüfen, ob Sie Speicherzugriff haben

Mit document.hasStorageAccess() kannst du prüfen, ob du bereits Zugriff auf den Speicher hast.

Wenn das Versprechen als „true“ aufgelöst wird, kannst du im websiteübergreifenden Kontext auf den Speicher zugreifen. Wenn das Problem mit „false“ behoben wird, 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 du den Speicherzugriff anfordern möchtest, prüfe zuerst die Berechtigung für den Speicherzugriff navigator.permissions.query({name: 'storage-access'}), um festzustellen, ob dafür eine Nutzergeste erforderlich ist oder ob die Berechtigung automatisch gewährt werden kann.

Wenn die Berechtigung granted lautet, können Sie document.requestStorageAccess() aufrufen. Der Vorgang sollte ohne Nutzergeste erfolgreich sein.

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

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 innerhalb des Frames, der Navigation oder der untergeordneten Ressourcen erhalten 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.

Websites der obersten Ebene, die im Namen von ursprungsübergreifenden Websites Cookie-Zugriff anfordern

Websites auf oberster Ebene können mithilfe von requestStorageAccessFor() Speicherzugriff für bestimmte Ursprünge anfordern.

hasStorageAccess() prüft nur, ob die Website, die sie 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 dazu aufgefordert wird oder ob dem angegebenen Ursprung bereits Speicherzugriff gewährt wurde.

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

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

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 Crossorigin-Attribut enthalten. Websites sollten also möglicherweise warten, bevor sie eine Anfrage auslösen.

Für die 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 durchführen

Vorbereitung

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

Chrome-Flag aktivieren

Um das erforderliche Chrome-Flag zu aktivieren, navigieren Sie von der Adressleiste zu chrome://flags#test-third-party-cookie-phaseout und ändern Sie die Markierung in Enabled. Starten Sie den Browser neu, nachdem die Flags geändert wurden.

Chrome mit einer lokalen Gruppe ähnlicher Websites starten

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

Weitere Informationen zur Ausführung 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 enthält, die zu einem Satz 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üfe, ob du Zugriff auf websiteübergreifende Cookies hast

Rufen Sie die APIs (rSA oder rSAFor) von den Websites auf, die getestet werden, und validieren Sie den Zugriff auf die websiteübergreifenden Cookies.

Einreichen von Gruppen ähnlicher Websites

Gehen Sie wie folgt vor, um die Beziehung zwischen Domains und zu welcher Teilmenge sie gehören.

1. RWS ermitteln

Identifizieren Sie die relevanten Domains, einschließlich der Domains Primär angeben und Mitglieder festlegen. die zur Gruppe ähnlicher Websites gehören. Geben Sie auch an, subset type, zu dem jedes Satzmitglied gehört.

2. RWS-Einreichung erstellen

Erstellen Sie eine lokale Kopie (Klon oder Verzweigung) des GitHub-Repository. Nehmen Sie in einem neuen Zweig die Änderungen an der related_website_sets.JSON für Ihren Datensatz. Um sicherzustellen, dass Ihr Set die richtige JSON-Formatierung und können Sie das JSON-Generator-Tool verwenden.

3. Achten Sie darauf, dass Ihre RWS die technischen Anforderungen erfüllt

Stellen Sie sicher, dass die Formatierungsanforderungen festlegen und Validierungsanforderungen festlegen vorhanden sind.

4. RWS lokal testen

Vor dem Erstellen einer Pull-Anfrage (PR) Um Ihr Set einzureichen, testen Sie es lokal, um sicherzustellen, dass es alle erforderlichen Prüfungen besteht.

5. RWS einreichen

Reichen Sie die Gruppe ähnlicher Websites ein, indem Sie eine PR an den related_website_sets.JSON -Datei, in der Chrome die kanonische Liste ähnlicher Websites hostet. (Ein GitHub -Konto erforderlich, um PRs zu erstellen, und Sie müssen ein Lizenzvereinbarung des Mitwirkenden, bevor du einen Beitrag zur Liste leisten kannst.

Nach der Erstellung des PR werden eine Reihe von Prüfungen durchgeführt, müssen die Anforderungen aus Schritt 3 erfüllt sein, z. B. haben die CLA signiert und die Datei .well-known ist gültig.

Ist der Vorgang erfolgreich, zeigt der PR an, dass die Überprüfungen bestanden wurden. Genehmigte PRs werden manuell in Batches zur Liste der kanonischen Gruppen ähnlicher Websites zusammengeführt einmal pro Woche (dienstags um 12:00 Uhr Eastern Time). Wenn eine der Prüfungen fehlschlägt, erhält der Absender eine Benachrichtigung über den PR-Fehler. auf GitHub. Der Absender kann die Fehler beheben und die PR aktualisieren. dass:

• Wenn die PR nicht erfolgreich ist, werden in einer Fehlermeldung zusätzliche Informationen angezeigt. warum die Einreichung fehlgeschlagen sein könnte. (Beispiel)
• Alle technischen Prüfungen für das Einreichen von Sets werden auf GitHub durchgeführt. und folglich auch alle Übermittlungsfehler, die aus technischen Prüfungen resultieren sind auf GitHub sichtbar.

Unternehmensrichtlinien

Chrome verfügt über zwei Richtlinien, um die Anforderungen von Unternehmensnutzern zu erfüllen:

• Systeme, die sich möglicherweise nicht mit Gruppen ähnlicher Websites verknüpfen lassen, haben die Möglichkeit, die Funktion für Gruppen ähnlicher Websites in allen Unternehmensinstanzen über die Richtlinie RelatedWebsiteSetsEnabled zu deaktivieren.
• Einige Unternehmenssysteme haben nur interne Websites (z. B. ein Intranet) mit registrierbaren Domains, die sich von den Domains in ihrer Gruppe ähnlicher Websites unterscheiden. Wenn sie diese Websites als Teil ihrer Gruppe ähnlicher Websites behandeln müssen, ohne sie öffentlich zugänglich zu machen (da die Domains vertraulich sind), können sie ihre öffentliche Liste mit Gruppen ähnlicher Websites mit der RelatedWebsiteSetsOverrides-Richtlinie erweitern oder überschreiben.

Chrome löst jede Schnittmenge von öffentlichen und Enterprise-Sets in einer von zwei auf je nachdem, ob replacemements oder additions angegeben ist.

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

replacements Satzes:	{primary: C, associated: [D, E]}
Das Enterprise-Dataset nimmt die gemeinsame Website auf, um einen neuen Satz zu bilden.
Resultierende Sätze:	{primary: A, associated: [B]} {primary: C, associated: [D, E]}
additions Satzes:	{primary: C, associated: [D, E]}
Öffentliche und Enterprise-Sets werden kombiniert.
Ergebnissatz:	{primary: C, associated: [A, B, D, E]}

Fehlerbehebung für Gruppen ähnlicher Websites

„Benutzeraufforderung“ und „Nutzergeste“

Eine „Benutzeraufforderung“ und „Nutzergeste“ sind unterschiedliche Dinge. Chrome zeigt keine Berechtigungsaufforderung die sich zur selben Gruppe ähnlicher Websites befinden, aber Chrome weiterhin erfordert, dass der Nutzer mit der Seite interagiert hat. Bevor Sie die Berechtigung erteilen, Für Chrome ist ein Nutzergeste auch als „User-Interaction“ bezeichnet, oder „Nutzeraktivierung“. Das liegt daran, dass die Verwendung von die Storage Access API außerhalb des Kontexts einer Gruppe ähnlicher Websites (nämlich requestStorageAccess()) erfordert außerdem eine Nutzergeste. Designprinzipien für Webplattformen.

Auf andere Websites zugreifen Cookies oder Speicher

Bei Gruppen ähnlicher Websites wird der Speicherplatz für verschiedene Websites nicht zusammengeführt, sondern nur ermöglicht, einfachere (ohne Aufforderungen) requestStorageAccess()-Anrufe. Ähnliche Website Mit Sets verringert sich nur der Aufwand für die Nutzung der Storage Access API, aber nicht was zu tun ist, nachdem der Zugriff wiederhergestellt wurde. Wenn A und B unterschiedliche Websites sind ähnlicher Websites in derselben Gruppe und die Einbettungen B und B können requestStorageAccess() und erhalten ohne Nachfrage Zugriff auf eigenen Speicher Nutzenden. Bei Gruppen ähnlicher Websites erfolgt keine websiteübergreifende Kommunikation. Für Beispiel: Bei der Einrichtung einer Gruppe ähnlicher Websites an B gesendet werden, um an A weitergeleitet zu werden. Wenn Sie teilen möchten, müssen Sie sie selbst teilen, z. B. indem Sie wird ein window.postMessage von einem B-iFrame an einen Ein Frame.

Standardmäßig nicht partitionierter Cookie-Zugriff

Für Gruppen ähnlicher Websites ist kein impliziter, nicht partitionierter Cookie-Zugriff zulässig ohne eine API aufzurufen. Keine websiteübergreifenden Cookies verfügbar default innerhalb des Satzes; Bei Gruppen ähnlicher Websites sind nur Websites innerhalb des festgelegten überspringen Sie die Storage Access API-Berechtigungsaufforderung. Ein iFrame muss document.requestStorageAccess() aufrufen, wenn er auf seine oder die Seite auf oberster Ebene document.requestStorageAccessFor() aufrufen kann.

Feedback geben

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

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

• Treten Sie der öffentlichen Mailingliste für Gruppen ähnlicher Websites bei.
• Melden Sie Probleme und folgen Sie der Diskussion im GitHub-Repository für Gruppen ähnlicher Websites.