Browser-Fingerprinting ohne Cookies: Was die GDPR tatsächlich zulässt
Die meisten Plattformen zur Einwilligungsverwaltung basieren auf Cookies. Das Einwilligungsbanner wird angezeigt, der Nutzer klickt darauf, und die CMP setzt oder verweigert document.cookie schreibt. Diese Architektur schafft einen systematischen blinden Fleck: Browser-Fingerprinting-Techniken, die den Cookie-Speicher nie berühren, werden routinemäßig vor, während und nach der Einwilligungsinteraktion eingesetzt – und Rechtsabteilungen haben oft keinerlei Einblick in diese.
Die technische Anatomie des Cookie-freien Fingerprintings
Drei APIs dominieren moderne Fingerprinting-Stacks gerade deshalb, weil sie Identifikatoren mit hoher Entropie ohne Speicherbedarf erzeugen:
Canvas-Fingerprinting
Ein Skript zeichnet Text oder Formen in ein Off-Screen-Element <canvas> Element über die Canvas-2D-API und liest dann die Pixeldaten mithilfe von canvas.toDataURL() oder ctx.getImageData(). Unterschiede bei GPU-Treibern, Anti-Aliasing-Implementierungen und der Schriftartendarstellung erzeugen einen gerätespezifischen Hash. Der Vorgang läuft im Hintergrund ab – es gibt keinen Set-Cookie Header, kein localStorage Schreibvorgang, nichts im Speicherinspektor des Browsers.
AudioContext-Fingerprinting
Der OfflineAudioContext verarbeitet ein synthetisches Audiosignal (typischerweise einen Oszillator durch einen Kompressorknoten). Die über getChannelData(), unterscheidet sich geringfügig je nach Hardware und Implementierung des Betriebssystem-Audio-Stacks. Diese Abweichung liefert, wenn sie gehasht wird, eine stabile sekundäre Entropiequelle, die das Löschen von Cookies, den privaten Modus und die Nutzung von VPNs überdauert.
WebGL-Fingerprinting
WEBGL_debug_renderer_info gibt den GPU-Hersteller-String und den Renderer-String direkt über gl.getParameter(). In Kombination mit den Ausgabedaten der WebGL-Shader-Ausführung – die je nach Treiberversion variieren – ergibt dies eines der individuellen Signale mit der höchsten Entropie, die im Browserkontext verfügbar sind. Browser wie Firefox haben begonnen, hier gefälschte Zeichenfolgen zurückzugeben, aber die Mehrheit der Chrome-basierten User-Agents gibt nach wie vor echte Werte preis.
In Kombination mit Navigator-Eigenschaften (navigator.hardwareConcurrency, navigator.deviceMemory), der Bildschirmgeometrie, der Zeitzonenverschiebung und der Auflistung installierter Schriftarten über CSS oder Canvas erreichen diese Signale regelmäßig Wiedererkennungswahrscheinlichkeiten, die diejenigen von Drittanbieter-Cookies für Desktop-Nutzer ohne VPN übersteigen.
Warum „Kein Cookie = keine Einwilligung erforderlich“ ein juristischer Mythos ist
Die entscheidende Bestimmung der DSGVO ist keine, in der Cookies überhaupt erwähnt werden. Artikel 5 Absatz 1 Buchstabe a verlangt, dass die Verarbeitung rechtmäßig, fair und transparent ist. Artikel 6 verlangt eine rechtmäßige Grundlage für jede Verarbeitung personenbezogener Daten – und ein Browser-Fingerabdruck, der eine natürliche Person wiederidentifizieren kann, ist eindeutig eine personenbezogene Angabe im Sinne von Artikel 4 Absatz 1.
Die ePrivacy-Richtlinie (2002/58/EG), Artikel 5 Absatz 3 – in der Umsetzung in nationales Recht – verlangt eine vorherige informierte Einwilligung für die Speicherung von Informationen auf oder den Zugriff auf Informationen von den Endgeräten eines Nutzers. Das Urteil des EuGH in der Rechtssache C-673/17 (Planet49) bestätigte, dass diese Verpflichtung nicht auf Cookies beschränkt ist: Der Begriff „bereits gespeicherte Informationen“ in Endgeräten umfasst jegliches Auslesen des Gerätestatus, einschließlich Fingerabdrucksignale, die aus der Hardware- und Softwarekonfiguration abgeleitet werden.
Die Leitlinien 05/2020 des EDPB zur Einwilligung bekräftigen dies: Die Einwilligung muss spezifisch, in Kenntnis der Sachlage, eindeutig und freiwillig erteilt sein. Fingerprinting, das vor oder unabhängig von einem Einwilligungssignal erfolgt, erfüllt keines der vier Kriterien gleichzeitig.
Ein erwähnenswerter Präzedenzfall: Die französische CNIL hat sich in ihren Cookie-Leitlinien ausdrücklich mit Fingerprinting befasst und festgestellt, dass das Auslesen von Geräteeigenschaften zur Erstellung eines Identifikators unter Artikel 5 Absatz 3 der ePrivacy-Richtlinie fällt und eine Einwilligung erfordert, die der für Cookies erforderlichen gleichwertig ist. Die Position der ICO ist im Wesentlichen identisch.
Die Sackgasse des berechtigten Interesses
Betreiber argumentieren manchmal, dass Fingerprinting zur Betrugsaufdeckung oder zu Sicherheitszwecken unter Artikel 6 Absatz 1 Buchstabe f – berechtigte Interessen – fällt und keine Einwilligung erfordert. Dieses Argument ist enger gefasst, als es scheint.
Die Analyse des EuGH in der Rechtssache C-252/21 (Meta/Bundeskartellamt) konzentrierte sich zwar auf Verhaltensprofilierung, stellte jedoch fest, dass die Grundlage des berechtigten Interesses eine echte Abwägungsprüfung erfordert, bei der die berechtigten Erwartungen der betroffenen Person gegen das Interesse des Verantwortlichen abgewogen werden. Von Nutzern, denen nicht mitgeteilt wurde, dass ihre GPU-Renderer-Zeichenkette gehasht wird, um einen dauerhaften Identifikator zu erstellen, kann vernünftigerweise nicht erwartet werden, dass sie dies erwartet haben.
Entscheidend ist der Umfang des Fingerprintings. Die Verwendung eines minimalen Gerätesignals (z. B. IP-Adresse in Kombination mit User-Agent) für die Echtzeit-Betrugsbewertung während einer Transaktion ist unter dem Gesichtspunkt berechtigter Interessen vertretbar. Die Erstellung eines dauerhaften, sitzungsübergreifenden Fingerabdruck-Hashes, der serverseitig gespeichert und für Verhaltensanalysen verwendet wird, ist ein wesentlich anderer Vorgang – einer, der unabhängig von der zur Erfassung verwendeten technischen Methode eine Einwilligung erfordert.
Was ist ohne Einwilligung tatsächlich zulässig
Es gibt enge, operativ reale Anwendungsfälle, in denen das Auslesen von Signalen aus Endgeräten ohne Einwilligung rechtmäßig ist:
- Unbedingt notwendige Sicherheitsmaßnahmen: Das Auslesen der IP-Adresse, des TLS-Fingerabdrucks (JA3/JA4-Hash, der serverseitig aus dem ClientHello generiert wird) und von HTTP-Headern, einschließlich
User-Agentzur Bot-Erkennung auf Basis einzelner Anfragen, ohne Persistenz über die Sitzung hinaus, ist vertretbar. Die wesentliche Einschränkung ist, dass keine sitzungsübergreifende Re-Identifizierung stattfindet. - Signale auf Netzwerkebene: DNS-Abfragemuster, TCP/IP-Stack-Fingerprinting und die Analyse des TLS-Handshakes finden statt, bevor JavaScript ausgeführt wird, und stellen keinen „Zugriff auf in Endgeräten gespeicherte Informationen“ im Sinne von Artikel 5 Absatz 3 der ePrivacy-Verordnung dar. Sie fallen ausschließlich unter Artikel 6 der DSGVO, und die vorübergehende Verarbeitung aus Sicherheitsgründen kann auf berechtigten Interessen mit einer dokumentierten Abwägungsprüfung beruhen.
- Nur serverseitige Signale: Wenn auf dem Client keine JavaScript-API aufgerufen wird und die Identifizierung ausschließlich auf vom Server empfangenen Headern beruht, findet Artikel 5 Absatz 3 der ePrivacy-Verordnung keine Anwendung. Die DSGVO gilt weiterhin, aber die Analyse der Rechtsgrundlage ist klarer.
Praktische Prüfungscheckliste für Datenschutzbeauftragte und technische Leiter
- Erfassen und überprüfen Sie Ihr eigenes JavaScript: Verwenden Sie einen Browser mit einem Endpunkt für die Content Security Policy und prüfen Sie alle Skripte auf Aufrufe von
HTMLCanvasElement.toDataURL,OfflineAudioContext,WEBGL_debug_renderer_info, undnavigator.hardwareConcurrency. Tools wie fp-detective oder ein benutzerdefinierter Puppeteer-basierter Scanner können dies in großem Maßstab über Ihre gesamte Subdomain-Landschaft hinweg automatisieren. - Prüfen Sie die Nutzdaten von Tags von Drittanbietern: Tag-Manager laden Skripte von Anbietern, die von den Verantwortlichen nie geprüft werden. Die Tatsache, dass ein Fingerprinting-Aufruf aus einem Analytics-SDK stammt, entbindet den Verantwortlichen gemäß Artikel 28 nicht von seiner Haftung. Verlangen Sie von Ihren Anbietern, dass sie den gesamten Zugriff auf Endgeräte in ihren DPA-Anhängen angeben.
- Prüfen Sie auf Ausführung vor der Einwilligung: Eine Netzwerk-Timing-Analyse sollte bestätigen, dass kein Fingerprinting-Skript ausgeführt wird, bevor ein gültiges Einwilligungssignal empfangen wurde. Dies unterscheidet sich vom Laden der CMP – das CMP-JavaScript selbst darf vor der Einwilligung kein Fingerprinting durchführen.
- Dokumentieren Sie Ihre Abwägungsprüfung: Wenn Sie sich bei der Verarbeitung von Gerätesignalen auf berechtigte Interessen stützen, erstellen Sie eine schriftliche Abwägungsprüfung, in der die spezifischen Signale, der Verarbeitungszweck, die Aufbewahrungsfrist und das Ergebnis der Abwägung genannt werden. Eine allgemeine LIA, die „Betrugsbekämpfung“ abdeckt, ist unzureichend.
- Beziehen Sie Fingerprinting in Ihre ROPA ein: Die Aufzeichnungen gemäß Artikel 30 müssen die tatsächlichen Verarbeitungsaktivitäten widerspiegeln. Eine ROPA, die „Cookies“ aufführt, aber die Canvas-/WebGL-basierte Re-Identifizierung auslässt, ist unvollständig und birgt regulatorische Risiken.
Die erforderliche Umstellung der Compliance-Architektur
Das grundlegende Problem besteht darin, dass die meisten Einwilligungsarchitekturen eher speicherzentriert als verarbeitungszentriert sind. Die DSGVO ist ein Verarbeitungsgesetz. Der Auslöser für die Einwilligung muss an den Vorgang der Erhebung und Verarbeitung identifizierender Signale geknüpft sein – nicht an den Vorgang des Schreibens in den Cookie-Speicher.
CMPs müssen die Blockierung der JavaScript-Ausführung auf API-Aufrufebene durchsetzen, nicht nur auf der Ebene des Schreibvorgangs in den Cookie-Speicher. Dies bedeutet, browser-native Techniken zu nutzen, wie z. B. das Überschreiben HTMLCanvasElement.prototype.toDataURL , um vor der Einwilligung einen neutralen Wert zurückzugeben, oder die Nutzung von Service-Worker-Interception, um das Laden von Fingerprinting-Skripten vollständig zu unterbinden, bis ein gültiges Einwilligungssignal in localStorage oder über einen postMessage Kanal aus dem CMP-Iframe übermittelt wird.
Die Betreiber, die Fingerprinting als zustimmungsfreien Fallback behandeln, wenn die Cookie-Zustimmung verweigert wird, befinden sich nicht in einer Grauzone. Sie verarbeiten personenbezogene Daten ohne rechtmäßige Grundlage – und die technische Raffinesse der Methode mindert das rechtliche Risiko nicht, sondern verstärkt es.
Dieser Artikel wurde mit Unterstützung von KI erstellt und redaktionell geprüft. Rechtliche Fragen sollten stets mit einem qualifizierten Datenschutzexperten besprochen werden.