Bereite dich auf das Ende von Drittanbieter-Cookies in Chrome vor. Testen Sie Ihre Website noch heute auf Mängel.

Diese Seite wurde von der Cloud Translation API übersetzt.

Fingerprinting

Mit Fingerprinting wird versucht, einen Nutzer zu identifizieren, wenn er zu Ihrer Website zurückkehrt, oder derselbe Nutzer auf verschiedenen Websites identifizieren. Zwischen Ihrer Einrichtung und denen anderer Nutzer können sich viele Merkmale unterscheiden. Dies kann beispielsweise der Fall sein, wenn Sie einen anderen Gerätetyp und einen anderen Browser verwenden, eine andere Bildschirmgröße haben und verschiedene Schriftarten installiert haben. Wenn ich die Schriftart „Dejavu Sans“ installiert habe, sie aber nicht, kann jede Website den Unterschied zwischen Ihnen und mir erkennen. So funktioniert das Fingerprinting: Sie bauen eine Sammlung dieser Datenpunkte auf und jeder bietet weitere Möglichkeiten, zwischen Nutzern zu unterscheiden.

Eine formellere Definition könnte so aussehen: Beim Fingerprinting werden offensichtliche und nicht offensichtliche langlebige Eigenschaften der Einrichtung eines Nutzers verwendet, um sie von so vielen anderen Nutzern wie möglich zu unterscheiden.

Warum Fingerprinting den Datenschutz für Nutzer beeinträchtigt

Es gibt einige Grenzfälle, in denen Fingerprinting wichtig ist, beispielsweise die Betrugserkennung. Aber Fingerprinting kann auch verwendet werden, um Nutzer websiteübergreifend zu erfassen. Dieses Tracking erfolgt oft ohne die Einwilligung der Nutzer oder in einigen Fällen auf der Grundlage einer ungültigen Einwilligung, die den Nutzer nicht angemessen informiert. Diese Nutzenden finden dies dann oft etwas verstörend und fühlen sich dann eher betrogen.

Beim Fingerprinting werden Möglichkeiten gefunden, Nutzer heimlich von anderen zu unterscheiden. Mithilfe der Fingerprinting-Technologie kann erkannt werden, dass es sich immer noch um denselben Nutzer auf derselben Website handelt, oder um denselben Nutzer gleichzeitig in zwei verschiedenen Browserprofilen zu erkennen. Das bedeutet, dass Fingerprinting verwendet werden kann, um Nutzer websiteübergreifend zu erfassen. Die deterministischen und offensichtlichen Tracking-Methoden, wie das Speichern eines Cookies mit einer eindeutigen nutzerspezifischen ID, können von Nutzern bis zu einem gewissen Grad von Nutzern beobachtet und kontrolliert werden. Im vorherigen Modul wurden einige dieser Ansätze erläutert. Fingerprinting ist jedoch schwieriger zu vermeiden, da es verdeckt ist. Es basiert auf unveränderlichen Merkmalen und geschieht höchstwahrscheinlich unsichtbar. Deshalb wird es auch „Fingerprinting“ genannt. Es ist im Idealfall schwierig, den Fingerabdruck zu wechseln, egal ob es sich dabei um den digitalen oder an Ihren Fingerspitzen handelt.

Browseranbieter wissen, dass Nutzer nicht gern erfasst werden, und implementieren daher kontinuierlich Funktionen zur Einschränkung des Fingerprinting (einige davon haben wir im vorherigen Modul gesehen). Hier sehen wir uns an, wie sich diese Funktionen auf die Anforderungen Ihres Unternehmens auswirken können und wie Sie trotzdem das tun können, was Sie wollen, ohne den Datenschutz zu wahren. Es geht hier mehr darum, wie sich der Browserschutz gegen Fingerprinting auf Ihre Arbeit auswirkt, und nicht darauf, wie er das Fingerprinting verhindert.

In der Praxis ist es für die meisten Entwickler und die meisten Unternehmen nicht erforderlich, einen Fingerabdruck der Nutzer zu erstellen. Wenn sich Nutzer in Ihrer App anmelden müssen, identifizieren sich diese Nutzer mit ihrer Einwilligung und auf eine Weise, die sie jederzeit widerrufen können. Dies ist eine datenschutzkonforme Methode, um zu ermitteln, welche Nutzer angemeldet sind. In Ihrer App müssen Nutzer sich möglicherweise überhaupt nicht anmelden, was die Privatsphäre Ihrer Nutzer noch besser schützt (und Sie erheben dann nur die Daten, die Sie benötigen).

Das sollten Sie tun:

Prüfen Sie Drittanbieter auf Fingerprinting. Im Rahmen des Moduls Drittanbieter haben Sie möglicherweise bereits eine Liste der Drittanbieterdienste, die Sie einbinden, und der entsprechenden Webanfragen. Unter Umständen ist es möglich, diese Anfragen zu prüfen, um festzustellen, welche Daten gegebenenfalls an den Urheber zurückgegeben werden. Dies ist jedoch oft schwierig. Das Fingerprinting ist von Natur aus ein verdeckter Prozess, bei dem Daten angefordert werden, die nicht der Genehmigung des Nutzers unterliegen.

Sie sollten auch die Datenschutzerklärungen Ihrer Drittanbieterdienste und -abhängigkeiten lesen, um nach Anzeichen für die Verwendung von Fingerprinting zu suchen. Sie wird manchmal als „probabilistische Übereinstimmung“ oder als Teil einer Reihe von probabilistischen Abgleichstechniken im Gegensatz zum „deterministischen Abgleich“ bezeichnet.

So funktioniert Fingerprinting

Häufig ist Ihre persönliche Kombination all dieser Attribute einzigartig für Sie oder zumindest für eine kleine Gruppe ähnlicher Personen. Dies kann verwendet werden, um Sie heimlich zu verfolgen.

Nebenbemerkung: passives und aktives Fingerprinting

Dabei wird zwischen passiven und aktiven Fingerprinting-Techniken unterschieden. Bei einer passiven Fingerprinting-Technik werden Informationen verwendet, die standardmäßig an die Website übergeben werden. Eine aktive Fingerprinting-Technik ist eine Methode, die den Browser explizit nach zusätzlichen Informationen abfragt. Diese Unterscheidung ist wichtig, weil Browser versuchen können, aktive Techniken zu erkennen und abzufangen oder zu mindern. APIs können eingeschränkt oder hinter einem Dialogfeld geschützt werden, in dem die Berechtigung des Nutzers angefordert wird. Der Nutzer wird dann über ihre Verwendung informiert oder kann die Einwilligung standardmäßig ablehnen. Eine passive Technik ist eine Methode, bei der Daten verwendet werden, die bereits der Website zur Verfügung gestellt wurden. Dies ist häufig der Fall, weil diese Informationen in den Anfangstagen der Informationsflut an alle Websites weitergegeben wurden. Ein Beispiel dafür ist der User-Agent-String, den wir uns später genauer ansehen werden. Es wurde als nützlich erachtet, um eine Vielzahl von Informationen zum Browser, zur Version und zum Betriebssystem des Nutzers zu liefern, damit eine Website auf dieser Grundlage unterschiedliche Inhalte präsentieren konnte. Allerdings erhöht sich dadurch auch die Menge an Informationen, die zur Identifizierung der einzelnen Nutzer beitragen, sodass diese Informationen zunehmend nicht mehr verfügbar oder zumindest eingefroren sind, sodass sie nicht mehr voneinander unterschieden werden können. Wenn Sie auf diesen Informationen angewiesen sind, z. B. wenn Sie je nach User-Agent unterschiedliche Codezweige nehmen, funktioniert dieser Code möglicherweise nicht mehr, da Browser diese Informationen zunehmend einfrieren oder stoppen. Tests stellen hier die beste Abwehr dar ( siehe später).

Nebenbemerkung: Fingerabdruckerkennung messen

Das technische Maß dafür, wie viele Informationen jeder dieser Datenpunkte liefert, wird als Entropie bezeichnet und in Bits gemessen. Ein Feature mit vielen verschiedenen möglichen Werten (z. B. die Liste der installierten Schriftarten) kann viele Bits zur Gesamtsumme hinzufügen. Wenn es also nicht viel charakteristische Bedeutung gibt (z. B. welches Betriebssystem Sie verwenden), werden möglicherweise nur wenige Bits hinzugefügt. Der HTTP Almanac beschreibt, wie vorhandene Fingerprinting-Bibliotheken diesen Vorgang der Kombination der Antworten vieler verschiedener APIs zu einem „Hash“ automatisieren. Dadurch wird möglicherweise nur eine kleine Gruppe von Nutzern identifiziert, eventuell sogar nur einer. Maud Nalpas wird in diesem YouTube-Video ausführlich darauf eingehen. Stell dir aber kurz vor, du müsstest eine Liste deiner Freunde mit ihrer Lieblingsmusik, ihrem Lieblingsessen und den Sprachen sehen, die sie sprechen – aber ohne Namen. Es ist sehr wahrscheinlich, dass jede Person sie in der Liste Ihrer Freunde eindeutig identifiziert oder die Liste zumindest auf wenige Personen eingrenzt. So funktioniert Fingerprinting: Die Liste der Dinge, die Ihnen gefallen, wird zum „Hash“. Mit diesem Hash wird es einfacher, einen Nutzer auf zwei verschiedenen nicht verbundenen Websites als dieselbe Person zu identifizieren. Ziel des Trackings ist es, den Datenschutz des Nutzers zu umgehen.

Was unternehmen Browser gegen Fingerprinting?

Wichtig ist, dass Browseranbieter viele verschiedene Möglichkeiten kennen, wie eine Website (oder ein auf einer Website enthaltener Drittanbieter) einen Unterscheidungs-Fingerabdruck für einen Nutzer berechnen oder unterschiedliche Informationen zur Eindeutigkeit dieses Fingerabdrucks beitragen kann. Einige dieser Methoden sind explizit und bewusst, wie z. B. der User-Agent-String des Browsers, der häufig den Browser, das Betriebssystem und die verwendete Version identifiziert. Dies trägt dazu bei, Sie von mir zu unterscheiden, falls Sie und ich verschiedene Browser verwenden. Einige der Methoden sind nicht absichtlich für einen Fingerabdruck konzipiert, aber letztendlich auch so, wie etwa die Liste der Schriftarten oder die für den Browser verfügbaren Video- und Audiogeräte. Der Browser muss diese Geräte nicht verwenden, sondern sie rufen sie einfach namentlich auf. Und einige gehören nachgewiesenermaßen zu einem Fingerabdruck, wie das genaue Pixel-Rendering der Kantenglättung von Schriftarten in einem Canvas-Element. Es gibt noch viele weitere Browser und jede Art, auf die sich dein Browser von meinem unterscheidet, führt zu Entropie. Dies trägt möglicherweise dazu bei, den Unterschied zwischen dir und mir zu erkennen und eine einzelne Person so eindeutig wie möglich auf verschiedenen Websites zu identifizieren. Unter https://amiunique.org findest du eine lange (aber nicht umfassende) Liste potenzieller Funktionen, die einen Fingerabdruck unterstützen, und die Liste wächst.

Bestimmte leistungsstarke APIs werden nicht unterstützt

Die Antwort von Browseranbietern auf all diese Ansätze zur Berechnung des Fingerabdrucks eines Nutzers besteht darin, Möglichkeiten zu finden, die über diese APIs verfügbare Entropiemenge zu reduzieren. Die restriktivste Option besteht darin, sie von vornherein nicht zu implementieren. Dies wurde von einigen großen Browsern für eine Vielzahl von Hardware- und Geräte-APIs durchgeführt (z. B. NFC- und Bluetooth-Zugriff über clientseitige Webanwendungen), wobei Fingerprinting und Bedenken im Hinblick auf den Datenschutz als Gründe genannt werden. Dies kann natürlich Auswirkungen auf Ihre Anwendungen und Dienste haben: In einem Browser, in dem sie nicht implementiert ist, kann eine API überhaupt nicht verwendet werden. Dies kann dazu führen, dass einige Hardwareansätze eingeschränkt oder vollständig ausgeschlossen werden.

Gateway für Nutzerberechtigungen

Ein zweiter Ansatz von Browser-Anbietern besteht darin, API- oder Datenzugriffe ohne ausdrückliche Nutzerberechtigung zu verhindern. Dieser Ansatz wird häufig auch aus Sicherheitsgründen gewählt. Eine Website sollte ohne Ihre Erlaubnis keine Fotos mit Ihrer Webcam aufnehmen können. Aber hier können Datenschutz und Sicherheit ähnliche Interessen haben. Die Identifizierung des Standorts einer Person ist natürlich eine Datenschutzverletzung, aber sie trägt auch zur Eindeutigkeit eines Fingerabdrucks bei. Das Erfordern der Berechtigung zum Aufrufen der Standortbestimmung verringert nicht die zusätzliche Entropie, die ein Standort zur Eindeutigkeit dieses Fingerabdrucks beiträgt. Es entfällt jedoch im Grunde die Verwendung der Standortbestimmung für Fingerprinting, da diese nicht mehr unbemerkt erfolgt. Der Sinn des Fingerabdrucks besteht darin, Nutzer heimlich heimlich voneinander zu unterscheiden. Wenn Sie darauf vorbereitet sind, dass der Nutzer weiß, dass Sie ihn identifizieren möchten, benötigen Sie keine Fingerprinting-Techniken: Bitten Sie den Nutzer, ein Konto zu erstellen und sich damit anzumelden.

Unvorhersehbarkeit hinzufügen

Ein dritter Ansatz in einigen Fällen besteht darin, dass Browseranbieter die Antworten von APIs „unschärfen“, um sie weniger detailliert und somit weniger identifizierbar zu machen. Dies wurde im Rahmen des Mechanismus zur zufälligen Antwort im Datenmodul beschrieben, damit Sie beim Erfassen von Daten von Nutzern nicht versehentlich identifizierende Daten erheben können. Browseranbieter können diesen Ansatz auch für API-Daten nutzen, die Webanwendungen und Drittanbietern zur Verfügung gestellt werden. Ein Beispiel dafür sind die sehr genauen Timing-APIs zur Messung der Seitenleistung von window.performance.now(). Der Browser kennt diese Werte auf Mikrosekunden genau. Die Genauigkeit der zurückgegebenen Werte wird jedoch bewusst reduziert, indem auf die nächste 20-Mikrosekundengrenze gerundet wird, um eine Verwendung beim Fingerprinting zu vermeiden (und auch aus Sicherheitsgründen, um zugegebenermaßen Timing-Angriffe zu vermeiden). Ziel ist es, dafür zu sorgen, dass die APIs nützlich bleiben, aber die Antworten weniger eindeutig sind. Im Wesentlichen soll „Herdenimmunität“ sichergestellt werden, indem Ihr Gerät mehr wie das Gerät eines anderen Herstellers aussieht, anstatt es spezifisch für Sie zu sein. Aus diesem Grund bietet Safari eine vereinfachte Version der Systemkonfiguration.

Datenschutzbudget durchsetzen

Das Privacy Budget ist ein Vorschlag, der vorschlägt, dass Browser die von den einzelnen Fingerprinting-Flächen offengelegten Informationen schätzen. Sie wurde noch nicht in Browsern implementiert. Ziel ist es, leistungsstarke APIs zu ermöglichen und gleichzeitig den Datenschutz für Nutzer zu wahren. Weitere Informationen zum datenschutzfreundlichen Budgetvorschlag

Verwenden Sie eine umfassende Testumgebung.

All dies hat Einfluss darauf, wie Sie Apps und Dienste erstellen. In diesem Bereich gibt es insbesondere bei Browsern und Plattformen eine große Vielfalt von Antworten und Ansätzen. Das bedeutet, dass das Testen Ihrer Arbeit in mehreren verschiedenen Umgebungen kritisch ist. Dies ist natürlich immer wichtig, es kann jedoch davon ausgegangen werden, dass das HTML-Rendering oder CSS für eine bestimmte Rendering-Engine konstant ist, unabhängig davon, in welchem Browser oder welcher Plattform sich die Engine befindet. Es kann daher verlockend sein, Tests nur in einem Blink-basierten Browser durchzuführen. Dies trifft ausdrücklich nicht auf die API-Nutzung zu, da sich Browser mit derselben Rendering-Engine in Bezug auf die Härtung ihrer API-Oberfläche gegen Fingerprinting erheblich unterscheiden können.

Das sollten Sie tun:

Überprüfen Sie Ihre eigenen Analysen und Zielgruppen, um festzulegen, welche Browser beim Testen priorisiert werden sollten.
Zu testende Browser sind Firefox, Chrome, Edge, Safari auf dem Computer, Chrome und Samsung Internet unter Android sowie Safari auf iOS. Dadurch werden Tests über die drei wichtigsten Rendering-Engines (Gecko in Firefox, verschiedene Forks von Blink in Chrome, Edge und Samsung Internet und Webkit in Safari) sowie auf Mobil- und Desktop-Plattformen durchgeführt.
Falls Ihre Website eventuell auch auf weniger gängigen Geräten wie Tablets, Smartwatches oder Spielekonsolen genutzt wird, sollten Sie den Test dort ebenfalls durchführen. Einige Hardwareplattformen sind bei Browserupdates nicht auf Mobilgeräten und Computern verfügbar. Das bedeutet, dass einige APIs in den Browsern dieser Plattformen möglicherweise nicht implementiert sind oder nicht verfügbar sind.
Testen Sie die Tests mit einem oder mehreren Browsern, bei denen der Datenschutz als Anreiz dient. Fügen Sie kommende Vorab- und Testversionen Ihrer gängigsten Browser ein, sofern möglich und falls verfügbar: die Technologievorschau von Safari, Canary von Chrome und die Betaversion von Firefox. Damit lassen sich API-Fehler und Änderungen, die sich auf Ihre Websites auswirken, am besten erkennen, bevor sich diese Änderungen auf Ihre Nutzer auswirken. Ebenso sollten Sie die Umgebungen Ihrer Nutzer im Hinblick auf Ihre Analysen berücksichtigen. Wenn deine Nutzer sehr viele ältere Android-Smartphones haben, nimm diese in die Tests auf. Die meisten Menschen haben nicht die schnelle Hardware und die neuesten Releases, die ein Entwicklungsteam bietet.
Verwenden Sie zum Testen sowohl ein sauberes Profil als auch den Inkognitomodus bzw. Modus für privates Surfen. Wahrscheinlich haben Sie die erforderlichen Berechtigungen in Ihrem privaten Profil bereits gewährt. Testen Sie, was passiert, wenn Sie der Website bei einer Frage die Berechtigung verweigern.
Testen Sie Ihre Seiten explizit im Firefox-Modus Fingerabdruckschutz. Dadurch werden Berechtigungsdialogfelder angezeigt, wenn Ihre Seite versucht, Fingerprinting durchzuführen, oder bei einigen APIs ungenaue Daten zurückgeben. So können Sie feststellen, ob in Ihrem Dienst enthaltene Drittanbieter Fingerabdruckdaten verwenden oder ob Ihr eigener Dienst davon abhängt. Sie können dann überlegen, ob das absichtliche Fuzzing es erschwert, das zu tun, was Sie benötigen. Nehmen Sie entsprechende Korrekturen vor, um Daten aus einer anderen Quelle zu beziehen, auf diese zu verzichten oder weniger detaillierte Daten zu verwenden.
Wie bereits im Modul zu Drittanbietern erläutert, ist es auch wichtig, die Abhängigkeiten von Drittanbietern zu prüfen, um festzustellen, ob sie Fingerprinting-Techniken verwenden. Passives Fingerprinting ist schwer zu erkennen (und es ist nicht möglich, wenn ein Drittanbieter dies auf seinem Server durchführt). Der Fingerprinting-Modus kann jedoch einige Fingerprinting-Techniken kennzeichnen. Wenn Sie nach der Verwendung von „navigator.userAgent“ oder einer unerwarteten Erstellung von <canvas>-Objekten suchen, finden Sie eventuell auch Ansätze, die genauer untersucht werden sollten. Es lohnt sich auch, nach dem Begriff „probabilistische Übereinstimmung“ in Marketing- oder technischen Materialien zu suchen, die einen Dritten beschreiben. Dies kann manchmal auf die Verwendung von Fingerprinting-Techniken hinweisen.

Browserübergreifende Testtools

Das Testen Ihres Codes aus Datenschutzgründen ist schwierig zu automatisieren. Die Punkte, auf die Sie bei manuellen Tests achten sollten, werden weiter oben beschrieben. Was passiert, wenn Sie der Website beispielsweise die Berechtigung für APIs verweigern, auf die sie zuzugreifen versucht, und wie wird dies dem Nutzer angezeigt? Bei einem automatisierten Test kann nicht festgestellt werden, ob die Website dem Nutzer Vertrauen entgegenbringt oder umgekehrt.

Nach der Prüfung der Website können jedoch die API-Tests automatisiert werden, um zu bestätigen, dass in neueren Browserversionen (oder in künftigen Beta- und Vorabversionen) keine Fehler aufgetreten sind. Die APIs sollten weitgehend Teil Ihrer vorhandenen Testsuite sein. Wenn Sie mit der API-Oberflächenabdeckung arbeiten, sollten Sie bei Ihren automatisierten Testtools berücksichtigen, dass die meisten Browser ein gewisses Maß an Kontrolle darüber bieten, welche APIs und Funktionen verfügbar sind. In Chrome und bei Firefox erfolgt dies über Befehlszeilen-Switches. Wenn Sie über die Einrichtung des Testtools darauf zugreifen können, können Sie bei deaktivierten oder aktivierten APIs bestimmte Tests ausführen. Informationen zum Hinzufügen von Browser-Flags beim Start finden Sie beispielsweise im Browser-Launch-Plug-in von Cypress und im launch.args-Parameter von Puppeteer.

Verlassen Sie sich nur bei groben Informationen auf den User-Agent-String.

Ein weiteres Beispiel: Browser haben seit den Anfängen des Webs mit jeder Anfrage im HTTP-User-Agent-Header eine Selbstbeschreibung gesendet. Fast genauso lange fordern Menschen Webentwickler auf, den Inhalt des User-Agent-Headers nicht zu verwenden, um unterschiedliche Inhalte an verschiedene Browser zu senden. Bislang haben Webentwickler das dennoch getan, und zwar in einigen (aber nicht allen) Fällen mit einem gewissen Maß an Begründung. Da Browser nicht für ein optimales Erlebnis auf Websites aussortiert werden möchten, führt dies dazu, dass jeder Browser vorgibt, jeder andere Browser zu sein, und der User-Agent-String in etwa so aussieht:

Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.

Es soll unter anderem Mozilla/5.0 heißen, ein Browser, der zeitgleich mit den ersten Astronauten an Bord der Internationalen Raumstation vor über zwei Jahrzehnten veröffentlicht wurde. Der User-Agent-String ist natürlich eine umfangreiche Entropiequelle für Fingerprinting. Um diese Fingerabdruckbarkeit zu verringern, haben Browserhersteller entweder den User-Agent-Header entweder bereits eingefroren oder arbeiten daran. Dies ist ein weiteres Beispiel für die Änderung der von einer API bereitgestellten Daten, ohne die API unbedingt vollständig zu entfernen. Wenn ein leerer User-Agent-Header gesendet wird, würden zahllose Websites nicht mehr funktionieren, die davon ausgehen, dass er vorhanden ist. Browser entfernen in der Regel einen Teil der Details und lassen sie dann weitgehend unverändert. Dies können Sie in Safari, Chrome und Firefox beobachten. Dieser Schutz vor detailliertem Fingerprinting bedeutet im Wesentlichen, dass Sie sich nicht mehr darauf verlassen können, dass der User-Agent-Header korrekt ist. In diesem Fall sollten Sie nach alternativen Datenquellen suchen.

Die Daten im User-Agent werden zwar nicht vollständig entfernt, aber die Daten sind mit einem geringeren Detaillierungsgrad verfügbar oder manchmal ungenau, weil unter Umständen eine ältere, sich nicht ändernde Zahl gemeldet wird. Für Firefox, Safari und Chrome wird die gemeldete macOS-Versionsnummer beispielsweise auf zehn begrenzt. Weitere Informationen finden Sie unter Update zur Reduzierung des User-Agent-Strings. Die genauen Details dazu, wie Chrome die Daten im User-Agent-String reduzieren möchte, finden Sie unter User-Agent-Reduktion. Kurz gesagt, können Sie davon ausgehen, dass die gemeldete Browserversionsnummer nur eine Hauptversion enthält. Die Versionsnummer sieht dann so aus, als wäre 123.0.0.0, auch wenn der Browser die Version 123.10.45.108 ist. Eine kleine Auswahl bleibt jedoch bestehen, sodass eine kleine Auswahl nicht mehr angezeigt wird. Eine imaginäre Chrome-Version 123.45.67.89, die auf einem imaginären „Windows 20“ ausgeführt wird, meldet also ihre Versionsnummer wie folgt:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Die wichtigsten Informationen (die Browserversion) sind weiterhin verfügbar: Chrome 123 unter Windows. Die Informationen der Tochtergesellschaft (die Chip-Architektur, die Windows-Version, die von Safari imitierte Version, die Nebenversion des Browsers) sind nach dem Einfrieren nicht mehr verfügbar.

Vergleichen Sie dies mit einem „aktuellen“ Chrome-User-Agent auf einer anderen Plattform:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,

Wie Sie sehen, unterscheiden sich nur die Chrome-Versionsnummer (104) und die Plattformkennung.

Ebenso zeigt der User-Agent-String von Safari eine Plattform und eine Safari-Versionsnummer sowie eine Betriebssystemversion unter iOS an, aber alles andere ist eingefroren. Eine imaginäre Safari-Version 1234.5.67, die auf einem imaginären macOS 20 ausgeführt wird, könnte dem User-Agent Folgendes geben:

Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,

und auf einem imaginären iOS 20-System könnte es so aussehen:

Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.

Die wichtigsten Informationen (z. B. Safari, unter iOS oder macOS) sind verfügbar und iOS Safari stellt weiterhin eine iOS-Versionsnummer bereit. Allerdings sind viele der zusätzlichen Informationen, die in der Vergangenheit verfügbar waren, inzwischen eingefroren. Dazu gehört auch die Versionsnummer von Safari, die nicht unbedingt verfügbar ist.

Die Änderungen am gemeldeten User-Agent wurden heiß diskutiert. https://github.com/WICG/ua-client-hints#use-cases summarises fasst einige Argumente und Gründe für die Änderung zusammen. Rowan Merewood hat eine Folienpräsentation, in der einige Strategien zur Migration von der Verwendung des User-Agents zur Differenzierung im Kontext des Vorschlags UA erläutert werden.

Fuzzing

Fuzzing ist ein Begriff aus der Sicherheitspraxis, in dem APIs mit unerwarteten Werten aufgerufen werden, in der Hoffnung, dass sie diese unerwarteten Werte schlecht verarbeiten und ein Sicherheitsproblem verursachen. Webentwickler sollten mit Cross-Site-Scripting (XSS) vertraut sein. Dabei werden einer Seite schädliche Skripts hinzugefügt. Dies ist häufig darauf zurückzuführen, dass eingeschleuster HTML-Code nicht richtig maskiert wird. Dazu führen Sie eine Suchanfrage mit dem Text <script> durch. Backend-Entwickler sind mit der SQL-Injection vertraut, bei der Datenbankabfragen, die Nutzereingaben nicht korrekt validieren, Sicherheitsprobleme verursachen (wie beispielsweise von xkcd mit Little Bobby Tables). Fuzzing oder Fuzztests werden besser für automatisierte Versuche eingesetzt, viele verschiedene ungültige oder unerwartete Eingaben für eine API bereitzustellen. Außerdem werden die Ergebnisse auf Sicherheitslücken, Abstürze oder andere fehlerhafte Verarbeitungen geprüft. Dies sind alles Beispiele für die absichtliche Angabe falscher Informationen. Hier erfolgt dies jedoch präventiv durch Browser, indem der User-Agent absichtlich falsch gemacht wird, um Entwickler zu ermutigen, sich nicht mehr auf diese Daten zu verlassen.

Das sollten Sie tun:

Überprüfen Sie Ihre Codebasis auf Abhängigkeiten vom User-Agent-String. Bei einer Suche nach navigator.userAgent werden die meisten Vorkommen in Ihrem clientseitigen Code gefunden und der Back-End-Code sucht wahrscheinlich nach User-Agent als Header, einschließlich Ihrer Abhängigkeiten.
Wenn Sie in Ihrem eigenen Code Verwendungen finden, ermitteln Sie, wonach der Code sucht, und suchen Sie einen anderen Weg, um diese Differenzierung zu erreichen (oder finden Sie eine Ersatzabhängigkeit oder arbeiten Sie mit der vorgelagerten Abhängigkeit zusammen, indem Sie Probleme melden oder bei ihm nach Updates fragen). Manchmal ist eine Browserdifferenzierung erforderlich, um Programmfehler zu umgehen. Sobald der User-Agent eingefroren ist, wird dies jedoch zunehmend nicht mehr möglich sein.
Eventuell sind Sie in Sicherheit. Wenn Sie nur die Kernwerte der Marke, der Hauptversion und der Plattform verwenden, sind diese höchstwahrscheinlich weiterhin verfügbar und im User-Agent-String korrekt.
Der MDN beschreibt gute Methoden, um die Abhängigkeit vom User-Agent-String ("Browser-Sniffing") zu vermeiden, der in erster Linie die Funktionserkennung ist.
Wenn Sie in irgendeiner Weise auf den User-Agent-String angewiesen sind (auch wenn Sie nur wenige nützliche Kernwerte verwenden), ist es eine gute Idee, Tests mit zukünftigen User-Agents in neuen Browser-Releases durchzuführen. Es ist möglich, mithilfe von Beta- oder Technologievorschau-Builds mit den anstehenden Browserversionen selbst zu testen, aber es ist auch möglich, zu Testzwecken einen benutzerdefinierten User-Agent-String festzulegen. Sie können den User-Agent-String bei der lokalen Entwicklung in Chrome, Edge, Firefox und Safari überschreiben, um zu prüfen, wie Ihr Code mit verschiedenen User-Agent-Werten umgeht, die Sie möglicherweise von Nutzern erhalten.

Kundenhinweise

Ein wichtiger Vorschlag zur Bereitstellung dieser Informationen sind User-Agent-Client-Hints, obwohl diese nicht in allen Browsern unterstützt werden. Unterstützte Browser übergeben drei Header: Sec-CH-UA gibt die Marke und Versionsnummer des Browsers an, Sec-CH-UA-Mobile gibt an, ob die Anfrage von einem Mobilgerät stammt, und Sec-CH-UA-Platform, mit dem das Betriebssystem benannt wird. Das Parsen dieser Header ist weniger einfach, als es scheint, da es sich um strukturierte Header und nicht um einfache Strings handelt. Dies wird von Browsern erzwungen, die „schwierige“ Werte senden. Diese Werte werden bei nicht ordnungsgemäßem Parsen falsch verarbeitet. Dies ist wie zuvor ein Beispiel für „Fuzztests“, die vom Browser präventiv durchgeführt werden. Ein Entwickler, der diese Daten verwendet, muss sie ordnungsgemäß verarbeiten, da die Daten so konzipiert sind, dass unsachgemäßes oder Lazy Parsing wahrscheinlich zu schlechten Ergebnissen führt. Es werden beispielsweise nicht vorhandene Marken oder Strings angezeigt, die sich nicht ordnungsgemäß schließen. Glücklicherweise werden diese Daten vom Browser auch direkt als navigator.userAgentData in JavaScript zur Verfügung gestellt. In einem unterstützenden Browser könnte das etwa so aussehen:

{
  "brands": [
    {
    "brand": " Not A;Brand",
    "version": "99"
    },
    {
    "brand": "Chromium",
    "version": "96"
    },
    {
    "brand": "Google Chrome",
    "version": "96"
    }
  ],
  "mobile": false
}