Was ist eine Reduzierung des User-Agents?

Die Reduzierung des User-Agents (UA) minimiert die personenidentifizierbaren Informationen im User-Agent-String, die für passives Fingerprinting verwendet werden können. Da diese Änderungen jetzt allgemein verfügbar sind, haben alle Ressourcenanfragen einen reduzierten User-Agent-Header. Daher werden die Rückgabewerte bestimmter Navigator-Benutzeroberflächen reduziert, darunter navigator.userAgent, navigator.appVersion und navigator.platform.

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

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

User-Agent-Client-Hinweise ermöglichen den Zugriff auf die vollständigen User-Agent-Daten, aber nur, wenn Server aktiv einen ausdrücklichen Bedarf an bestimmten Daten erklären.

Durch das Entfernen von passiv freigegebenen Nutzerdaten können wir die Menge der Informationen, die absichtlich über Anfrageheader, JavaScript-APIs und andere Mechanismen freigegeben werden, besser messen und reduzieren.

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

Bisher wurde mit dem User-Agent-String bei jeder HTTP-Anfrage ein großer Datenstring über den Browser, das Betriebssystem und die Version eines Nutzers gesendet. Das war aus zwei Gründen problematisch:

  • Die Detailgenauigkeit und die Fülle an Details können zur Identifizierung von Nutzern führen.
  • Die Standardverfügbarkeit dieser Informationen kann zu verdecktem Tracking führen.

Durch die reduzierten UA- und UA-CH-Strings wird die Privatsphäre der Nutzer verbessert, da standardmäßig nur grundlegende Informationen weitergegeben werden.

Der reduzierte User-Agent enthält die Marke und eine wichtige Version des Browsers, die Quelle der Anfrage (Computer oder Mobilgerät) und die Plattform. Wenn Sie auf weitere Daten zugreifen möchten, können Sie mit User-Agent-Clienthinweisen bestimmte Informationen zum Gerät oder zu den Bedingungen des Nutzers anfordern.

Außerdem wurde der User-Agent-String im Laufe der Zeit immer länger und komplexer, was zu einem fehleranfälligen String-Parsen führte. UA-CH bietet strukturierte und zuverlässige Daten, die sich leichter interpretieren lassen. Vorhandener Code, der den UA-String analysiert, sollte nicht beschädigt werden (es werden jedoch weniger Daten zurückgegeben). Wenn für Ihre Website spezifische Informationen zum Nutzer erforderlich sind, müssen Sie zu UA-CH migrieren.

Wie funktionieren die reduzierten UA- und UA-CH-Versionen?

Hier ein kurzes Beispiel für die Funktionsweise des reduzierten User-Agent-Strings und UA-CH. Ein ausführlicheres Beispiel finden Sie unter Datenschutz für Nutzer und Entwickler mit User-Agent-Client-Hints 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 enthält den User-Agent-Header mit dem reduzierten User-Agent-String. 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 Standard-User-Agent-Client-Hinweis-Header ein. Beispiel:

      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 Accept-CH-Antwortheader 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 die Nutzerkonfiguration an, um zu bestimmen, welche Daten in nachfolgenden Anfrage-Headern an den Server zurückgegeben werden dürfen. Beispiel:

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

Wichtige Client-Hints

Wenn Sie in Ihrer ersten Anfrage eine bestimmte Reihe von Clienthinweisen benötigen, können Sie den Critical-CH-Antwortheader verwenden. Die 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 eingestuft wird.

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 wichtigen Hinweis (Critical-CH) benötigt, um die Webseite richtig zu rendern, kann der Server mit dem Accept-CH-Header um diese zusätzlichen Informationen bitten. Der Browser kann dann eine neue Anfrage für die Seite senden, einschließlich des wichtigen Hinweises.

Zusammenfassend: Mit Accept-CH werden alle Werte angefordert, die Sie für die Seite benötigen, während mit Critical-CH nur die Werte angefordert werden, die zum Laden der Seite erforderlich sind. Weitere Informationen finden Sie in der Spezifikation zur Zuverlässigkeit von Clienthinweisen.

Tablets mit der UA-CH API erkennen

Da die Unterschiede zwischen Mobilgeräten, Tablets und Computern immer geringer werden und dynamische Formfaktoren immer häufiger vorkommen (z. B. faltbare Bildschirme oder der Wechsel zwischen Laptop- und Tabletmodus), sollten Sie ein responsives Design und die Funktionserkennung verwenden, um eine geeignete Benutzeroberfläche zu präsentieren.

Die vom Browser bereitgestellten Informationen für den User-Agent-String und die User-Agent-Client-Hinweise stammen jedoch aus derselben Quelle. Daher sollten dieselben Logikformen funktionieren.

Wenn dieses Muster beispielsweise für den UA-String aktiviert ist:

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

Die Übereinstimmung der Standard-UA-CH-Header-Benutzeroberfläche kann geprüft werden:

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

Oder die entsprechende JavaScript-Schnittstelle:

  • Telefonmuster: 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 mit hoher Entropie angefordert werden.

Wie verwende und teste ich die reduzierte UA?

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

Nachdem Sie auf die UA-CH API umgestellt haben, sollten Sie testen, ob Sie die erwarteten Daten vom User-Agent erhalten. Es gibt drei Testmethoden, die jeweils komplexer werden.

Die skalierte Verfügbarkeit der User-Agent-Verringerung bedeutet, dass der vollständig reduzierte UA-String auf allen Chrome-Geräten gesendet wird. Die Reduzierung begann mit einer kleineren Chrome-Version 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 Befehlszeilenflag --user-agent="Custom string here". Weitere Informationen zu Befehlszeilen-Flags

Alternativ können Sie den Geräteemulator in den Chrome-Entwicklertools verwenden.

String im Code Ihrer Website transformieren

Wenn Sie den vorhandenen Chrome-user-agent-String 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 entweder durch Überschreiben und Ersetzen des Strings oder durch Generieren der neuen Version und Vergleichen der beiden Versionen durchführen.

Unterstützung für Client- und kritische Hinweise

Es werden drei Standard-Clienthinweise an den Server zurückgegeben, darunter der Name und die Hauptversion des Browsers, ein boolescher Wert, der angibt, ob der Browser auf einem Mobilgerät ausgeführt wird, und der Name des Betriebssystems. Diese werden nach dem TLS-Handshake (Transport Layer Security) gesendet. Diese sind bereits in Ihrem Browser verfügbar und werden unterstützt.

Es kann jedoch vorkommen, dass Sie wichtige Informationen abrufen müssen, damit Ihre Website gerendert werden kann.

Wichtige Hinweise optimieren

Ein TLS-Handshake ist der erste Schritt zum Erstellen einer sicheren Verbindung zwischen dem Browser und dem Webserver. Ohne Eingreifen soll der Critical-CH-Antwortheader den Browser anweisen, die Anfrage sofort noch einmal zu versuchen, wenn die erste ohne kritischen Hinweis gesendet wurde.

Sequenzdiagramm für Client-Hints mit kritischen Hinweisen
Wenn vom Server ein kritischer Hinweis angefordert wird, versucht der Client noch einmal, die erste Anfrage für die Webseite mit dem kritischen Hinweis zu senden. In diesem Beispiel wird der Hinweis für Sec-CH-UA-Model zweimal angefordert: einmal als Clienthinweis mit Accept-CH und noch einmal als kritischer Hinweis mit Critical-CH.

Wenn Sie wichtige Hinweise (Critical-CH-Header) optimieren möchten, müssen Sie diesen Handshake abfangen und ein Modell für Client-Hinweise bereitstellen. Diese Schritte können komplex sein und fortgeschrittene Kenntnisse erfordern.

Die ACCEPT_CH HTTP/2- und HTTP/3-Frames in Kombination mit der TLS ALPS-Erweiterung sind eine Optimierung auf Verbindungsebene, um die Client-Hinweiseinstellungen des Servers rechtzeitig vor der ersten HTTP-Anfrage zu senden. Sie erfordern eine komplexe Konfiguration und sollten nur für wirklich kritische Informationen verwendet werden.

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 Verlässlichkeit und Optimierung wichtiger Hinweise.

FAQ

Wie lange werden Hinweise, die über den Accept-CH-Header angegeben werden, gesendet?

Über den Accept-CH-Header angegebene Hinweise werden während der gesamten Browsersitzung oder bis eine andere Reihe von Hinweisen angegeben wird, gesendet.

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

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

Benötigen Subdomains (und CNAMEs) eine Seite der obersten Ebene Permissions-Policy, um auf UA-CH mit hoher Entropie zuzugreifen?

UA-CH mit hoher Entropie in Anfrageheadern sind für ursprungsübergreifende 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 User-Agent-Reduzierung auf die Bot-Erkennung aus?

Die Änderung des User-Agent-Strings von 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 widerzuspiegeln, die Chrome sendet. Dies liegt jedoch in der alleinigen Verantwortung der Entwickler. Chrome sendet weiterhin dasselbe User-Agent-Format und Bots, die am Ende eines Chrome-User-Agent-Strings ihre eigene Kennung anhängen, können dies weiterhin tun.

Wenn Sie Bedenken im Zusammenhang mit bestimmten Bots haben, sollten Sie sich direkt an die Eigentümer wenden und fragen, ob sie ihren User-Agent-String ändern möchten.

Feedback geben und erhalten

Weitere Informationen