Was der Browser-Fingerprint-Test misst
Das Audit misst Kohärenz: ob unabhängige Subsysteme des Browsers zueinander passende Antworten über dieselbe Maschine geben. Es kann JavaScript mit CSS vergleichen, die Hauptseite mit einem Worker oder iframe, eine angegebene Browserfamilie mit APIs, die es nur in einer bestimmten Engine gibt, und eine gemeldete GPU mit der Rendering-Pipeline, die ein Bild tatsächlich erzeugt hat.
Das ist etwas anderes, als Seltenheit zu messen. Ein ungewöhnliches, aber in sich konsistentes Gerät kann bestehen. Eine gewöhnlich aussehende Identität kann durchfallen, wenn sich zwei Oberflächen widersprechen. Die meisten Checks brauchen deshalb keine Vergleichspopulation; der Browser liefert beide Seiten des Vergleichs selbst.
Wie der Kohärenz-Score berechnet wird
Der Score ist der Anteil der anwendbaren, gewerteten Checks, die übereinstimmen. Er ist keine Wahrscheinlichkeit dafür, dass ein Besucher ein Mensch ist, keine Erkennungsrate und keine Garantie, dass eine Automatisierungs-Session unsichtbar ist. Ein Score von 92 bedeutet, dass 92 Prozent der gewerteten Vergleiche, die anwendbar waren, kohärent waren.
Kontextabhängige Befunde werden ausgeschlossen, weil ganz normale Umgebungen sie erzeugen können: Barrierefreiheits-Tools, Erweiterungen, Remote-Desktops, per Richtlinie verwaltete Browser, Datenschutzfunktionen und fehlende Hardware verändern allesamt beobachtbare Oberflächen. Checks, die nicht laufen können, werden als „nicht gemessen“ ausgewiesen und nie als bestanden gezählt.
Warum manche Messungen eine Prüfung auf Netzwerkebene erfordern
JavaScript kann weder den TLS-ClientHello noch die Frame-Reihenfolge von HTTP/2, die QUIC-Transportparameter oder die von WebRTC genutzte öffentliche Adresse auslesen. Diese Fakten liegen unterhalb der Laufzeitumgebung der Seite. Um sie zu messen, muss ein Server melden, was tatsächlich über die Leitung ankam.
Das Audit öffnet zwei Verbindungen zu tls.clearcotelabs.com, um unabhängige TLS-Handshakes zu vergleichen. Sein WebRTC-Leak-Test kontaktiert stun.l.google.com – Google sieht also die verbindende IP – und vergleicht diese Adresse mit der, über die das Audit ausgeliefert wird. Ist einer der beiden Dienste nicht erreichbar, gilt das betreffende Ergebnis als nicht gemessen statt als sauber.
Datenerhebung und der Forschungskorpus
Wenn Sie das Audit ausführen, wird ein Browserprofil zur internen Analyse an Clearcote gesendet. Der Einwilligungshinweis im Tool nennt die Felder, bevor der Durchlauf beginnt. Der separate Forschungskorpus speichert einen gröberen Konfigurationsdatensatz, mit dem Abdeckung und False Positives untersucht werden; er ist keine Datenbank für Betrugserkennung oder Account-Reputation.
Die vollständigen Angaben zu Aufbewahrung, Löschung und den einzelnen Feldern stehen in der Datenschutzerklärung zum Audit. Weil diese Erklärung separat steht, bleibt der Test knapp, ohne zu verschleiern, was den Browser verlässt.
Was ein öffentlicher Browser-Test nicht feststellen kann
Eine öffentliche Seite sieht weder das globale Alter eines Profils noch den websiteübergreifenden Browserverlauf, die Account-Reputation, private Cookies anderer Origins oder die serverseitigen Risikomodelle kommerzieller Anti-Bot-Systeme. Eingabeverhalten kann mechanisches Timing oder perfekte Interpolation offenlegen, aber eine kurze Interaktion ist kein trainierter Verhaltensklassifikator.
Ein hoher Score ist deshalb eng auszulegen: Die durchgeführten Messungen haben nicht viele innere Widersprüche aufgedeckt. Über Reputation, Absicht, Account-Historie oder jedes Signal, das ein produktiv eingesetzter Detektor kombinieren kann, sagt er nichts Abschließendes.
Ein Fall verdient es, klar ausgesprochen zu werden, weil er am häufigsten missverstanden wird. Jeder Check in der Automatisierungsgruppe kann bestehen, und eine Session kann trotzdem als automatisiert eingestuft werden. In einem veröffentlichten Teardown eines produktiv eingesetzten kommerziellen Agents kam ein Payload, aufgezeichnet in einem über das DevTools-Protokoll gesteuerten Browser, mit der Einstufung als webdriver-Bot mit erkannten Developer Tools zurück – obwohl derselbe Payload jedes Automatisierungs-Flag als false meldete und sich von einem gewöhnlichen Fenster nur in Session-IDs, Zeitmesswerten und einem Netzwerk-Timing-Feld unterschied. Woran der Server das festgemacht hat, lässt sich vom Client aus nicht rekonstruieren, und diese Seite fügt bewusst keine Zeile für etwas hinzu, das sie nicht messen kann. Die ehrliche Schlussfolgerung: Ob ein Debugging-Protokoll vorhanden ist, wird außerhalb der Werte entschieden, die eine Seite lesen kann. Ein sauberer Automatisierungsbereich heißt also, dass genau diese Oberflächen sauber sind – nicht, dass die Verbindung unbeobachtet ist.
Derselbe Teardown ist der Grund, warum diese Seite mehrere Messwerte ausweist, statt sie zu bewerten. Identische aufgezeichnete Payloads, im Abstand von einer Woche erneut beim selben Anbieter eingereicht, kamen mit deutlich unterschiedlichen Tampering- und Anti-Detect-Urteilen zurück – Modelldrift, Replay-Historie oder beides, nicht auseinandergehalten. Absolute Scores eines Live-Detektors driften; aussagekräftig sind nur Unterschiede, die gegen eine Kontrolle in derselben Session gemessen wurden. Das gilt auch für die eigene Zahl dieser Seite. Deshalb weist der Durchlauf aus, wie stabil die Antworten Ihres Browsers waren, statt einen einzelnen Durchlauf als Ground Truth zu behandeln.