Verwandte Website-Sets: Entwicklerleitfaden

bookmark_border Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Gruppen ähnlicher Websites sind ein Webplattformmechanismus, mit dem Browser die Beziehungen zwischen einer Sammlung von Domains besser nachvollziehen können. So können Browser wichtige Entscheidungen treffen, um bestimmte Websitefunktionen zu aktivieren (z. B. ob der Zugriff auf websiteübergreifende Cookies zulässig ist) und diese Informationen den Nutzern zu präsentieren.

Viele Websites nutzen mehrere Domains, um eine einheitliche Nutzererfahrung zu bieten. Organisationen können verschiedene Top-Level-Domains für verschiedene Anwendungsfälle verwalten, z. B. länderspezifische Domains oder Dienstdomains zum Hosten von Bildern oder Videos. Mithilfe von Gruppen ähnlicher Websites können Websites Daten über Domains hinweg mit bestimmten Steuerelementen austauschen.

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 des verknüpften Teilsatzes erfüllen.

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

Zugehörige Website-Sets sind in einer öffentlichen JSON-Datei aufgeführt, die auf GitHub gehostet wird. Dies ist die kanonische Quelle für alle genehmigten Sets. Anhand dieser Datei wird in Browsern ermittelt, ob Websites zur selben Gruppe ähnlicher Websites gehören.

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 derselben Gruppe ä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 behandelt.

Weitere Informationen zum Einreichen von Sets findest du in den Richtlinien für die Einreichung. 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 Ländern 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 nutzen, mit denen Nutzer nie direkt interagieren, die aber Dienste auf den Websites derselben Organisation bereitstellen (beispiel-cdn.com)
• Trennung von Nutzerinhalten Zugriff auf Daten in verschiedenen Domains, die aus Sicherheitsgründen von Nutzern hochgeladene Inhalte 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 diese unter Umständen auch sicher in derselben Domain hosten, indem Sie die Best Practices befolgen.
  • Eingebettete authentifizierte Inhalte Unterstützung von eingebetteten Inhalten aus verschiedenen verknüpften Properties (Videos, Dokumente oder Ressourcen, die auf Nutzer beschränkt sind, die auf der Website der obersten Ebene angemeldet sind)
• 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 Customer Journey auf verbundenen 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 Gruppen ä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 denselben Ursprung wie der übergeordnete Frame hat.

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

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 über <iframe>-Elemente 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, ob in einem Dokument der obersten Ebene innerhalb der letzten 30 Tage eine Interaktion stattgefunden hat, da sich der Nutzer bereits auf der Seite befindet.

Berechtigungen für den Speicherzugriff prüfen

Der Zugriff auf einige Browserfunktionen wie Kamera oder Standortbestimmung 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 eine Aufforderung oder die Interaktion mit der Seite.

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

Wenn Sie die Berechtigung zum 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 zum 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 vom übergeordneten Dokument mit document.requestStorageAccessFor gewährt wurden.

Je nachdem, ob die Berechtigung automatisch gewährt werden kann oder eine Nutzergeste erfordert, 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. 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 die Attribute SameSite=None als auch Secure 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 vom RSA niemals in einem websiteübergreifenden Kontext weitergegeben.

Sicherheit

Für rSAFor sind für Unterressourcenanfragen CORS-Header (Cross-Origin Resource Sharing) oder das Attribut crossorigin für die 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 zum Speicherzugriff 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, können Sie document.requestStorageAccess() aufrufen. Dies sollte ohne Nutzerinteraktion funktionieren.

Wenn der Berechtigungsstatus prompt ist, müssen Sie 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
      }
    );
  }
}

Nachfolgende Anfragen innerhalb des Frames, Navigationen oder untergeordneten Ressourcen haben automatisch die Berechtigung zum Zugriff auf websiteübergreifende Cookies. hasStorageAccess() gibt „wahr“ zurück und websiteübergreifende Cookies aus demselben Set ähnlicher 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 Nutzerinteraktion 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.

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

Lokal testen

Vorbereitung

Wenn Sie Sets mit ähnlichen Websites lokal testen möchten, verwenden Sie Chrome 119 oder höher, das über die Befehlszeile gestartet wird, und aktivieren Sie die 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 lokalen Gruppe ähnlicher Websites 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 ähnliche Website-Sets 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 getesteten 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 Website und der Mitgliedswebsites, 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-Repositorys. Nehmen Sie in einem neuen Branch die Änderungen an der Datei related_website_sets.JSON vor, um sie an Ihren Satz anzupassen. Mit dem JSON-Generator können Sie dafür sorgen, dass Ihr Satz die richtige JSON-Formatierung und -Struktur hat.

3. Prüfen, ob die 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 deine Einreichung lokal, um sicherzustellen, dass sie alle erforderlichen Prüfungen besteht.

5. RWS einreichen

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

Nach dem Erstellen des PR 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 Eastern Time) 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 Sets werden auf GitHub durchgeführt. Daher sind alle Fehlermeldungen aufgrund technischer Prüfungen auf GitHub zu sehen.

Unternehmensrichtlinien

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

• Für Systeme, die nicht in Gruppen ähnlicher Websites eingebunden werden können, können Sie die Funktion für Gruppen ähnlicher Websites mit der RelatedWebsiteSetsEnabled-Richtlinie in allen Chrome-Enterprise-Instanzen deaktivieren.
  • Einige Unternehmenssysteme haben nur interne Websites (z. B. ein Intranet) mit registrierbaren Domains, die sich von den Domains in der Gruppe ähnlicher Websites unterscheiden. Wenn diese Websites als Teil der Gruppe ähnlicher Websites behandelt werden sollen, 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 zwei Arten auf, je nachdem, ob replacements oder additions angegeben ist.

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

Probleme mit Gruppen ähnlicher Websites beheben

„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 einer Gruppe ähnlicher Websites (nämlich requestStorageAccess()) aufgrund der Designprinzipien für Webplattformen ebenfalls eine Nutzergeste erfordert.

Auf Cookies oder Speicherplatz anderer Websites zugreifen

Mit Gruppen ähnlicher Websites wird der Speicherplatz für verschiedene Websites nicht zusammengeführt. Sie können damit nur einfacher (ohne Aufforderung) requestStorageAccess()-Aufrufe ausführen. Mit Gruppen ähnlicher Websites wird die Nutzung der Storage Access API für Nutzer vereinfacht. Es wird jedoch nicht festgelegt, was nach der Wiederherstellung des Zugriffs zu tun ist. Wenn A und B unterschiedliche Websites in derselben Gruppe ähnlicher Websites sind und A B einbettet, kann B requestStorageAccess() aufrufen und Zugriff auf den selbst erhobenen Speicher erhalten, ohne den Nutzer um Erlaubnis zu bitten. Bei Gruppen ähnlicher Websites findet keine websiteübergreifende Kommunikation statt. Wenn Sie beispielsweise eine Gruppe ähnlicher 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 einen window.postMessage von einem B-Iframe an einen A-Frame senden.

Standardmäßig nicht partitionierter Cookie-Zugriff

Bei Gruppen ähnlicher Websites ist kein impliziter Zugriff auf nicht partitionierte Cookies ohne Aufruf einer API möglich. Websiteübergreifende Cookies werden innerhalb der Gruppe standardmäßig nicht verfügbar gemacht. Mit Gruppen ähnlicher Websites können Websites innerhalb der Gruppe nur den Aufforderung zur Einwilligung 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 Satz 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:

• Öffentliche Mailingliste für Gruppen ähnlicher Websites
  • Sie können Probleme melden und die Diskussion im GitHub-Repository für zugehörige Website-Sets verfolgen.