Diese Seite wurde von der Cloud Translation API übersetzt.

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

Helen Cho

Ari Chivukula

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.

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 dieses Angebot im Rahmen eines Ursprungstests 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 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 lediglich 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 zurselben 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 jeder Hauptversion) 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.

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

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.
Starten Sie Chrome Version 120 oder höher und prüfen Sie, ob das Flag test-third-party-cookie-phaseout aktiviert ist.
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 StorageAccessAPIBeyondCookies-Ursprungstest 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 überprüfen können, ob Ihr Token richtig konfiguriert ist.
2. Befestigen Sie dieses Testtoken für den Ursprung im IFrame, in dem Sie den Storage Access API-Handle verwenden möchten, mit einem HTTP-Header, einem HTML-Meta-Tag oder programmgesteuert. Das Token muss in jedem Frame eingebettet sein, in dem diese API verwendet werden soll. Wenn es nur im übergeordneten Frame eingebettet ist, wird die API nicht in untergeordneten Frames aktiviert.
Rufen Sie document.requestStorageAccess(...) auf, um das 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.
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(...).
Öffnen Sie Ihre Website und prüfen Sie, ob der Alias für den Speicherzugriff wie vorgesehen funktioniert.
Wenn Sie nicht mehr am Ursprungstest teilnehmen möchten, entfernen Sie das Token, das Sie in Schritt 3 hinzugefügt haben.
Senden Sie Feedback oder melden Sie Probleme im GitHub-Repository für die Storage Access API, bei dem es sich nicht um Cookie-Speicher handelt.

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