Warum sind Client Hints nach dem Einfrieren des User-Agent das neue Fingerprint-Signal? Die Entwicklung von UA zu CH erklärt

In den vergangenen Jahren haben die großen Browser ihre Datenschutzmechanismen immer weiter verschärft: Safari führte ITP ein, Firefox Total Cookie Protection und Chrome treibt offiziell das Einfrieren des User-Agent (UA Reduction) voran. Viele glauben noch immer, ein geänderter UA reiche aus, um ein Gerät anders erscheinen zu lassen. Tatsächlich wurde der UA jedoch stark vereinfacht und verliert zunehmend Detailinformationen. Die Rolle als wichtiges Signal zur Geräteerkennung übernehmen nun Client Hints (CH).

Dieser Artikel erklärt keine Methoden zum „Umgehen von Erkennung“. Er behandelt ausschließlich die technischen Grundlagen und beantwortet drei Fragen: Warum wird der UA eingefroren? Was sind Client Hints und warum gelten sie als hochentropische Fingerprint-Signale? Und weshalb ist die sogenannte „Fingerprint-Konsistenz“ entscheidend? Das hilft zu verstehen, warum modernes Browser-Umgebungsmanagement – besonders bei der Trennung mehrerer Konten – Parameter als zusammenhängendes System behandeln muss, statt nur einzelne Felder unabhängig voneinander zu setzen.

1. Warum reicht der UA-String nicht mehr aus?

Lange Zeit war User-Agent die wichtigste Grundlage, mit der Websites Browser und Geräte erkannten. Der String verrät unter anderem Browsermarke und -version, Betriebssystem und Gerätearchitektur. Weil UA-Strings jedoch lang und stabil waren, konnten sie leicht für Fingerprinting genutzt werden. Chrome kündigte deshalb ausdrücklich an, den UA schrittweise zu reduzieren: Übrig bleiben vor allem grundlegende Angaben wie die Hauptversion, während detailliertere Fähigkeiten in einen neuen Mechanismus verlagert werden – Client Hints.

Die direkte Folge des UA-Freeze lautet: Nur den UA zu fälschen, überzeugt nicht mehr. Systeme verlassen sich nicht mehr allein auf den UA, sondern prüfen, ob andere Felder zu ihm passen. Besonders auffällig sind widersprüchliche Parameter, zum Beispiel:

• Im UA steht macOS 14, im Feld für die Plattformversion dagegen macOS 13;
• Der UA meldet ein Mobilgerät, während das Mobile-Flag weiterhin ?0 ist;
• Die Hardwarearchitektur lautet arm64, aber Werte wie navigator.hardwareConcurrency wirken eher wie x86.

Solche Widersprüche können in Systemen zur Geräteerkennung schnell darauf hinweisen, dass das Profil nicht von einem realen Gerät stammt. Genau deshalb funktioniert „nur den UA ändern“ im Zeitalter des UA-Freeze nicht mehr zuverlässig.

2. Was sind Client Hints und warum gelten sie als hochentropische Fingerprints?

Client Hints (CH) sind eine Gruppe von Informationen über Gerätefähigkeiten, die ein Browser bei Bedarf über HTTP-Anfragen oder die JavaScript-Umgebung an einen Server übermitteln kann. Gegenüber dem UA gibt es zwei wesentliche Unterschiede:

1. Sie enthalten hochentropische Felder (High Entropy Values). Hohe Entropie bedeutet, dass die Kombination dieser Informationen sehr unterscheidungskräftig und schwer zu erraten ist – etwa eine genaue Plattformversion, eine vollständige Marken- und Versionsliste oder die Gerätearchitektur. Reale Browser liefern solche Angaben bei Bedarf und nicht pauschal alle auf einmal.

2. CH wird nicht isoliert bewertet, sondern gemeinsam mit anderen Fingerprints geprüft. In realen Systemen zur Geräteerkennung wird häufig kontrolliert, ob CH und UA zusammenpassen, ob CH und Transport-Fingerprints wie TLS-Fingerprints JA3/JA4 zur gleichen Browserfamilie gehören, ob CH mit JavaScript-Eigenschaften wie navigator.platform, Parallelität und Device Pixel Ratio (DPR) konsistent ist und ob CH zu den Merkmalen der Betriebssystemplattform passt.

Daraus ergibt sich ein zentraler Punkt: Schwierig ist nicht, ein einzelnes Feld zu verändern, sondern alle Felder so wirken zu lassen, als stammten sie von demselben realen Gerät. Fast jedes einzelne Feld lässt sich isoliert ändern. Die eigentliche Herausforderung besteht darin, Marke, Plattformversion, UA, DPR, Arbeitsspeicher, Architektur, TLS-Fingerprint und weitere Signale zu einem stimmigen Geräteprofil zusammenzufügen. Deshalb können auch Konfigurationen, bei denen scheinbar „jedes Feld ausgefüllt“ ist, weiterhin deutlich inkonsistent wirken.

3. Welche typischen Fehler verraten einen inkonsistenten Fingerprint?

Wer verstanden hat, dass Konsistenz entscheidend ist, erkennt schnell, warum viele Parameterkonfigurationen scheitern. Häufige Fehler sind:

• CH und UA passen nicht zusammen (am häufigsten): Der UA meldet macOS 14.1, während CH eine Plattformversion zurückgibt, die in dieser Form gar nicht existiert;
• Mobiler UA mit Mobile-Flag ?0: Bei einem realen Mobilgerät sollte hier normalerweise ?1 stehen;
• Falsche Ableitung der vollständigen Versionsliste: Die Hauptversion des Browsers ist beispielsweise 120, die vollständigen Versionsmerkmale wirken jedoch wie bei einer alten 115-Version;
• DPR, Arbeitsspeicher oder ähnliche Werte widersprechen der realen Geräteklasse: Ein Apple-Gerät zeigt etwa eine ungewöhnlich niedrige Pixeldichte oder ein gewöhnlicher Windows-PC meldet nur 1 GB RAM;
• Browser-spezifische Unterschiede werden ignoriert: Ein Feld wird einem Browser aufgezwungen, der es gar nicht unterstützt, oder eine Engine liefert ein Merkmal, das sie tatsächlich nie ausgeben würde.

Solche Widersprüche fallen in Geräteerkennungssystemen deutlich auf. Im Kern entstehen sie alle dadurch, dass die Umgebung nicht als konsistentes Ganzes behandelt wird.

4. Was bedeutet eine „korrekte Konfiguration“ eigentlich?

Statt von „Felder ausfüllen“ zu sprechen, ist es treffender, von der Pflege eines in sich stimmigen Umgebungsprofils zu sprechen. Dazu gehören typischerweise folgende Punkte:

• CH an den UA binden: Die passenden CH-Werte für Marke, Plattform und Version werden nach den realen Regeln der Browser-Engine und -Version abgeleitet, statt beliebige Werte zusammenzusetzen;
• Die Rückgabestrategie hochentropischer Felder einhalten: Standardmäßig werden niedrigentropische Informationen geliefert, hochentropische Werte nur nach Bedarf so, wie es ein echter Browser tun würde; nicht unterstützte Felder werden nicht zurückgegeben;
• JavaScript-Eigenschaften, HTTP-Header und Systemmerkmale aufeinander abstimmen: DPR muss zur Bildschirmauflösung passen, der Arbeitsspeicher zur Plattformklasse, das Mobile-Flag zum UA und die Architektur zum restlichen Systemprofil;
• Transport-Fingerprints einbeziehen: Merkmale wie TLS/JA3/JA4 sollten ebenfalls zur angegebenen Browserversion passen.

Kurz gesagt: Die eigentliche Herausforderung besteht darin, CH, UA, JavaScript-Umgebung und Systemmerkmale zu einem konsistenten Browser-Verhaltensprofil zu verbinden – nicht darin, möglichst viele Felder auszufüllen.

5. Was hat das mit Multi-Account-Umgebungsmanagement zu tun?

Wer im grenzüberschreitenden E-Commerce, Social-Media-Marketing oder mit eigenen Shops arbeitet, fragt sich vielleicht, was diese Technik mit „separaten Browserumgebungen für verschiedene Geschäftskonten“ zu tun hat. Der Zusammenhang ist direkt: Umgebungsmanagement setzt voraus, dass jede Umgebung in sich konsistent ist.

• Bei vielen Konten und Regionen ist es wenig sinnvoll, UA, Betriebssystem, Auflösung und andere Parameter für jede Umgebung manuell zusammenzustellen. Ein Tool kann anhand des gewählten Systems und der Engine-Version automatisch zueinander passende Parameter erzeugen und so Nacharbeit durch widersprüchliche Einzeländerungen reduzieren.
• Geschäftskonten für unterschiedliche Regionen und Plattformen sollten voneinander getrennte, jeweils intern konsistente Umgebungen besitzen, statt überall dieselben „Vorlagenparameter“ zu verwenden und dadurch auf Geräteebene ungewöhnlich ähnlich zu wirken.
• Beim Wechsel eines Proxys in eine andere Region entspricht es eher dem Verhalten eines realen Geräts, wenn Systemversion, Gerätemodell und weitere Merkmale innerhalb derselben Umgebung weiterhin logisch zusammenpassen, als wenn „nur die IP wechselt und alle anderen Parameter unverändert bleiben“.

Genau diese Konsistenzprobleme sollen Browser-Umgebungsmanager für mehrere Konten lösen. PurpleMark bietet beim Erstellen einer Umgebung eine einheitliche Konfiguration für Betriebssystem, Chromium-Engine-Version, User-Agent, Auflösung, Zeitzone, Sprache, CPU/Arbeitsspeicher, Canvas, WebGL, TLS und weitere Fingerprint- sowie Geräteparameter. Nach Auswahl einer Region und eines Kontozwecks kann eine Umgebung nach einem zusammenhängenden Schema erstellt werden, statt bei jeder Anmeldung Werte neu zusammenzusetzen. Verwaltet wird die Gesamtkonsistenz und Wiederverwendbarkeit von Konto, Browserumgebung und Netzwerkkonfiguration in einem gemeinsamen Arbeitsbereich – nicht das Überlisten eines bestimmten Erkennungsverfahrens.

6. Fazit

Der UA-Freeze markiert eine neue Phase des Browser-Fingerprintings: Entscheidend ist nicht mehr nur, welche Felder vorhanden sind, sondern ob diese Felder zueinander passen. Seit Client Hints den UA als hochentropisches Fingerprint-Signal ergänzen beziehungsweise ablösen, ist es wichtiger, die Zusammenhänge zwischen CH, UA, Systemmerkmalen und Transport-Fingerprints zu verstehen, als eine lange Liste einzelner Feldnamen auswendig zu lernen.

Wer nur einige echte und regelkonform genutzte Geschäftskonten verwaltet, muss seine Energie nicht in den Kampf gegen Erkennungssysteme stecken. Praktischer ist es, mit einem Umgebungsmanagement-Tool wie PurpleMark Region, System und Browserparameter jedes Kontos klar, konsistent und wiederverwendbar zu organisieren und so Probleme durch widersprüchliche Umgebungsparameter von vornherein zu vermeiden.

(Hinweis: Dieser Artikel dient ausschließlich der technischen Aufklärung über Browser-Fingerprinting. Beachten Sie stets die Nutzungsbedingungen der jeweiligen Plattform und verwenden Sie legitime Konten.)