Ähnliche Website-Gruppen (RWS) sind ein Webplattformmechanismus, der Browsern hilft, die Beziehungen zwischen einer Sammlung 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
Unterstützte Browser
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
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
Unterstützte Browser
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
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 innerhalb 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 erfordern 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
<ph type="x-smartling-placeholder">![Diagramm mit einer eingebetteten Website auf einer Top-Level-Website](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/SV7SXAQRcVnBZEgjgxYc.png?authuser=19&hl=de)
requestStorageAccess()
in einer Einbettung auf einer anderen Website verwendenPrüfen, ob Sie Speicherzugriff haben
Mit document.hasStorageAccess()
kannst du prüfen, ob du bereits Zugriff auf den Speicher hast.
Wenn das Versprechen auf „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'})
. So kannst du feststellen, 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
<ph type="x-smartling-placeholder">![Diagramm, das zeigt, wie „requestStorageAccessFor()“ auf einer Website auf oberster Ebene und nicht in einer Einbettung verwendet wird](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/jRgDgWl7yb1cEcwpcdMo.png?authuser=19&hl=de)
requestStorageAccessFor()
auf einer Website der obersten Ebene für einen anderen Ursprung verwendenWebsites auf oberster Ebene können mit 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.
Einreichung von Gruppen ähnlicher Websites
So deklarieren Sie die Beziehung zwischen Domains und geben an, zu welcher Teilmenge sie gehören:
- Identifizieren Sie die relevanten Domains. Dazu gehören die primären Domains und Gruppenmitglieder, die zur Gruppe ähnlicher Websites gehören. Ermitteln Sie außerdem, zu welchem Untermengentyp die einzelnen Gruppenmitglieder gehören.
- Prüfen Sie, ob die Formatierungsanforderungen und die Validierungsanforderungen festgelegt sind.
- Geben Sie die Gruppe ähnlicher Websites im richtigen JSON-Format an.
- Senden Sie die Gruppe ähnlicher Websites durch Erstellen einer Pull-Anfrage an die
related_website_sets.JSON
, wo Chrome die kanonische Gruppe ähnlicher Websites hostet. Zum Erstellen von PRs ist ein GitHub-Konto erforderlich und Sie müssen eine Lizenzvereinbarung des Beitragenden unterzeichnen, um einen Beitrag zur Liste zu leisten.
Sobald die PR erstellt wurde, wird eine Reihe von Prüfungen durchgeführt, um zu bestätigen, dass die Anforderungen aus Schritt 2 erfüllt sind.
Ist der Vorgang erfolgreich, zeigt der PR an, dass die Überprüfungen bestanden wurden. Genehmigte PRs werden einmal pro Woche (dienstags um 12:00 Uhr Eastern Time) manuell in Batches zur Liste der kanonischen Gruppen ähnlicher Websites zusammengeführt.
Wenn eine der Prüfungen fehlschlägt, wird der Absender über einen PR-Fehler auf GitHub benachrichtigt. Der Absender kann die Fehler beheben und die PR aktualisieren. Dabei ist Folgendes zu beachten:
- Wenn die PR nicht erfolgreich ist, erhalten Sie in einer Fehlermeldung weitere Informationen dazu, warum die Übermittlung fehlgeschlagen ist (Beispiel).
- Alle technischen Prüfungen für das Einreichen von Sets werden auf GitHub durchgeführt. Daher sind alle Übermittlungsfehler, die aus technischen Prüfungen resultieren, auf GitHub einsehbar.
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 bei 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.