Die Migration zu User-Agent Client Hints: Geräte messen ohne den vollständigen UA-String

Der langsame Tod des User-Agent-Strings

Jahrzehntelang war der Request-Header User-Agent das Arbeitspferd der Analytik für einfache Fragen: welcher Browser, welches Betriebssystem, mobil oder Desktop? Er war zugleich ein Datenschutzrisiko. Ein vollständiger UA-String wie Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xxx.0.0.0 Safari/537.36 verrät exakte Versionsnummern und Plattformdetails, die in Kombination mit anderen Signalen helfen, einzelne Besucherinnen und Besucher zu identifizieren.

Googles Initiative zur User-Agent-Reduktion stutzt diesen String seit Jahren. Chrome sendet inzwischen eine reduzierte UA, in der die Plattformversion eingefroren und die Nebenversionssegmente auf null gesetzt sind. Die Absicht ist laut Chrome-Dokumentation, passiv verfügbare Entropie zu entfernen und zugleich einen strukturierten, ausdrücklich angeforderten Ersatz zu erhalten: User-Agent Client Hints (UA-CH).

Wer 2026 Analytik baut, zieht daraus eine klare praktische Konsequenz. Den alten UA-String für mehr als die grobe Browserfamilie zu parsen, wird zunehmend unzuverlässig — und zunehmend zum falschen Ansatz.

Wie Client Hints tatsächlich funktionieren

UA-CH zerlegt Geräteinformationen in einzelne, anforderbare Hints statt in einen dichten String. Hints mit geringer Entropie werden standardmäßig bei jeder Anfrage mitgesendet:

• Sec-CH-UA — Liste von Marke und signifikanter Version
• Sec-CH-UA-Mobile — ein Boolean ?0 / ?1
• Sec-CH-UA-Platform — z. B. "macOS"

Hints mit hoher Entropie — vollständige Plattformversion, Architektur, Modell, Bitness — werden nicht gesendet, sofern der Server sie nicht ausdrücklich anfordert. Der Server fordert sie mit einem Accept-CH-Response-Header an, und der Browser kann sie dann bei folgenden Anfragen mitschicken. Das Präfix Sec- bedeutet, dass diese Header vom Browser kontrolliert werden und nicht per Skript gesetzt werden können — eine bedeutsame Integritätseigenschaft.

Diese Umkehrung ist für den Datenschutz entscheidend. Die Standardhaltung ist minimale Offenlegung. Zusätzliche Entropie wird zu einer bewussten Handlung, dokumentiert in Ihren eigenen Response-Headern, statt still und leise bei jedem Besuch abgegriffen zu werden.

Die datenschutzfreundliche Lesart dieser Verschiebung

Monoid bleibt bewusst auf der Seite geringer Entropie. Wir senden nie Accept-CH, um Architektur, Modell oder vollständige Plattformversion abzurufen, und wir kombinieren die Hints, die wir sehen, nie zu einer stabilen Gerätesignatur. Das wäre Fingerprinting — das Rekonstruieren einer Kennung aus Geräteeigenschaften —, also genau das, was die UA-Reduktion verhindern soll und was Artikel 5 Absatz 3 der ePrivacy-Richtlinie sowie die Anti-Fingerprinting-Richtlinien der Browser als Zugriff auf Informationen im Endgerät behandeln.

Die standardmäßigen Hints mit geringer Entropie genügen für die Fragen, die Analytik stellen sollte:

• Browserfamilie und Hauptversion aus Sec-CH-UA, für Kompatibilitäts- und Supportplanung.
• Mobil vs. nicht mobil aus Sec-CH-UA-Mobile, für Layout- und Core-Web-Vitals-Segmentierung.
• Plattform aus Sec-CH-UA-Platform, für Auswertungen auf Betriebssystemebene.

Entscheidend: Das sind aggregierte Dimensionen, keine Schlüssel pro Person. Ein Boolean und ein Plattformname, die Millionen von Besucherinnen und Besuchern teilen, haben für sich genommen keine nennenswerte Identifizierungskraft.

Hints am Edge auslesen

Weil Client Hints gewöhnliche Request-Header sind, kann ein Edge-Worker sie ohne jedes clientseitige Skript lesen. Bei Cloudflare treffen die Hints mit geringer Entropie am eingehenden Request-Objekt ein:

export default {
  async fetch(request) {
    const brands = request.headers.get('Sec-CH-UA') || '';
    const isMobile = request.headers.get('Sec-CH-UA-Mobile') === '?1';
    const platform = request.headers.get('Sec-CH-UA-Platform') || '';
    // Nur grobe Dimensionen ableiten; niemals einen zusammengesetzten Schlüssel speichern.
    return new Response('ok');
  }
};

Beachten Sie, was fehlt: kein Accept-CH-Echo, keine Anforderung von Hints mit hoher Entropie, kein Hashen der kombinierten Werte. Der Wert von Sec-CH-UA ist eine strukturierte Liste, parsen Sie ihn also sorgfältig — er enthält absichtliche „GREASE"-Markeneinträge, die brüchiges Parsen per exakter Übereinstimmung verhindern sollen, eine Technik, die sich die Spezifikation von TLS abgeschaut hat.

Was Sie in Ihrer Pipeline ändern sollten

Wenn Ihre Analytik weiterhin den vollständigen UA-String per Regex auswertet, brechen mit der Zeit drei Dinge. Versionsnummern driften zu .0.0.0, Plattformversionen frieren ein, und eine auf Teilstring-Suche gestützte Mobilerkennung wird unzuverlässig. Der Migrationsweg ist unkompliziert:

1. Bevorzugen Sie die strukturierten Hints mit geringer Entropie gegenüber dem Parsen des UA-Strings.
2. Behandeln Sie den reduzierten UA-String nur als Fallback für ältere Clients.
3. Widerstehen Sie der Versuchung, Hints mit hoher Entropie „für alle Fälle" anzufordern — jeder zusätzliche Hint vergrößert Ihre Fingerprinting-Angriffsfläche und Ihr Compliance-Risiko.

Die übergreifende Lehre passt zu allem, was wir bauen. Browserhersteller entfernen stetig passive Entropie aus der Webplattform. Die richtige Antwort ist nicht, ihr über neue APIs hinterherzujagen, sondern eine Messung zu entwerfen, die sie nie gebraucht hat.

Sources

• Chrome for Developers — User-Agent Reduction
• MDN — User-Agent Client Hints headers (Sec-CH-UA)
• W3C — User-Agent Client Hints specification
• MDN — Accept-CH header