Was ist eine Reduzierung des User-Agents?

Die Reduzierung des User-Agents (UA) minimiert die im User-Agent-String weitergegebenen personenidentifizierbaren Informationen, die für den passiven Fingerprinting verwendet werden können. Nachdem diese Änderungen 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 werden muss, 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 den gesamten Satz an User-Agent-Daten, allerdings nur, wenn Server explizit einen bestimmten Bedarf an bestimmten Daten deklarieren.

Wenn Sie passiv offengelegte Nutzerdaten entfernen, können wir die Menge an Informationen, die absichtlich durch Anfrageheader, JavaScript APIs und andere Mechanismen preisgegeben 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 zum Browser, zum Betriebssystem und zur Version eines Nutzers übertragen. Dies war aus zwei Gründen problematisch:

  • Die Detailgenauigkeit und die Fülle an Details kann zur Identifizierung von Nutzenden führen.
  • Die Standardverfügbarkeit dieser Informationen kann 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 (Computer oder Mobilgerät) und die Plattform. Wenn Sie auf weitere Daten zugreifen möchten, können Sie mit User-Agent-Client-Hinweisen bestimmte Informationen zum Gerät oder zu den Bedingungen des Nutzers anfordern.

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

Wie funktionieren der reduzierte UA und UA-CH?

Hier ist 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-Hinweisen den Datenschutz für Nutzer und die Entwicklererfahrung 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 Standardheader „User-Agent-Client-Hints“ ein. Beispiel:

      Sec-CH-UA: "Chrome"; v="98"
      Sec-CH-UA-Mobile: ?1
      Sec-CH-UA-Platform: "Android"
      
  2. Der Server kann den Browser mit dem Antwortheader Accept-CH auffordern, zusätzliche Clienthinweise zu senden, z. B. das Gerätemodell. 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 Anfrageheadern 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"
    

Kritische Kundenhinweise

Wenn Sie in Ihrer ersten Anfrage bestimmte Clienthinweise 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) benötigt, um die Webseite korrekt zu rendern, kann der Server diese zusätzlichen Informationen über den Accept-CH-Header anfordern. Der Browser kann dann eine neue Anfrage einschließlich des kritischen Hinweises für die Seite senden.

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 beim Laden vorhanden sein muss, damit die Seite ordnungsgemäß geladen wird. Weitere Informationen finden Sie in der Spezifikation zur Zuverlässigkeit von Clienthinweisen.

Tabletgeräte mit der UA-CH API erkennen

Die Grenze zwischen Smartphones, Tablets und Desktop-Geräten wird immer weniger deutlich und dynamische Formfaktoren nehmen häufiger zu (faltbare Bildschirme, Wechsel zwischen Laptop- und Tabletmodus), daher empfiehlt es sich, responsives Design und 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 die User-Agent-Client-Hints stammen jedoch aus derselben Quelle. Daher sollte die gleiche Logik funktionieren.

Beispiel: Dieses Muster wird im UA-String geprüft:

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

Die entsprechende standardmäßige UA-CH-Header-Schnittstelle kann aktiviert sein:

  • Smartphone-Muster: 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-Oberfläche:

  • Smartphone-Muster: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • Tabletmuster: 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 kann ich reduzierte UA verwenden und testen?

Prüfen Sie zuerst Ihren Websitecode auf Instanzen und Verwendungen des User-Agent-Strings. Wenn für Ihre Website das Parsen des User-Agent-Strings erforderlich ist, 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 aktualisiert haben, sollten Sie testen, ob Sie die vom User-Agent erwarteten Daten erhalten. Es gibt drei Testmöglichkeiten, die immer komplexer werden.

Dank der skalierten Verfügbarkeit der User-Agent-Reduktion wird der UA-String auf allen Chrome-Geräten vollständig reduziert. 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 können Sie 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 ihn in das neue Format umwandeln, um die Kompatibilität zu testen. Sie können den Test entweder überschreiben und ersetzen oder die neue Version generieren und gleichzeitig testen.

Unterstützung von Client-Hinweisen und wichtigen Hinweisen

Es gibt drei Standard-Clienthinweise, die an den Server zurückgegeben werden, einschließlich des Browsernamens und der Hauptversion, ein boolescher Wert, der angibt, ob der Browser ein Mobilgerät verwendet, und der Name 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.

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

Wichtige Tipps für die Optimierung

Ein TLS-Handshake ist der erste Schritt zum Herstellen einer sicheren Verbindung zwischen Browser und Webserver. Ohne Eingreifen war der Critical-CH-Antwortheader 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, versucht der Client, 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 Client-Hinweis mit Accept-CH und einmal als kritischer Hinweis mit Critical-CH.

Um kritische Hinweise (Critical-CH-Header) zu optimieren, müssen Sie diesen Handshake abfangen und ein Modell für Clienthinweise bereitstellen. Diese Schritte können komplex sein und erfordern fortgeschrittenes Wissen.

Der ACCEPT_CH HTTP/2- und HTTP/3-Frame ist in Kombination mit der TLS-ALPS-Erweiterung eine Optimierung auf Verbindungsebene, mit der die Client-Hinweis-Einstellungen des Servers rechtzeitig für die erste HTTP-Anfrage gesendet werden. Diese erfordern eine komplexe Konfiguration und wir empfehlen, diese nur für wirklich kritische Informationen zu verwenden.

BoringSSL (eine Abspaltung von OpenSSL) hilft Ihnen, mit den experimentellen Funktionen von Google in Chromium zu arbeiten. Derzeit ist ALPS nur in BoringSSL implementiert.

Wenn Sie kritische Hinweise verwenden müssen, lesen Sie unseren Leitfaden zur Zuverlässigkeit und Optimierung kritischer Hinweise.

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 der obersten 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 widerzuspiegeln, die von Chrome gesendet werden. Das ist jedoch allein ihre Entscheidung für die Implementierung. 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 Zusammenhang mit bestimmten Bots kann es hilfreich sein, sich direkt an die Inhaber zu wenden und zu fragen, ob sie den User-Agent-String ändern möchten.

Reagieren und Feedback geben

Weitere Informationen