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

Mit Chrome 115 wurden Änderungen an Speicher-, Service-Worker- und Kommunikations-APIs vorgenommen, da sie in Drittanbieterkontexte partitioniert wurden. Die betroffenen APIs, die in Drittanbieterkontexten verwendet werden, werden nicht nur durch die Same-Origin-Richtlinie isoliert, sondern auch durch die Website des Kontexts der obersten Ebene isoliert.

Für Websites, für die bisher noch keine Unterstützung für die Speicherpartitionierung durch Drittanbieter implementiert wurde, können Sie an einem Einstellungstest teilnehmen. Damit können Sie die Partitionierung vorübergehend aufheben (weiterhin durch eine Richtlinie mit demselben Ursprung isoliert, aber durch die Website auf oberster Ebene isoliert) und das bisherige Verhalten von Speicher-, Service-Worker- und Kommunikations-APIs in den auf der Website eingebetteten Inhalten wiederherstellen. Dieser Test zur Einstellung läuft mit der Veröffentlichung von Chrome 127 am 3. September 2024 ab. Hinweis: Dies hat nichts mit dem Test zur Einstellung des Zugriffs auf Drittanbieter-Cookies zu tun, sondern nur für den Zugriff auf den Speicher.

Als langfristige Lösung zur Bewältigung bestimmter Anwendungsfälle, die durch Drittanbieter-Speicherpartitionen ohne Cookies unterbrochen werden, bietet Chrome jetzt die Möglichkeit für Drittanbieter, Speicher-/Kommunikationszugriff (sowohl mit als auch ohne Cookies) über die Storage Access API (Versand ab Chrome 117) anzufordern. Damit können Drittanbieter bereits den Zugriff auf Cookies anfordern.

Ab Chrome 120 kann dieses Angebot im Rahmen eines Ursprungstests getestet werden. Entwickler sollten an diesem Ursprungstest teilnehmen, um zu evaluieren, wie die vorgeschlagene Lösung auf ihre Anwendungsfälle zugeschnitten ist. So können sie sich auf die Tests vorbereiten, bevor der Einstellungstest endet.

Details zum Ursprungstest

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

Mechanik

Die API kann folgendermaßen 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 Sie nur bestimmten API-Zugriff statt Zugriff auf all erhalten möchten, können Sie nur die Namen der API-Handles übergeben, die Sie benötigen. Sie könnten beispielsweise {sessionStorage: true} übergeben, um nur Zugriff auf Session Storage zu erhalten, oder {indexedDB: true, locks:true}, um Zugriff auf IndexedDB und Web Locks zu erhalten.

Über diese zusätzliche Erweiterung hinaus würde der Zugriff auf Nicht-Cookie-Speicher den aktuellen Anforderungen für den Cookie-Zugriff über die Storage Access API entsprechen. In Chrome wird beispielsweise keine Aufforderung angezeigt, wenn sich die Quellen im selben Set ähnlicher Websites (RWS, der neue Name für First-Party-Sets) befinden. Ursprünge, die nicht Teil desselben RWS sind, unterliegen den Aufforderungsanforderungen der Storage Access API in Chrome.

Dauer

Der Ursprungstest ist von Chrome 120 bis Chrome 125 bzw. nach dem 6. August 2024 bei allen Meilenstein-Releases verfügbar.

Umfang

In Chrome 120 sind nur DOM-Speicher (Sitzung und lokaler Speicher), indexierte DB und Websperren verfügbar.

„Cache-Speicher“, „Privates privates Dateisystem“, „Kontingent“, „Blob-Speicher“ und „Übertragungskanal“ wurden in Chrome 121 hinzugefügt.

Gemeinsam genutzte Worker und die Möglichkeit, die Verwendung von Cookies zu steuern, wurden in Chrome 123 hinzugefügt.

Dedizierte Worker übernehmen den Zugriff auf nicht partitionierte Cookies, wenn requestStorageAccess aufgerufen wurde, bevor der Worker ab Chrome 120 erstellt wurde. Dies erfordert nicht die Verwendung des Storage Access API-Handles.

Teilnehmen

  1. Bewerten, wie Sie Cookies und andere Arten von Speicherung im Zusammenhang mit Drittanbietern verwenden. Anhand der Anwendungsbeispiele können Sie besser verstehen, ob dieses Angebot für Ihre Anforderungen geeignet ist.
  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 zuvor ein Token für den Ursprungstest einzurichten, können Sie #enable-experimental-web-platform-features in Ihrem Browser aktivieren.
    1. Nachdem Sie die lokalen Tests abgeschlossen haben, können Sie sich für den StorageAccessAPIBeyondCookies-Ursprungstest registrieren und ein Token für Ihre Domains erhalten. Eine ausführlichere Anleitung finden Sie unter Erste Schritte mit Ursprungstests. Im Leitfaden zur Fehlerbehebung bei Chrome-Ursprungstests finden Sie eine vollständige Checkliste, mit der Sie überprüfen können, ob Ihr Token richtig konfiguriert ist.
    2. Betten Sie dieses Ursprungstesttoken in den iFrame ein, in dem Sie das Handle der Storage Access API verwenden müssen. Verwenden Sie dazu einen HTTP-Header, ein HTML-Meta-Tag oder programmatisch. Beachten Sie, dass das Token in jeden Frame eingebettet werden muss, in dem diese API verwendet werden soll. Wenn Sie es in den übergeordneten Frame einbetten, wird die API nicht in untergeordneten Frames aktiviert.
  4. Rufen Sie document.requestStorageAccess(...) auf, um das Storage Access API-Handle im websiteübergreifenden iFrame abzurufen. Die Voraussetzungen für einen erfolgreichen Aufruf finden Sie in der Dokumentation zur Storage Access API.
  5. Migrieren Sie den Speicher in Ihrem iFrame, um das Handle der Storage Access API zu verwenden, falls es verfügbar ist. Aufrufe von window.sessionStorage.setItem(...) werden beispielsweise zu handle.sessionStorage.setItem(...).
  6. Öffnen Sie Ihre Website und prüfen Sie, ob der Alias für den Speicherzugriff wie vorgesehen funktioniert.
  7. Wenn Sie nicht mehr am Ursprungstest teilnehmen möchten, entfernen Sie das Token, das Sie in Schritt 3 hinzugefügt haben.
  8. Senden Sie Feedback oder melden Sie Probleme im GitHub-Repository zur Storage Access API, bei dem es sich nicht um Cookie-Speicher handelt.

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

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 121 oder höher erforderlich. Das Flag test-third-party-cookie-phaseout muss aktiviert sein.

Zusätzliche Ressourcen