Browser-Fingerabdruck-Test: Canvas, WebGL & Eindeutigkeit prüfen

Das alleinige Ändern der User-Agent-Zeichenkette schützt nicht vor Erkennung, sondern erzeugt auffällige "Schichten-Widersprüche": Erstens die Diskrepanz zwischen Anwendungs- und Transportschicht: Ändert man unter Windows den UA auf iPhone Safari, deklariert die HTTP-Schicht Apple, das TCP-SYN-Paket stammt jedoch eindeutig aus dem Windows-Kernel (keine TS-Option, Optionsfolge MSS, NOP, WS, NOP, NOP, SACK_PERM) und widerspricht Apples 8-teiliger Optionssequenz. Zweitens HTTP/3- und HTTP/2-Implementierungsunterschiede: Chromium-, WebKit- und Gecko-Engines weisen feste, unveränderliche Merkmale auf, etwa bei HTTP/3-Unidirektional-Stream-Mappings (Chromium: 2:control,10:encoder vs. WebKit: 2:control,6:encoder) und HTTP/2-Pseudokopfzeilen (Chromium: m,a,s,p vs. Nicht-Chromium: m,s,a,p). Die Manipulation eines einzelnen Headers steht somit in direktem Widerspruch zum Netzwerk-Stack.

💡 Weitere Details zu Transport-Signaturen finden Sie in unserer Proxy-Anonymitätsanalyse.

Anti-Detect-Browser modifizieren Chromium oder injizieren JavaScript-Hooks, um navigator-Eigenschaften zu überschreiben, Rauschen in Canvas/WebGL-Bilder einzufügen und Bildschirmauflösungen oder Audiokontexte zu simulieren. Sicherheitssysteme erkennen jedoch typische Spuren: Erstens Manipulationen an Prototypen und nativen Funktionen: JS-Hooks beschädigen häufig Function.prototype.toString, Eigenschaftsdeskriptoren und Prototypenketten. Zweitens unveränderliche GPU- und Shader-Gesetzmäßigkeiten: Künstliches Rauschen verändert zwar den Bild-Hash, die inhärente Fließkommapräzision und Rasterisierungslogik des physischen Grafiktreibers bleibt jedoch bestehen und bildet oft ein künstlich erkennbares Rauschmuster. Drittens unveränderte Netzwerk-Stacks: Die meisten Anti-Detect-Browser agieren nur auf JS-Ebene und passen die TCP/TLS-Merkmale des Host-Betriebssystems nicht an.

Nein. Der Inkognito-Modus verhindert ausschließlich das "Speichern lokaler Verlaufsdaten auf Ihrem eigenen Gerät", nicht aber die "Wiedererkennung durch entfernte Server". Nach dem Schließen des Fensters werden Cookies, LocalStorage und Verlauf gelöscht. Browser-Fingerprinting erfasst jedoch physische Hardware- und Systemeigenschaften per JavaScript (Grafikkartenmodell, Canvas-Renderabweichungen, WebGL-Shader, installierte Schriftarten, Audio-Signalverarbeitung, CPU-Kerne und Farbtiefe). Da physische Hardware, Treiber und Rendering-Engine im Inkognito-Modus identisch bleiben, berechnen Server denselben Fingerprint-Hash wie im normalen Modus.

Dies ist kein Fehlalarm, sondern eine technische Notwendigkeit auf der iOS-Plattform: Erstens die Richtlinien des Apple App Store: Apple schreibt verbindlich vor, dass alle Browser auf iOS/iPadOS (einschließlich Chrome, Edge, Firefox und Opera) die hauseigene WebKit / WKWebView-Engine nutzen müssen; Chromium Blink oder Gecko sind unzulässig. Zweitens der Protokollnachweis: Chrome unter iOS (CriOS) sendet bei HTTP/3-Verbindungen strikt das WebKit-typische Unidirektional-Stream-Mapping (2:control,6:encoder), abweichend von Chromium auf Desktop oder Android (2:control,10:encoder). Chrome unter iOS ist technisch ein WebKit-Browser mit Google-Oberfläche.

Ja, jedoch unter strengen Voraussetzungen und klaren Grenzen, und dies hat keinerlei Ähnlichkeit mit einer „Benutzerauthentifizierung“. Die Identitätswiedererkennung auf unserer Seite nutzt ein vierstufiges Gewichtungsmodell: 1) Hardware-Ankerschicht (GPU-Modellbezeichnung, Soundkarten-Basislatenz, Anzahl der Mediengeräte); 2) System-Hochentropieschicht (Liste installierter Schriftarten, Sprachausgabe-Stimmen); 3) Browser-Variableschicht (Canvas-Rendering-Hash, AudioContext-Berechnungs-Hash); 4) Anzeigeumgebungsschicht (Bildschirmauflösung, Zeitzone). Nach der Aggregation aller vier Schichten müssen beide folgenden Bedingungen zwingend erfüllt sein, um ein bestehendes Profil zuzuordnen: Der Gesamtwert muss den Schwellenwert überschreiten und mindestens ein hochgradig entropisches Kernmerkmal muss übereinstimmen (Schriftartenliste, Sprachpakete, Canvas oder Audio). Diese zweite Bedingung ist bewusst gesetzt: Öffentliche Merkmale mit geringer Entropie wie GPU-Modell, Zeitzone und Auflösung wiederholen sich millionenfach auf baugleichen Geräten und dürfen niemals für sich allein eine Identität begründen. Frühere Versionen ohne diese Schranke konnten fremde Geräte fälschlicherweise verwechseln. Darüber hinaus besitzt die Hardware-Ankerschicht ein striktes Vetorecht: Weichen logische CPU-Kerne ab, unterscheidet sich der Arbeitsspeicher um mehr als 4GB, weicht die Basislatenz der Audiokarte um mehr als 0.005 Sekunden ab oder differieren die maximalen Berührungspunkte, wird der Kandidat unmittelbar als fremdes Gerät eingestuft und von der Punkteberechnung ausgeschlossen.

⚠ Ziel dieses Mechanismus ist es, wiederholte Beobachtungen desselben Geräts stabil abzugleichen, nicht Ihre bürgerliche Identität zu beweisen – er stellt keine Authentifizierung dar und darf niemals als solche verwendet werden.

Beide zählen zu den „hochgradig entropischen Systemmerkmalen“, erfordern keinerlei Berechtigungen und arbeiten vollkommen unbemerkt und geräuschlos. AudioContext-Fingerabdruck: In einem OfflineAudioContext wird ein Oszillator (Oscillator) durch einen Dynamikkompressor (DynamicsCompressor) geleitet, um ein Audiosignal offline zu rendern, woraufhin die Fließkomma-Abtastwerte ausgelesen und gehasht werden. Derselbe Audiograph erzeugt je nach Browser-Engine, mathematischen Bibliotheken und Fließkomma-Backends kleinste Differenzen im niederwertigsten Bit, ohne einen Ton abzuspielen. Davon völlig unabhängig ist AudioContext.baseLatency: Dieser Wert gibt die von Treiber und Hardware bestimmte Puffergröße der Soundkarte an; wir nutzen ihn als Hardware-Anker (eine Differenz von mehr als 0.005 Sekunden schließt eine Übereinstimmung aus), nicht als Identitäts-Hash. Schriftarten-Enumerations-Fingerabdruck: Er misst nacheinander Breite und Höhe einer Textzeichenkette beim Rendern mit jeder Schriftart aus einer Auswahlliste gegenüber Standard-Schriftarten; Abweichungen beweisen das Vorhandensein der Schriftart. Welche Schriftarten vorhanden sind, hängt eng mit installierter Software zusammen (Office-Pakete, Adobe-Software, Entwicklerwerkzeuge, Eingabemethoden), weshalb die Schriftartenliste im Regelfall das trennschärfste Einzelmerkmal des gesamten Fingerabdrucks darstellt.

💡 Der Unterschied in der Stabilität liegt in der Ursache der Veränderungen: Canvas- und Audio-Hashes ändern sich mit jedem Browser-Versionsupdate (Rendering-Engines und Rechenmodule werden kontinuierlich modifiziert), während sich die Schriftartenliste nur bei der Installation oder Deinstallation von Software verändert – deshalb besitzt sie das höchste Gewicht.

Die MSS (Maximum Segment Size) ist die maximale Nutzlast pro TCP-Segment, die während des TCP-Handshakes übermittelt wird. Unser Server liest sie direkt aus Ihrem SYN-Paket aus, ohne dass Client-Software oder Konfigurationen erforderlich sind. Durch Hinzurechnen des IP- und TCP-Header-Overheads wird die MTU der Verbindung rekonstruiert: plus 40 Bytes bei IPv4, plus 60 Bytes bei IPv6. Typische Werte besitzen eine feste technische Bedeutung: 1500 bezeichnet standardmäßiges Ethernet oder direkte Cloud-Server-Anbindungen; 1492 steht für PPPoE-Breitband (DSL / FTTH-Heimanschlüsse), bei denen der 8-Byte-PPPoE-Header die Nutzlast verringert; kleiner oder gleich 1420 weist auf eine zusätzliche Protokollkapselung hin, wie sie typisch für VPN-Tunnel wie WireGuard / Tailscale oder CDN-Weiterleitungen ist.

⚠ Entscheidend ist: Die MSS beschreibt die Netzwerkverbindung, nicht das Endgerät. Sie zeigt lediglich an, dass auf dem Pfad eine Kapselung vorliegt, beweist jedoch für sich allein keine Proxy-Nutzung (auch ein regulärer PPPoE-Heimanschluss liegt nicht bei 1500). Echten diagnostischen Wert besitzen Widersprüche: Wenn der auf Anwendungsebene angegebene Standort dauerhaft nicht zu den Merkmalen der Transportschicht passt (z. B. Angabe einer lokalen Direktverbindung, während die MSS stabil im Tunnelbereich liegt). Weitere Details finden Sie in unserer Proxy-Anonymitätsanalyse.

Dies ist die Art von Fehler, die wir am strengsten vermeiden (fehlerhafte Zusammenführung), weshalb drei aufeinanderfolgende Schutzebenen greifen – schlägt eine davon an, wird die Zuordnung abgelehnt. Erstens strikte Partitionierung nach Buckets: Identitätskandidaten werden strikt nach Betriebssystemplattform und Browser-Engine getrennt, ohne vergleichende Prüfungen über Bucket-Grenzen hinweg. Zwei verschiedene Browser-Engines auf demselben physischen Rechner werden selbst bei identischer Hardwareausstattung niemals zusammengeführt. Zweitens Vetorecht der Hardware-Anker: CPU-Kernanzahl, Arbeitsspeicher (Toleranz 4GB), Soundkarten-Basislatenz (Toleranz 0.005 Sekunden) und maximale Berührungspunkte führen bei beidseitig vorliegenden und kollidierenden Werten zum direkten Ausschluss vor der Punktevergabe. Drittens Zulassungsschranke für Kernmerkmale: Selbst bei sehr hoher Gesamtpunktzahl wird eine Zuordnung verwehrt, wenn keines der hochgradig entropischen Kernmerkmale (Schriften, Sprachpakete, Canvas, Audio) übereinstimmt – dies verhindert, dass gewöhnliche öffentliche Low-Entropy-Merkmale gemeinsam fälschlicherweise eine hohe Punktzahl erzeugen.

⚠ Ehrliche Offenlegung: Wir verfügen derzeit über keinen empirisch ermittelten Messwert für Fehlzusammenführungsraten aus dem Produktivverkehr, den wir veröffentlichen könnten. Diese Kennzahl erfordert langfristige statistische Erhebungen über reale Zugriffsmengen; Zahlenangaben vor Erreichen einer hinreichenden Stichprobengröße wären unaufrichtig.