Am Ursprungstest für den Zugriff auf Speicher ohne Cookies über die Storage Access API teilnehmen

Helen Cho
Helen Cho
Ari Chivukula
Ari Chivukula
GitHub

In Chrome 115 wurden Änderungen an Storage-, Service-Worker- und Kommunikations-APIs eingeführt, indem sie in Drittanbieterkontexten partitioniert wurden. Die betreffenden APIs, die in Drittanbieterkontexten verwendet werden, werden nicht nur durch die Same-Origin-Policy isoliert, sondern auch durch die Website des übergeordneten Kontexts getrennt.

Websites, für die es zeitlich nicht möglich war, die Unterstützung der Speicherpartitionierung von Drittanbietern zu implementieren, können an einem Einstellungstestlauf teilnehmen, um die Partitionierung vorübergehend aufzuheben (Isolierung durch die Same-Origin-Policy fortsetzen, aber durch die Website der obersten Ebene entfernen) und das vorherige Verhalten der Storage-, Service-Worker- und Communication APIs in Inhalten auf der Website wiederherzustellen. Dieser Test zur Einstellung läuft mit der Veröffentlichung von Chrome 127 am 3. September 2024 ab. Hinweis: Dieser Test ist unabhängig vom Test zur Einstellung des Zugriffs auf Drittanbieter-Cookies. Er bezieht sich nur auf den Zugriff auf den Speicher.

Als langfristige Lösung für bestimmte Anwendungsfälle, die durch die Partitionierung des Nicht-Cookie-Speichers von Drittanbietern beeinträchtigt werden, bietet Chrome Drittanbietern die Möglichkeit, über die Storage Access API (ab Chrome 117 verfügbar) den Zugriff auf Speicher/Kommunikation (sowohl Cookies als auch Nicht-Cookies) anzufordern. Über diese API können Drittanbieter bereits den Cookie-Zugriff anfordern.

Ab Chrome 120 kann dieser Vorschlag über einen Ursprungstest getestet werden. Entwickler sollten an diesem Test teilnehmen, um zu prüfen, wie die vorgeschlagene Lösung ihre Anwendungsfälle erfüllt, damit sie vor Ablauf des Testzeitraums für die Einstellung gerüstet sind.

Details zum Ursprungstest

Ab Chrome 120 unterstützt Chrome den Ursprungstest StorageAccessAPIBeyondCookies, um die vorgeschlagene Erweiterung der Storage Access API (abwärtskompatibel) zu ermöglichen, um den Zugriff auf nicht partitionierten Speicher (Cookies und Nicht-Cookies) in einem Drittanbieterkontext zu ermöglichen.

Mechanik

Die API kann so verwendet werden (JavaScript wird in einem eingebetteten iFrame ausgeführt):

// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);

Wenn du nur Zugriff auf eine bestimmte API und nicht auf all benötigst, kannst du nur die Namen der benötigten API-Handles übergeben. Sie können beispielsweise {sessionStorage: true} übergeben, um nur Zugriff auf den Sitzungsspeicher zu erhalten, oder {indexedDB: true, locks:true}, um Zugriff auf IndexedDB und Websperren zu erhalten.

Neben der Aufrufung dieser zusätzlichen Erweiterung entspricht der Zugriff auf Nicht-Cookie-Speicher den aktuellen Anforderungen für den Cookie-Zugriff über die Storage Access API. In Chrome wird beispielsweise keine Aufforderung angezeigt, wenn sich die Ursprünge im selben Set mit ähnlichen Websites (RWS, der neue Name für Sets mit selbst erhobenen Daten) befinden. Ursprünge, die nicht zur selben RWS gehören, unterliegen den Aufforderungsanforderungen der Storage Access API in Chrome.

Dauer

Der Ursprungstest ist von Chrome 120 bis Chrome 125 (oder nach dem 6. August 2024 in einer beliebigen Hauptversion) verfügbar.

Umfang

In Chrome 120 sind nur DOM-Speicher (Sitzungs- und lokaler Speicher), Indexierte Datenbank und Websperren verfügbar.

Cache-Speicher, Origin Private File System, Kontingent, Blob Storage und Broadcast-Kanal wurden in Chrome 121 hinzugefügt.

In Chrome 123 wurden freigegebene Worker und die Möglichkeit zur Einbeziehung von Cookies hinzugefügt.

Spezielle Worker erben den Zugriff auf nicht partitionierte Cookies, wenn requestStorageAccess vor der Erstellung des Workers in Chrome 120 aufgerufen wurde. Dazu ist keine Verwendung des Storage Access API-Handles erforderlich.

Teilnehmen

  1. Prüfen Sie, wie Sie Cookies und Nicht-Cookie-Speicher in Drittanbieterkontexten verwenden. Die Beispiele für Anwendungsfälle können Ihnen dabei helfen, zu entscheiden, ob dieses Angebot Ihren Anforderungen entspricht.
  2. Starten Sie Chrome Version 120 oder höher und prüfen Sie, ob das Flag test-third-party-cookie-phaseout aktiviert ist.
  3. Wenn Sie die Funktion lokal testen möchten, ohne zuerst ein Testtoken für den Ursprung einzurichten, können Sie #enable-experimental-web-platform-features in Ihrem Browser aktivieren.
    1. Sobald Sie die lokalen Tests abgeschlossen haben, können Sie sich für den Ursprungstest der StorageAccessAPIBeyondCookies registrieren und ein Token für Ihre Domains erhalten. Eine ausführlichere Anleitung finden Sie im Hilfeartikel Einstieg in Ursprungstests. Im Leitfaden zur Fehlerbehebung bei Chrome-Ursprungstests finden Sie eine vollständige Checkliste, mit der Sie prüfen können, ob Ihr Token richtig konfiguriert ist.
    2. Binde dieses Testtoken für den Ursprung in den IFrame ein, in dem du den Storage Access API-Handle verwenden möchtest. Verwende dazu einen HTTP-Header, ein HTML-Meta-Tag oder programmiere es. Das Token muss in jedem Frame eingebettet sein, der diese API verwenden soll. Wenn es nur im übergeordneten Frame eingebettet ist, wird die API nicht in untergeordneten Frames aktiviert.
  4. Rufen Sie document.requestStorageAccess(...) auf, um den Storage Access API-Handle im websiteübergreifenden iframe abzurufen. In der Dokumentation zur Storage Access API finden Sie die Anforderungen, die für einen erfolgreichen Aufruf erfüllt sein müssen.
  5. Migrieren Sie den Speicher in Ihrem Iframe, um den Storage Access API-Handle zu verwenden, falls verfügbar. Beispiel: Aufrufe von window.sessionStorage.setItem(...) werden zu handle.sessionStorage.setItem(...).
  6. Öffnen Sie Ihre Website und prüfen Sie, ob der Speicherzugriffs-Handle wie vorgesehen funktioniert.
  7. Wenn Sie nicht mehr am Test teilnehmen möchten, entfernen Sie das in Schritt 3 hinzugefügte Token.
  8. Senden Sie Feedback oder melden Sie Probleme im GitHub-Repository für die Storage Access API für Nicht-Cookie-Speicher.

Demo: Mit der Storage Access API auf nicht partitionierten lokalen Speicher zugreifen

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 121 oder höher mit aktiviertem Flag test-third-party-cookie-phaseout erforderlich.

Zusätzliche Ressourcen