User-Agent Erklärt: Von UA Strings und Browser-Fingerabdrücken zu Client Hints

Öffne das Netzwerk-Panel in den Entwicklertools deines Browsers und findest fast immer einen User-Agent-Header. Es sieht nach einer kurzen Einführung aus: Welcher Browser stellt die Anfrage, auf welchem Betriebssystem läuft er und welche Version er angeblich ist.

Das macht es verlockend, den Header als Geräte-ID zu behandeln – oder anzunehmen, dass eine Änderung einer Zeile einen Browser in ein anderes Gerät verwandeln kann. Beide Ideen sind nur teilweise richtig.

Ein User-Agent-String, oder UA, ist Kompatibilitätsinformation, die vom Client deklariert wird. Es handelt sich nicht um eine vertrauenswürdige Identitätszugangsberechtigung, und ein Client kann sie modifizieren. Doch sie existiert nicht isoliert. Eine Seite kann die UA mit Client Hints, JavaScript APIs, Bildschirmeigenschaften, Schriftarten, Canvas, WebGL, Netzwerkkontext und Verhalten vergleichen. Die nützliche Frage ist daher nicht einfach, ob ein UA verändert werden kann, sondern welche Rolle er in der vollständigen Beobachtbarkeit des Browsers spielt.

Dieser Artikel nutzt HTTP Standards und Browser-Fingerprinting-Forschung, um vier Fragen zu beantworten:

1. Warum sieht eine UA Saite aus wie ein Stück Browser-Archäologie?
2. Wie viel identifizierende Informationen können UA beitragen, und wie sollten wir die Forschung interpretieren?
3. Warum kann die Änderung nur der UA eine offensichtlichere Inkonsistenz schaffen?
4. Was haben UA Reduction und User-Agent Client Hints tatsächlich verändert?

In diesem Artikel meint UA hauptsächlich den HTTP User-Agent-Anfrage-Header. Wir besprechen auch navigator.userAgent und navigator.userAgentData in JavaScript. Diese Schnittstellen sind in jedem Browser und Kontext miteinander verbunden, aber nicht dauerhaft identisch.

1. Was ist ein User-Agent?

Abschnitt 10.1.5 RFC 9110 definiert User-Agent als ein Feld, das Informationen über den User Agent enthält, der die Anfrage initiiert hat. Die vereinfachte Grammatik lautet:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

In klarer Sprache beginnt die Zeichenkette mit einem Produktnamen und kann eine Version enthalten. Weitere Produkte oder Kommentare können folgen. Der Standard erkennt Anwendungsgebiete wie Interoperabilitäts-Workarounds, Diagnostik und Analysen an, rät aber auch von Implementierungen, keine unnötigen Details preiszugeben: Ein längeres, spezifischeres UA erhöht sowohl die Anzahl der Anfragen als auch das Risiko des Fingerabdrucks.

Ein moderner Chromium Desktop-UA könnte so aussehen:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

Das Aufteilen der Zeichenkette durch Leerzeichen zeigt mehrere Namen, die offenbar nichts mit Chrome zu tun haben:

Token	Was es heute im Allgemeinen bedeutet	Eine häufige Fehlinterpretation
Mozilla/5.0	Ein historischer Kompatibilitätstoken	Der Browser muss Firefox oder ein Mozilla Produkt sein
Windows NT 10.0	Eine Windows Plattformkategorie; Eine reduzierte UA kann Windows 10 nicht zuverlässig von 11	Der Computer muss Windows 10
Win64; x64	Ein Hinweis darauf, dass dies 64-Bit-Windows auf einer x86-64-Architektur ist	Es beweist das exakte physikalische CPU-Modell
AppleWebKit/537.36	Ein Engine-Lineage- und Kompatibilitätstoken	Chrome verwendet immer noch die vollständige Implementierung von Safari
KHTML, like Gecko	Historische Kompatibilitätssprache	Sowohl KHTML als auch Gecko laufen
Chrome/145.0.0.0	Die Chrome/Chromium Familie und Hauptversion; Komponenten der niedrigeren Version können reduziert werden	Es zeigt die genaue Patch-Version
Safari/537.36	Ein Token, das zur Kompatibilität mit älteren Seiten beibehalten wurde	Der Browser muss Safari

Die UA wurden ausführlich, weil frühe Websites oft auf Browsernamen verzweigten. Neue Browser mussten die Kompatibilität mit älteren Produkten angeben, um die korrekte Seite zu erhalten. Diese Erklärungen häuften sich im Laufe der Zeit an und schufen eine historische Aufzeichnung, die nicht wörtlich gelesen werden kann.

Die erste Regel UA Parsing ist daher einfach: Es ist ein Kompatibilitätsprotokoll, keine strenge Gerätebeschreibung.

2. Warum verwenden Websites immer noch UA?

UA wird nicht nur zur Verfolgung verwendet. Legitime Verwendungen umfassen:

• eine Rückfalloption für einen älteren Browser mit bekanntem Kompatibilitätsproblem bereitzustellen;
• Auswahl eines geeigneten Installations- oder Download-Formats;
• versionsspezifische Fehler in Diagnoseprotokollen zu finden;
• Messung breiter Browser-Familien-, Plattform- und Großversionen-Distributionen;
• unmögliche Kombinationen im automatisierten oder bösartigen Datenverkehr zu identifizieren.

Das Problem beginnt, wenn UA Sniffing von einem engen Kompatibilitätsrückfall zu einer Vermutung nach Produktnamen übergeht. Code kann Chrome sehen und annehmen, dass eine bestimmte API existiert. Diese Annahme kann in einem eingebetteten WebView, einem Chromium-abgeleiteten Browser, einem Browser mit Unternehmensrichtlinie, einem eingefrorenen UA oder einem Client, der seinen Header geändert hat, scheitern.

Eine robustere Reihenfolge der Operationen ist:

1. Teste die erforderliche API oder das erforderliche Verhalten direkt, wann immer eine Fähigkeitserkennung möglich ist.
2. Wenn Browser-Identifikation unvermeidbar ist, verwenden Sie einen gepflegten Parser anstelle eines Ad-hoc-Regulärausdrucks.
3. Speichern Sie nur die groben Kategorien, die das Produkt wirklich benötigt.
4. Bieten Sie einen Rückfallplan für unbekannte Marken, unbekannte Versionen und fehlende Felder bereit.

3. Ist UA ein Browser-Fingerabdruck?

Genauer gesagt ist UA eine Eingabe eines Browser-Fingerabdrucks, meist nicht der vollständige Fingerabdruck.

Browser-Fingerprinting erfordert keine geheime Seriennummer. Er misst eine Sammlung relativ stabiler, unterscheidender Merkmale, die vom Browser freigegeben werden. UA liefert Hinweise auf die Browserfamilie, Version und Plattform. Bildschirmabmessungen, Schriftarten, Zeitzone, Canvas, WebGL, AudioContext und andere Oberflächen fügen zusätzliche Informationen hinzu.

Die Übersicht von Laperdrix und Kollegen Browser Fingerprinting: A Survey behandelt diese Techniken als eine Form der staatlosen Anerkennung. Eine Seite muss nicht unbedingt zuerst ein Cookie schreiben; Es kann versuchen, Besuche von den Attributen zu verknüpfen, die ein Browser offenlegt. "Stateless" bedeutet nicht, dass der Server nichts speichert. Das bedeutet, dass das Erkennungsmaterial nicht von einer persistenten clientseitigen Kennung abhängt.

1. Was bedeutet das 10-Bit-Ergebnis des Artikels?

In der Panopticlick-Studie von 2010 How Unique Is Your Web Browser? analysierte Peter Eckersley etwa 470.000 Browser-Fingerabdrücke. Die Zeitung berichtete:

• Der vollständige Fingerabdruck trug durchschnittlich etwa 18,1 Bit identifizierende Informationen in dieser Probe;
• Intuitiv ausgedrückt trat ein durchschnittlicher Fingerabdruck etwa einmal in 286.777 Browsern auf;
• Die Tabelle zeigte etwa 10,0 Bit an durchschnittlicher Information allein für die UA Zeichenkette;
• unter Browsern mit aktivierter Flash oder Java waren 94,2 % der vollständigen Fingerabdrücke eindeutig.

Selbstinformation wird üblicherweise wie folgt geschrieben:

I(x) = -log₂ P(x)

Wenn ein bestimmtes UA mit Wahrscheinlichkeit 1/1024 in einer Population auftritt, liefert die Beobachtung davon 10 Informationsbits. Das bedeutet nicht, dass UA genau 1.024 mögliche Werte hat oder eine Person eindeutig identifiziert. Sie beschreibt, wie viel Unsicherheit diese Beobachtung im Durchschnitt beseitigt.

2. Warum ist das Ergebnis von 2010 für das heutige Web keine Konstante?

Das Ergebnis bleibt wichtig, aber es braucht mindestens drei Einschränkungen:

• Besucher einer Datenschutztest-Seite waren keine zufällige Stichprobe aller Internetnutzer;
• Browser-, Plugin- und UA-Versionsvielfalt im Jahr 2010 unterschied sich stark vom heutigen Ökosystem;
• UA Reduction, schrumpfende Plugin-Oberflächen und Anti-Fingerabdruck-Schutz haben die Verteilung observierbarer Attribute verändert.

Die Studie stützt die Behauptung, dass UA und andere Eigenschaften messbare, unterscheidende Informationen beitragen können. Es unterstützt nicht die Aussage, dass ein UA heute immer genau 10 Bit Entropie hat. Die Fingerabdruckkraft hängt von der Bevölkerungszahl, dem Zeitfenster, den Browserrichtlinien und der Kombination der Signale ab.

4. Warum kann es nach hinten losgehen, nur UA zu verändern?

UA ist eine Client-Erklärung ohne kryptografischen Beweis. Ein Server kann die Werkswahrheit eines Geräts nicht aus diesem Header ablesen. Es kann jedoch prüfen, ob verschiedene Beobachtungen einigermaßen kompatibel sind.

Angenommen, ein UA behauptet, ein mobiler Browser zu sein, aber die Seite beobachtet keine Berührungspunkte, ein Fenster, das konsequent einem Desktop-Display ähnelt, und Client Hints, die eine Desktop-Plattform anzeigen. Jede einzelne Beobachtung kann eine legitime Ausnahme haben. Mehrere stabile Widersprüche zusammen können dennoch ein klassifizierbares Muster bilden.

Die Panopticlick Studie dokumentierte bereits vergleichbare Fälle: Einige Browser gaben an, iPhone zu sein, unterstützten Flash, und einige Firefox UAs erschienen neben Speicherfunktionen, die nur im Internet Explorer verfügbar sind. Die Studie von 2018 FP-Scanner untersuchte dieses Problem systematisch. Einige Anti-Fingerabdruck-Erweiterungen und Spoofing-Tools führten zu Inkonsistenzen zwischen den Schnittstellen, sodass ein Detektor modifizierte Attribute identifizieren und in manchen Fällen die ursprüngliche Browser- oder Betriebssystemfamilie ableiten konnte.

Nicht jede Inkonsistenz ist böswillig. Remote-Desktops, Barrierefreiheitstools, Unternehmensrichtlinien, Kompatibilitätsschichten und ungewöhnliche Hardware können alle ungewöhnliche Kombinationen erzeugen. Ein sorgfältiges Risikosystem sollte eine Inkonsistenz als probabilistisches Dokument behandeln und nicht als automatischen Grund, einen Nutzer zu blockieren.

Für die Verwaltung von Browser-Profilen sind drei Eigenschaften wichtig:

• Interne Konsistenz: UA, Client Hints, Plattform, Architektur, Touch- und Bildschirmsignale sollten sich nicht direkt widersprechen.
• Stabilität über die Zeit: Ein langlebiges Profil sollte sich nicht bei jedem Start ohne Grund dramatisch verändern.
• Plausible Diversität: Profile können variieren, aber seltene mechanisch erzeugte Kombinationen sind nicht unbedingt sicherer.

Die FP-STALKER-Studie zeigte außerdem, dass Attributänderungen nicht automatisch eine Verknüpfung verhindern. Ein Modell kann stabile Attribute und plausible Versionsänderungen verwenden, um frühere und spätere Fingerabdrücke zu verbinden.

5. Welches Problem geht UA Reduction an?

Mit fast jeder Anfrage wird ein traditioneller UA versengt. Jeder Erstanbieter- oder Drittanbieter-Endpunkt, der die Anfrage empfängt, kann sie passiv lesen. Je präziser die Zeichenkette, desto mehr unterscheidende Informationen erhält jeder Empfänger standardmäßig.

Chromium User-Agent Reduction Plan reduziert diese Standardgranularität:

• Ab Chrome 101 wurden die Desktop-Minor-, Build- und Patch-Versionen auf 0.0.0 reduziert;
• spätere Phasen vereinheitlichten Desktop-Betriebssystemversionen, CPU-Details und Android Geräteinformationen;
• Ein reduzierter Android UA verwendet feste Plattform- und Modellwerte wie Android 10; K;
• Seiten, die tatsächlich mehr Details benötigen, können User-Agent Client Hints verlangen.

Das reduzierte Format lässt sich wie folgt zusammenfassen:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

Die Reduzierung verringert die passive Fingerabdruckfläche der alten UA. Es beseitigt nicht das Fingerabdrücken des Browsers. Die Hauptversion, die breite Plattform und der mobile Zustand können sichtbar bleiben, während andere APIs, Netzwerkeigenschaften und Verhalten weiterhin Informationen liefern können.

6. Wie funktionieren User-Agent Client Hints?

Der allgemeine Mechanismus ist in RFC 8942 definiert, während der WICG User-Agent Client Hints Entwurf UA-spezifische Felder beschreibt. Der Ansatz teilt Informationen, die einst in einer unstrukturierten Zeichenkette lebten, in strukturierte Felder auf und unterscheidet Hinweise mit niedriger Entropie, die standardmäßig gesendet werden können, von Hinweisen mit hoher Entropie, die ein Standort normalerweise explizit anfragt.

Eine vereinfachte erste Anfrage kann so aussehen:

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

Wenn der Server tatsächlich Architektur und Bitigkeit benötigt, um einen Installer auszuwählen, kann er antworten:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

Wenn der Browser den Mechanismus unterstützt und die Sicherheits- und Richtlinienanforderungen erfüllt sind, kann eine spätere Anfrage Folgendes umfassen:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

Häufige UA Client Hints sind:

Feld	Typischer Zweck	Informationsebene
Sec-CH-UA	Marken- und Hauptversionenliste	Normalerweise niedrige Entropie
Sec-CH-UA-Mobile	Ob der Kunde ein mobiles Erlebnis bevorzugt	Normalerweise niedrige Entropie
Sec-CH-UA-Platform	Breite Plattform-Kategorie	Normalerweise niedrige Entropie
Sec-CH-UA-Arch	CPU-Architektur	Hohe Entropie; Anfrage bei Bedarf
Sec-CH-UA-Bitness	Architektur-Bitigkeit	Hohe Entropie; Anfrage bei Bedarf
Sec-CH-UA-Platform-Version	Plattformversion	Hohe Entropie; Anfrage bei Bedarf
Sec-CH-UA-Full-Version-List	Vollständige Versionen für gemeldete Marken	Hohe Entropie; Anfrage bei Bedarf
Sec-CH-UA-Model	Gerätemodell	Hohe Entropie; Anfrage bei Bedarf

Drei technische Details sind leicht zu übersehen.

1. Client Hints werden nicht alle automatisch gesendet

Hinweise mit niedriger Entropie können standardmäßig erscheinen. Hinweise mit hoher Entropie erfordern meist eine Accept-CH Reaktion. Anfangsnavigation, Unterressourcen, Berechtigungsrichtlinien, sicherer Transport und Browser-Unterstützung können alle beeinflussen, was ankommt. Ein Server muss jedes optionale Feld fehlen lassen.

2. Die Markenliste testet absichtlich die Parser-Robustheit

Sec-CH-UA kann mehrere Marken und eine synthetische Marke enthalten, die zur Prüfung der Kompatibilität verwendet wird. Der Code darf nicht davon ausgehen, dass der erste Eintrag immer der Produktname ist, und er darf nicht scheitern, wenn eine unbekannte Marke erscheint. Analysieren Sie das strukturierte Feld, ignorieren Sie Einträge, die Sie nicht erkennen, und lassen Sie Platz für zukünftige Marken.

3. Antworten, die bei Hinweisen variieren, benötigen eine korrekte Cache-Handhabung

Wenn Architektur, Plattform oder ein anderer Hinweis die Antwort ändert, konfigurieren Sie Vary oder eine entsprechende Cache-Key-Strategie korrekt. Andernfalls kann ein gemeinsamer Cache Inhalte für eine Geräteklasse an eine andere ausliefern.

7. Sind Client Hints privater als die traditionelle UA?

Sie verbessern, wie Informationen offengelegt werden, bieten aber keine Immunität gegen Fingerabdrucke.

Die traditionelle UA zeigt ein großes unstrukturiertes Bündel passiv und standardmäßig auf. Client Hints dieses Bündel in Felder aufteilen, Anfragen zu Informationen mit höherer Entropie expliziter machen und dem Browser die Möglichkeit geben, Richtlinien, Berechtigungen oder Datenschutzbudgetkontrollen anzuwenden.

Architektur, Vollversionen, Plattformversionen und Gerätemodelle können jedoch weiterhin die Unterscheidbarkeit erhöhen. RFC 8942 behandelt Privatsphäre und Leistung ausdrücklich als Designbeschränkungen. Entwickler sollten fragen:

• Erfordert diese Funktion wirklich das Feld?
• Kann die Fähigkeitserkennung oder eine Nutzerwahl sie ersetzen?
• Kann die Anwendung nur eine grobe Kategorie speichern?
• Wie lange werden rohe Werte aufbewahrt und wer kann darauf zugreifen?
• Erhalten Drittanbieter-Ressourcen die gleichen Hinweise?

8. Technische Anleitungen für serverseitige UA

1. Verwenden Sie UA niemals als Identitäts- oder Autoritätsnachweis

UA können Präsentationswahl und Kompatibilitäts-Fallbacks unterstützen. Es sollte keine Identität, Autorisierung, Zahlungstreuhandschrift oder Sicherheitsgrenze bestimmen. Ein vom Client kontrollierter Wert kann nicht als Zugriffskontroll-Credential dienen.

2. Bevorzuge die Fähigkeitserkennung gegenüber Browserlisten

Wenn ein Frontend eine API benötigt, testen Sie diese Fähigkeit direkt:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

Die Fähigkeitserkennung behandelt abgeleitete Browser, experimentelle Funktionen, Unternehmensrichtlinien und zukünftige Versionen besser als eine Regel wie "enable dies for Chrome 145".

3. Akzeptieren von Legacy-UA-, Client Hints- und unbekannten Zuständen

Während der Migration kann ein Server nur die Legacy-UA erhalten, sowohl UA als auch Client Hints, oder stark reduzierte Formen beider. Das Datenmodell sollte unknown erlauben, statt zu raten, dass ein genaues Betriebssystem oder Gerätemodell jedes Feld füllt.

4. Reduzierung der Log-Granularität

Wenn Analytics nur Desktop- versus Mobilgeräte, Browserfamilie und Hauptversionen benötigt, solltest du nicht die rohen UA Strings und jeden Hinweis mit hoher Entropie unbegrenzt behalten. Datenminimierung verringert das Datenschutzrisiko und verhindert, dass eine Analysepipeline geringfügige Variationen als sinnvolle Dimension behandelt.

5. Anomalien als Beweis zu behandeln, nicht als Urteile

Eine UA, die Windows behauptet, während sich eine API anders verhält, ist höchstens ein Risikosignal. Unternehmensumgebungen, Virtualisierung, Fernsitzungen, Kompatibilitätsschichten und unterstützende Technologien können legitime Anomalien erzeugen. Wenn eine Fehlanpassung in eine automatische Betrugsentscheidung verwandelt wird, entstehen Fehlalarme.

9. Wie sollte UA in Multi-Profil-Umgebungen konfiguriert werden?

Für regionsübergreifende Tests, Werbevorschauen, Kontooperationen und Datenschutzisolation sollte das Ziel nicht sein, die ungewöhnlichste UA zu schaffen. Ein Profil sollte erklärbar, stabil und kompatibel mit seiner Umgebung sein.

Überprüfen Sie Folgendes in der richtigen Reihenfolge:

1. Browserversion: Die UA Hauptversion sollte für die eigentliche Engine und ihre Fähigkeiten plausibel sein.
2. Betriebssystem: Die Kategorie UA Plattform, Client Hints Plattform und JavaScript-sichtbare Plattform sollten kompatibel sein.
3. Architektur und Bitigkeit: UA, Client Hints und die ausführbare Umgebung sollten keine direkt widersprüchlichen Behauptungen aufstellen.
4. Geräteformfaktor: Eine mobile Deklaration sollte zusammen mit Touch-Unterstützung, Ansichtsfenster, Pixelverhältnis und Interaktionsmustern sinnvoll sein.
5. Regionaler Kontext: Sprache, Zeitzone, Geolocation und Proxy-Ausgang müssen mechanisch nicht übereinstimmen, aber sie sollten für den realen Arbeitsablauf sinnvoll sein.
6. Profilstabilität: Wenn ein Konto oder eine Testidentität ein langlebiges Profil wiederverwendet, sollten Sie vermeiden, ohne Grund die Plattform und die Hauptversion zu wechseln.

Die aktuelle Profilkonvertierung von PurpleMark mappt das ausgewählte Betriebssystem auf eine UA Plattform und versucht zunächst, die Browserversion aus einem konfigurierten Chrome/ oder CriOS/ Token zu extrahieren. Wenn keine brauchbare Version existiert, zieht sie einen vernünftigen Rückgang aus der aktuellen Hauptversion der Engine. Der Zweck ist nicht, einen isolierten String zu fälschen, sondern UA Konfiguration in ein konsistentes Browser-Profilmodell zu setzen.

Profilisolierung und Parameterkonsistenz können technische Korrelation und Testverzerrung verringern. Sie können nicht garantieren, dass Konten niemals verknüpft werden, und ersetzen keine Plattformregeln, Kontodaten, Zahlungsinformationen oder verantwortungsvolle Betriebspraktiken. Nutzen Sie diese Funktionen ausschließlich zum rechtlichen Datenschutz, legalen Prüfungen und konformen Geschäftsaktivitäten.

10. Häufig gestellte Fragen

F1: Verwandelt das Ändern UA den Browser in einen anderen Browser?

Nein. Es verändert einen Teil dessen, was der Kunde erklärt. Sie ersetzt nicht die JavaScript Engine, die Rendering-Pipeline, den Netzwerkstack oder die unterstützten Web-APIs.

F2: Kann eine Website das "echte UA" lesen?

Es gibt keinen universellen hardwarebasierten "echten UA", den jede Website den Browser umgehen kann. Eine Seite kann dennoch Client Hints, Fähigkeitstests und andere Fingerabdrucksignale vergleichen, unvereinbare Behauptungen finden und eine probabilistische Schlussfolgerung ziehen.

F3: Kann ein reduziertes UA Windows 10 von Windows 11 unterscheiden?

Das reduzierte Legacy-UA kann dies normalerweise nicht zuverlässig tun, da beide Windows NT 10.0 melden können. Ein Browser, der UA Client Hints unterstützt, kann detailliertere Informationen zur Plattformversion bereitstellen, nachdem eine Seite diese angefordert hat. Server müssen weiterhin fehlende Felder und Kartierungsunterschiede verarbeiten.

F4: Stoppt das Deaktivieren JavaScript UA Exposition?

Nicht ganz. Der HTTP User-Agent ist ein Anfrage-Header und kann zusammen mit der Seitenanfrage gesendet werden, bevor Seite JavaScript ausgeführt wird. Das Deaktivieren JavaScript entfernt einige Sammelflächen, zerstört aber auch erhebliche Teile des modernen Netzes.

F5: Werden Client Hints User-Agent komplett ersetzen?

Nehmen Sie das in kurzer Zeit nicht an. Viele Clients und Server sind weiterhin auf das Legacy-UA angewiesen, während UA Client Hints Support variiert. Behandle Client Hints als progressive Verbesserung: Bevorzuge strukturierte Informationen, wenn verfügbar, aber behalte Rückgriffe für Alt-UA und unbekannte Zustände.

F6: Verbessert ein zufällig generiertes UA die Anonymität?

Nicht unbedingt. Das Zufälligisieren eines Feldes kann Widersprüche mit Version-, Plattform-, Touch- und Rendering-Signalen erzeugen. Für ein langlebiges Profil ist eine häufige, stabile, intern kompatible Konfiguration in der Regel besser vertretbar als häufige zufällige Änderungen.

11. Fazit

User-Agent ist weder ein vertrauenswürdiger Identitätsnachweis noch ein irrelevanter String. Es befindet sich an der Schnittstelle von Webkompatibilität, Datenschutz und Risikoanalyse. Für Entwickler ist es eine Kompatibilitätseingabe, die durch die Geschichte belastet ist. Für Fingerabdruckforscher ist es eine Eigenschaft mit messbaren statistischen Informationen. Für Browserhersteller ist es eine Standard-Expositionsfläche, die reduziert werden muss.

Die Schlüsselideen fügen sich in drei Aussagen zusammen:

• Lesen Sie ein UA nicht wörtlich; es enthält viele historische Kompatibilitätstoken.
• Bewerten Sie UA nicht isoliert; Praktische Erkennung entsteht durch Kombinationen von Signalen und deren Entwicklung im Laufe der Zeit.
• Betrachten Sie Client Hints nicht nur als "mehr UA Felder"; Ihr Wert liegt in strukturierter, anforderungsgesteuerter, steuerbarer Offenlegung.

Wenn ein System von der Identifizierung eines Browsernamens hin zum Testen der benötigten Fähigkeit übergeht – und von der Sammlung aller verfügbaren Details zu der Anforderung nur noch das Notwendige –, kehrt UA zu seiner eigentlichen Rolle zurück: einem Kompatibilitätshinweis, nicht einer Identitätswahrheit.

Referenzen und Standards

1. Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
2. Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
3. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
4. Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
5. IETF. RFC 9110: HTTP Semantics, 2022.
6. IETF. RFC 8942: HTTP Client Hints, 2021.
7. WICG. User-Agent Client Hints, Draft Community Group Report.
8. Chromium. User-Agent Reduction.
9. Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.