Was ist eine Reduzierung des User-Agents?

Durch die Reduzierung des User-Agents (UA) werden die im User-Agent-String weitergegebenen Informationen zur Identifizierung minimiert, die für das passive Fingerprinting verwendet werden können. Da diese Änderungen nun zur allgemeinen Verfügbarkeit eingeführt wurden, haben alle Ressourcenanfragen einen reduzierten User-Agent-Header. Dadurch werden die Rückgabewerte bestimmter Navigator-Schnittstellen reduziert, darunter navigator.userAgent, navigator.appVersion und navigator.platform.

Webentwickler sollten ihren Websitecode auf die Verwendung des User-Agent-Strings prüfen. Wenn der User-Agent-String auf deiner Website geparst wird, um das Gerätemodell, die Plattformversion oder die vollständige Browserversion zu lesen, musst du die User-Agent Client Hints API implementieren.

User-Agent-Client-Hints (UA-CH)

User-Agent-Client-Hints ermöglichen den Zugriff auf alle User-Agent-Daten, allerdings nur, wenn die Server den expliziten Bedarf an bestimmten Daten explizit deklarieren.

Durch das Entfernen von passiv offengelegten Nutzerdaten können wir die Menge an Informationen, die absichtlich durch Anfrageheader, JavaScript APIs und andere Mechanismen offengelegt werden, besser messen und reduzieren.

Warum benötigen wir reduzierte UA und UA-CH?

In der Vergangenheit hat der User-Agent-String bei jeder HTTP-Anfrage einen großen Datenstring zu Browser, Betriebssystem und Version eines Nutzers gesendet. Dies war aus zwei Gründen problematisch:

  • Der Detaillierungsgrad und die Fülle der Details kann zur Identifizierung der Nutzenden führen.
  • Wenn diese Informationen standardmäßig verfügbar sind, kann das zu verdecktem Tracking führen.

Reduzierte UA und UA-CH verbessern den Datenschutz für Nutzer, da standardmäßig nur grundlegende Informationen geteilt werden.

Der reduzierte User-Agent umfasst die Marke des Browsers, eine signifikante Version, von der die Anfrage stammt (Desktop oder Mobilgerät) und die Plattform. Um auf mehr Daten zuzugreifen, können Sie mit User-Agent-Client-Hints bestimmte Informationen zum Gerät oder zu den Bedingungen des Nutzers anfordern.

Außerdem wurde der String User-Agent mit der Zeit länger und komplexer, was zu einem fehleranfälligen Parsen des Strings führte. UA-CH bietet strukturierte und zuverlässige Daten, die sich leichter interpretieren lassen. Vorhandener Code, der den UA-String parst, sollte nicht beschädigt werden, es werden aber weniger Daten zurückgegeben. Sie müssen zu UA-CH migrieren, wenn Ihre Website bestimmte Clientinformationen benötigt.

Wie funktionieren das reduzierte UA und UA-CH?

Hier sehen Sie ein kurzes Beispiel dafür, wie der reduzierte User-Agent-String und UA-CH funktionieren. Ein ausführlicheres Beispiel finden Sie unter Mit User-Agent-Client-Hints den Datenschutz und die Nutzerfreundlichkeit für Entwickler verbessern.

Ein Nutzer öffnet den Browser und gibt example.com in die Adressleiste ein:

  1. Der Browser sendet eine Anfrage zum Laden der Webseite.
    1. Der Browser fügt den Header User-Agent mit dem reduzierten User-Agent-String ein. Beispiel: User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36
    2. Der Browser fügt diese Informationen in die standardmäßigen User-Agent-Client-Hint-Header ein. Beispiel: powershell Sec-CH-UA: "Chrome"; v="98" Sec-CH-UA-Mobile: ?1 Sec-CH-UA-Platform: "Android"
  2. Der Server kann den Browser auffordern, zusätzliche Clienthinweise wie das Gerätemodell mit dem Antwortheader Accept-CH zu senden. Beispiel: Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model
  3. Der Browser wendet Richtlinien und Nutzerkonfigurationen an, um zu bestimmen, welche Daten in nachfolgenden Anfrageheadern an den Server zurückgegeben werden dürfen. Beispiel: powershell Sec-CH-UA: "Chrome"; v="93" Sec-CH-UA-Mobile: ?1 Sec-CH-UA-Platform: "Android" Sec-CH-UA-Model: "Pixel 2"

Wichtige Kundenhinweise

Wenn Sie einen bestimmten Satz von Clienthinweisen in Ihrer ersten Anfrage benötigen, können Sie den Antwortheader Critical-CH verwenden. Critical-CH-Werte müssen eine Teilmenge der von Accept-CH angeforderten Werte sein.

Die ursprüngliche Anfrage kann beispielsweise eine Anfrage für Device-Memory und Viewport-Width enthalten, wobei Device-Memory als kritisch gilt.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

Wenn der Browser einen kritischen Hinweis (Critical-CH) für das korrekte Rendern der Webseite benötigt, kann der Server diese zusätzlichen Informationen mit dem Accept-CH-Header anfordern. Der Browser kann dann eine neue Anfrage für die Seite senden, einschließlich des kritischen Hinweises.

Zusammenfassend lässt sich sagen, dass Accept-CH alle gewünschten Werte für die Seite anfordert, während Critical-CH nur die Teilmenge der Werte anfordert, die geladen werden müssen, damit die Seite richtig geladen wird. Weitere Informationen finden Sie in der Spezifikation für die Zuverlässigkeit von Clienthinweisen.

Tablet-Geräte mit der UA-CH API erkennen

Da die Grenze zwischen Smartphones, Tablets und Desktop-Geräten immer weniger ausgeprägt ist und dynamische Formfaktoren immer häufiger vorkommen (faltbare Bildschirme, Wechsel zwischen Laptop- und Tablet-Modus), empfiehlt es sich, ein responsives Design und eine Funktionserkennung zu verwenden, um eine geeignete Benutzeroberfläche zu präsentieren.

Vom Browser bereitgestellte Informationen sowohl für den User-Agent-String als auch für User-Agent-Client-Hints stammen jedoch aus derselben Quelle, daher sollte dieselbe Logik funktionieren.

Wenn dieses Muster beispielsweise im UA-String geprüft wird:

  • Smartphone-Muster: 'Android' + 'Chrome/[.0-9]* Mobile'
  • Tablet-Muster: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

In der Schnittstelle für übereinstimmende Standard-UA-CH-Header kann ein Häkchen gesetzt sein:

  • Telefonmuster: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?1
  • Tabletmuster: Sec-CH-UA-Platform: "Android", Sec-CH-UA-Mobile: ?0

Oder die entsprechende JavaScript-Oberfläche:

  • Smartphone-Muster: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • Tablet-Muster: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

Für hardwarespezifische Anwendungsfälle kann der Name des Gerätemodells über den Sec-CH-UA-Model-Hinweis für hohe Entropie angefordert werden.

Wie kann ich reduzierte UA verwenden und testen?

Überprüfen Sie zuerst Ihren Websitecode auf Instanzen und Verwendungen des User-Agent-Strings. Wenn der User-Agent-String auf Ihrer Website geparst wird, um das Gerätemodell, die Plattformversion oder die vollständige Browserversion zu lesen, müssen Sie die UA-CH API implementieren.

Nach der Aktualisierung auf die UA-CH API sollten Sie testen, ob Sie die erwarteten Daten vom User-Agent erhalten. Es gibt drei Testmöglichkeiten, die immer komplexer werden.

Die skalierte Verfügbarkeit der User-Agent-Reduzierung bedeutet, dass der UA-String, der auf allen Chrome-Geräten verfügbar ist, vollständig reduziert wird. Die Reduzierung begann mit einer Chrome-Nebenversion im 2. Quartal 2022.

Benutzerdefinierte Strings lokal testen

Wenn Sie Ihre Website mit benutzerdefinierten User-Agent-Strings testen möchten, um verschiedene Geräte zu simulieren, starten Sie Chrome mit dem Befehlszeilen-Flag --user-agent="Custom string here". Weitere Informationen zu Befehlszeilen-Flags

Alternativ kannst du den Geräteemulator in den Chrome-Entwicklertools verwenden.

String im Code Ihrer Website umwandeln

Wenn Sie den vorhandenen Chrome-String user-agent in Ihrem clientseitigen oder serverseitigen Code verarbeiten, können Sie diesen String in das neue Format umwandeln, um die Kompatibilität zu testen. Sie können den Test durch Überschreiben und Ersetzen des Strings oder Generieren der neuen Version und des Tests gleichzeitig ausführen.

Support für Client-Hinweise und wichtige Hinweise

Es werden drei standardmäßige Clienthinweise an den Server zurückgegeben, darunter der Browsername und die Hauptversion, ein boolescher Wert, der angibt, ob der Browser auf einem Mobilgerät verwendet wird, und den Namen des Betriebssystems. Sie werden nach dem TLS-Handshake (Transport Layer Security Protocol) gesendet. Diese sind bereits in Ihrem Browser verfügbar und werden unterstützt.

Unter Umständen müssen Sie jedoch wichtige Informationen abrufen, damit Ihre Website gerendert werden kann.

Wichtige Hinweise optimieren

Ein TLS-Handshake ist der erste Schritt zum Herstellen einer sicheren Verbindung zwischen dem Browser und dem Webserver. Der Critical-CH-Antwortheader ohne Eingriff wurde so konzipiert, dass der Browser den Browser anweist, die Anfrage sofort zu wiederholen, wenn die erste Anfrage ohne einen kritischen Hinweis gesendet wurde.

Sequenzdiagramm für Clienthinweise mit wichtigen Hinweisen
Wenn vom Server ein kritischer Hinweis angefordert wird, wiederholt der Client das Senden der ersten Anfrage für die Webseite mit dem kritischen Hinweis. In diesem Beispiel wird der Hinweis für Sec-CH-UA-Model zweimal angefordert: einmal als Clienthinweis mit Accept-CH und einmal als kritischer Hinweis mit Critical-CH.

Zur Optimierung wichtiger Hinweise (Critical-CH-Header) müssen Sie diesen Handshake abfangen und ein Modell für Clienthinweise bereitstellen. Diese Schritte können komplex sein und fortgeschrittene Kenntnisse erfordern.

ACCEPT_CH HTTP/2- und HTTP/3-Frames sind in Kombination mit der TLS ALPS-Erweiterung eine Optimierung auf Verbindungsebene, um die Client-Hinweiseinstellungen des Servers rechtzeitig für die erste HTTP-Anfrage bereitzustellen. Diese erfordern eine komplexe Konfiguration. Wir empfehlen, diese nur für wirklich wichtige Informationen zu verwenden.

BoringSSL (eine Fork von OpenSSL) unterstützt Sie bei der Arbeit mit den experimentellen Funktionen von Google in Chromium. Derzeit ist ALPS nur in BoringSSL implementiert.

Wenn Sie wichtige Hinweise verwenden müssen, lesen Sie unseren Leitfaden zur Zuverlässigkeit und Optimierung von kritischen Hinweisen.

Häufig gestellte Fragen

Wie lange werden im Accept-CH-Header angegebene Hinweise gesendet?

Hinweise, die über den Header Accept-CH angegeben werden, werden für die Dauer der Browsersitzung gesendet oder so lange, bis ein anderer Satz von Hinweisen angegeben wird.

Funktioniert UA-CH mit HTTP/2 und HTTP/3?

UA-CH funktioniert sowohl mit HTTP/2- als auch mit HTTP/3-Verbindungen.

Ist für Subdomains (und CNAMEs) eine Seite auf oberster Ebene (Permissions-Policy) erforderlich, um auf UA-CH mit hoher Entropie zuzugreifen?

UA-CH mit hoher Entropie in Anfrageheadern ist bei ursprungsübergreifenden Anfragen eingeschränkt, unabhängig davon, wie dieser Ursprung auf der DNS-Seite definiert ist. Die Delegierung muss für jede ursprungsübergreifende Unterressource über Permissions-Policy erfolgen oder über JavaScript abgerufen werden, das im ursprungsübergreifenden Kontext ausgeführt wird.

Wie wirkt sich die Reduzierung des User-Agents auf die Bot-Erkennung aus?

Die Änderung des User-Agent-Strings in Chrome wirkt sich nicht direkt auf den User-Agent-String aus, den ein Bot sendet.

Bots können ihre eigenen Strings aktualisieren, um die reduzierten Informationen wiederzugeben, die Chrome sendet, aber das ist allein ihre Implementierungsentscheidung. Chrome sendet weiterhin dasselbe User-Agent-Format. Bots, die ihre eigene ID an das Ende eines Chrome-User-Agent-Strings anhängen, können dies auch weiterhin tun.

Bei Bedenken im Hinblick auf bestimmte Bots kann es sich lohnen, die Inhaber direkt zu fragen, ob sie den User-Agent-String ändern möchten.

Reagieren und Feedback geben

Weitere Informationen