Get to know MDN better
Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.
Veraltet: Diese Funktion wird nicht mehr empfohlen. Obwohl einige Browser sie möglicherweise noch unterstützen, könnte sie bereits aus den relevanten Webstandards entfernt worden sein, in Kürze entfernt werden oder nur noch aus Kompatibilitätsgründen bestehen. Vermeiden Sie die Verwendung und aktualisieren Sie vorhandenen Code, falls möglich; siehe die Kompatibilitätstabelle am Ende dieser Seite, um Ihre Entscheidung zu unterstützen. Beachten Sie, dass diese Funktion jederzeit aufhören könnte zu funktionieren.
Nicht standardisiert: Diese Funktion ist nicht standardisiert. Wir raten davon ab, nicht-standardisierte Funktionen auf produktiven Webseiten zu verwenden, da sie nur von bestimmten Browsern unterstützt werden und sich in Zukunft ändern oder entfernt werden können. Unter Umständen kann sie jedoch eine geeignete Option sein, wenn es keine standardisierte Alternative gibt.
Warnung: Dieses Feature wird momentan von einem Browser-Anbieter abgelehnt. Details finden Sie im Abschnitt Standards Positionen unten.
Die Shared Storage API ist ein clientseitiger Speichermechanismus, der nicht-partitionierten, seitenübergreifenden Datenzugriff ermöglicht und zugleich die Privatsphäre wahrt (d.h. ohne auf Tracking-Cookies angewiesen zu sein).
Eine Hauptquelle von Privatsphäre- und Sicherheits-problemen im Web ist der Einsatz von Cookies, die auf Drittinhalten gesetzt werden, die auf Websites eingebettet sind (zum Beispiel über <iframe>-Elemente). Diese Cookies können verwendet werden, um Nutzer zu verfolgen und zu profilieren sowie Informationen über Sites hinweg zu teilen.
Um seitenübergreifendes Tracking zu verhindern, arbeiten Browser daran, alle Speicherarten zu partitionieren, einschließlich Cookies, Web Storage, IndexedDB und der Cache-API. Ein großes Hindernis dabei ist jedoch der Bedarf an mehreren legitimen Anwendungsfällen, die auf seitenübergreifenden Informationsaustausch angewiesen sind. Beispiele solcher Anwendungsfälle sind Werbetreibende, die die Reichweite ihrer Anzeigen über Sites hinweg messen und Berichte erzeugen möchten, und Seitenbetreiber, die Nutzererfahrungen anpassen möchten, basierend auf der Gruppe, in der sie sind, oder ihren vorherigen Interaktionen auf der Website.
Die Shared Storage API bietet eine flexible Lösung für solche Anwendungsfälle. Sie zielt darauf ab, die erforderlichen Datenspeicher-, Verarbeitungs- und Freigabefunktionen bereitzustellen, ohne dass die Möglichkeit besteht, Nutzer zu verfolgen und zu profilieren.
Wie bei anderen Speicher-APIs können Sie jederzeit auf den Shared Storage schreiben. Allerdings können Sie Shared Storage-Daten nur aus einem Worklet auslesen. Worklets bieten eine sichere Umgebung, in der Sie Shared Storage-Daten verarbeiten und nützliche Ergebnisse zurückgeben können, ohne dass Sie die Daten direkt mit dem zugehörigen Browsing-Kontext teilen können.
Um nützliche Ergebnisse aus einem Shared-Storage-Worklet zu extrahieren, müssen Sie ein Output Gate verwenden. Diese Tore dienen spezifischen Zwecken, wie z.B. der Auswahl einer URL aus einer bereitgestellten Liste, die basierend auf Shared Storage-Daten dem Nutzer angezeigt wird. Ergebnisse, die für den Nutzer bestimmt sind, werden sicher in einem fenced frame angezeigt, wo sie von der einbettenden Seite nicht abgerufen werden können.
Die derzeit verfügbaren Output Gates für die Shared Storage API werden in den folgenden Abschnitten erläutert. In jedem Abschnitt listen wir typische Anwendungsfälle für jedes Gate auf und bieten Links zu Leitfäden mit weiteren Informationen und Codebeispielen.
Hinweis: Weitere Output Gates werden voraussichtlich in Zukunft hinzugefügt, um zusätzliche Anwendungsfälle zu unterstützen.
Das URL-Auswahl-Output Gate, das über die Methode selectURL() aufgerufen wird, wird verwendet, um eine URL aus einer bereitgestellten Liste auszuwählen, die dem Nutzer basierend auf den Shared Storage-Daten angezeigt werden soll. Dieses Gate kann für folgende Zwecke verwendet werden:
Das Run-Output Gate, aufgerufen über die Methode run(), ist dazu gedacht, auf generische Weise einige Shared Storage-Daten zu verarbeiten.
Die Private Aggregation API kann das Run-Output Gate verwenden, um Shared Storage-Daten zu verarbeiten und aggregierte Berichte zu generieren. Diese Berichte können in den folgenden Anwendungsfällen verwendet werden:
Es gibt zwei Teile bei der Nutzung der Shared Storage API: das Schreiben von Daten in den Speicher und das Lesen/Verarbeiten dieser Daten. Um Ihnen eine Vorstellung davon zu geben, wie diese Teile gehandhabt werden, führen wir Sie durch das grundlegende A/B-Testing-Beispiel von developer.chrome.com. In diesem Beispiel wird ein Nutzer einer Experimentgruppe zugewiesen, und die Gruppendetails werden im Shared Storage gespeichert. Andere Sites können diese Daten verwenden, wenn sie eine URL auswählen, die in einem fenced frame angezeigt werden soll.
Das Schreiben von Daten in den Shared Storage ist einfach — Sie verwenden Methoden, die in der Schnittstelle SharedStorage definiert sind, um Daten zu setzen, anzuhängen oder zu löschen/zu leeren.
Diese Funktionalität ist in zwei verschiedenen Kontexten verfügbar:
In unserem A/B-Testing-Beispiel definieren wir eine Funktion in unserem App-Kontext, die eine Zufallszahl — 0 oder 1 — erzeugt, um eine Experimentgruppe zu repräsentieren. Anschließend führen wir die Funktion window.sharedStorage.set() aus, um den Nutzer einer Gruppe zuzuweisen und das Ergebnis im Shared Storage zu speichern:
Hinweis: Die Option ignoreIfPresent: true bewirkt, dass die Funktion set() abgebrochen wird, wenn der Shared Storage bereits ein Datenelement mit dem angegebenen Schlüssel enthält.
Wie oben erwähnt, müssen Sie, um nützliche Ergebnisse aus einem Shared Storage-Worklet zu extrahieren, ein Output Gate verwenden. In diesem Beispiel werden wir das URL-Auswahl Output Gate verwenden, um die Experimentgruppe des Nutzers zu lesen und basierend auf dieser Gruppe eine URL in einem fenced frame anzuzeigen.
Um das Output Gate zu verwenden, müssen Sie:
Im Folgenden betrachten wir diese Schritte nacheinander.
Die URL-Auswahl basiert auf der im Shared Storage gespeicherten Experimentgruppe. Um diesen Wert abzurufen und eine URL basierend darauf auszuwählen, müssen wir eine Operation in einem SharedStorageWorklet-Kontext definieren. Dies stellt sicher, dass die Rohdaten vor anderen Kontexten verborgen bleiben, wodurch die Privatsphäre gewahrt wird.
Die URL-Auswahl-Operation ist eine JavaScript-Klasse, die die folgenden Regeln einhalten muss (diese Regeln variieren je nach Output Gate, abhängig von ihrem beabsichtigten Anwendungsfall):
Hinweis: Jedes Output Gate hat eine entsprechende Schnittstelle, die die erforderliche Struktur ihrer Klasse und der Methode run() definiert. Für die URL-Auswahl siehe SharedStorageSelectURLOperation.
Sobald die Operation definiert ist, muss sie mit SharedStorageWorkletGlobalScope.register() registriert werden.
Beachten Sie, wie der im Haupt-App-Kontext gesetzte Wert mit WorkletSharedStorage.get() abgerufen wird. Um es zu wiederholen, um die Privatsphäre zu erhalten und Datenlecks zu vermeiden, können Werte aus dem Shared Storage nur innerhalb eines Worklets gelesen werden.
Hinweis: Es ist möglich, mehrere Operationen im selben Shared Storage-Worklet-Modulskript mit unterschiedlichen Namen zu definieren und zu registrieren; siehe SharedStorageOperation für ein Beispiel.
Um die im Worklet-Modul definierte Operation zu verwenden, muss sie mit window.sharedStorage.worklet.addModule() zum Shared Storage-Worklet hinzugefügt werden. In unserem Haupt-App-Kontext geschieht dies, bevor wir den Experimentgruppenwert setzen, sodass er bereit ist, wenn er benötigt wird:
Um die im Worklet definierte Operation auszuführen, rufen wir WindowSharedStorage.selectURL() auf. Diese Methode fungiert als Proxy für unsere Worklet-Operation, greift sicher darauf zu und gibt das Ergebnis zurück, ohne irgendwelche Daten zu leaken. selectURL() ist die korrekte Methode, um unsere benutzerdefinierte Worklet-Operation aufzurufen, da sie mit der entsprechenden Klassenstruktur für eine URL-Auswahloperation definiert wurde, wie oben erläutert.
selectURL() erwartet ein Array von Objekten, die URLs zur Auswahl enthalten, ein optionales Optionsobjekt, und dass die zugrundeliegende Operation eine Ganzzahl zurückgibt, die sie zur Auswahl einer URL verwenden kann.
Da das Optionsobjekt resolveToConfig: true enthält, wird das zurückgegebene Promise mit einem FencedFrameConfig-Objekt aufgelöst. Dieses Objekt kann als Wert der Eigenschaft HTMLFencedFrameElement.config gesetzt werden, sodass der Inhalt der gewählten URL im entsprechenden <fencedframe>-Element angezeigt wird:
Das vollständige App-Script sieht folgendermaßen aus:
Der Hauptunterschied besteht darin, dass Shared Storage für die Verwendung mit seitenübergreifenden Daten gedacht ist, nachdem die Speicherung partitioniert wurde.
Ein weiterer wichtiger Unterschied zwischen Shared Storage und Web Storage besteht darin, dass das Lesen aus dem Shared Storage geschützt ist (das Schreiben funktioniert ähnlich). Mit localStorage und sessionStorage können Sie frei lesen. Mit Shared Storage kann das Lesen nur innerhalb eines Shared Storage-Worklets geschehen, und der Ursprung, der im Worklet zum Lesen verwendet wird, ist derselbe wie der Browsing-Kontext, der es erstellt hat.
Außerdem können Sie Daten aus dem Shared Storage nicht außerhalb eines Shared Storage-Worklets extrahieren, als Schutz vor Tracking. Sie müssen eines der Output Gates verwenden, um mit Ihren Daten im Shared Storage zu arbeiten.
Zuletzt bleiben Daten in localStorage bestehen, bis sie manuell gelöscht werden. sessionStorage wird am Ende einer Browsersitzung gelöscht, während Shared Storage-Daten 30 Tage nach dem letzten Schreibaufruf gelöscht werden.
Repräsentiert den Shared Storage für einen bestimmten Ursprung. Es definiert Methoden zum Schreiben von Daten in den Shared Storage.
WindowSharedStorageRepräsentiert den Shared Storage für einen bestimmten Ursprung, wie er in einem Standard-Browsing-Kontext bereitgestellt wird. Unter anderem definiert es Methoden zur Nutzung der verfügbaren Output Gates, die als Proxys für die im Worklet definierten Operationen dienen.
WorkletSharedStorageRepräsentiert den Shared Storage für einen bestimmten Ursprung innerhalb eines Worklet-Kontexts. Unter anderem definiert es Methoden zum Lesen der Shared Storage-Daten.
SharedStorageWorkletRepräsentiert das Shared Storage-Worklet des aktuellen Ursprungs. Es enthält die Methode addModule() zum Hinzufügen von Modulen. Im Gegensatz zu einem regulären Worklet kann das SharedStorageWorklet aus Datenschutzgründen nur ein einziges Modul hinzugefügt werden.
SharedStorageWorkletGlobalScopeRepräsentiert den globalen Bereich eines SharedStorageWorklet-Moduls. Es enthält die Funktionalität, eine definierte Operation zu registrieren und auf den Shared Storage zuzugreifen.
Repräsentiert die Basisklasse für alle unterschiedlichen Output Gate-Operationstypen.
SharedStorageRunOperationRepräsentiert eine Run-Output-Gate-Operation.
SharedStorageSelectURLOperationRepräsentiert eine URL-Auswahl-Output-Gate-Operation.
Gibt das WindowSharedStorage-Objekt für den aktuellen Ursprung zurück.
Um die Shared Storage API in Ihren Sites zu verwenden, müssen Sie sie im Privacy Sandbox-Einschreibungsprozess spezifizieren. Wenn Sie dies nicht tun, werden die Methoden der Shared Storage API nicht erfolgreich ausgeführt.
Sie können Ihren Shared Storage API-Code lokal testen, ohne sich einzuschreiben. Um lokale Tests zu ermöglichen, aktivieren Sie das folgende Chrome-Entwickler-Flag:
chrome://flags/#privacy-sandbox-enrollment-overrides
Für ausführliche Demos siehe die Shared Storage API-Demoseite, die auch einige Beispiele der Private Aggregation API enthält.
Ein Browser-Anbieter lehnt diese Spezifikation ab. Bekannte Standards Positionen sind wie folgt:
JavaScript aktivieren, um diese Browser-Kompatibilitätstabelle anzuzeigen.
Der Bauplan für ein besseres Internet.
Besuche die gemeinnützige Muttergesellschaft der Mozilla Corporation, die Mozilla Foundation.
Teile dieses Inhalts sind ©1998–2026 von einzelnen mozilla.org-Mitwirkenden. Inhalte sind verfügbar unter einer Creative-Commons-Lizenz.