Jenseits des Cookies: Local Storage, Session Storage und IndexedDB

Du klickst auf „Ablehnen“, die Cookie-Liste bleibt kurz – und beim nächsten Besuch erkennt dich die Website trotzdem wieder. Kein Cookie im Spiel, kein Eintrag in der Übersicht, und in vielen Prüfberichten kommt die Kennung schlicht nicht vor. Sie liegt im Local Storage.

Das ist keine Lücke im Gesetz, sondern eine Lücke in der Prüfroutine: Cookies sind nur eine von mehreren Schubladen, in die eine Website etwas legen kann. Die Regel dahinter interessiert sich für die Schublade nicht.

§ 25 Absatz 1 TDDDG knüpft die Einwilligung an zwei Vorgänge: „die Speicherung von Informationen in der Endeinrichtung des Endnutzers“ und „den Zugriff auf Informationen, die bereits in der Endeinrichtung gespeichert sind“. Das Wort Cookie kommt in der Vorschrift nicht vor. Absatz 2 nennt die Ausnahmen – Übertragung einer Nachricht und das, was für einen ausdrücklich gewünschten Dienst unbedingt erforderlich ist.

Der Europäische Datenschutzausschuss hat diese Technologieoffenheit ausbuchstabiert: In den Leitlinien 2/2023 zum technischen Anwendungsbereich von Art. 5 Abs. 3 der ePrivacy-Richtlinie, Endfassung von Oktober 2024, stehen Browser-Speicher neben Tracking-Pixeln, URL-Parametern, eindeutigen Kennungen und lokal im Browser verarbeiteten Daten. Auch die Orientierungshilfe der deutschen Aufsichtsbehörden für Anbieter digitaler Dienste nennt Local Storage und Session Storage ausdrücklich neben Cookies.

Technisch sind das getrennte Baustellen mit unterschiedlichem Verhalten:

Der letzte Punkt der Liste ist der entscheidende. Ein Cookie hängt sich von allein an jede Anfrage an die passende Domain – im Netzwerk-Tab siehst du es im Kopf der Anfrage stehen. Local Storage, Session Storage und IndexedDB verlassen den Browser nie von allein. Damit ein Wert dort ankommt, muss ein Skript ihn auslesen und in eine Anfrage schreiben.

Für die Prüfung heißt das: Wer nur auf den Netzwerkverkehr schaut, sieht im besten Fall die Folge, nie den Eintrag selbst. Und wenn das Skript die Kennung erst später verschickt – beim nächsten Seitenaufruf, beim nächsten Klick, oder erst nach der Einwilligung –, dann ist im Netzwerk-Tab gar nichts zu sehen, obwohl längst geschrieben wurde.

Der Browser-Speicher ist erst einmal ein normales Werkzeug: Warenkorb-Zwischenstände, die gewählte Sprache, ein Formular, das den Reload überlebt. Wiedererkennungs-relevant wird es bei anderen Einträgen – einer Besucher- oder Geräte-ID, der zugewiesenen Variante eines A/B-Tests, dem Puffer eines Session-Recordings, gesammelten Ereignissen, die gebündelt abgeschickt werden. Und in fast jedem Setup liegt dort auch die Einwilligungsentscheidung selbst.

Der Zweck entscheidet, nicht die Schublade. Die gespeicherte Einwilligung ist genau der Eintrag, ohne den deine Entscheidung beim nächsten Klick verloren wäre. Eine ID, mit der Statistik oder Werbung dich wiedererkennt, ist etwas anderes – auch wenn beide im selben Local Storage stehen. Wo die Grenze in deinem Fall verläuft, ist eine Frage für deine Datenschutzberatung; was tatsächlich geschrieben wird, kannst du selbst nachsehen.

Die Browser-Hersteller haben auf Wiedererkennung über Web Storage reagiert. Safari löscht seit 2020 sämtlichen per Skript beschreibbaren Speicher, wenn eine Website sieben Tage lang ohne Interaktion bleibt – Local Storage, Session Storage, IndexedDB und Service-Worker-Registrierungen inbegriffen. Firefox trennt den Speicher seit Version 103 standardmäßig nach der Seite obendrüber, sodass ein eingebetteter Dienst auf zwei Websites zwei getrennte Ablagen sieht statt einer gemeinsamen; Chrome macht das für eingebettete Dritt-Kontexte seit 2023 ebenfalls.

Das begrenzt die Reichweite von Wiedererkennung, beantwortet aber eine andere Frage als die aus § 25: ob der Eintrag vor der Einwilligung überhaupt geschrieben werden durfte. Und als Prüfergebnis taugt es nicht, weil jeder Browser anders aufräumt – was in Safari nach einer Woche verschwindet, liegt in Chrome noch da.

Zwei Muster tauchen dabei immer wieder auf. Das erste: Das Consent-Tool blockiert externe Skripte nach Kategorie und wartet damit brav auf die Einwilligung – der selbst geschriebene Code auf der Seite tut das nicht und legt seine ID sofort ab. Das zweite: Beim Klick auf „Ablehnen“ werden Cookies gelöscht, die Speicher-Einträge bleiben stehen. Beim nächsten Aufruf liest das Skript dieselbe Kennung wieder aus – und das ist der zweite Vorgang aus § 25, der Zugriff auf bereits gespeicherte Informationen.

Beides fällt in einer Cookie-Liste nicht auf. Sie ist nach dem benannt, was sie zeigt.

Öffne deine Website in einem privaten Fenster und dann die Entwicklerwerkzeuge. Im Bereich für Anwendungsdaten liegen Local Storage, Session Storage und IndexedDB direkt neben den Cookies. Prüf in denselben drei Phasen, in denen du auch Cookies prüfst:

Erstens vor jeder Interaktion mit dem Banner – notier, welche Einträge schon da sind. Zweitens nach dem Klick auf „Ablehnen“, am besten mit einem Reload: Was ist verschwunden, was nicht, was ist neu dazugekommen? Drittens nach dem Annehmen, als Vergleichsmaßstab dafür, was das Setup überhaupt schreibt. Interessant sind vor allem Werte, die aussehen wie eine Kennung – lange Zufallsfolgen, Zeitstempel, wiederkehrende Zahlen – und die zwischen zwei privaten Fenstern gleich bleiben.