Chrome stellt die Unterstützung für Drittanbieter-Cookies und die Partitionierung des Speichers ein, um das websiteübergreifende Tracking zu reduzieren. Dies stellt eine Herausforderung für Websites und Dienste dar, die auf Cookies und andere Speicherung in eingebetteten Kontexten angewiesen sind, z. B. bei der Authentifizierung. Mit der Storage Access API (SAA) können diese Anwendungsfälle weiter genutzt werden, wobei das websiteübergreifende Tracking so weit wie möglich eingeschränkt wird.
Implementierungsstatus
Die Storage Access API ist in allen gängigen Browsern verfügbar. Es gibt jedoch geringfügige Unterschiede bei der Implementierung zwischen den Browsern. Diese Unterschiede werden in den relevanten Abschnitten in diesem Beitrag hervorgehoben.
Wir arbeiten daran, alle verbleibenden Blockierungsprobleme zu beheben, bevor Sie die API standardisieren.
Was ist die Storage Access API?
Die Storage Access API ist eine JavaScript API, die es iFrames ermöglicht, Speicherzugriffsberechtigungen anzufordern, wenn der Zugriff andernfalls durch die Browsereinstellungen verweigert würde. Bei Einbettungen mit Anwendungsfällen, bei denen websiteübergreifende Ressourcen geladen werden müssen, kann die API verwendet werden, um bei Bedarf Zugriffsberechtigungen vom Nutzer anzufordern.
Wenn die Speicheranforderung gewährt wird, hat der iFrame Zugriff auf seine nicht partitionierten Cookies und Speicher, die auch verfügbar sind, wenn Nutzer ihn als Website der obersten Ebene aufrufen.
Die Storage Access API ermöglicht es, bestimmten nicht partitionierten Cookie- und Speicherzugriff mit minimaler Belastung für den Endnutzer bereitzustellen. Gleichzeitig wird der allgemeine nicht partitionierte Cookie- und Speicherzugriff verhindert, wie er häufig für das Nutzer-Tracking verwendet wird.
Anwendungsfälle
Einige Drittanbieter-Einbettungen benötigen Zugriff auf nicht partitionierte Cookies oder Speicher, um die Nutzerfreundlichkeit zu verbessern – etwas, das nach der Einstellung von Drittanbieter-Cookies nicht mehr verfügbar ist und die Speicherpartitionierung aktiviert ist.
Dies ist unter anderem in folgenden Fällen hilfreich:
- Eingebettete Kommentar-Widgets, für die Details zur Anmeldesitzung erforderlich sind.
- „Gefällt mir“-Schaltflächen für soziale Medien, für die Details zur Anmeldung erforderlich sind.
- Eingebettete Dokumente, für die Details zur Anmeldesitzung erforderlich sind.
- Eine Premium-Funktion für eingebettete Videos, z. B. um keine Anzeigen für angemeldete Nutzer einzublenden, die Einstellungen des Nutzers für Untertitel zu kennen oder um bestimmte Videotypen einzuschränken.
- Eingebettete Zahlungssysteme
Viele dieser Anwendungsfälle beinhalten den dauerhaften Anmeldezugriff in eingebetteten iFrames.
Wann sollte die Storage Access API gegenüber anderen APIs verwendet werden?
Die Storage Access API ist eine der Alternativen zur Verwendung von nicht partitionierten Cookies und Speicher. Daher sollten Sie wissen, wann Sie diese API im Vergleich zu den anderen verwenden sollten. Sie ist für Anwendungsfälle gedacht, in denen die beiden folgenden Bedingungen zutreffen:
- Der Nutzer interagiert mit dem eingebetteten Inhalt, d. h. es handelt sich nicht um einen passiven oder versteckten iFrame.
- Der Nutzer hat den eingebetteten Ursprung in einem Kontext auf oberster Ebene besucht, d. h., wenn dieser Ursprung nicht in eine andere Website eingebettet ist.
Es gibt alternative APIs für eine Vielzahl von Anwendungsfällen:
- Cookies Having Independent Partitioned State (CHIPS) ermöglicht es Entwicklern, ein Cookie für „partitionierten“ Speicher mit einer separaten Cookie-JAR-Datei pro Top-Level-Website zu aktivieren. Ein Web-Chat-Widget eines Drittanbieters kann beispielsweise ein Cookie setzen, um Sitzungsinformationen zu speichern. Die Sitzungsinformationen werden pro Website gespeichert, sodass auf anderen Websites, auf denen es ebenfalls eingebettet ist, kein Zugriff auf das vom Widget gesetzte Cookie erforderlich ist. Die Storage Access API ist nützlich, wenn ein eingebettetes Drittanbieter-Widget davon abhängig ist, dass dieselben Informationen für verschiedene Quellen freigegeben werden, z. B. für Details oder Einstellungen von angemeldeten Sitzungen.
- Die Speicherpartitionierung ist eine Möglichkeit für websiteübergreifende iFrames, vorhandene JavaScript-Speichermechanismen zu nutzen und gleichzeitig den zugrunde liegenden Speicher pro Website aufzuteilen. Dadurch wird verhindert, dass auf den eingebetteten Speicher einer Website von derselben Einbettung auf anderen Websites zugegriffen wird.
- Mit Related Websites Sets (RWS) können Organisationen Beziehungen zwischen Websites deklarieren, damit Browser einen eingeschränkten, nicht partitionierten Cookie- und Speicherzugriff für bestimmte Zwecke ermöglichen. Websites müssen weiterhin den Zugriff über die Storage Access API anfordern, aber für Websites innerhalb des Satzes kann der Zugriff ohne Aufforderung des Nutzers gewährt werden.
- Federated Credential Management (FedCM) ist ein datenschutzfreundlicher Ansatz für föderierte Identitätsdienste. Die Storage Access API befasst sich mit dem Zugriff auf nicht partitionierte Cookies und Speicher nach der Anmeldung. Für einige Anwendungsfälle bietet FedCM eine alternative Lösung zur Storage Access API. Die Lösung ist möglicherweise besser geeignet, da sie eine stärker anmeldeorientierte Browseraufforderung enthält. Die Einführung von FedCM erfordert jedoch in der Regel zusätzliche Änderungen an Ihrem Code, z. B. zur Unterstützung seiner HTTP-Endpunkte.
- Es gibt auch APIs für Betrug, anzeigenbezogene und Messung. Die Storage Access API ist dafür nicht vorgesehen.
Storage Access API verwenden
Die Storage Access API bietet zwei versprochene Methoden:
Document.hasStorageAccess()(ab Chrome 125 auch unter dem neuen NamenDocument.hasUnpartitionedCookieAccess()verfügbar)Document.requestStorageAccess()
Außerdem lässt es sich in die Permissions API einbinden. So können Sie den Status der Speicherzugriffsberechtigung im Zusammenhang mit Drittanbietern prüfen und angeben, ob ein Aufruf von document.requestStorageAccess() automatisch gewährt wird:
hasStorageAccess()-Methode verwenden
Beim ersten Laden einer Website kann mit der Methode hasStorageAccess() geprüft werden, ob der Zugriff auf Drittanbieter-Cookies bereits gewährt wurde.
// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;
async function handleCookieAccessInit() {
if (!document.hasStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
hasAccess = true;
} else {
// Check whether access has been granted via the Storage Access API.
// Note on page load this will always be false initially so we could be
// skipped in this example, but including for completeness for when this
// is not so obvious.
hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
// Handle the lack of access (covered later)
}
}
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
Speicherzugriff wird einem iFrame-Dokument erst gewährt, nachdem es requestStorageAccess(), aufgerufen hat. Daher gibt hasStorageAccess() anfangs immer „false“ zurück – es sei denn, einem anderen Dokument mit demselben Ursprung im selben iFrame wurde bereits Zugriff gewährt. Die Erteilung wird für die Navigation am selben Ursprung innerhalb des iFrames beibehalten, um Aktualisierungen zu ermöglichen, nachdem der Zugriff für Seiten gewährt wurde, für die Cookies in der ursprünglichen Anfrage für das HTML-Dokument vorhanden sein müssen.
requestStorageAccess()-Methode verwenden
Wenn der iFrame keinen Zugriff hat, muss er möglicherweise mit der requestStorageAccess()-Methode den Zugriff anfordern:
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
Bei der ersten Anforderung muss der Nutzer den Zugriff möglicherweise mit einer Browseraufforderung genehmigen. Danach wird das Promise aufgelöst oder wird abgelehnt, sodass bei Verwendung von await eine Ausnahme entsteht.
Um Missbrauch zu verhindern, wird diese Browseraufforderung erst nach einer Nutzerinteraktion angezeigt. Aus diesem Grund muss requestStorageAccess() erst einmal über einen vom Nutzer aktivierten Event-Handler und nicht sofort beim Laden des iFrames aufgerufen werden:
async function doClick() {
// Only do this extra check if access hasn't already been given
// based on the hasAccess variable.
if (!hasAccess) {
try {
await document.requestStorageAccess();
hasAccess = true; // Can assume this was true if above did not reject.
} catch (err) {
// Access was not granted.
return;
}
}
if (hasAccess) {
// Use the cookies
}
}
document.querySelector('#my-button').addEventListener('click', doClick);
Wenn Sie anstelle von Cookies die lokale Speicherung verwenden müssen, können Sie so vorgehen:
let handle = null;
async function doClick() {
if (!handle) {
try {
handle = await document.requestStorageAccess({localStorage: true});
} catch (err) {
// Access was not granted.
return;
}
}
// Use handle to access unpartitioned local storage.
handle.localStorage.setItem('foo', 'bar');
}
document.querySelector('#my-button').addEventListener('click', doClick);
Aufforderungen zur Erteilung von Berechtigungen
Wenn der Nutzer zum ersten Mal auf die Schaltfläche klickt, wird automatisch die Browseraufforderung angezeigt, normalerweise in der Adressleiste. Unten sehen Sie ein Beispiel für eine Aufforderung von Chrome. Andere Browser haben eine ähnliche Benutzeroberfläche:
Die Aufforderung wird möglicherweise vom Browser übersprungen und die Berechtigung wird unter bestimmten Umständen automatisch erteilt:
- Wenn die Seite und der iFrame in den letzten 30 Tagen nach Annahme der Aufforderung verwendet wurden.
- Ob der eingebettete iFrame Teil einer Gruppe ähnlicher Websites ist
- In Firefox wird die Aufforderung auch bei bekannten Websites (die Sie auf oberster Ebene interagiert haben) bei den ersten fünf Versuchen übersprungen.
Unter bestimmten Umständen kann die Methode auch automatisch abgelehnt werden, ohne dass die Aufforderung angezeigt wird:
- Wenn der Nutzer die Website, zu der der iFrame gehört, noch nicht als übergeordnetes Dokument und nicht in einem iFrame besucht und mit ihr interagiert hat Das bedeutet, dass die Storage Access API nur für eingebettete Websites nützlich ist, die Nutzer zuvor selbst besucht haben.
- Die Methode
requestStorageAccess()wird außerhalb eines Nutzerinteraktionsereignisses ohne vorherige Genehmigung der Aufforderung nach einer Interaktion aufgerufen.
Der Nutzer wird zwar bei der ersten Verwendung aufgefordert, bei späteren Besuchen in Chrome und Firefox requestStorageAccess() jedoch ohne Nachfrage und ohne Interaktion des Nutzers aufgelöst werden können. Beachten Sie, dass Safari immer eine Nutzerinteraktion erfordert.
Da der Zugriff auf Cookies und Speicher ohne Nachfrage oder Nutzerinteraktion gewährt werden kann, ist es in Browsern, die dies unterstützen (Chrome und Firefox), oft vor einer Nutzerinteraktion nicht partitioniert, bevor eine Nutzerinteraktion erfolgt, indem beim Seitenaufbau requestStorageAccess() aufgerufen wird. So können Sie möglicherweise sofort auf nicht partitionierte Cookies und Speicher zugreifen und bieten umfassendere Funktionen, noch bevor der Nutzer mit dem iFrame interagiert. Dies kann in einigen Situationen eine bessere Nutzererfahrung bieten, als auf eine Nutzerinteraktion zu warten.
Berechtigungsabfrage storage-access verwenden
Wenn Sie prüfen möchten, ob der Zugriff ohne Nutzerinteraktion gewährt werden kann, können Sie den Status der Berechtigung storage-access prüfen und den requestStoreAccess()-Aufruf nur vorzeitig starten, wenn keine Nutzeraktion erforderlich ist. Er sollte nicht aufgerufen werden, sodass er fehlschlägt, wenn eine Interaktion erforderlich ist.
Auf diese Weise können Sie möglicherweise im Voraus mit einer Aufforderung umgehen, indem Sie andere Inhalte anzeigen, z. B. eine Anmeldeschaltfläche.
Mit dem folgenden Code wird dem vorherigen Beispiel die Berechtigungsprüfung storage-access hinzugefügt:
// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;
async function hasCookieAccess() {
// Check if Storage Access API is supported
if (!document.requestStorageAccess) {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
return true;
}
// Check if access has already been granted
if (await document.hasStorageAccess()) {
return true;
}
// Check the storage-access permission
// Wrap this in a try/catch for browsers that support the
// Storage Access API but not this permission check
// (e.g. Safari and older versions of Firefox).
let permission;
try {
permission = await navigator.permissions.query(
{name: 'storage-access'}
);
} catch (error) {
// storage-access permission not supported. Assume no cookie access.
return false;
}
if (permission) {
if (permission.state === 'granted') {
// Permission has previously been granted so can just call
// requestStorageAccess() without a user interaction and
// it will resolve automatically.
try {
await document.requestStorageAccess();
return true;
} catch (error) {
// This shouldn't really fail if access is granted, but return false
// if it does.
return false;
}
} else if (permission.state === 'prompt') {
// Need to call requestStorageAccess() after a user interaction
// (potentially with a prompt). Can't do anything further here,
// so handle this in the click handler.
return false;
} else if (permission.state === 'denied') {
// Currently not used. See:
// https://github.com/privacycg/storage-access/issues/149
return false;
}
}
// By default return false, though should really be caught by one of above.
return false;
}
async function handleCookieAccessInit() {
hasAccess = await hasCookieAccess();
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
Sandbox-iFrames
Wenn Sie die Storage Access API in Sandbox-iFrames verwenden, sind die folgenden Sandbox-Berechtigungen erforderlich:
allow-storage-access-by-user-activationist erforderlich, um den Zugriff auf die Storage Access API zu ermöglichen.allow-scriptsist erforderlich, damit JavaScript zum Aufrufen der API verwendet werden kann.allow-same-originist erforderlich, um den Zugriff auf Same-Origin-Cookies und anderen Speicher zu ermöglichen.
Beispiel:
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin"
src="..."></iframe>
Anforderungen an Cookies
Für den Zugriff über die Storage Access API in Chrome müssen websiteübergreifende Cookies mit den folgenden zwei Attributen festgelegt werden:
SameSite=None– erforderlich, um das Cookie als websiteübergreifend zu markierenSecure: Damit wird sichergestellt, dass nur von HTTPS-Websites eingerichtete Cookies aufgerufen werden können.
In Firefox und Safari sind Cookies standardmäßig auf SameSite=None eingestellt und beschränken SSA nicht auf Secure-Cookies, sodass diese Attribute nicht erforderlich sind. Es wird empfohlen, das Attribut SameSite explizit anzugeben und immer Secure-Cookies zu verwenden.
Seitenzugriff auf oberster Ebene
Die Storage Access API soll den Zugriff auf Drittanbieter-Cookies in eingebetteten iFrames ermöglichen.
Es gibt auch andere Anwendungsfälle, in denen die Seite auf oberster Ebene Zugriff auf Drittanbieter-Cookies benötigt. Beispielsweise Bilder oder Skripts, die durch Cookies eingeschränkt sind, die Websiteinhaber eher direkt in das Dokument der obersten Ebene und nicht in einen iFrame einbinden möchten. Für diesen Anwendungsfall hat Chrome eine Erweiterung der Storage Access API vorgeschlagen, mit der die Methode requestStorageAccessFor() hinzugefügt wird.
Die Methode requestStorageAccessFor()
Die Methode requestStorageAccessFor() funktioniert ähnlich wie die Methode requestStorageAccess(), nur für Ressourcen der obersten Ebene. Sie kann nur für Websites verwendet werden, die zu einer Gruppe ähnlicher Websites gehören. Damit soll verhindert werden, dass ein allgemeiner Zugriff auf Drittanbieter-Cookies gewährt wird.
Weitere Informationen zur Verwendung von requestStorageAccessFor() finden Sie im Entwicklerleitfaden für Gruppen ähnlicher Websites.
Die Berechtigungsabfrage top-level-storage-access
Unterstützte Browser
- x
- x
- x
- x
Ähnlich wie die Berechtigung storage-access gibt es die Berechtigung top-level-storage-access, um zu prüfen, ob für requestStorageAccessFor() Zugriff gewährt werden kann.
Wie unterscheidet sich die Storage Access API bei der Verwendung mit RWS?
Wenn Gruppen ähnlicher Websites mit der Storage Access API verwendet werden, sind bestimmte zusätzliche Funktionen verfügbar. Diese werden in der folgenden Tabelle beschrieben:
| Ohne RWS | Mit RWS | |
|---|---|---|
| Erfordert eine Nutzergeste, um die Anfrage für den Speicherzugriff zu initiieren | ||
| Nutzer müssen den angeforderten Speicherursprung in einem Kontext auf oberster Ebene aufrufen, bevor sie Zugriff gewähren | ||
| Aufforderung des Nutzers beim ersten Mal kann übersprungen werden | ||
requestStorageAccess muss nicht aufgerufen werden, wenn zuvor Zugriff gewährt wurde |
||
| Gewährt automatisch Zugriff auf andere Domains auf einer Website mit ähnlichen Websites | ||
Unterstützt requestStorageAccessFor für den Seitenzugriff auf oberster Ebene |
Demo: Cookies setzen und darauf zugreifen
Die folgende Demo zeigt, wie Sie auf dem ersten Bildschirm der Demo auf ein von Ihnen gesetztes Cookie in einem eingebetteten Frame der zweiten Website der Demo zugreifen können:
storage-access-api-demo.glitch.me
Für die Demo ist ein Browser erforderlich, in dem Drittanbieter-Cookies deaktiviert sind:
- Chrome 118 oder höher mit gesetztem Flag
chrome://flags/#test-third-party-cookie-phaseoutund Neustart des Browsers. - Firefox
- Safari
Demo: Lokalen Speicher einrichten
Die folgende Demo zeigt, wie Sie mithilfe der Storage Access API über einen Drittanbieter-iFrame auf nicht partitionierte Übertragungskanäle zugreifen:
https://saa-beyond-cookies.glitch.me/
Für die Demo ist Chrome 125 oder höher erforderlich. Das Flag test-third-party-cookie-phaseout muss aktiviert sein.
Weitere Informationen
- Lesen Sie die Spezifikation zum Zugriff auf Drittanbieter-Cookies oder folgen und melden Sie Probleme.
- Lesen Sie die Spezifikation zum Zugriff auf nicht partitionierten Speicher oder folgen Sie der Anleitung und melden Sie Probleme.
- API-Dokumentation und Leitfaden
- Chrome-Dokumentation zur Verwendung der Storage Access API in Gruppen ähnlicher Websites