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 Speicher in eingebetteten Kontexten für Nutzeraktionen wie die Authentifizierung angewiesen sind. Die Storage Access API (SAA) ermöglicht es, dass diese Anwendungsfälle weiterhin funktionieren, während das websiteübergreifende Tracking so weit wie möglich eingeschränkt wird.

Implementierungsstatus

Die Storage Access API ist in allen wichtigen Browsern verfügbar, es gibt jedoch geringfügige Implementierungsunterschiede zwischen den Browsern. Diese Unterschiede wurden in den entsprechenden Abschnitten dieses Beitrags hervorgehoben.

Wir arbeiten weiterhin daran, alle verbleibenden Blockierungsprobleme zu beheben, bevor wir die API standardisieren.

Was ist die Storage Access API?

Die Storage Access API ist eine JavaScript API, mit der iFrames Speicherzugriffsberechtigungen anfordern können, wenn der Zugriff ansonsten durch Browsereinstellungen verweigert würde. Einbettungen mit Anwendungsfällen, die vom Laden von websiteübergreifenden Ressourcen abhängen, können die API verwenden, um bei Bedarf die Zugriffsberechtigung vom Nutzer anzufordern.

Wenn die Speicheranfrage genehmigt wird, hat der iFrame Zugriff auf seine nicht partitionierten Cookies und seinen nicht partitionierten Speicher, die auch verfügbar sind, wenn Nutzer ihn als Website der obersten Ebene aufrufen.

Die Storage Access API ermöglicht den Zugriff auf bestimmte nicht partitionierte Cookies und Speicher mit minimalem Aufwand für den Endnutzer. Gleichzeitig wird der allgemeine Zugriff auf nicht partitionierte Cookies und Speicher verhindert, der häufig für das Nutzer-Tracking verwendet wird.

Anwendungsfälle

Für einige Einbettungen von Drittanbietern ist der Zugriff auf nicht partitionierte Cookies oder Speicher erforderlich, um Nutzern eine bessere Nutzererfahrung zu bieten. Das ist nicht möglich, wenn Drittanbieter-Cookies eingeschränkt 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 in sozialen Medien, für die Details zur Anmeldesitzung erforderlich sind.
• Eingebettete Dokumente, für die Anmeldesitzungsdetails erforderlich sind.
• Eine Premium-Funktion für ein eingebettetes Video, z. B. keine Anzeigen für angemeldete Nutzer oder die Möglichkeit, die Einstellungen des Nutzers für Untertitel zu berücksichtigen oder bestimmte Videotypen einzuschränken.
• Eingebettete Zahlungssysteme

Bei vielen dieser Anwendungsfälle muss der Log-in-Zugriff in eingebetteten iFrames beibehalten werden.

Wann die Storage Access API anstelle anderer APIs verwendet werden sollte

Die Storage Access API ist eine der Alternativen zur Verwendung von nicht partitionierten Cookies und Speichern. Daher ist es wichtig zu wissen, wann diese API im Vergleich zu den anderen verwendet werden sollte. Es ist für Anwendungsfälle gedacht, in denen beides zutrifft:

• Der Nutzer interagiert mit den eingebetteten Inhalten. Es handelt sich also nicht um ein passives oder verborgenes iFrame.
• Der Nutzer hat den eingebetteten Ursprung im Kontext der obersten Ebene besucht, d. h., wenn dieser Ursprung nicht in eine andere Website eingebettet ist.

Für verschiedene Anwendungsfälle gibt es alternative APIs:

• Mit Cookies Having Independent Partitioned State (CHIPS) können Entwickler ein Cookie für die „partitionierte“ Speicherung aktivieren. Dabei wird für jede Website der obersten Ebene ein separater Cookie-Bereich erstellt. Ein Webchat-Widget eines Drittanbieters kann beispielsweise ein Cookie setzen, um Sitzungsinformationen zu speichern. Die Sitzungsinformationen werden pro Website gespeichert. Auf den vom Widget gesetzten Cookie muss also nicht auf anderen Websites zugegriffen werden, auf denen es ebenfalls eingebettet ist. Die Storage Access API ist nützlich, wenn ein eingebettetes Drittanbieter-Widget darauf angewiesen ist, dieselben Informationen über verschiedene Ursprünge hinweg zu teilen, z. B. für Details zur angemeldeten Sitzung oder für Einstellungen.
• Speicherpartitionierung ist eine Möglichkeit für websiteübergreifende iFrames, vorhandene JavaScript-Speichermechanismen zu verwenden und gleichzeitig den zugrunde liegenden Speicher pro Website aufzuteilen. Dadurch wird verhindert, dass auf eingebetteten Speicher auf einer Website über dieselbe Einbettung auf anderen Websites zugegriffen wird.
• Mit Gruppen ähnlicher Websites (Related Website Sets, RWS) können Organisationen Beziehungen zwischen Websites deklarieren, damit Browser für bestimmte Zwecke eingeschränkten Zugriff auf nicht partitionierte Cookies und Speicher zulassen. Websites müssen weiterhin Zugriff über die Storage Access API anfordern. Für Websites in der Gruppe kann der Zugriff jedoch ohne Nutzeraufforderungen 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 zur Storage Access API, die möglicherweise vorzuziehen ist, da sie einen stärker auf die Anmeldung ausgerichteten Browser-Prompt bietet. 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 für Betrugsbekämpfung, anzeigenbezogene und Analyse. Die Storage Access API ist nicht für diese Anwendungsfälle vorgesehen.

Storage Access API verwenden

Die Storage Access API hat zwei Promise-basierte Methoden:

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

Sie lässt sich auch in die Permissions API einbinden. So können Sie den Status der Speicherzugriffsberechtigung im Drittanbieterkontext prüfen und feststellen, ob ein Aufruf von document.requestStorageAccess() automatisch gewährt würde:

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

hasStorageAccess()-Methode verwenden

Wenn eine Website zum ersten Mal geladen wird, kann sie mit der Methode hasStorageAccess() prüfen, 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.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

Die Storage Access API gewährt einem iframe-Dokument erst dann Speicherzugriff, wenn es requestStorageAccess(), aufruft. hasStorageAccess() kann also anfangs „false“ zurückgeben, z. B. wenn der Nutzer Drittanbieter-Cookies standardmäßig blockiert. Website-spezifische Nutzereinstellungen können jedoch auch den Cookie-Zugriff auf einer bestimmten Website zulassen, selbst wenn der Nutzer Drittanbieter-Cookies standardmäßig blockiert. Der Speicherzugriff über diese API bleibt bei Navigationen mit derselben Quelle im Iframe erhalten. Dies soll insbesondere ermöglichen, dass Seiten, für die Cookies in der ursprünglichen Anfrage für das HTML-Dokument vorhanden sein müssen, nach der Erteilung des Zugriffs neu geladen werden können.

„requestStorageAccess()“ verwenden

Wenn das iFrame keinen Zugriff hat, muss es möglicherweise mit der Methode requestStorageAccess() Zugriff anfordern:

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

Wenn der Zugriff zum ersten Mal angefordert wird, muss der Nutzer ihn 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 vorzubeugen, wird diese Browseraufforderung erst nach einer Nutzerinteraktion angezeigt. Aus diesem Grund muss requestStorageAccess() anfangs über einen vom Nutzer aktivierten Ereignishandler aufgerufen werden und nicht sofort nach dem 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);

Berechtigungsaufforderungen

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

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

• Wenn die Seite und der iFrame in den letzten 30 Tagen nach dem Akzeptieren der Aufforderung verwendet wurden.
• Wenn der eingebettete iFrame Teil einer Gruppe ähnlicher Websites ist.
• Wenn FedCM als Trust-Signal für den Speicherzugriff verwendet wird.
• In Firefox wird die Aufforderung bei bekannten Websites (mit denen Sie auf der obersten Ebene interagiert haben) bei den ersten fünf Versuchen ebenfalls übersprungen.

Alternativ kann die Methode unter bestimmten Umständen automatisch abgelehnt werden, ohne dass die Aufforderung angezeigt wird:

• Wenn der Nutzer die Website, zu der das iFrame gehört, noch nicht als Dokument der obersten Ebene besucht und mit ihr interagiert hat, nicht in einem iFrame. Das bedeutet, dass die Storage Access API nur für eingebettete Websites nützlich ist, die Nutzer zuvor im Erstanbieterkontext besucht haben.
• Wenn die Methode requestStorageAccess() außerhalb eines Nutzerinteraktionsereignisses ohne vorherige Genehmigung des Prompts nach einer Interaktion aufgerufen wird.

Bei der ersten Verwendung wird der Nutzer aufgefordert, requestStorageAccess() zu bestätigen. Bei nachfolgenden Besuchen kann requestStorageAccess() ohne Aufforderung und ohne Nutzerinteraktion in Chrome und Firefox aufgelöst werden. In Safari ist immer eine Nutzerinteraktion erforderlich.

Da der Cookie- und Speicherzugriff ohne Aufforderung oder Nutzerinteraktion gewährt werden kann, ist es oft möglich, vor einer Nutzerinteraktion in Browsern, die dies unterstützen (Chrome und Firefox), Zugriff auf nicht partitionierte Cookies oder Speicher zu erhalten, indem requestStorageAccess() beim Laden der Seite aufgerufen wird. So können Sie möglicherweise sofort auf nicht partitionierte Cookies und den Speicher zugreifen und eine umfassendere Nutzererfahrung bieten, noch bevor der Nutzer mit dem iFrame interagiert. In manchen Situationen kann dies eine bessere Nutzererfahrung bieten, als auf eine Nutzerinteraktion zu warten.

FedCM als Vertrauenssignal für SAA

FedCM (Federated Credential Management) ist ein datenschutzfreundlicher Ansatz für föderierte Identitätsdienste (z. B. „Über… anmelden“), der nicht auf Drittanbieter-Cookies oder Navigationsweiterleitungen basiert.

Wenn sich ein Nutzer mit FedCM bei einer vertrauenden Partei (Relying Party, RP) anmeldet, die eingebettete Inhalte von einem Drittanbieter-Identitätsanbieter (Identity Provider, IdP) enthält, kann der eingebettete IdP-Inhalt automatisch Speicherzugriff auf seine eigenen unpartitionierten Cookies auf oberster Ebene erhalten. Damit der automatische Speicherzugriff mit FedCM aktiviert werden kann, müssen die folgenden Bedingungen erfüllt sein:

• Die FedCM-Authentifizierung (der Anmeldestatus des Nutzers) muss aktiv sein.
• Der RP hat die Berechtigung identity-credentials-get festgelegt, z. B. so:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

Beispiel: Ein idp.example-Iframe ist in rp.example eingebettet. Wenn sich der Nutzer mit FedCM anmeldet, kann das idp.example-iFrame Speicherzugriff für seine eigenen Top-Level-Cookies anfordern.

Mit rp.example wird ein FedCM-Aufruf ausgeführt, um den Nutzer mit dem Identitätsanbieter idp.example anzumelden:

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

Nachdem sich der Nutzer angemeldet hat, kann der IdP requestStorageAccess() aus dem idp.example-iFrame aufrufen, sofern der RP dies mit der Berechtigungsrichtlinie explizit zugelassen hat. Das eingebettete Element erhält automatisch Speicherzugriff auf sein eigenes Top-Level-Cookie, ohne dass eine Nutzeraktivierung oder ein weiterer Berechtigungs-Prompt erforderlich ist:

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

Die Berechtigung wird nur automatisch erteilt, solange der Nutzer mit FedCM angemeldet ist. Sobald die Authentifizierung inaktiv ist, gelten die standardmäßigen SAA-Anforderungen für die Gewährung des Speicherzugriffs.

Storage Access API für Nicht-Cookie-Speicher

Sie können Zugriff auf nicht partitionierten lokalen Speicher anfordern, indem Sie den Parameter typesrequestStorageAccessrequestStorageAccessrequestStorageAccess Wenn Sie beispielsweise Zugriff auf nicht partitionierten lokalen Speicher anfordern möchten, können Sie requestStorageAccess({localStorage: true}) aufrufen.

Wenn Drittanbieter-Cookies aktiviert sind, wird mit dieser Methode Zugriff gewährt, ohne dass eine Nutzeraktivierung oder eine Aufforderung zur Erteilung von Berechtigungen erforderlich ist. Wenn der Nutzer Drittanbieter-Cookies deaktiviert hat, muss er aufgefordert werden, bevor der Speicherzugriff gewährt wird.

Prüfen Sie zuerst, ob der Browser bereits Speicherzugriff hat:

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

Wenn Drittanbieter-Cookies aktiviert sind, fordern Sie den Speicherzugriff an:

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

Wenn Drittanbieter-Cookies blockiert sind (z. B. im Inkognitomodus), prüfen Sie die Berechtigungen für Anfragen, um zu entscheiden, ob eine Nutzeraufforderung erforderlich ist. Der Berechtigungsstatus navigator.permissions.query({name: 'storage-access'}) kann die folgenden Werte haben:

• granted. Der Nutzer hat bereits Zugriff gewährt. Rufen Sie requestStorageAccess auf, um ohne zusätzliche Nutzeraufforderung auf nicht partitionierten Speicher zuzugreifen.
• prompt. Der Nutzer hat den Zugriff noch nicht gewährt. Legen Sie einen Klick-Listener fest und rufen Sie requestStorageAccess nach einer Nutzerinteraktion noch einmal auf.
• error. Die Berechtigung wird nicht unterstützt. Wenn die Storage Access API unterstützt wird, wird diese Berechtigung wahrscheinlich auch unterstützt.

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

Der vollständige Ablauf für die Verarbeitung von nicht cookie-partitioniertem Speicher kann so implementiert werden:

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

Nachfolgendes Laden mit Storage Access Headers

Storage Access Headers sind eine empfohlene, leistungsstärkere Methode zum Laden eingebetteter Inhalte, einschließlich Nicht-iFrame-Ressourcen. Die Funktion ist ab Chrome 133 verfügbar. Mit Storage Access Headers kann der Browser erkennen, wann der Nutzer dem Drittanbieterursprung im aktuellen Kontext bereits die Berechtigung für storage-access erteilt hat. Bei nachfolgenden Besuchen können Ressourcen mit Zugriff auf nicht partitionierte Cookies geladen werden.

Ablauf von Headern für Speicherzugriff

Mit Storage Access Headers wird bei den nachfolgenden Seitenaufrufen der folgende Ablauf ausgelöst:

1. Der Nutzer hat website.example, in die eine calendar.example-Ressource eingebettet ist, bereits besucht und storage-access mit dem document.requestStorageAccess()-Aufruf die Berechtigung erteilt.
2. Der Nutzer besucht website.example, in die die Ressource calendar.example noch einmal eingebettet ist. Diese Anfrage hat noch keinen Zugriff auf das Cookie, wie bisher. Der Nutzer hat jedoch zuvor die Berechtigung storage-access erteilt und der Fetch enthält einen Sec-Fetch-Storage-Access: inactive-Header, der angibt, dass der Zugriff auf nicht partitionierte Cookies verfügbar, aber nicht aktiviert ist.
3. Der calendar.example-Server antwortet mit einem Activate-Storage-Access: retry; allowed-origin='<origin>'-Header (in diesem Fall wäre <origin> https://website.example), um anzugeben, dass für das Abrufen der Ressource nicht partitionierte Cookies mit der Berechtigung storage-access verwendet werden müssen.
4. Der Browser wiederholt die Anfrage und fügt diesmal nicht partitionierte Cookies ein (wodurch die Berechtigung storage-access für diesen und nachfolgende Abrufe aktiviert wird).
5. Der calendar.example-Server antwortet mit dem personalisierten Iframe-Inhalt. Die Antwort enthält einen Activate-Storage-Access: load-Header, der angibt, dass der Browser die Inhalte mit aktivierter storage-access-Berechtigung laden soll (d. h. mit nicht partitioniertem Cookie-Zugriff, als ob document.requestStorageAccess() aufgerufen worden wäre).
6. Der User-Agent lädt die Iframe-Inhalte mit nicht partitioniertem Cookie-Zugriff mithilfe der Berechtigung storage-access. Danach kann das Widget wie erwartet funktionieren.

Header für den Speicherzugriff verwenden

In der folgenden Tabelle sind die Storage Access-Header aufgeführt.

Mit Storage Access Headers kann beispielsweise ein Bild von einem Drittanbieter geladen werden:

  // On the client side
  <img src="https://server.example/image">

In diesem Fall sollte server.example die folgende serverseitige Logik implementieren:

  app.get('/image', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    res.set('Activate-Storage-Access', `retry; allowed-origin='${req.headers.origin}'`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

In der Storage Access API-Demo wird Drittanbieterinhalt (einschließlich eines Nicht-Iframe-Bildes) mithilfe von Storage Access-Headern eingebettet.

storage-access-Berechtigungsanfrage verwenden

Um zu prüfen, ob der Zugriff ohne Nutzerinteraktion gewährt werden kann, können Sie den Status der Berechtigung storage-access prüfen und den Aufruf von requestStoreAccess() nur dann frühzeitig ausführen, wenn keine Nutzeraktion erforderlich ist. So vermeiden Sie, dass der Aufruf fehlschlägt, wenn eine Interaktion erforderlich ist.

So können Sie auch die Notwendigkeit eines Prompts im Voraus berücksichtigen, indem Sie unterschiedliche Inhalte anzeigen, z. B. eine Anmeldeschaltfläche.

Im folgenden Code wird dem vorherigen Beispiel die Berechtigungsprüfung für 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 mit Sandbox-Attribut

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 die API über JavaScript aufgerufen werden kann.
• allow-same-origin ist erforderlich, um den Zugriff auf Cookies und andere Speicherbereiche desselben Ursprungs zu ermöglichen.

Beispiel:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

Cookie-Anforderungen

Damit in Chrome mit der Storage Access API auf websiteübergreifende Cookies zugegriffen werden kann, müssen diese mit den folgenden beiden Attributen gesetzt werden:

• SameSite=None – erforderlich, um das Cookie als websiteübergreifend zu kennzeichnen
• Secure – dadurch wird sichergestellt, dass nur auf Cookies zugegriffen werden kann, die von HTTPS-Websites gesetzt wurden.

In Firefox und Safari sind Cookies standardmäßig auf SameSite=None festgelegt und SAA ist nicht auf Secure-Cookies beschränkt. Daher sind diese Attribute nicht erforderlich. 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 die Seite der obersten Ebene Zugriff auf Drittanbieter-Cookies benötigt. Das können beispielsweise Bilder oder Skripts sein, die durch Cookies eingeschränkt werden und die Websiteinhaber lieber direkt im Dokument der obersten Ebene als in einem iFrame einfügen möchten. Um diesen Anwendungsfall zu unterstützen, hat Chrome eine Erweiterung der Storage Access API vorgeschlagen, die einerequestStorageAccessFor()-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 einer Gruppe ähnlicher Websites verwendet werden, um den allgemeinen Zugriff auf Drittanbieter-Cookies zu verhindern.

Weitere Informationen zur Verwendung von requestStorageAccessFor() finden Sie im Entwicklerleitfaden zu Gruppen ähnlicher Websites.

Die Berechtigungsanfrage top-level-storage-access

Ähnlich wie bei der Berechtigung storage-access gibt es eine Berechtigung top-level-storage-access, mit der geprüft werden kann, ob Zugriff auf requestStorageAccessFor() gewährt werden kann.

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

Wenn Gruppen ähnlicher Websites mit der Storage Access API verwendet werden, sind bestimmte zusätzliche Funktionen verfügbar, wie in der folgenden Tabelle beschrieben:

Demo: Cookies setzen und darauf zugreifen

In der folgenden Demo sehen Sie, wie ein Cookie, das Sie im ersten Bildschirm der Demo selbst gesetzt haben, in einem eingebetteten Frame auf der zweiten Website der Demo aufgerufen werden kann:

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 dem Flag chrome://flags/#test-third-party-cookie-phaseout und einem Neustart des Browsers.
• Firefox
• Safari

Demo: Lokalen Speicher festlegen

In der folgenden Demo wird gezeigt, wie über ein Drittanbieter-iFrame mit der Storage Access API auf nicht partitionierte Broadcast-Channels zugegriffen wird:

https://saa-beyond-cookies.glitch.me/

Für die Demo ist Chrome 125 oder höher mit aktiviertem Flag test-third-party-cookie-phaseout erforderlich.

Ressourcen

• Lesen Sie die Spezifikation für den Zugriff auf Drittanbieter-Cookies oder folgen Sie den Problemen und melden Sie sie.
• Lesen Sie die Spezifikation für den Zugriff auf nicht partitionierten Speicher oder folgen Sie Problemen und melden Sie sie.
• API-Dokumentation und Leitfaden
• Chrome-Dokumentation zur Verwendung der Storage Access API in Gruppen ähnlicher Websites