Speicher und Cookies

Erweiterungen können ähnlich wie normale Websites Cookies speichern und auf Web Storage APIs zugreifen. Manchmal verhalten sich diese Elemente in Erweiterungen jedoch anders.

Informationen zur Erweiterungs-API findest du unter chrome.storage.

Speicher

Es ist oft wünschenswert, Speicher-APIs von Webplattformen in Erweiterungen zu verwenden. In diesem Abschnitt wird das Verhalten dieser APIs in einem Erweiterungskontext untersucht. Das Verhalten im Web kann sich dabei manchmal unterscheiden.

Persistenz

Der Erweiterungsspeicher wird nicht gelöscht, wenn ein Nutzer Browserdaten löscht. Dies gilt für alle Daten, die mit Web Storage-APIs (z. B. Local Storage und IndexedDB) gespeichert werden.

Erweiterungen unterliegen standardmäßig den normalen Speicherkontingentbeschränkungen. Diese können durch Aufrufen von navigator.storage.estimate() überprüft werden. Speicher kann auch unter hoher Speicherauslastung entfernt werden. Dies kommt jedoch selten vor. So kannst du das vermeiden:

  • Fordern Sie die Berechtigung "unlimitedStorage" an. Diese wirkt sich sowohl auf Erweiterungs- als auch auf Webspeicher-APIs aus und befreit Erweiterungen sowohl von Kontingentbeschränkungen als auch von der Bereinigung.
  • Rufen Sie navigator.storage.persist() an, um sich vor einer Bereinigung zu schützen.

Der Erweiterungsspeicher wird vom Ursprung der Erweiterung gemeinsam genutzt, einschließlich des Service Workers der Erweiterung, aller Erweiterungsseiten (einschließlich Pop-ups und Seitenleiste) und nicht sichtbaren Dokumenten. In Inhaltsskripts wird beim Aufrufen von Web Storage-APIs auf Daten von der Hostseite zugegriffen, auf der das Inhaltsskript eingeschleust wird, und nicht von der Erweiterung.

Zugriff in Service Workern

Die APIs IndexedDB und Cache Storage sind über Service Worker zugänglich. Lokaler Speicher und Sitzungsspeicher hingegen nicht.

Wenn Sie über den Service Worker auf den lokalen Speicher oder Sitzungsspeicher zugreifen müssen, verwenden Sie ein Offscreen-Dokument.

Partitionierung

Bei der Partitionierung werden Schlüssel für gespeicherte Daten eingeführt, um den Zugriff auf diese einzuschränken. Der Speicher wurde in der Vergangenheit nach Ursprung verschlüsselt.

Ab Chrome 115 führt die Speicherpartitionierung Änderungen an der Definition von Partitionierungsschlüsseln zum Einsatz, um bestimmte Arten von websiteübergreifendem Tracking zu verhindern. In der Praxis bedeutet dies, dass Website B nicht auf denselben Speicher zugreifen kann, wenn Website A einen iFrame einbettet, der Website B enthält.

Um diese Auswirkungen bei Erweiterungen abzuschwächen, gelten zwei Ausnahmen:

  • Wenn eine Seite mit dem Schema chrome-extension:// in eine Website eingebettet ist, findet keine Speicherpartitionierung statt und die Erweiterung hat Zugriff auf ihre Partition auf oberster Ebene.
  • Wenn eine Seite mit dem Schema chrome-extension:// einen iFrame enthält und die Erweiterung Hostberechtigungen für die eingebettete Website hat, hat diese Website auch Zugriff auf ihre Partition auf oberster Ebene.

Kekse

Cookies bieten eine Möglichkeit zum Speichern von Schlüssel/Wert-Paaren, die einer bestimmten Domain und einem bestimmten Pfad zugeordnet sind. Sie sind bei Erweiterungen nur begrenzt nützlich. Es kann aber hilfreich sein, ihr Verhalten zu verstehen, wenn Sie einen bestimmten Anwendungsfall haben oder ein Drittanbieterskript gebündelt haben, das sie in der Implementierung verwendet.

Sichere Cookies

Das Cookie-Attribut Secure wird nur für das https://-Schema unterstützt. Daher können Seiten auf chrome-extension:// keine Cookies mit diesem Attribut setzen.

Das bedeutet auch, dass Erweiterungsseiten keine anderen Cookie-Attribute verwenden können, bei denen das Attribut Secure erforderlich ist:

Partitionierung und SameSite-Verhalten

Für Cookies, die auf „chrome-extension://“-Seiten gesetzt werden, wird immer SameSite=Lax verwendet. Folglich kann auf Cookies, die von einer Erweiterung selbst gesetzt werden, nie in Frames zugegriffen werden und die Partitionierung ist nicht relevant.

Bei Cookies, die mit Websites von Drittanbietern verknüpft sind, z. B. für eine Drittanbieterwebsite, die in einen Frame auf einer Erweiterungsseite geladen wird, oder eine Anfrage von einer Erweiterungsseite an den Ursprung eines Drittanbieters verhalten sich Cookies wie das Web, allerdings in zweierlei Hinsicht:

  • Drittanbieter-Cookies werden auch dann niemals in Subframes blockiert, wenn die Seite der obersten Ebene für einen bestimmten Tab eine chrome-extension://-Seite ist.
  • Anfragen von einer Erweiterung an einen Drittanbieter werden als dieselbe Website behandelt, wenn die Erweiterung Hostberechtigungen für den Drittanbieter hat. Das bedeutet, dass SameSite=Strict Cookies gesendet werden können. Dies gilt nur für Netzwerkanfragen, nicht für den Zugriff über document.cookie in JavaScript und nicht, wenn Drittanbieter-Cookies blockiert werden.

Die Einstellungen für Drittanbieter-Cookies werden von der Privacy Sandbox beeinflusst und entsprechend dem Zeitplan angepasst.

Die chrome.cookies API bietet Kontrolle über den Partitionsschlüssel, der mit jeder API-Methode verwendet werden soll. Weitere Informationen findest du in der API-Referenz.