Browser-Speicher-Fingerprinting pflanzt Identifier in localStorage, sessionStorage, IndexedDB und HTTP-Cookies — und überlebt damit Cookie-Löschung durch Redundanz über viele Speicherschichten. Die bekannteste Umsetzung, Evercookie, nutzt bis zu 16 gleichzeitige Speichervektoren. Nach der DSGVO ist das Setzen solcher Tracker ohne Einwilligung in der EU grundsätzlich unzulässig.
Die Speicherschichten
localStorage und sessionStorage
Die einfachste Methode: Ein UUID wird in localStorage gespeichert und bei jedem Besuch gelesen. sessionStorage überlebt nur die aktuelle Sitzung, kann aber mit localStorage synchronisiert werden.
// Identifier anlegen oder abrufen
let userId = localStorage.getItem('_uid');
if (!userId) {
userId = crypto.randomUUID();
localStorage.setItem('_uid', userId);
}IndexedDB
IndexedDB bietet eine strukturierte Datenbank im Browser — persistenter als Cookies und schwieriger zu löschen, da viele Nutzer nicht wissen, wo sie IndexedDB-Daten finden und löschen können.
HTTP-Cookies
Klassische Tracking-Cookies mit HttpOnly, Secure und langem Max-Age. Unter Druck durch Cookie-Banner und DSGVO, aber technisch noch immer das verbreitetste Tracking-Mittel.
Cache Storage / Service Worker
Ein Service Worker kann Identifier im Cache API speichern — dieser überlebt das Löschen von Cookies in manchen Browser-Implementierungen.
Evercookie: 16 Speichervektoren
Evercookie, entwickelt von Samy Kamkar, kombiniert alle verfügbaren Speichermechanismen simultan. Wird einer gelöscht, werden alle anderen verwendet, um ihn wiederherzustellen:
- HTTP-Cookies
- localStorage
- sessionStorage
- IndexedDB
- WebSQL (veraltet, aber teilweise noch implementiert)
- Flash-Cookies (LSO) — heute weitgehend tot
- Canvas-Fingerprint als Identifier
- PNG-Pixel (RGB-kodierter Identifier im Cache)
- ETag-basiertes Caching
- HTTP Strict Transport Security (HSTS) Supercookie
- … und weitere
IndexedDB-Sicherheitslücke: CVE-2026-6770
Eine unter CVE-2026-6770 erfasste Lücke erlaubte Timing-Angriffe auf IndexedDB, um den genauen RAM-Wert eines Geräts zu ermitteln. Die Lücke wurde in Firefox 150 und Tor Browser 15.0.10 geschlossen. Sie zeigt, dass Speicher-APIs auch als Seitenkanal für Hardware-Fingerprinting genutzt werden können — weit über ihre eigentliche Funktion als Identifier-Speicher hinaus.
Firefox Total Cookie Protection
Firefox isoliert seit Version 86 alle Cookies und Speicher-APIs pro Website in separate „Cookie-Jars". Ein Tracker kann localStorage-Werte, die er auf Website A gesetzt hat, nicht auf Website B lesen — selbst wenn beide Sites denselben Tracker-Code einbinden. Dies ist derzeit der stärkste Schutz gegen Browser-Speicher-Fingerprinting im Mainstream-Browser.
DSGVO und Datenschutz
Das Setzen von Tracking-Cookies ohne ausdrückliche Einwilligung verstößt gegen § 25 TTDSG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz) in Deutschland und Art. 5 Abs. 3 der ePrivacy-Richtlinie in der EU. Evercookie-ähnliche Techniken, die Cookie-Löschung aktiv umgehen, sind nach Ansicht des Europäischen Datenschutzausschusses (EDPB) nicht durch berechtigte Interessen rechtfertigbar und erfordern ausdrückliche Einwilligung.
Schutzmaßnahmen
- Firefox: Total Cookie Protection (standardmäßig aktiv seit Firefox 86) isoliert alle Speicher-APIs pro Website-Ursprung.
- Brave Browser: Aktiviert Ephemeral Storage standardmäßig — alle Speicher werden beim Schließen des Tabs gelöscht.
- Tor Browser: Löscht alle Speicher-Daten nach jeder Sitzung; keine persistente Speicherung über Sitzungen hinweg.
- Cookie-Isolation + regelmäßiges Löschen: Kombiniert mit uBlock Origin reduziert dies die Überlebensdauer von Storage-Trackern erheblich.
Verwandte Signale
Browser-Speicher-Fingerprinting ist am effektivsten in Kombination mit cookie-freiem Canvas-Fingerprinting. Während Canvas-Fingerprinting den Nutzer gerätebasiert erkennt, ermöglicht Storage-Fingerprinting die persistente Speicherung dieser Identität. Prüfen Sie Ihren Datenschutz mit unserem Fingerprint-Tool.
