Chrome stellt die Unterstützung für Drittanbieter-Cookies schrittweise ein, um das websiteübergreifende Tracking zu reduzieren. Dies stellt Websites und Dienste, die auf Cookies in eingebetteten Kontexten basieren, eine Herausforderung für Nutzer dar, z. B. bei der Authentifizierung. Die Storage Access API (SAA) lässt diese Anwendungsfälle weiterhin zu und schränkt das websiteübergreifende Tracking so weit wie möglich ein.
Implementierungsstatus
Die Storage Access API ist in allen gängigen Browsern verfügbar. Die Implementierung der einzelnen Browser unterscheidet sich jedoch geringfügig. Diese Unterschiede wurden in den entsprechenden Abschnitten in diesem Post hervorgehoben.
An der Lösung aller verbleibenden Probleme mit Blockierungen wird weiter gearbeitet, bevor die API standardisiert wird.
Was ist die Storage Access API?
Die Storage Access API ist eine JavaScript API, mit der iFrames Speicherzugriffsberechtigungen anfordern können, wenn der Zugriff andernfalls durch die Browsereinstellungen verweigert würde. Bei Einbettungen mit Anwendungsfällen, die das Laden websiteübergreifender Ressourcen erfordern, können bei Bedarf über die API Zugriffsberechtigungen vom Nutzer angefordert werden.
Wenn die Speicheranforderung genehmigt wird, hat der iFrame Zugriff auf seine websiteübergreifenden Cookies, die auch verfügbar sind, wenn Nutzer die Website als Website der obersten Ebene aufrufen.
Die Storage Access API ermöglicht den spezifischen websiteübergreifenden Cookie-Zugriff mit minimaler Belastung für den Endnutzer. Gleichzeitig wird der allgemeine websiteübergreifende Cookie-Zugriff verhindert, der häufig für das Nutzer-Tracking verwendet wird.
Anwendungsfälle
Für einige Einbettungen von Drittanbietern ist der Zugriff auf websiteübergreifende Cookies erforderlich, um die Nutzerfreundlichkeit zu verbessern. Nach der Einstellung von Drittanbieter-Cookies ist dies nicht mehr möglich.
Dies ist unter anderem in folgenden Fällen hilfreich:
- Eingebettete Kommentar-Widgets, für die Details der 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 der Anmeldesitzung erforderlich sind.
- Ein Premium-Bereich für eingebettete Videos, z. B. um keine Anzeigen für angemeldete Nutzer einzublenden, um die Nutzereinstellungen für Untertitel zu kennen oder um bestimmte Videotypen einzuschränken.
- Eingebettete Zahlungssysteme
Bei vielen dieser Anwendungsfälle muss der Anmeldezugriff in eingebetteten iFrames dauerhaft bestehen.
Wann die Storage Access API gegenüber anderen APIs verwendet werden sollte
Die Storage Access API ist eine der Alternativen zur Verwendung von Drittanbieter-Cookies. Daher ist es wichtig zu wissen, wann Sie diese API im Vergleich zu anderen verwenden sollten. Sie ist für Anwendungsfälle vorgesehen, in denen die beiden folgenden Bedingungen zutreffen:
- Der Nutzer interagiert mit den eingebetteten Inhalten, d. h. es handelt sich nicht um einen passiven oder einen versteckten iFrame.
- Der Nutzer hat den eingebetteten Ursprung 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:
- Mit Cookies Having Independent Partitioned State (CHIPS) können Entwickler Cookies für „partitionierten“ Speicher mit einer separaten Cookie-JAR-Datei pro Website der obersten Ebene aktivieren. Für das Webchat-Widget eines Drittanbieters kann beispielsweise ein Cookie gesetzt werden, um Sitzungsinformationen zu speichern. Die Sitzungsinformationen werden pro Website gespeichert, sodass das vom Widget gesetzte Cookie nicht auf anderen Websites aufgerufen werden muss, auf denen es ebenfalls eingebettet ist. Die Storage Access API ist nützlich, wenn ein eingebettetes Drittanbieter-Widget davon abhängig ist, dass dieselben Informationen für verschiedene Ursprünge geteilt werden (z. B. für Details oder Einstellungen einer angemeldeten Sitzung).
- Mit Gruppen ähnlicher Websites (RWS) können Organisationen Beziehungen zwischen Websites angeben, sodass Browser den Zugriff auf Drittanbieter-Cookies für bestimmte Zwecke eingeschränkt zulassen. Websites müssen weiterhin den Zugriff über die Storage Access API anfordern, aber für Websites innerhalb des Satzes kann der Zugriff ohne Aufforderung durch den Nutzer gewährt werden.
- Federated Credential Management (FedCM) ist ein datenschutzfreundlicher Ansatz für föderierte Identitätsdienste. Die Storage Access API sorgt für den Zugriff auf Cookies nach der Anmeldung. Für einige Anwendungsfälle bietet FedCM eine alternative Lösung zur Storage Access API, die besser geeignet ist, da sie eine anmeldungsorientierte Browseraufforderung hat. Die Einführung von FedCM erfordert jedoch in der Regel zusätzliche Änderungen an Ihrem Code, z. B. zur Unterstützung der HTTP-Endpunkte.
- Es gibt auch APIs zum Schutz vor Betrug, anzeigenbezogene und Measurement. Die Storage Access API ist nicht dafür vorgesehen, diese Bedenken auszuräumen.
Storage Access API verwenden
Die Storage Access API hat zwei Promise-basierte Methoden:
Außerdem ist sie in die Permissions API eingebunden. So können Sie den Status der Berechtigung zum Zugriff auf den Speicher in einem Drittanbieterkontext 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 bereits Zugriff auf Drittanbieter-Cookies 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() anfänglich immer „false“ zurück – es sei denn, einem anderen Dokument mit demselben Ursprung im selben iFrame wurde bereits Zugriff gewährt. Die Gewährung wird in den Navigationen 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 ersten Anfrage für das HTML-Dokument vorhanden sein müssen.
requestStorageAccess()-Methode verwenden
Wenn der iFrame keinen Zugriff hat, muss er möglicherweise über die requestStorageAccess()-Methode Zugriff anfordern:
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
Wenn dies zum ersten Mal angefordert wird, muss der Nutzer diesen Zugriff möglicherweise über eine Browseraufforderung genehmigen. Danach wird das Promise aufgelöst oder abgelehnt, was zu einer Ausnahme führt, wenn await verwendet wird.
Um Missbrauch zu verhindern, wird diese Browseraufforderung erst nach einer Nutzerinteraktion angezeigt. Aus diesem Grund muss requestStorageAccess() anfangs von einem vom Nutzer aktivierten Event-Handler aufgerufen werden und nicht sofort, wenn der iFrame geladen wird:
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);
Berechtigungsaufforderungen
Wenn der Nutzer zum ersten Mal auf die Schaltfläche klickt, wird automatisch die Browseraufforderung angezeigt, normalerweise in der Adressleiste. Hier sehen Sie ein Beispiel für die Aufforderung von Chrome. Andere Browser haben jedoch eine ähnliche Benutzeroberfläche:
Die Aufforderung kann vom Browser übersprungen werden und unter bestimmten Umständen automatisch gewährte Berechtigungen:
- Die Seite und der iFrame wurden in den letzten 30 Tagen nach Annahme der Aufforderung verwendet.
- Der eingebettete iFrame ist Teil einer Gruppe ähnlicher Websites.
- In Firefox wird die Aufforderung auch bei bekannten Websites (d. h. Websites, mit denen 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:
- Der Nutzer hat die Website, die den iFrame besitzt, noch nicht als Dokument auf oberster Ebene und nicht in einem iFrame zuvor besucht und mit ihr interagiert. Das bedeutet, dass die Storage Access API nur für eingebettete Websites nützlich ist, die Nutzer zuvor in einem Erstanbieter-Kontext besucht haben.
- Wenn die Methode
requestStorageAccess()außerhalb eines Nutzerinteraktionsereignisses ohne vorherige Genehmigung der Aufforderung nach einer Interaktion aufgerufen wird.
Während der Nutzer bei der ersten Verwendung aufgefordert wird, kann requestStorageAccess() bei nachfolgenden Besuchen ohne Nachfrage und ohne Nutzerinteraktion in Chrome und Firefox aufgelöst werden. Beachten Sie, dass Safari immer eine Nutzerinteraktion erfordert.
Da der Zugriff auf Cookies ohne Nachfrage oder Nutzerinteraktion gewährt werden kann, ist es oft möglich, den Zugriff auf Drittanbieter-Cookies vor einer Nutzerinteraktion in Browsern, die diese Funktion unterstützen (Chrome und Firefox), zu erhalten. Dazu muss beim Seitenaufbau requestStorageAccess() aufgerufen werden. So können Sie möglicherweise sofort auf websiteübergreifende Cookies von Drittanbietern zugreifen und für eine umfassendere Nutzererfahrung sorgen, noch bevor der Nutzer mit dem iFrame interagiert. Dies kann in manchen Situationen eine bessere User Experience bieten, als auf eine Nutzerinteraktion zu warten.
storage-access-Berechtigungsabfrage 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 dann vorzeitig starten, wenn keine Nutzeraktion erforderlich ist. Der Aufruf schlägt fehl, wenn eine Interaktion erforderlich ist.
Auf diese Weise können Sie die Notwendigkeit einer Aufforderung im Vorfeld auch vermeiden, indem Sie verschiedene Inhalte anzeigen lassen, z. B. eine Anmeldeschaltfläche.
Mit dem folgenden Code wird die storage-access-Berechtigungsprüfung zum vorherigen Beispiel 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();
In einer Sandbox ausgeführte 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, um die Verwendung von JavaScript zum Aufrufen der API zuzulassen.allow-same-originist erforderlich, um den Zugriff auf Cookies mit derselben Quelle und anderen Speicher zuzulassen.
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 beiden Attributen festgelegt werden:
SameSite=None: ist erforderlich, um das Cookie als websiteübergreifend zu markierenSecure: Damit wird sichergestellt, dass nur von HTTPS-Websites gesetzte Cookies aufgerufen werden können.
In Firefox und Safari ist für Cookies standardmäßig SameSite=None festgelegt und sie beschränken SSA nicht auf Cookies vom Typ Secure. Daher sind diese Attribute nicht erforderlich. Es wird empfohlen, das Attribut SameSite ausdrücklich zu formulieren und Secure-Cookies immer zu verwenden.
Seitenzugriff auf oberster Ebene
Die Storage Access API soll den Zugriff auf Drittanbieter-Cookies innerhalb eingebetteter iFrames ermöglichen.
Es gibt auch andere Anwendungsfälle, in denen die Seite der obersten Ebene Zugriff auf Drittanbieter-Cookies erfordert. Dazu gehören beispielsweise Bilder oder Skripts, die durch Cookies eingeschränkt sind und die Websiteinhaber direkt in das Dokument auf oberster Ebene anstatt in einen iFrame einfügen möchten. Aus diesem Grund hat Chrome eine Erweiterung für die Storage Access API vorgeschlagen, die eine requestStorageAccessFor()-Methode hinzufügt.
Die Methode requestStorageAccessFor()
Die Methode requestStorageAccessFor() funktioniert ähnlich wie requestStorageAccess(), gilt jedoch für Ressourcen der obersten Ebene. Sie kann nur für Websites verwendet werden, die zu einer Gruppe ähnlicher Websites gehören, um zu verhindern, dass der allgemeine Zugriff auf Drittanbieter-Cookies gewährt wird.
Weitere Informationen zur Verwendung von requestStorageAccessFor() finden Sie im Entwicklerleitfaden für Gruppen ähnlicher Websites.
Abfrage für die top-level-storage-access-Berechtigung
Unterstützte Browser
- 119
- 119
- x
- x
Ähnlich wie bei der Berechtigung storage-access gibt es auch die Berechtigung top-level-storage-access, mit der geprüft werden kann, ob 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, stehen bestimmte zusätzliche Funktionen zur Verfügung (siehe folgende Tabelle):
| Ohne RWS | Mit RWS | |
|---|---|---|
| Erfordert eine Nutzergeste, um die Anfrage für den Speicherzugriff zu starten | ||
| Verlangt den Nutzer, den angeforderten Speicherursprung in einem Kontext auf oberster Ebene zu besuchen, bevor er Zugriff gewährt | ||
| Die Aufforderung für den ersten Nutzer kann übersprungen werden | ||
requestStorageAccess muss nicht aufgerufen werden, wenn zuvor Zugriff gewährt wurde |
||
| Gewährt automatisch Zugriff auf andere Domains einer Website mit ähnlichen Websites | ||
Unterstützt requestStorageAccessFor für den Seitenzugriff auf oberster Ebene |
Demo: Cookies setzen und aufrufen
Die folgende Demo zeigt, wie Sie auf ein von Ihnen gesetztes Cookie im ersten Bildschirm der Demo in einem eingebetteten Frame auf 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 festgelegtem
chrome://flags/#test-third-party-cookie-phaseout-Flag und neu gestartetem Browser. - Firefox
- Safari
Ressourcen
- Lesen Sie die Spezifikationen oder folgen Sie Problemen und melden Sie Probleme.
- API-Dokumentation und Leitfaden
- Chrome-Dokumentation zur Verwendung der Storage Access API in Gruppen ähnlicher Websites