---
url: 'https://www.corbado.com/de/blog/client-hints-user-agent-chrome-safari-firefox'
title: 'Client Hints & User-Agents in Chrome, Safari & Firefox'
description: 'Erfahren Sie mehr über die Unterstützung von User-Agent- und Client-Hints-APIs in Chrome, Safari und Firefox und wie wir sie für Passkeys und die Geräteerkennung in JavaScript-Komponenten verwenden.'
lang: 'de'
author: 'Vincent Delitz'
date: '2026-07-27T08:23:45.302Z'
lastModified: '2026-07-27T08:25:49.252Z'
keywords: 'User-Agent-Reduzierung, User-Agent, Client Hints, User-Agent Client Hints API, Client Hints Browser-Unterstützung, User-Agent-String, Client Hints Chrome'
category: 'Engineering'
---
# Client Hints & User-Agents in Chrome, Safari & Firefox
## Key Facts
- **Die User-Agent-Reduzierung** ist in allen gängigen Browsern abgeschlossen: Chrome und Edge seit 2023, Firefox teilweise und Safari eingefroren seit iOS 26 (veröffentlicht im September 2025).
- **Firefox unterstützt weder Client Hints** noch `navigator.userAgentData`, sodass Entwickler bei Mozillas Browser auf das klassische Parsen von User-Agent-Strings zurückgreifen müssen.
- Die JavaScript-API **`getHighEntropyValues()`** greift auf hochgradig entropische Gerätedaten zu, dies jedoch nur in Chromium-Browsern. Safari und Firefox fehlt diese API vollständig.
- **Eine Unterscheidung zwischen Windows 10 und Windows 11** ist allein anhand von User-Agent-Strings unmöglich. Nur Client Hints in Chrome und Edge können die tatsächliche Plattformversion preisgeben.
- Corbado nutzt Client Hints für **Passkey-Intelligenz**: um neue Geräte zu erkennen und die Berechtigung für geräteübergreifende Authentifizierung zu bewerten, insbesondere zur Unterscheidung von Windows-Versionen.
## 1. Einführung: Was sind Client Hints und User-Agent-Reduzierung?
Die Methoden zur Erkennung von und Reaktion auf unterschiedliche Benutzerumgebungen ändern sich ständig. Traditionell waren **User-Agent-Strings** das Mittel der Wahl, um Browser- und Geräteinformationen zu identifizieren, sodass Websites das Benutzererlebnis entsprechend anpassen konnten. Allerdings wurden diese Strings oft für das Fingerprinting und die Identifizierung von Benutzern ohne deren Zustimmung für Marketingzwecke verwendet, was Datenschutzbedenken aufwarf.
In diesem Zusammenhang sind **Client Hints als JavaScript-APIs** als ein Werkzeug entstanden, das eine kontrolliertere und datenschutzfreundlichere Möglichkeit bietet, notwendige Informationen über das Gerät und die Präferenzen des Benutzers zu teilen. Dieser Artikel konzentriert sich auf die **Konsequenzen der User-Agent-Reduzierung** und untersucht, wie Client Hints dabei helfen, sich an diese neue Situation anzupassen.
Wichtige Punkte, die wir ansprechen werden:
- **Was ist User-Agent-Reduzierung:** Ein Verständnis des Wandels hin zu reduzierten User-Agent-Strings und dessen Auswirkungen.
- **Wie funktionieren Client Hints:** Eine Untersuchung der Mechanismen hinter Client Hints und wie sie effektiv implementiert werden können.
Da Browser und Betriebssysteme unterschiedliche Positionen einnehmen und ihre Ansätze unterschiedlich anpassen, stehen Softwareentwickler vor der Herausforderung sicherzustellen, dass ihre Anwendungen verschiedene Benutzerumgebungen über alle Browser und Betriebssysteme hinweg weiterhin genau erkennen und darauf reagieren können.
Dieser Artikel zielt darauf ab, einen umfassenden Überblick über diese Änderungen zu geben und bietet Einblicke und praktische Anleitungen für Entwickler, falls deren Anwendungsfall oder Software von Geräte- oder Betriebssystemdetails abhängt (z. B. detailliertes Gerätemanagement, Erkennung bekannter Geräte, Betrugsprävention oder andere Funktionserkennungen) oder wie in unserem eigenen Fall, um das **Passkey-Erlebnis mit User-Agents und Client Hints zu optimieren**.
Bevor wir in die technischen Details zu Client Hints eintauchen, werden wir kurz die Geschichte des User-Agents erkunden und uns ansehen, wie die verschiedenen Bemühungen zur User-Agent-Reduzierung funktionieren.
### 1.1 Eine kurze Geschichte des User-Agents
Die Geschichte der User-Agent-Strings lässt sich bis zu den Anfängen der ersten Webbrowser zurückverfolgen. Tim Berners-Lee entwickelte 1990 den ersten Webbrowser, WorldWideWeb (später in Nexus umbenannt). Diesem folgten bald weitere wegweisende Browser wie der Line Mode Browser 1991, und anschließend erschienen Browser wie MidasWWW, ViolaWWW, Erwise und Cello.
Im Jahr 1993 wurde die Veröffentlichung von [NCSA Mosaic](https://en.wikipedia.org/wiki/NCSA_Mosaic), oft einfach Mosaic genannt, für den anfänglichen Popularitätsschub des Webs verantwortlich gemacht. Der User-Agent-String von Mosaic war recht unkompliziert, typischerweise formatiert als `NCSA_Mosaic/1.0`, bestehend aus dem Produktnamen gefolgt von einem optionalen Schrägstrich und der Versionsnummer.
Ursprünglich wurde das **User-Agent-Feld für Analysezwecke und zur Identifizierung von Problemen eingeführt**. Es wurde ausdrücklich empfohlen, dass dieses Feld in HTTP-Anfragen "enthalten sein sollte", wie im W3C HTTP-Archiv von 1992 vermerkt ist. Dieses unkomplizierte Feld bot eine einfache, aber effektive Möglichkeit, den Produktnamen und die Version zu übermitteln, was beim Verständnis und der Behebung von browserbezogenen Problemen half.
Mit der Entwicklung des Webs nahm auch die Komplexität und Nutzung von User-Agent-Strings zu. Sie wurden detaillierter und begannen, eine Fülle von Informationen über den Browser, das Betriebssystem und das Gerät aufzunehmen. Während diese Informationen für Webanalysen und die Optimierung des Benutzererlebnisses wertvoll waren, brachten sie auch **erhebliche Datenschutzbedenken** mit sich. Detaillierte User-Agent-Strings **ermöglichten das Geräte-Fingerprinting**, was es Werbetreibenden und Trackern erlaubte, eindeutige Profile von Benutzern zu erstellen und deren Online-Aktivitäten über verschiedene Websites hinweg zu verfolgen.
In der modernen Ära, in der Datenschutz für Benutzer und Regulierungsbehörden gleichermaßen ein wichtiges Anliegen geworden ist, wurde die Detailliertheit von User-Agent-Strings zunehmend als problematisch angesehen. Diese Erkenntnis hat zu Bemühungen geführt, die Granularität von User-Agent-Strings zu reduzieren, mit dem Ziel, ein Gleichgewicht zwischen der Bereitstellung notwendiger Informationen für die Webfunktionalität und dem Schutz der Privatsphäre der Benutzer zu finden.
Dieser Übergang markiert den Beginn der **User-Agent-Reduzierung, einer Bewegung hin zur Minimierung der in User-Agent-Strings geteilten Informationen, um Datenschutzrisiken zu mindern und die Sicherheit zu erhöhen**.
### 1.2 Einführung in User-Agent-Reduzierung & Client Hints
Die Bewegung zur User-Agent-Reduzierung begann als Reaktion auf wachsende Datenschutzbedenken. Hier ist eine chronologische Übersicht der wichtigsten Meilensteine dieser Entwicklung:
#### 1.2.1 User-Agents in Safari
Im Jahr 2017 leitete Apple die **Bewegung zur User-Agent-Reduzierung mit einem berühmten Twitter-Post** ([hier auf X (ehemals Twitter)](https://x.com/rmondello/status/943545865204989953)) ein, in dem angekündigt wurde, dass Safari den User-Agent-String in Safari Technology Preview 46 (STP 46) einfrieren würde, um Fingerprinting zu bekämpfen und den Datenschutz zu verbessern.
Diese Entscheidung wurde jedoch später im Jahr 2021 aufgrund erheblicher Kompatibilitätsprobleme mit Websites, die auf aktuelle User-Agent-Informationen angewiesen waren, teilweise revidiert.
#### 1.2.2 User-Agents in Chrome (+ Edge)
In den Jahren 2019/2020 kündigte Google Pläne an, die Granularität von User-Agent-Strings in Chrome zu reduzieren ([siehe hier](https://groups.google.com/a/chromium.org/g/blink-dev/c/-2JIRNMWJ7s/m/u-YzXjZ8BAAJ)) und führte [User-Agent Client Hints (UA-CH)](https://chromestatus.com/feature/5704553745874944) als flexible und kontrollierte Möglichkeit ein, spezifische Browser- und Geräteinformationen anzufordern. Google begann, die User-Agent-Reduzierung in Chrome Canary- und Beta-Versionen zu testen, sammelte Feedback, um Kompatibilität und Funktionalität sicherzustellen, und die Reduzierung wurde [2023 abgeschlossen](https://www.chromium.org/updates/ua-reduction/) für Android und alle anderen Chrome-Plattformen. Gleichzeitig **führte Chrome Client Hints ein**, als neue Möglichkeit, auf diese Informationen zuzugreifen. Da Microsoft Edge auf Chromium basiert, verhält sich Microsoft Edge auf allen Plattformen wie Chrome.
#### 1.2.3 User-Agents in Firefox
Im Jahr 2021 schloss sich Mozilla der Initiative an und reduzierte allmählich die Granularität des User-Agent-Strings, entschied sich jedoch dafür, **Client Hints in Firefox nicht zu unterstützen**.
#### 1.2.4 User-Agents heute (aktualisiert im September 2025)
- **User-Agent-Reduzierung variiert je nach Browser:** Chromium (Chrome, Edge) hat eine vollständige UA-Reduzierung mit Unterstützung für Client Hints implementiert. Safari nutzt jedoch seinen eigenen Ansatz mit eingefrorenen UAs ohne UA-CH zu übernehmen, und Firefox hat `navigator.userAgentData` nicht implementiert. Das Ökosystem bleibt zersplittert.
- **Client Hints haben sich in Chromium weiterentwickelt:** Alle Browser senden weiterhin einen User-Agent-Header, aber bei den meisten ist dieser auf eine ältere Version eingefroren (siehe Tabelle unten). Für Chromium können Client Hints verwendet werden, um mehr Informationen zu erhalten.
Lassen Sie uns im folgenden Kapitel ansehen, was Browser derzeit als User-Agents senden.
## 2. Was ist User-Agent-Reduzierung?
Wenn von User-Agent-Reduzierung die Rede ist, ist damit gemeint, die **Informationen innerhalb des User-Agent-Strings zu reduzieren**. Lassen Sie uns tiefer eintauchen, um herauszufinden, was vor der Reduzierung im User-Agent eingebettet war.
### 2.1 Was ist ein klassischer User-Agent?
Ein klassischer User-Agent-String enthielt typischerweise die folgenden Komponenten, die zur Erkennung von Funktionen verwendet werden konnten:
`Mozilla/5.0 (Linux; Android 13; Pixel 7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.2.1.0 Mobile Safari/537.36`
- **Betriebssystem:** Der Name des Betriebssystems (z. B. Windows, macOS, Linux).
- **Betriebssystemversionsnummer:** Die spezifische Version des Betriebssystems.
- **Browser-Name:** Der Name des Browsers (z. B. Chrome, Firefox, Safari).
- **Browser-Version:** Die spezifische Version des Browsers.
- **Architektur:** Die Architektur des Systems (z. B. x86, ARM).
- **Gerätetyp/Modell:** Informationen über den Gerätetyp oder das Modell (z. B. iPhone, Pixel).
- **Weitere Informationen:** Dies kann zusätzliche Details wie Plattform, Build-Nummer usw. umfassen.
#### 2.1.1 Warum User-Agents zur Funktionserkennung verwenden?
Historisch gesehen wurden User-Agent-Strings oft für die Funktions- und Plattformerkennung verwendet, wodurch Websites ihre Inhalte und Funktionen basierend auf den erkannten Browser- und Geräteeigenschaften anpassen konnten (z. B. um zu bestimmen, welcher Download für ein bestimmtes Binary angeboten werden soll). Dies wurde besonders wichtig mit dem Aufkommen von Mobiltelefonen und Tablets für Layouts, die nicht responsiv aufgebaut waren, um Mobiltelefone auf ihre spezifische Version umzuleiten.
Dieser Ansatz wird nun jedoch **als suboptimal angesehen, da er auf Annahmen über Browser-Fähigkeiten beruht, die möglicherweise nicht zutreffen oder nicht spezifisch genug sind**. Moderne Webentwicklungspraktiken befürworten, wo immer möglich, die **Funktionserkennung über Browser-APIs** zu nutzen, um direkt auf spezifische Browser-Funktionen und -Fähigkeiten zu prüfen. Diese Methode ist zuverlässiger und stellt sicher, dass Websites unabhängig vom User-Agent-String oder der Browser-Version korrekt funktionieren. Die Funktionserkennung konzentriert sich auf die tatsächlichen Fähigkeiten des Browsers und bietet eine robustere und zukunftssicherere Möglichkeit, Unterschiede im Verhalten und in der Funktionalität von Browsern zu handhaben.
Bis heute ist dies nicht vollständig möglich, da neue Browser-APIs zur Erkennung von Funktionen zu unterschiedlichen Zeiten implementiert werden und es oft einen unterschiedlichen Ansatz zwischen den größeren (z. B. Chromium-basierten Browsern) und kleineren Browser-Teams (z. B. Firefox) gibt.
#### 2.1.2 Entropie beim Fingerprinting verstehen: Warum ist die Bereitstellung vieler Informationen ein Problem?
Mehr Informationen geben einer Website eine größere Möglichkeit, einen Fingerabdruck mit mehr "Entropie" zu erstellen. Entropie ist in diesem Zusammenhang das Maß an Variation, das verwendet werden kann, um einen eindeutigen Fingerabdruck unter den verschiedenen Besuchern einer Website zu generieren.
Ein Fingerabdruck kann für verschiedene Zwecke verwendet werden. Er kann zu Schutzzwecken eingesetzt werden, wie z. B. zur Aufdeckung von Betrug und zur Verhinderung von Kontoübernahmen durch Identifizierung neuer Geräte, aber er kann auch dazu verwendet werden, Besucher ohne deren Zustimmung zu identifizieren oder für ein spezifischeres Ad-Targeting.
Im Kontext von User-Agent-Strings bezieht sich Entropie auf die Menge an eindeutigen, identifizierbaren Informationen, die verwendet werden können, um einzelne Benutzer zu tracken und zu unterscheiden.
- **Informationen mit hoher Entropie:** Wie spezifische Browser- und Betriebssystemversionen, tragen signifikant zur Einzigartigkeit des Fingerabdrucks eines Benutzers bei und erleichtern es, ihn über verschiedene Websites hinweg zu verfolgen.
- **Informationen mit geringer Entropie:** Allgemeine Browser- oder Betriebssystemnamen, liefern weniger detaillierte Daten und tragen weniger zum User-Tracking bei, da mehr Benutzer diese Kombinationen aufweisen.
Es gibt viele weitere Informationen, die als Entropiequelle neben dem User-Agent verwendet werden können. Verschiedene Entropiequellen finden Sie beispielsweise auf [https://coveryourtracks.eff.org](https://coveryourtracks.eff.org).
### 2.2 Reduzierung der User-Agent-Entropie
Wenn Browser also von der User-Agent-Reduzierung sprechen, zielen sie in erster Linie darauf ab, die Informationen mit hoher Entropie zu reduzieren. Hier sind verschiedene Beispiele für die Reduzierung:
#### 2.2.1 Beispiel 1: Chrome User-Agent-Reduzierung
Im Folgenden finden Sie ein Beispiel für die User-Agent-Reduzierung von Googles Chrome auf einem Android-Handy:
**Vorher:**
`Mozilla/5.0 (Linux; Android 13; Pixel 7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.0.0 Mobile Safari/537.36`
**Nachher:**
`Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.0.0 Mobile Safari/537.36`
Das Format des User-Agents blieb unverändert, um bestehende Parsing-Logik von Bibliotheken nicht zu stören. Die folgenden Werte wurden reduziert:
- Betriebssystemversion
- Browser-Minor-Version
- Hardware-Modell 
Die Grafik zeigt detailliert, welche Werte weiterhin basierend auf dem Betriebssystem aktualisiert werden, und die grünen Werte zeigen, welche Werte auf allen Plattformen konstant bleiben. Für verschiedene Betriebssystemwerte wird es nur noch eine Variante geben, die konstant bleibt:
| **Betriebssystem** | **Reduzierter/fester Name** |
| ------------------ | --------------------------------- |
| Mac | Macintosh; Intel Mac OS X 10_15_7 |
| Windows | Windows NT 10.0; Win64; x64 |
| ChromeOS | X11; CrOS x86_64 14541.0.0 |
| Linux | X11; Linux x86_64 |
| Android | Linux; Android 10; K |
| iOS | reduziert (iOS 26+) |
#### 2.2.2 Beispiel 2: Firefox User-Agent-Reduzierung
Im Folgenden finden Sie ein Beispiel für die User-Agent-Reduzierung von Mozilla Firefox, die in den meisten Punkten Googles Positionen zur User-Agent-Reduzierung folgt.
Hier ist ein Beispiel für einen User-Agent unter Windows 11 mit einer aktuellen Firefox-Version:
`Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0`
In diesem User-Agent wurden die CPU-Architektur, die Betriebssystemversion und die Browser-Minor-Version eingefroren.
#### 2.2.3 Beispiel 3: Safari User-Agent-Reduzierung unter macOS
Im Folgenden finden Sie ein Beispiel für eine Safari User-Agent-Reduzierung unter macOS.
Beginnen wir zunächst mit einem **Safari User-Agent unter macOS Sonoma Version 14.5** auf einem Mac Silicon M2.
`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15`
Sie können sehen, dass die macOS-Version auf `10_15_07` begrenzt ist und die Architektur ebenfalls auf `Intel` festgelegt ist und nicht die Mac-CPU-Architektur meldet. Dies gilt auch für Firefox und [Chrome](https://issues.chromium.org/issues/40167872) unter macOS.
#### 2.2.4 Beispiel 4: Safari User-Agent unter iOS (Jetzt reduziert ab iOS 26)
Vor iOS 26 (veröffentlicht im September 2025) legte Safari unter iOS die tatsächliche Betriebssystemversion offen. **Apple hat jedoch den iOS/iPadOS User-Agent in Safari 26 eingefroren**, ähnlich wie bei macOS. Das Beispiel unten zeigt einen User-Agent vor iOS 26:
`Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1`
**Hinweis:** Ab iOS 26 verfügen alle Browser unter iOS (Chrome, Firefox, Safari) über eingefrorene User-Agent-Strings, ähnlich wie macOS. Die Beispiele unten zeigen das Verhalten vor iOS 26:
`Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/126.0.6478.153 Mobile/15E148 Safari/604.1`
`Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/127.1 Mobile/15E148 Safari/605.1.15`
### 2.3 Erkennungsgrenzen bei reduzierten User-Agents
Insgesamt ist offensichtlich, dass der User-Agent speziell im Hinblick auf Informationen mit hoher Entropie reduziert wird. Die folgende Übersicht zeigt, auf welchen Plattform- / Betriebssystemkombinationen der User-Agent reduziert ist.
| **Browser** | **Windows** | **MacOS** | **iOS** | **Android** |
| ---------------- | ----------- | --------- | -------------------------- | --------------------------- |
| Chrome | reduziert | reduziert | reduziert (iOS 26+) | reduziert |
| Edge | reduziert | reduziert | reduziert (iOS 26+) | reduziert |
| Firefox | reduziert | reduziert | reduziert (iOS 26+) | reduziert |
| Safari | - | reduziert\* | reduziert (Safari 26+)\*\* | - |
| Samsung Internet | - | - | - | reduziert |
| WebViews | - | - | reduziert (iOS 26+) | nicht reduziert (≥ 16: red) |
Daher sind die wichtigsten Erkennungsprobleme mit einem reduzierten User-Agent (* = siehe Anmerkungen unten für die macOS-Version):
- **Windows 10 und Windows 11 können nicht unterschieden werden:** Sie können Windows 10- und Windows 11-Systeme nicht mehr anhand des User-Agents unterscheiden.
- **Android-Geräte und -Betriebssystemversionen können nicht unterschieden werden:** Im Gegensatz zu Apple schloss Android früher das tatsächliche Hardware-Modell in den User-Agent ein. Dies ist nicht mehr der Fall. Daher können verschiedene Hardware-Modelle nicht mehr nur über den User-Agent unterschieden werden. Bei Apple war dies noch nie möglich.
- **macOS-Version und -Architektur können nicht unterschieden werden:** Es gibt keine Möglichkeit, macOS-Versionen und Plattformarchitekturen anhand des User-Agents zu unterscheiden.
- **(\*) macOS-Version in Safari:** Safari hat die Betriebssystemversion eingefroren, zeigt aber weiterhin die Safari-Version an. Zum Zeitpunkt des Schreibens dieses Artikels ist es für Version 10.15 und höher sicher, drei von der Safari-Version abzuziehen, um die Hauptversion von macOS zu erkennen.
- **(\*\*) iOS-Version in Safari 26+:** Ab iOS 26 (September 2025) hat Apple den iOS/iPadOS User-Agent eingefroren, ähnlich wie bei macOS. Die Betriebssystemversion wird nicht mehr offengelegt.
Hier ist eine Tabelle, die macOS-Versionen ihren entsprechenden Safari-Versionen zuordnet:
| **macOS Version** | **Safari Version** | **Erscheinungsjahr** |
| ---------------------- | ------------------ | -------------------- |
| macOS Sequoia (15) | Safari 18 | 2024 |
| macOS Sonoma (14) | Safari 17 | 2023 |
| macOS Ventura (13) | Safari 16 | 2022 |
| macOS Monterey (12) | Safari 15 | 2021 |
| macOS Big Sur (11) | Safari 14 | 2020 |
| macOS Catalina (10.15) | Safari 13 | 2019 |
Es gibt andere Möglichkeiten, Betriebssysteme und Browser auf der Grundlage aufwändiger Fingerprinting-Techniken wie dem TLS-Fingerprinting zu erkennen. Da es legitime Szenarien gibt, in denen eine tiefere Betriebssystemerkennung sinnvoll wäre, hat Google Client Hints eingeführt, um diese Informationen programmatisch abrufen zu können. Wir werden im nächsten Kapitel sehen, wie Client Hints funktionieren.
## 3. Wie funktionieren Client Hints?
Client Hints ermöglichen es Websites, auf hoch entropische Informationen, die aus dem User-Agent-String entfernt wurden, auf datenschutzfreundliche Weise zuzugreifen. Es gibt zwei primäre Methoden, um auf Client Hints zuzugreifen:
- **HTTP-Header**: Über HTTP-Anfrage-Header, was nur im First-Party-Kontext verfügbar ist.
- **JavaScript-API**: Über eine JavaScript-API, die von einem eingebetteten Skript verwendet werden kann.
Client Hints können auch verwendet werden, um die niederentropischen Informationen abzurufen, die bereits im User-Agent enthalten sind. Dies impliziert, dass in Chrome, wo Client Hints unterstützt werden, User-Agents nicht mehr benötigt werden.
### 3.1 Welche Client Hints gibt es?
Je nachdem, welche Zugriffsmethode verwendet wird, unterscheidet sich die Benennung der Client Hints leicht. Wir haben die wichtigsten Namen von Client Hints aufgelistet:
| **HTTP UA-CH Token** | **UA-CH JS API** | **Entropie** |
| -------------------------- | ---------------------------- | ------------ |
| Sec-CH-UA-Platform-Version | UADataValues.platformVersion | Hoch |
| Sec-CH-UA-Mobile | NavigatorUAData.mobile | Niedrig |
| Sec-CH-UA-Model | UADataValues.model | Hoch |
| Sec-CH-UA | NavigatorUAData.brands | Niedrig |
| Sec-CH-UA-Arch | UADataValues.architecture | Hoch |
### 3.2 Zugriff auf Client Hints über HTTP-Anfrage-Header
In einem First-Party-Kontext können Websites spezifische Informationen über den Browser und das Gerät des Benutzers über HTTP-Anfrage-Header anfordern. Dieser Ansatz beinhaltet das Setzen des korrekten Headers in der HTTP-Antwort des Servers, der angibt, an welchen Client Hints der Server interessiert ist. Der Browser fügt diese Hints dann in nachfolgende Anfragen an denselben Ursprung (Origin) ein.
Dieser Header signalisiert dem Browser, in zukünftigen Anfragen detaillierte Benutzerinformationen zu senden, wodurch der Server die Antworten entsprechend anpassen kann. Diese Methode stellt sicher, dass detaillierte Benutzerinformationen nur für die First-Party-Website zugänglich sind und verhindert, dass Ressourcen von Drittanbietern hoch entropische Daten erhalten. Es gibt zwei Arten von Anfrage-Headern, die wir jetzt besprechen werden:
- Reguläre Client-Hint-Header
- Kritische (Client-)Hint-Header
#### 3.2.1 Wie verwendet man reguläre Client-Hint-Header?
Reguläre Client Hints sind Header, die ein Server vom Browser anfordern kann, um Informationen über die Umgebung des Benutzers **in nachfolgenden Anfragen** zu sammeln.
**Beispiel: Chrome unter macOS 14.5 mit regulären Client Hints auf corbado.com**
1. Bei der ersten Anfrage für corbado.com wird Chrome bereits die folgenden Header mit niedriger Entropie enthalten, da diese Informationen auch im User-Agent enthalten sind.
| **Header** | **Wert** |
| ------------------ | ----------------------------------------------------------------- |
| Sec-CH-UA | "Google Chrome";v="125", "Chromium";v="125", "Not.A/Brand";v="24" |
| Sec-CH-UA-Mobile | ?0 |
| Sec-CH-UA-Platform | "macOS" |
2. Nehmen wir an, corbado.com möchte die Betriebssystemversion (Plattformversion) bei **nachfolgenden Anfragen** erhalten. Daher würde es dann den entsprechenden Header "Sec-CH-UA-Platform-Version" in der Antwort auf die erste Anfrage setzen:
| **Header** | **Wert** |
| ---------- | -------------------------- |
| Accept-CH | Sec-CH-UA-Platform-Version |
3. Bei **nachfolgenden Anfragen** würde corbado.com dann einen zusätzlichen Header mit der Plattformversion erhalten:
| **Header** | **Wert** |
| -------------------------- | ----------------------------------------------------------------- |
| Sec-CH-UA | "Google Chrome";v="125", "Chromium";v="125", "Not.A/Brand";v="24" |
| Sec-CH-UA-Mobile | ?0 |
| Sec-CH-UA-Platform | "macOS" |
| Sec-CH-UA-Platform-Version | "14.5.0" |
Gleichzeitig bleibt der User-Agent für diese Anfrage unverändert (ohne Plattformversion):
`Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36`
Über [https://user-agent-client-hints.glitch.me/headers](https://user-agent-client-hints.glitch.me/headers) können Sie tatsächlich damit herumspielen, wie verschiedene Informationslayouts für reguläre Hints aussehen würden (denken Sie daran, **Sie müssen Chrome verwenden**). Weitere Details finden Sie [hier](https://github.com/WICG/ua-client-hints). Falls corbado.com diese Informationen bereits beim allerersten Seitenaufruf benötigen würde, wäre die Verwendung von regulären Client Hints nicht ausreichend, aber es gibt eine Möglichkeit, diesen Prozess mit kritischen (Client) Hints zu beschleunigen.
#### 3.2.2 Wie verwendet man kritische (Client) Hint-Header?
Angenommen, [corbado.com](https://corbado.com) benötigt die Plattformversion bei der ersten Anfrage, um eine entsprechende Download-Seite zu rendern, die genau auf die macOS-Version zugeschnitten ist. Es könnte die Critical (Client) Hints verwenden, was zu einem **sofortigen erneuten Versuch der Anfrage** führen würde, um die Seite einschließlich des Headers zu rendern:
**Beispiel: Chrome unter macOS 14.5 mit kritischen Client Hints auf corbado.com**
1. Bei der ersten Anfrage für corbado.com wird Chrome bereits die folgenden Header mit niedriger Entropie enthalten, da diese Informationen auch im User-Agent enthalten sind.
| **Header** | **Wert** |
| ------------------ | ----------------------------------------------------------------- |
| Sec-CH-UA | "Google Chrome";v="125", "Chromium";v="125", "Not_A/Brand";v="24" |
| Sec-CH-UA-Mobile | ?0 |
| Sec-CH-UA-Platform | "macOS" |
2. Angenommen, corbado.com möchte die Betriebssystemversion (Plattformversion) beim **ersten Rendern der Seite** erhalten. Es würde dann den kritischen Client-Hint-Header "Sec-CH-UA-Platform-Version" in der Antwort auf die erste Anfrage setzen:
| **Header** | **Wert** |
| ---------- | -------------------------- |
| Accept-CH | Sec-CH-UA-Platform-Version |
3. Chrome würde nicht mit dem Rendern beginnen und die Anfrage sofort erneut versuchen, sodass **der Header beim ersten Rendern** von corbado.com verfügbar ist. Es würde dann den zusätzlichen Header mit der Plattformversion erhalten:
| **Header** | **Wert** |
| -------------------------- | ----------------------------------------------------------------- |
| Sec-CH-UA | "Google Chrome";v="125", "Chromium";v="125", "Not_A/Brand";v="24" |
| Sec-CH-UA-Mobile | ?0 |
| Sec-CH-UA-Platform | "macOS" |
| Sec-CH-UA-Platform-Version | "14.5.0" |
In den folgenden Diagrammen sehen wir **ein weiteres Beispiel**, bei dem die Website das Gerätemodell als kritischen Teil mit dem Critical-CH-Header anfordert. Wie wir sehen können, versucht der Client die Anfrage wie im obigen Beispiel erneut (linkes Sequenzdiagramm).
_Client Hints mit Chromium: [https://developers.google.com/privacy-sandbox/protections/User-Agent](https://developers.google.com/privacy-sandbox/protections/User-Agent)_
Die Verwendung von kritischen Client Hints fügt daher Latenz hinzu, da der Browser sofort eine zweite Anfrage starten muss, was Roundtrips hinzufügt. Es gibt eine Möglichkeit, die Übertragung zu optimieren, indem der **TLS-Handshake erleichtert wird** (das grüne Kästchen oben im Diagramm), um die Details bereits zu übertragen. Dieser Ansatz zur Erleichterung von **[ALPN](https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation) (Application-Layer Protocol Negotiation)** ist [hier](https://docs.google.com/document/d/1HQd3vosjFls2jp6DwpkNMUN4CBdmmxZJJz0WhhcqOPw/edit) im Detail zu finden, sprengt aber den Rahmen dieses Artikels.
Um zusätzliche Informationen mithilfe von Headern zu erhalten, muss die Konfiguration entweder dem Backend oder dem Webserver / Load Balancer hinzugefügt werden. Dies ist in einem First-Party-Kontext leicht zu bewerkstelligen, wenn Sie als Unternehmen die volle Kontrolle über die Website haben. Beispielsweise benötigen unsere UI-Komponenten auf corbado.com die Plattformversion, um die Präzision unserer [Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) zu erhöhen. Entwickler integrieren unsere Komponenten auf verschiedenen Seiten und von ihnen zu verlangen, Header hinzuzufügen und diese Informationen dann an unsere Komponenten weiterzugeben, wäre ein unangenehmer Mehraufwand. Für SPAs und andere eingebettete JavaScript-Anwendungen gibt es eine weitere Schnittstelle, die verwendet werden kann, was im nächsten Abschnitt erläutert wird.
### 3.3 Zugriff auf Client Hints über JavaScript-API (Eingebettete Skripte)
Mithilfe der Funktion [navigator.userAgentData.getHighEntropyValues()](https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData/getHighEntropyValues) kann auch über eine JavaScript-API auf Client Hints zugegriffen werden, was eine flexible und dynamische Möglichkeit bietet, spezifische Informationen über den Browser und das Gerät des Benutzers anzufordern. Diese Methode beinhaltet die Verwendung des Objekts `navigator.userAgentData` innerhalb des Skripts der Webseite, um Client Hints abzufragen. **Diese Methode erfordert nicht, dass Client-Hint-Header gesetzt werden, aber sie funktioniert nur in Browsern, die `navigator.userAgentData` unterstützen (Chromium-basierte Browser wie Chrome und Edge). Firefox und Safari unterstützen diese API nicht, sodass Entwickler eine Feature-Erkennung durchführen und Fallbacks bereitstellen müssen.**
Wenn Sie diesen Code beispielsweise in einer Chrome-Konsole unter macOS ausführen:
```javascript
if (navigator.userAgentData) {
navigator.userAgentData
.getHighEntropyValues(["architecture", "model", "platformVersion"])
.then((ua) => {
console.log(ua);
});
}
```
Wenn der Promise aufgelöst wird, werden die relevanten Informationen zurückgegeben. Wie wir oben skizziert haben, sind die Namen nicht vollständig identisch mit den Headern, kommen diesen aber sehr nahe.
Die `platformVersion` wird dann im Promise zurückgegeben und kann direkt aus dem eingebetteten JavaScript-Code abgerufen werden. Die Abdeckung für diese Funktion ist viel geringer als die tatsächliche User-Agent-Reduzierung:
Darüber hinaus bietet Chrome diese Funktionalität unter iOS nicht an, da es aufgrund von Apples Einschränkungen WebKit unter iOS einsetzt.
Wir haben nun die wichtigsten Fakten zur User-Agent-Reduzierung zusammengestellt und aufgezeigt, wie Client Hints einen Ausweg in Chrome bieten.
## 4. Empfehlung für den heutigen Umgang mit User-Agents
Abhängig von Ihrem Anwendungsfall sollten Sie einen anderen Ansatz wählen, um sicherzustellen, dass Ihre Anwendung das bestmögliche Ergebnis erzielt:
- **Funktionserkennung: Verwenden Sie vorhandene Browser-JavaScript-APIs, wo immer dies möglich ist**. Verlassen Sie sich nach Möglichkeit auf Browser-APIs, um Funktionen direkt zu erkennen, anstatt den User-Agent zu verwenden. Dies ist zuverlässiger und zukunftssicherer.
- **Für geringe Entropie reichen Hinweise wie Gerätetyp: Der User-Agent ist ausreichend**. Wenn Ihre Anwendung nur den Gerätetyp oder andere Details mit geringer Entropie ermitteln muss, ist der User-Agent-String ausreichend detailliert. Sie können für diese Zwecke auch vorhandene APIs verwenden.
- **Für hoch entropische Informationen und Domainkontrolle: Verwenden Sie den Header-Ansatz**. Wenn Sie detaillierte Informationen benötigen und die Kontrolle über die Domain haben, nutzen Sie den HTTP-Header-Ansatz, um hoch entropische Informationen anzufordern, wo diese unterstützt werden (Chrome, Edge). In allen anderen Browsern (die keine Client-Hint-Header senden) verwenden Sie den klassischen User-Agent. Entscheiden Sie, ob Sie kritische Client Hints verwenden müssen, je nachdem, ob Sie die Informationen sofort benötigen oder eine leichte Verzögerung in Kauf nehmen können.
- **Für JavaScript-Bibliotheken: Verwenden Sie getHighEntropyValues**. Wenn Sie eine JavaScript-Bibliothek entwickeln, ist die beste Option, die Funktion navigator.userAgentData.getHighEntropyValues() zu verwenden, um spezifische Informationen über den Browser und das Gerät des Benutzers dynamisch anzufordern, wann immer diese Funktion definiert ist, und in anderen Fällen auf User-Agent-Parsing-Bibliotheken zurückzugreifen.
Die folgende Tabelle fasst zusammen, wo Sie die Betriebssystemversion noch erkennen können, wenn Sie Zugriff auf den User-Agent (UA) und Client Hints (CH) haben:
| **Browser** | **Windows** | **MacOS** | **iOS** | **Android** |
| ---------------- | ----------- | ------------ | --------------- | ---------------- |
| Chrome | ✅ CH | ✅ CH | ❌ (iOS 26+) | ✅ CH |
| Edge | ✅ CH | ✅ CH | ❌ (iOS 26+) | ✅ CH |
| Firefox | ❌ | ❌ | ❌ (iOS 26+) | ❌ |
| Safari | - | ✅ UA-Safari | ❌ (Safari 26+) | - |
| Samsung Internet | - | - | - | ✅ CH |
| WebViews | - | - | ❌ (iOS 26+) | ✅ UA (≥ 16: ❌) |
Durch die Auswahl der geeigneten Methode basierend auf Ihren spezifischen Anforderungen können Sie den Bedarf an detaillierten Benutzerinformationen mit Datenschutz- und Leistungsüberlegungen effektiv in Einklang bringen. Wenn Sie stark von Informationen abhängig sind, die schwer zu extrahieren oder sehr gerätespezifisch sind, greifen Sie auf professionelle Bibliotheken wie [wurfl](https://web.wurfl.io/) oder [51degrees.com](https://51degrees.com) zurück, die Ihnen die schwere Arbeit abnehmen. Beide Bibliotheken unterstützen die Integration von Client-Links in die Erkennung und verfügen auch über eine eigene proprietäre Methode, um sogar iPhone-Modelle zu erkennen.
## 5. Wie man User-Agents und Client Hints für Passkeys nutzt
Bei Corbado konzentrieren wir uns auf die Entwicklung von Lösungen rund um Passkeys mithilfe von UI-Komponenten, die hauptsächlich mit React entwickelt wurden. Unsere Komponenten werden in verschiedene Websites eingebettet, daher folgen wir unserer eigenen Empfehlung und verwenden getHighEntropyValues() überall dort, wo es verfügbar ist, und greifen für alle anderen Fälle auf das klassische User-Agent-Parsing zurück. Wir verwenden dies hauptsächlich für:
- **Passkey-Verwaltung:** Auf unserer Website zur Passkey-Verwaltung zeigen wir alle verfügbaren Informationen über das Gerät an, auf dem der Passkey erstellt wurde.
- **Geräteübergreifende Authentifizierung:** Für die geräteübergreifende Authentifizierung (CDA) verwenden wir Informationen über das Betriebssystem, um zu bestimmen, wie wahrscheinlich es ist, dass der Client die Nutzung von CDA unterstützt. Dies ist besonders wichtig, wenn zwischen Windows 10 und 11 unterschieden wird, was nur mit Client Hints in Chrome und Edge möglich ist:
_Weitere Details auf: [https://learn.microsoft.com/en-us/microsoft-edge/web-platform/how-to-detect-win11](https://learn.microsoft.com/en-us/microsoft-edge/web-platform/how-to-detect-win11)_
- **Passkey Intelligence:** Wir sind der Meinung, dass die Plattform entscheiden sollte, ob ein Passkey-Login initiiert werden soll. Daher integrieren wir so viel Logik wie möglich in unsere Komponenten, um zu erkennen, ob ein neues Gerät verwendet wird. In solchen Szenarien ist eine neue oder kleinere Betriebssystemversion ein wertvoller Hinweis darauf, dass sich die Dinge geändert haben könnten.
Als wir anfingen, Informationen für unsere Komponenten zusammenzustellen, stießen wir auf viele fragmentierte Daten, die während oder vor dem Start der User-Agent-Reduzierung erstellt wurden. Daher dachten wir, eine Zusammenfassung würde Entwicklern helfen, die die Erkennung verbessern wollen, aber nicht regelmäßig mit User-Agents oder Client Hints arbeiten.
## 6. Fazit
Nachdem die User-Agent-basierte Erkennung jahrzehntelang der Standard war, sind User-Agent-Strings weniger detailliert geworden, um die Privatsphäre der Benutzer zu schützen.
In diesem Artikel haben wir Folgendes behandelt:
- **Was ist User-Agent-Reduzierung?** Die User-Agent-Reduzierung ist der Prozess der Minimierung der über User-Agent-Strings geteilten Informationsmenge, um die Privatsphäre der Benutzer zu schützen. Dieser Übergang verringert die Granularität von Daten wie der Betriebssystemversion und dem Hardwaremodell, die zuvor für das Fingerprinting und das Tracking von Benutzern über verschiedene Websites hinweg verwendet wurden. Wir haben untersucht, wie sich diese Reduzierung auf Entwickler auswirkt und wie sie sich an diese Änderungen anpassen können.
- **Wie funktionieren Client Hints?** Client Hints bieten einen Mechanismus, um spezifische, hoch entropische Informationen über das Gerät des Benutzers auf eine datenschutzfreundlichere Weise anzufordern. Durch die Verwendung von HTTP-Headern und JavaScript-APIs können Entwickler bei Bedarf auf detaillierte Daten über die Umgebung des Benutzers zugreifen. Wir haben besprochen, wie Client Hints implementiert werden, welche Arten von Hints verfügbar sind und welche Methoden es gibt, um über HTTP-Anfrage-Header und JavaScript auf sie zuzugreifen.
Client Hints entwickeln sich weiter, und ihre Akzeptanz könnte steigen, da immer mehr Browser und Entwickler ihre Vorteile erkennen. Es bleibt jedoch abzuwarten, ob sich ihre Unterstützung weit verbreiten wird oder ob das Web bei diesem Thema weiterhin unterschiedliche Wege gehen wird.
## Häufig gestellte Fragen
### Wie bekomme ich die tatsächliche iOS-Version in meiner Web-App nach iOS 26?
Apple hat den iOS/iPadOS User-Agent-String in Safari 26, der im September 2025 veröffentlicht wurde, eingefroren, was bedeutet, dass die Betriebssystemversion nicht mehr über den User-Agent in einem Browser unter iOS offengelegt wird. Im Gegensatz zu Chrome auf Android oder Desktop ist in iOS-Browsern keine Client-Hints-API verfügbar, sodass die tatsächliche iOS-Version nicht mehr programmatisch zugänglich ist.
### Was ist der Unterschied zwischen regulären Client Hints und kritischen Client Hints?
Reguläre Client Hints, die über den `Accept-CH`-Antwort-Header angefordert werden, sind nur in nachfolgenden Anfragen enthalten und beim anfänglichen Laden der Seite nicht verfügbar. Kritische Client Hints (Critical Client Hints) lösen vor dem Rendern einen sofortigen erneuten Versuch des Browsers aus und stellen so sicher, dass der Hint beim ersten Rendern verfügbar ist, dies fügt dem Anfragezyklus jedoch einen Roundtrip an Latenz hinzu.
### Warum hat Apple seine ursprüngliche Entscheidung von 2017, den Safari User-Agent einzufrieren, revidiert?
Apple kündigte 2017 das Einfrieren des User-Agents in der Safari Technology Preview 46 an, revidierte diese Entscheidung jedoch 2021 teilweise aufgrund erheblicher Kompatibilitätsprobleme mit Websites, die auf aktuelle User-Agent-Informationen angewiesen waren. Apple implementierte daraufhin einen schrittweiseren Ansatz für eingefrorene UAs anstelle eines sofortigen, vollständigen Einfrierens zu diesem Zeitpunkt.
### Wie kann ich die macOS-Version in Safari erkennen, wenn Client Hints nicht unterstützt werden?
Safari unterstützt keine Client Hints, aber die macOS-Version kann aus der Safari-Versionsnummer im User-Agent-String abgeleitet werden. Wenn man drei von der Hauptversion von Safari abzieht, erhält man zuverlässig die Hauptversion von macOS für macOS 10.15 und höher, basierend auf der konsistenten Abstimmung der Veröffentlichungen zwischen Safari- und macOS-Versionen.
### Welchen Ansatz sollten Entwickler von JavaScript-Bibliotheken für die browserübergreifende Geräteerkennung verwenden?
Der empfohlene Ansatz besteht darin, `navigator.userAgentData.getHighEntropyValues()` aufzurufen, wenn die Funktion definiert ist, was Chromium-basierte Browser abdeckt, und für Firefox und Safari auf Bibliotheken zum Parsen von User-Agent-Strings zurückzugreifen. Für Fälle, die eine hochspezifische Identifizierung des Gerätemodells erfordern, bieten professionelle Bibliotheken wie wurfl oder 51degrees zusätzliche Erkennungsmöglichkeiten über das hinaus, was User-Agent-Strings offenlegen.