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 weiterhin funktionieren, während das websiteübergreifende Tracking so weit wie möglich eingeschränkt wird.

Implementierungsstatus

Unterstützte Browser

  • Chrome: 119.
  • Edge: 85.
  • Firefox: 65.
  • Safari: 11.1.

Quelle

Die Storage Access API ist in allen gängigen Browsern verfügbar. Es gibt jedoch geringe Implementierungsunterschiede 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, die es iFrames ermöglicht, Speicherzugriffsberechtigungen anzufordern, wenn der Zugriff andernfalls durch die Browsereinstellungen verweigert würde. Bei Einbettungen mit Anwendungsfällen, die vom Laden von websiteübergreifenden Ressourcen abhängen, kann die API verwendet werden, um bei Bedarf die Zugriffsberechtigung 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
  • Premium-Funktionen für ein eingebettetes Video (z. B. keine Anzeigen für angemeldete Nutzer, Informationen zu den Einstellungen des Nutzers für Untertitel oder Einschränkungen bestimmter Videotypen)
  • Eingebettete Zahlungssysteme

Bei vielen dieser Anwendungsfälle wird der Anmeldezugriff in eingebetteten Iframes beibehalten.

Wann die Storage Access API anstelle anderer APIs verwendet werden sollte

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 eignet sich für Anwendungsfälle, bei denen folgende Bedingungen erfüllt sind:

  • Der Nutzer interagiert mit den eingebetteten Inhalten. Es handelt sich also nicht um einen passiven oder versteckten iFrame.
  • Der Nutzer hat den eingebetteten Ursprung in einem Kontext der obersten Ebene besucht, d. h., der Ursprung ist nicht in einer anderen Website eingebettet.

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 Webchat-Widget eines Drittanbieters kann beispielsweise ein Cookie zum Speichern von Sitzungsinformationen verwenden. 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 darauf angewiesen ist, dieselben Informationen für verschiedene Quellen zu teilen (z. B. für Details oder Einstellungen einer angemeldeten Sitzung).
  • 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. So wird verhindert, dass über dasselbe eingebettete Element auf anderen Websites auf den eingebetteten Speicher einer Website zugegriffen wird.
  • Mit Sets ähnlicher Websites (Related Websites Sets, RWS) können Organisationen Beziehungen zwischen Websites deklarieren, damit Browser für bestimmte Zwecke einen eingeschränkten, nicht partitionierten Cookie- und Speicherzugriff zulassen. 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 kümmert sich um den 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 und ist möglicherweise vorzuziehen, da sie eine nutzerfreundlichere Browseraufforderung zum Anmelden bietet. 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:

Außerdem lässt sie 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:

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 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();

Der Speicherzugriff wird einem iframe-Dokument erst gewährt, nachdem requestStorageAccess(), aufgerufen wurde. 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 alle 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 ursprünglichen Anfrage für das HTML-Dokument vorhanden sein müssen.

„requestStorageAccess()“ verwenden

Wenn der iFrame keinen Zugriff hat, muss er möglicherweise den Zugriff mit der Methode requestStorageAccess() 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 nur nach einer Nutzerinteraktion angezeigt. Deshalb muss requestStorageAccess() zuerst von einem vom Nutzer aktivierten Ereignis-Handler aufgerufen werden, nicht sofort beim Laden des iframes:

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

Berechtigungsanfragen

Wenn der Nutzer zum ersten Mal auf die Schaltfläche klickt, wird die Browseraufforderung automatisch angezeigt, in der Regel in der Adressleiste. Der folgende Screenshot zeigt ein Beispiel für die Aufforderung in Chrome. Andere Browser haben eine ähnliche Benutzeroberfläche:

Chrome Storage Access API-Berechtigungsanfrage
Aufforderung zur Einwilligung in die Storage Access API in Chrome

Die Aufforderung wird vom Browser möglicherweise ü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 eine umfassendere Nutzung ermöglichen, noch bevor der Nutzer mit dem Iframe interagiert. Dies kann in einigen Situationen eine bessere Nutzererfahrung bieten, als auf eine Nutzerinteraktion zu warten.

storage-access-Berechtigungsanfrage verwenden

Wenn Sie prüfen möchten, ob der Zugriff ohne Nutzerinteraktion gewährt werden kann, können Sie den Status der storage-access-Berechtigung prüfen und den requestStoreAccess()-Aufruf nur dann vorzeitig starten, wenn keine Nutzeraktion erforderlich ist. Andernfalls wird der Aufruf fehlschlagen, 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();

IFrames in einer Sandbox

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>

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 kennzeichnen
  • 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.

Zugriff auf Seiten der obersten Ebene

Die Storage Access API soll den Zugriff auf Drittanbieter-Cookies in eingebetteten iFrames ermöglichen.

Es gibt auch andere Anwendungsfälle, in denen für die Seite der obersten Ebene Zugriff auf Drittanbieter-Cookies erforderlich ist. 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 für die Storage Access API vorgeschlagen, mit der die Methode requestStorageAccessFor() hinzugefügt wird.

Die Methode requestStorageAccessFor()

Unterstützte Browser

  • Chrome: 119.
  • Edge: 119.
  • Firefox: nicht unterstützt
  • Safari: nicht unterstützt.

Quelle

Die Methode requestStorageAccessFor() funktioniert ähnlich wie die Methode requestStorageAccess(), nur 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

Unterstützte Browser

  • Chrome: Nicht unterstützt.
  • Edge: Nicht unterstützt.
  • Firefox: nicht unterstützt
  • Safari: Nicht unterstützt.

Ähnlich wie bei der storage-access-Berechtigung gibt es eine top-level-storage-access-Berechtigung, um zu prüfen, ob Zugriff für requestStorageAccessFor() gewährt werden kann.

Wie unterscheidet sich die Storage Access API bei der Verwendung mit RWS?

Wenn Sie Sets mit ähnlichen Websites mit der Storage Access API verwenden, sind bestimmte zusätzliche Funktionen verfügbar, wie in der folgenden Tabelle beschrieben:

Ohne RWS Mit RWS
Der Nutzer muss eine Nutzergeste ausführen, um den Speicherzugriff anzufordern.
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 verknüpften Website
Unterstützt requestStorageAccessFor für den Zugriff auf Seiten der obersten Ebene
Unterschiede zwischen der Storage Access API ohne und mit Gruppen ähnlicher Websites

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 mit deaktivierten Drittanbieter-Cookies erforderlich:

  • Chrome 118 oder höher mit gesetztem Flag chrome://flags/#test-third-party-cookie-phaseout und neu gestartetem Browser
  • Firefox
  • Safari

Demo: Lokalen Speicher festlegen

In der folgenden Demo wird gezeigt, wie du mithilfe der Storage Access API von einem Drittanbieter-Iframe aus auf nicht partitionierte Broadcast-Kanäle zugreifen kannst:

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