Was sollte vor dem Einsatz einer eingerichteten Umgebung geprüft werden? Kontrollieren Sie Zeitzone und Exit-Standort, Sprache, Auflösung, WebRTC-Leaks sowie Canvas/WebGL und achten Sie besonders auf widersprüchliche Parameter.
Dass eine konfigurierte Umgebung Webseiten normal öffnen kann, bedeutet noch nicht, dass sie einsatzbereit ist. Die eigentliche Abnahme sollte vor dem Start erfolgen: Prüfen Sie die wichtigsten Parameter nacheinander und kontrollieren Sie, ob sie dieselbe Geschichte erzählen.
Zunächst ist eines wichtig. Ein rot markiertes Prüfergebnis kann zwei Ursachen haben: Entweder liegt tatsächlich ein Problem in der Umgebung vor, oder die Prüfseite verwendet eine Datenbank mit anderen Zuordnungen als Ihre Konfiguration. Letzteres kommt nicht selten vor, trotzdem müssen beide Möglichkeiten geprüft werden. Eine Warnung sollte nicht übersprungen werden, nur weil sie ein Fehlalarm sein könnte.
Fünf Punkte, die geprüft werden sollten
Erstens: Zeitzone und Exit-Standort. Liegt die Exit-IP in einem bestimmten Land und einer bestimmten Stadt, sollte die Systemzeitzone dazu passen. Wenn diese beiden Angaben nicht zusammenpassen, ist das besonders leicht zu erkennen, weil die Prüfung kaum Aufwand verursacht.
Zweitens: Sprache und Region. Idealerweise stimmen Browsersprache, Systemsprache und der im Kontoprofil hinterlegte Markt überein. Wenn eine Umgebung in den USA ins Netz geht, aber eine andere Oberflächensprache mit höchster Priorität eingestellt ist, deutet das bereits auf Spuren einer manuellen Konfiguration hin.
Drittens: Auflösung und Gerätetyp. Bei einer Desktop-Umgebung sollten die Bildschirmabmessungen in einem plausiblen Desktop-Bereich liegen. Kombinationen wie ein mobiler User-Agent mit Desktop-Auflösung fallen leicht auf. Auch Fenstergröße und Pixelverhältnis sollten zum konfigurierten Gerät passen.
Viertens: WebRTC. Beim Aufbau von Peer-to-Peer-Verbindungen kann WebRTC lokale und öffentliche Adressen offenlegen. Bei falscher Behandlung kann dadurch der tatsächliche Netzwerk-Exit sichtbar werden. Die Prüfung ist einfach: Vergleichen Sie die von der Prüfseite angezeigte WebRTC-Adresse mit der Zugriffs-IP. Stimmen sie nicht überein, ist die zuvor eingerichtete Isolierung praktisch wirkungslos.
Fünftens: Canvas- und WebGL-Merkmale. Diese Werte spiegeln Grafikhardware und Rendering-Fähigkeiten wider. Wenn sich das System als Computer einer bestimmten Marke ausgibt, WebGL aber Informationen zu einer anderen Hardware meldet, ist das ein typischer Widerspruch. Falls die Umgebung benutzerdefinierte Hardwareparameter unterstützt, sollten Hersteller und Modell zum eingestellten Gerät passen.
Widersprüche fallen stärker auf als mangelnde Perfektion
Viele konzentrieren sich darauf, ob jeder einzelne Wert realistisch genug wirkt. Größer ist jedoch häufig das Risiko, dass mehrere Parameter einander widersprechen.
Echte Geräte widersprechen sich nicht selbst: Wo der Exit liegt, dazu passen normalerweise Zeitzone, Sprache und Systemeinstellungen; zum Gerät passen Auflösung, Pixelverhältnis und Grafikinformationen als zusammengehöriges Paket. Diese Beziehungen entstehen auf echten Geräten von selbst und sind genau der Punkt, an dem simulierte Umgebungen leicht Fehler machen. Sind die Parameter dagegen intern stimmig, fällt ein einzelner eher ungewöhnlicher Wert nicht sofort auf.
Daher empfiehlt sich die umgekehrte Prüfreihenfolge: Zuerst Widersprüche suchen, dann Einzelwerte prüfen.
Wie Prüfscores verwendet werden sollten
Ein Gesamtscore ist ein Richtwert und keine Schulnote. Er zeigt, wie sehr die Umgebung einem echten Gerät ähnelt, nicht ob ein Konto sicher ist. Liegt der Wert unter 90 %, lohnt sich ein Blick in die Details. Ein hoher Score bedeutet jedoch nicht, dass beliebige Aktionen unbedenklich sind, und ein niedriger Score beweist nicht automatisch ein echtes Problem.
Entscheidend ist, wo die Auffälligkeit gemeldet wird. Meldet nur eine Prüfseite ein Problem, sollte zunächst an unterschiedliche Datenquellen gedacht werden. Melden mehrere Seiten übereinstimmend dasselbe Problem, spricht das sehr stark für einen Konfigurationsfehler.
Reihenfolge bei der Fehlersuche
Prüfen Sie zuerst, ob WebRTC den echten Exit offenlegt. Die Folgen sind hier am schwerwiegendsten, und die Prüfung ist einfach. Danach sollten Widersprüche zwischen Systemkennung, Zeitzone, Sprache und Hardwareinformationen gesucht werden. Überlegen Sie anschließend, ob kürzlich Erweiterungen installiert wurden, die das Browserverhalten verändern. Erweiterungen können Umgebungseinstellungen überschreiben und selbst Teil des Fingerprints werden; deaktivieren Sie sie nacheinander und testen Sie erneut. Prüfen Sie zuletzt die Datenquelle und ob eine IP-Geolokalisierungsdatenbank möglicherweise nicht rechtzeitig aktualisiert wurde.
Die meisten ernst wirkenden Auffälligkeiten lassen sich mit dieser Reihenfolge auf einen konkreten Parameter zurückführen.
Zur Wiederverwendung von Parametern
Wenn dieselben Fingerprint-Parameter in mehreren Umgebungen verwendet werden, verweisen in einem Erkennungssystem mehrere Konten faktisch auf dasselbe Gerät. Das widerspricht dem Ziel der Isolierung. Jede Umgebung braucht eine eigene, stabile Parameterkombination, die langfristig unverändert bleibt. Häufige Änderungen können stattdessen neue Auffälligkeiten erzeugen. PurpleMark unterstützt die separate Konfiguration und Speicherung von Parametern pro Fingerprint-Umgebung, damit die Einstellungen einer Umgebung nicht die einer anderen überschreiben.
Diese fünf Prüfungen direkt nach der Einrichtung durchzuführen, ist wesentlich einfacher, als später auf Plattformwarnungen reagieren zu müssen.
