Canvas, WebGL und Audio: Die drei Fingerprints, die jeden Neustart überleben

Warum gerade diese drei

Ein modernes Fingerprinting-Skript greift auf einer typischen Seite rund 40 Vektoren ab: User-Agent, Bildschirmgrösse, Sprach-Header, Schriftenliste, installierte Plugins, Zeitzonen-Offset, Pointer-Präzision, Hardware-Concurrency. Das sind meist kurze Zahlen oder kurze Strings, und in der Praxis trägt jeder davon ein bis fünf Bit Entropie. Sie taugen als Bindemittel, nicht als Identifikatoren.

Bei Canvas, WebGL und AudioContext ist das anders. Jeder dieser Vektoren schickt eine deterministische Arbeitslast durch das Gerät und hasht das Ergebnis. Der Hash hängt vom GPU-Silizium ab, von der Treiber-Version, vom Font-Rasterizer des Betriebssystems, von der Anti-Aliasing-Strategie und von der Floating-Point-Implementierung des Audio-Subsystems. Eine frische Chrome-Installation auf derselben Maschine liefert am nächsten Tag deshalb fast dieselben drei Hashes, während ein anderer GPU-Treiber sofort sichtbar abweichende Werte erzeugt.

Die Zahlen aus dem EFF-Datensatz Cover Your Tracks und dem Inria-Korpus AmIUnique verorten den Canvas-Hash bei rund zehn Bit Entropie, die WebGL-Renderer-Informationen bei sechs bis acht Bit und AudioContext bei vier bis fünf Bit. Eine Session, die alle drei preisgibt, kommt locker auf mehr als achtzehn Bit. Das genügt, um dich aus einer Viertelmillion Nutzern herauszuziehen, und damit für Ad-Targeting, Fraud-Scoring und die meisten Analytics-Pipelines.

Canvas-Fingerprinting im Detail

Ein Canvas-Fingerprint ist der Hash eines Bildes, das dein Browser gezeichnet, dir aber nie gezeigt hat. Das Skript erzeugt ein unsichtbares <canvas>, malt ein paar Formen und einen Textstring in zwei oder drei Schriften hinein, ruft toDataURL() auf und hasht die resultierenden PNG-Bytes. Für dich ist nichts davon sichtbar, der ganze Vorgang dauert wenige Millisekunden.

Der Hash bleibt auf einer Maschine stabil, weil der Rendering-Pfad deterministisch ist. Gleiche GPU, gleicher Treiber, gleicher Font-Rasterizer, gleicher Anti-Aliasing-Modus, gleiches PNG, Byte für Byte. Ändert sich eine dieser Variablen, kippt der Hash. Deshalb sieht ein zuvor stabiler Nutzer nach einem Windows-Feature-Update für Tracker aus wie neu, und deshalb gleichen sich Firmenrechner mit festgeschriebenen Treibern fast bis aufs Haar.

Das Grundgerüst des Angriffs sieht so aus:

const c = document.createElement("canvas");
const ctx = c.getContext("2d");
ctx.textBaseline = "alphabetic";
ctx.font = "14px 'Arial'";
ctx.fillStyle = "#069";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 2, 15);
ctx.fillStyle = "rgba(102,204,0,0.7)";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 4, 17);
const png = c.toDataURL();
// hash(png) wird dein Canvas-Fingerprint

Daran ist nichts Exotisches. Im Kern ist das genau die Routine, die FingerprintJS, ThreatMetrix und Cloudflare Bot Management beim Erstkontakt abspielen, mit kleinen Variationen. Brave und uBlock Origin schieben vor dem Auslesen ein kleines Per-Session-Rauschen ein, sodass der Hash jedes Mal anders aussieht. Gegen naive Sammler reicht das. Die Schutzmassnahme selbst ist trotzdem sichtbar: Ein Hash, der sich nie wiederholt, ist für sich genommen ein Signal, und Tracker stecken dich in die Schublade „Nutzer mit Canvas-Randomisierung".

WebGL-Fingerprinting im Detail

WebGL gibt der Seite über einen JavaScript-Wrapper der OpenGL-ES-API direkten Zugriff auf deine GPU. Zwei Punkte stechen sofort heraus. Erstens legt eine kleine Erweiterung namens WEBGL_debug_renderer_info den GPU-Hersteller und den Renderer-String im Klartext offen. Auf den meisten Desktops sieht das aus wie ANGLE (NVIDIA, GeForce RTX 4070, OpenGL 4.5.0) oder ähnlich spezifisch. Schon dieser eine String kann mehr als zehn Bit Entropie tragen, weil er den Treiber-Branch und manchmal einen Build-Hash mitliefert.

Zweitens lässt sich auch ohne diese Erweiterung das gerenderte Bild einer mittelkomplexen 3D-Szene (ein texturierter Torus, eine Verlaufskugel, ein paar gedrehte Dreiecke) noch hashen. Verschiedene Shader-Compiler, Precision-Einstellungen und Blending-Implementierungen verschieben Pixel um kleine, aber konsistente Beträge. Das Skript liest mit readPixels() den Framebuffer zurück, hasht ihn und legt das Ergebnis ab.

WebGL komplett zu deaktivieren ist die sauberste, aber auch die teuerste Verteidigung. Google Maps, fast alle Browser-Spiele, die Hälfte der modernen SaaS-Werkzeuge mit GPU-gerenderten Charts und überraschend viele 3D-Produktansichten im E-Commerce funktionieren dann nicht mehr. Firefox bietet für alle, die das in Kauf nehmen, die Einstellung webgl.disabled. Der Tor Browser lässt WebGL aktiviert, normalisiert aber den Renderer-String über alle Tor-Installationen einer Plattform hinweg auf einen einheitlichen Wert. Deshalb melden zwei Tor-Nutzer auf komplett unterschiedlicher Hardware dieselbe WebGL-Signatur an die Seite.

AudioContext-Fingerprinting im Detail

AudioContext-Fingerprinting ist von den dreien das leiseste, ganz wörtlich genommen. Das Skript instanziiert einen OfflineAudioContext, erzeugt bei fester Frequenz eine Dreiecks- oder Sinuswelle, schickt sie durch einen Dynamik-Kompressor mit festen Parametern und liest die Samples als Float32Array zurück. Es kommt kein Ton am Lautsprecher an. Das Gerät muss nicht entstummt sein, Kopfhörer sind egal. Worauf es ankommt, ist die Floating-Point-Mathematik, mit der dein Audio-Stack diese Samples berechnet hat.

Für das menschliche Ohr klingt das Ergebnis identisch (und für jeden Spektralanalysator, der sich nur fürs Hörbare interessiert, ebenfalls), aber die darunterliegenden Float32-Werte unterscheiden sich je nach Implementierung des Kompressor-Algorithmus. Browser-Builds, OS-Audio-Engines und sogar einzelne CPU-Microcode-Revisionen verschieben die niederwertigen Bits in stabilen Mustern. Wer den Buffer hasht oder aufsummiert, erhält eine Zahl, die Neustarts, Profil-Resets und die meisten Erweiterungen überlebt.

AudioContext trägt weniger Entropie als Canvas (typisch vier bis fünf Bit), für sich allein identifiziert er also niemanden. Der eigentliche Wert für Tracker liegt darin, dass sich kaum jemand dagegen wehrt. Canvas und WebGL bekommen die laute Aufmerksamkeit der Privacy-Tools, Audio läuft darunter durch. Findet ein Skript in zwei Sessions identische Canvas- und Audio-Hashes, ist die Übereinstimmung deutlich überzeugender, als Canvas allein rechtfertigen würde, weil die Audio-Zahl praktisch nie zufällig kollidiert.

Die drei im Vergleich

Nebeneinander gestellt zeigen die drei Vektoren unterschiedliche Stärken. Die folgende Tabelle fasst zusammen, was jeder einem Tracker bringt, was die Abwehr dich kostet und wie auffällig die Abwehr selbst für den Tracker ist.

Das Muster ist immer dasselbe. Einzeln ist jeder Vektor schwer zu schlagen, und die Abwehrmassnahmen, die wirklich greifen, fallen auf. Ein Tracker, der normales Canvas plus normales WebGL plus eine fehlende AudioContext-Markierung sieht, hat einen kleinen Bevölkerungsausschnitt vor sich, und genau das ist wiederum ein Identifikator.

Warum Tor trotzdem einen davon preisgibt

Der Tor Browser ist die aggressivste Endnutzer-Verteidigung gegen statisches Fingerprinting. Beim Auslesen eines Canvas gibt er standardmässig ein einheitliches weisses Bild zurück (echte Daten werden erst nach Rückfrage freigegeben). WebGL bleibt aktiv, aber der Renderer-String wird über alle Tor-Installationen einer Plattform auf einen einzigen Wert normalisiert, und das gerenderte Bild wird gerundet, um Treibervarianz zu schlucken. Zwei der drei Vektoren sind unter Tor faktisch tot.

AudioContext ist der lose Faden. Das Bedrohungsmodell des Tor Project deckt ihn ab (Ticket tor-browser#13017 und zugehörige Mozilla-Bug-Reports liegen schon Jahre zurück), aber die Floating-Point-Ausgabe eines OfflineAudioContext hängt nach wie vor von der Build-Chain ab. Ein Tor Browser auf Linux x86_64 erzeugt messbar andere Audio-Hashes als ein Tor Browser auf macOS arm64, selbst wenn beide denselben Plattform-String melden. Funktionierende AudioContext-Unterscheider für Tor sind mehrfach veröffentlicht worden, von der ursprünglichen AmIUnique-Arbeit bis zu jüngeren akademischen Nachfolgern.

Eine Korrektur ist aufwendig, denn die Alternative wäre, den OfflineAudioContext ganz abzuschalten. Das würde jede Web-App zerlegen, die im Hintergrund Audio dekodiert (Podcast-Player, Videokonferenzen, Browser-Spiele, Tools für Barrierefreiheit). An dieser Stelle bleibt das Tor Project bewusst zurückhaltend. Das Ergebnis: Selbst der am sorgfältigsten gehärtete Endnutzer-Browser legt einen der drei Vektoren weiter offen.

Was wirklich gegen diese Hashes hilft

Die drei Vektoren teilen eine Eigenschaft: Sie leiten sich aus dem Verhalten physischer Hardware ab. Reine Software-Abwehr hilft, aber vollständig wird es erst, wenn sich ändert, was die Seite von deinem Gerät sieht, nicht, was dein Gerät tatsächlich ist.

FAQ

Was am Ende übrig bleibt

Canvas, WebGL und AudioContext kommen in einer typischen Session zusammen auf mehr als achtzehn Bit Entropie. Das reicht, um einen Nutzer aus mehr als 250 000 herauszufischen, und sämtliche Werkzeuge der Cookie-Ära (Inkognito, VPNs, die meisten Privacy-Erweiterungen) lassen alle drei unberührt. Die Hashes kommen aus deiner GPU, deinen Treibern, deinen Schriften und deinem Audio-Stack, und genau diese Schicht erreichen jene Werkzeuge nie.

Einen einzelnen Vektor zu verteidigen ist selbst sichtbar. Canvas-Randomisierung, WebGL-Maskierung und Audio-Rauschen erzeugen erkennbare Anomalien, also stecken Tracker „verteidigte" Nutzer in eine kleinere und damit fast interessantere Gruppe. Tor schliesst zwei der drei überzeugend und lässt die Audio-Signatur weiter durch. Wirklich alle drei schliesst nur, was die Hardware und den Software-Stack ändert, die die Seite zu sehen bekommt. In der Praxis heisst das: eine andere physische Maschine, ein anderes OS-Image oder ein containerisierter Remote-Browser wie Browser.lol.