Canvas-Fingerprinting jenseits der Grundlagen: Warum zwei identische Chromes unterschiedliche Pixel rendern

Canvas-Fingerprinting ist seit 2012 im Produktionseinsatz. Die Idee ist simpel: Der Browser wird angewiesen, 2D-Inhalte zu rendern, die Pixel werden ausgelesen und gehasht. Verschiedene Geräte erzeugen für dieselben Anweisungen leicht unterschiedliche Pixel, und diese Unterschiede sind stabil genug, um ein Gerät über Sessions hinweg zu identifizieren.

So weit ist das bekannt. Weniger verstanden ist, warum die Technik funktioniert — warum identische Software-Konfigurationen auf identischer Hardware trotzdem unterschiedliche Pixel-Ausgaben erzeugen. Die Antwort liegt an der Schnittstelle von GPU-Treibern, Font-Rendering und Gleitkomma-Arithmetik.

Die Rendering-Pipeline ist nicht deterministisch

Wenn JavaScript context.fillText("Cwm fjord bank glyphs vext quiz", 4, 45) aufruft, rendert Chrome die Pixel nicht selbst. Es erzeugt Anweisungen für Skia — die 2D-Grafikbibliothek —, die wiederum Zeichenbefehle an ein GPU-beschleunigtes Backend ausgibt (üblicherweise ANGLE unter Windows, Metal unter macOS oder der Software-Fallback in Containern).

Bei jedem Schritt summieren sich kleine Implementierungsunterschiede:

• Skias Font-Subsystem wählt eine Schriftfamilie aus. Ist Arial nicht installiert, greift der Fallback — und der Fallback variiert je nach den im System installierten Schriften.

• Die gewählte Schrift wird in der angeforderten Größe mit FreeType (unter Linux), DirectWrite (unter Windows) oder Core Text (unter macOS) gerendert. Jede Bibliothek hat andere Hinting-Algorithmen.

• Subpixel-Positionierung wird angewendet. Hier beginnen identische Schriften, unterschiedliche Pixel zu erzeugen — der Algorithmus rundet Positionen auf fraktionale Pixel-Offsets, und die Rundungsregeln unterscheiden sich zwischen den Plattformen.

• Der gerasterte Text wird auf die Canvas komponiert. Das Blending erfolgt auf hardware-beschleunigten Systemen über GPU-Shader, im Fallback-Modus über CPU-Code.

Jeder dieser Schritte kann Unterschiede von ein oder zwei Pixelwerten einführen. Einzeln unsichtbar. Zusammengenommen einzigartig.

GPU-Treiberversionen dominieren den Fingerprint

Zwei Windows-11-Maschinen mit Intel-UHD-Graphics-620-Chips können unterschiedliche Canvas-Ausgaben erzeugen, wenn sich ihre GPU-Treiber unterscheiden. Intel liefert mehrmals pro Jahr Treiber-Updates aus, und jedes Update kann Subpixel-Filterung, Gammakorrektur und Text-Anti-Aliasing verändern.

Das bedeutet: Die Stabilität des Canvas-Fingerprints ist durch die Frequenz der Treiber-Updates begrenzt. Ein Nutzer, der seinen Grafiktreiber aktualisiert — oft still, per Windows Update —, sieht seinen Canvas-Fingerprint wechseln.

Erkennungssysteme begegnen dem, indem sie den Canvas-Fingerprint als eines von vielen Signalen behandeln, nicht als eigenständigen Identifikator. Ändert er sich, während andere Signale stabil bleiben (TLS-Fingerprint, WebGL-Renderer, Zeitzone, installierte Schriften), wird der Besucher weiterhin wiedererkannt.

Emoji-Rendering ist eine Goldgrube

Das identifizierendste Element eines Canvas-Fingerprints ist oft weder Text noch Formen, sondern Emoji. Das Emoji-Rendering hängt vom Emoji-Font ab, den das OS mitliefert — Segoe UI Emoji unter Windows, Apple Color Emoji unter macOS, Noto Color Emoji unter Android.

Selbst innerhalb eines einzelnen OS ändert sich das Emoji-Rendering über Versionen hinweg. Windows 10 rendert ein Regenbogen-Emoji anders als Windows 11. Das grinsende Gesicht von iOS 16 hat ein anderes Anti-Aliasing als das von iOS 17.

Moderne Canvas-Fingerprinting-Skripte rendern gezielt Emoji-Sequenzen, einschließlich neuer Unicode-Ergänzungen. Ein Besucher, der angeblich Safari auf dem iPhone nutzt, aber ein in iOS 17 hinzugekommenes Emoji nicht rendern kann, läuft auf einem älteren iOS — oder lügt über die Plattform.

Automatisierungs-Frameworks erzeugen unverwechselbare Fingerprints

Headless Chrome, das in einem Docker-Container ohne GPU läuft, nutzt SwiftShader für das Rendering. SwiftShader erzeugt Canvas-Ausgaben, die in sich konsistent sind, sich aber von jedem hardware-beschleunigten Chrome unterscheiden.

Die Signatur ist wiedererkennbar: ungewöhnlich sauberes Anti-Aliasing, spezifische Farbwerte in Verlaufsbereichen und Textkanten, die zu keinem bekannten GPU-Treiber passen. Ein Canvas-Fingerprint, der zu SwiftShader in Chrome 124 in einem Linux-Container passt, ist mit an Sicherheit grenzender Wahrscheinlichkeit Automatisierung — kein echter Nutzer betreibt einen Browser auf diese Weise.

Puppeteer-extra-stealth versucht, die Canvas-Ausgabe zu fälschen, indem es toDataURL() abfängt und modifizierte Daten zurückgibt. Doch die Modifikation führt oft eigene Artefakte ein — Rauschmuster, die sich über Sessions hinweg wiederholen und den Anti-Fingerprinting-Versuch paradoxerweise auffälliger machen, als gar nichts zu tun.

Warum Noise-Injection nicht gut funktioniert

Datenschutzorientierte Browser wie Brave injizieren Rauschen in die Canvas-Ausgabe, um Tracking zu verhindern. Die Idee: kleine zufällige Variationen der Pixelwerte, damit dasselbe Gerät in jeder Session einen anderen Fingerprint erzeugt.

In der Praxis hat Noise-Injection drei Probleme:

1. Das Rauschen ist selbst ein Fingerprint. Ein Besucher, dessen Canvas-Ausgabe sich bei jedem Laden ändert, während seine übrigen Signale identisch bleiben, ist als Browser mit Noise-Injection erkennbar. Das allein ist identifizierend.

2. Der Rausch-Algorithmus ist stabil. Braves Implementierung erzeugt spezifische Rauschmuster, die nicht zur natürlichen Varianz des GPU-Renderings passen. Erkennungssysteme können Canvas-Ausgaben, die nach Noise-Injection aussehen, von solchen unterscheiden, die natürlich wirken.

3. Ausgefeilte Systeme kombinieren Stichproben. Mehrere Renderings auf derselben Seite oder über Sessions hinweg lassen sich mitteln. Ist das Rauschen klein, konvergiert der Mittelwert gegen den zugrunde liegenden deterministischen Fingerprint.

Was Canvas-Fingerprinting erfasst

Über die offensichtliche visuelle Ausgabe hinaus kann Canvas-Fingerprinting mehrere Geräteattribute als Nebeneffekte extrahieren:

Rendering-Zeit — wie lange die Canvas zum Rendern braucht, verrät die Leistungsfähigkeit der GPU. Ein 4K-Desktop mit dedizierter GPU rendert schneller als ein Mittelklasse-Laptop.

Textmetriken — measureText() liefert exakte Pixelbreiten, die je nach Font-Rendering variieren. Die Textbreite lässt sich sogar ohne Rendering als Fingerprint nutzen.

Unterstützung von Composite-Operationen — manche Browser oder GPU-Konfigurationen unterstützen erweiterte Composite-Modi. Der Test auf Unterstützung offenbart die Grenzen der Fähigkeiten.

Filtereffekte — CSS-artige Filter auf der Canvas erzeugen über GPUs hinweg unterschiedliche Ausgaben, insbesondere Blur- und Drop-Shadow-Filter.

Wo Canvas-Fingerprinting im Erkennungs-Stack seinen Platz hat

Für sich allein ist Canvas-Fingerprinting kein robuster Identifikator. Treiber ändern sich. Nutzer wechseln den Browser. Noise-Injection ist in datenschutzaffinen Zielgruppen verbreitet.

Seine wahre Stärke liegt im Quercheck. Wenn eine Session auf Basis von Cookies oder Konto-Login behauptet, ein wiederkehrender Nutzer zu sein, dient der Canvas-Fingerprint als zweites Signal — stimmt er mit dem historischen Fingerprint überein, bestätigt das die Behauptung; weicht er ab, deutet das auf Kontoübernahme oder Session-Hijacking hin.

Für die Bot-Erkennung glänzt Canvas-Fingerprinting beim Aufspüren containerisierter Automatisierung. Echte Nutzer haben echte GPUs. Echte GPUs erzeugen wiedererkennbare Rendering-Signaturen. Alles, was wie SwiftShader rendert — oder wie eine schlecht gefälschte Canvas —, landet im Korb „mit an Sicherheit grenzender Wahrscheinlichkeit Bot".

Die Technik von 2012 funktioniert 2026 noch aus demselben Grund: Rendering ist pro Umgebung deterministisch, aber nahezu unmöglich vollständig zu fälschen. Jeder Versuch, sich zu verstecken, hinterlässt Spuren des Versuchs selbst.