Storage Access API

Das Blockieren von Drittanbieter-Cookies durch Browser, Nutzereinstellungen und Speicherpartitionierung 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 weiter daran, alle verbleibenden Blockierungsprobleme zu beheben, bevor die API standardisiert wird.

Was ist die Storage Access API?

Die Storage Access API ist eine JavaScript API, mit der iframes Berechtigungen für den Speicherzugriff anfordern können, wenn der Zugriff andernfalls durch die Browsereinstellungen abgelehnt 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.

Mit der Storage Access API kann der Zugriff auf nicht partitionierte Cookies und Speicher mit minimaler Belastung für den Endnutzer bereitgestellt werden. Gleichzeitig wird der Zugriff auf nicht partitionierte Cookies und Speicher verhindert, der 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. Diese Funktion ist nicht verfügbar, wenn Drittanbieter-Cookies eingeschränkt sind 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“ in sozialen Medien Schaltflächen, für die Details zur Log-in-Sitzung erforderlich sind.
• Eingebettete Dokumente, für die Anmeldedaten 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 nicht partitionierter Cookies und Speicher. Daher ist es wichtig zu wissen, wann diese API im Vergleich zu den anderen verwendet werden sollte. 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 „partitioniert“ zu aktivieren. mit einer separaten Keksdose pro Top-Level-Website. 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, mit iframes, die websiteübergreifend sind, vorhandene JavaScript-Speichermechanismen zu verwenden und 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 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 Verwendung von FedCM erfordert jedoch in der Regel zusätzliche Änderungen am Code, z. B. zur Unterstützung der 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 versprechensbasierte Methoden:

• Document.hasStorageAccess() (ab Chrome 125 auch unter dem neuen Namen Document.hasUnpartitionedCookieAccess() verfügbar)
• Document.requestStorageAccess()

Außerdem lässt es sich in die Permissions API einbinden. So können Sie den Status der Berechtigung für den Speicherzugriff im Kontext eines Drittanbieters prüfen, was angibt, ob ein Aufruf von document.requestStorageAccess() automatisch gewährt wird:

• navigator.permissions.query({name: "storage-access"});

Methode hasStorageAccess() 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 using 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()“ 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 requestStorageAccess() 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 die Browseraufforderung angezeigt. werden automatisch in der Adressleiste angezeigt. Der folgende Screenshot zeigt ein Beispiel für eine Aufforderung von Chrome. Andere Browser haben eine ähnliche Benutzeroberfläche:

Unter bestimmten Umständen kann die Aufforderung vom Browser übersprungen und die Berechtigung automatisch erteilt werden:

• 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 Cookie- und Speicherzugriff ohne Aufforderung oder Nutzerinteraktion gewährt werden kann, ist es in Browsern, die dies unterstützen (Chrome und Firefox), oft möglich, vor einer Nutzerinteraktion nicht partitionierten Cookie- oder Speicherzugriff zu erhalten, indem requestStorageAccess() beim Seitenaufbau 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 eine 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 und schlägt fehl, 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 earlier 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') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  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-activation ist erforderlich, um den Zugriff auf die Storage Access API zu ermöglichen.
• allow-scripts ist erforderlich, damit JavaScript zum Aufrufen der API verwendet werden kann.
• allow-same-origin ist 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>

Cookie-Anforderungen

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 markieren
• Secure: 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 SAA 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 wird in Chrome eine Erweiterung der Storage Access API vorgeschlagen, die eine requestStorageAccessFor()-Methode hinzufügt.

Die Methode requestStorageAccessFor()

Die Methode requestStorageAccessFor() funktioniert ähnlich wie requestStorageAccess(), aber für Ressourcen der obersten Ebene. Sie kann nur für Websites innerhalb eines Sets ähnlicher Websites verwendet werden, um zu verhindern, dass 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

Ähnlich der 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-phaseout und 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.

Ressourcen

• 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