Vielen Dank, dass du bei der Google I/O dabei warst! Inhalte on demand ansehen

Diese Seite wurde von der Cloud Translation API übersetzt.

Fingerabdruck

Beim Fingerprinting wird versucht, einen Nutzer zu identifizieren, wenn er Ihre Website wiederaufruft, oder denselben Nutzer auf verschiedenen Websites zu identifizieren. Viele Merkmale können sich zwischen Ihrer Einrichtung und der eines anderen Nutzers unterscheiden. Möglicherweise verwenden Sie beispielsweise ein anderes Gerät und einen anderen Browser, haben eine andere Bildschirmgröße und andere Schriftarten installiert. Wenn ich die Schriftart „Dejavu Sans“ installiert habe und Sie nicht, kann jede Website den Unterschied zwischen Ihnen und mir erkennen, indem sie nach dieser Schriftart sucht. So Fingerprinting funktioniert, erstellen Sie eine Sammlung dieser Datenpunkte, die jeweils mehr Möglichkeiten bieten, zwischen Nutzenden zu unterscheiden.

Eine förmlichere Definition könnte wie folgt aussehen: Fingerprinting ist die Aktion der Verwendung offensichtlicher und nicht offensichtlicher, langlebiger Merkmale der Nutzereinrichtung, um sie von möglichst vielen anderen Nutzern zu unterscheiden.

Warum Fingerprinting die Privatsphäre der Nutzer beeinträchtigt

Es gibt einige Grenzfälle, in denen das Fingerprinting eines Nutzers wichtig ist, z. B. bei der Betrugserkennung. Mit Fingerprinting können Nutzer aber auch über Websites hinweg verfolgt werden. Dieses Tracking erfolgt häufig ohne die Einwilligung der Nutzer oder in einigen Fällen auf der Grundlage einer ungültigen Einwilligung, die den Nutzer nicht ausreichend informiert. Wenn das passiert, finden diese Nutzer das oft etwas beunruhigend und fühlen sich eher betrogen.

Beim Fingerprinting geht es darum, Nutzer heimlich voneinander zu unterscheiden. Mithilfe von Fingerprinting können wir erkennen, Es handelt sich immer noch um denselben Nutzer auf derselben Website oder um denselben Nutzer in zwei verschiedenen Browserprofilen gleichzeitig zu erkennen. Das bedeutet, dass Nutzer websiteübergreifend mithilfe von Fingerprinting erfasst werden können. Die deterministischen und offenen Methoden des Trackings, z. B. das Speichern eines Cookies mit einer eindeutigen, nutzerspezifischen ID, können von Nutzern in gewissem Maße beobachtet und kontrolliert werden. Einige dieser Ansätze wurden im vorherigen Modul erläutert. Das ist aber gerade deshalb schwieriger, weil es verdeckt erfolgt. Es basiert auf unveränderlichen Merkmalen und geschieht höchstwahrscheinlich unsichtbar. Deshalb heißt es: „Fingerabdruck“. Es ist im Idealfall schwierig, Ihren Fingerabdruck zu ändern, sei es Ihr digitaler oder an den Enden. Ihrer Finger.

Browseranbieter wissen, dass Nutzer nicht gerne beobachtet werden, und implementieren ständig Funktionen, um das Fingerprinting einzuschränken. Einige davon haben wir im vorherigen Modul bereits kennengelernt. Hier sehen wir uns an, wie sich diese Funktionen auf Ihre Geschäftsanforderungen auswirken können und wie Sie Ihre Anforderungen trotzdem datenschutzfreundlich umsetzen können. Es geht dabei eher darum, wie sich der Browserschutz vor Fingerprinting auf Ihre Aktivitäten auswirkt, als darum, wie er Sie daran hindert, Fingerprinting zu verwenden.

In der Praxis müssen die meisten Entwickler und Unternehmen keine Fingerabdrücke von Nutzern erstellen. Wenn sich Nutzer in Ihrer App anmelden müssen, identifizieren sie sich mit ihrer Einwilligung und auf eine Weise, die sie jederzeit einseitig deaktivieren können. Dies ist eine datenschutzfreundliche Methode, um nachzuvollziehen, welche Nutzer angemeldet sind. Möglicherweise müssen sich Nutzer in Ihrer App gar nicht anmelden. Das schützt die Daten Ihrer Nutzer noch besser und Sie erheben dann nur die Daten, die Sie benötigen.

Do

Prüfen Sie Ihre Drittanbieter auf Fingerprinting. Im Modul Drittanbieter haben möglicherweise bereits eine Liste aller Drittanbieterdienste, die Sie einschließen, und die entsprechenden Webanfragen. Es ist unter Umständen möglich, diese Anfragen zu prüfen, um zu sehen, welche Daten gegebenenfalls an den Absender zurückgegeben werden. Das ist jedoch oft schwierig. Der Fingerabdruck ist von Natur aus ein verdeckter Vorgang, bei dem Daten angefordert werden, die nicht der Nutzergenehmigung unterliegen.

Es empfiehlt sich, auch die Datenschutzerklärungen Ihrer Drittanbieterdienste und -abhängigkeiten zu lesen und nach Anzeichen für Fingerprinting zu suchen. verwendet wird. Es wird manchmal als „probabilistisches Abgleichsverfahren“ oder als Teil einer Reihe von probabilistischen Abgleichsverfahren bezeichnet, im Gegensatz zum „deterministischen Abgleich“.

So funktioniert der Fingerprint

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

Hinweis: Passiver und aktiver Fingerprinting

Es gibt einen sinnvollen Unterschied zwischen passiven und aktiven Fingerprinting-Techniken. Passives Fingerprinting werden standardmäßig an die Website übermittelte Informationen verwendet. sind aktive Fingerprinting-Techniken das den Browser explizit nach zusätzlichen Informationen abfragt. Diese Unterscheidung ist wichtig, da Browser versuchen können, aktive Techniken zu erkennen und abzufangen oder zu mildern. APIs können eingeschränkt oder durch ein Dialogfeld geschützt werden, in dem der Nutzer um Erlaubnis gebeten wird. So wird er darüber informiert, dass die APIs verwendet werden, oder er kann sie standardmäßig ablehnen. Bei einer passiven Methode werden Daten verwendet, die bereits der Website zur Verfügung gestellt wurden. Das liegt oft daran, dass diese Informationen in den Anfängen des Internets allen Websites zur Verfügung gestellt wurden. Der User-Agent-String ist ein Beispiel dafür. Wir werden uns das später genauer ansehen. Es wurde als nützlich erachtet, da es viele Informationen zum Browser, zur Version und zum Betriebssystem des Nutzers liefert, damit eine Website entsprechend unterschiedliche Inhalte präsentieren kann. Allerdings werden dadurch auch mehr Unterscheidungsmerkmale, Informationen um Nutzende voneinander zu unterscheiden. Deshalb sind solche Informationen zunehmend nicht mehr verfügbar oder zumindest eingefroren. damit es nicht mehr vom anderen abhebt. Wenn Ihre Vorgehensweise auf diesen Informationen basiert, z. B. wenn Sie Codeverzweigungen je nach User-Agent – dann kann dieser Code beschädigt werden, da Browser zunehmend einfrieren oder diese Information stoppen. Tests sind hier die beste Abwehr ( mehr dazu später).

Nebenbemerkung: Fingerabdruckbarkeit messen

Das technische Maß dafür, wie viele Informationen jeder dieser Datenpunkte bereitstellt, wird als Entropie bezeichnet und wird in Bit gemessen. Eine Funktion mit vielen verschiedenen möglichen Werten (z. B. die Liste der installierten Schriftarten) kann einen großen Beitrag zur Gesamtzahl der Bits leisten, während etwas ohne große Unterscheidungskraft (z. B. das verwendete Betriebssystem) nur wenige hinzufügt. Im HTTP-Almanac wird beschrieben, wie die Verwendung von Fingerprinting automatisieren. Dabei werden die Antworten vieler verschiedener APIs in einem „Hash“ zusammengefasst, wodurch möglicherweise nur ein einer kleinen Gruppe von Nutzenden, vielleicht sogar nur einer. Maud Nalpas beschreibt dies ausführlich in in diesem YouTube-Video ansehen. Kurz gesagt: eine Liste deiner Freunde mit ihrer Lieblingsmusik, ihrem Lieblingsessen und den Sprachen, die sie sprechen... aber mit ihren Namen entfernt. Es ist sehr wahrscheinlich, dass die Liste einer Person sie eindeutig unter Ihren Freunden identifiziert oder die Liste zumindest auf nur wenige Personen eingrenzt. So funktioniert der Fingerabdruck: Die Liste der Dinge, die dir gefallen, wird zum „Hash“. Mit diesem Hash wird es einfacher, einen Nutzer als dieselbe Person auf zwei verschiedenen, nicht miteinander verbundenen Websites zu identifizieren. Das ist das Ziel des Trackings: den Wunsch der Nutzer nach Datenschutz zu umgehen.

Was tun Browser gegen Fingerprinting?

Wichtig ist vor allem, dass Browseranbieter viele verschiedene Möglichkeiten kennen, wie eine Website (oder ein auf einer Website eingebundener Drittanbieter) funktioniert. zur Berechnung eines unterscheidenden Fingerabdrucks für einen Nutzer oder für unterschiedliche Informationen, die zur Eindeutigkeit beitragen. dieses Fingerabdrucks. Einige dieser Methoden sind explizit und beabsichtigt, wie z. B. die User-Agent-Zeichenfolge des Browsers, die häufig identifiziert den Browser, das Betriebssystem und die verwendete Version (und trägt so dazu bei, Sie von mir zu unterscheiden, falls Sie und Ich verwende einen anderen Browser). Einige der Methoden sind nicht absichtlich für einen Fingerabdruck konzipiert, führen aber trotzdem dazu, z. B. 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 nur eine Liste der Geräte nach Namen abrufen. Einige haben sich erst nach der Veröffentlichung als Beitragende zu einem Fingerabdruck erwiesen, z. B. das genaue Pixel-Rendering des Anti-Aliasing von Schriftarten auf einem Canvas-Element. Es gibt noch viele weitere und jede Abweichung Ihres Browsers von meinem trägt zur Entropie bei und trägt so potenziell dazu bei, zwischen Ihnen und mir zu unterscheiden und eine einzelne Person möglichst eindeutig über Websites hinweg zu identifizieren. Auf https://amiunique.org finden Sie eine lange (aber definitiv nicht vollständige) Liste der Funktionen, die zum Fingerabdruck beitragen. Die Liste wird ständig erweitert, da es ein großes finanzielles Interesse daran gibt, Nutzer zu identifizieren, auch wenn sie das nicht möchten oder nicht erwarten.

Bestimmte leistungsstarke APIs werden nicht unterstützt

Die Antwort der Browseranbieter auf all diese Ansätze zur Berechnung des Fingerabdrucks eines Nutzers besteht darin, nach Möglichkeiten zu suchen, die Entropie zu reduzieren, die über diese APIs verfügbar ist. Die restriktivste Option besteht darin, sie gar nicht zu implementieren. Dies ist bei einigen gängigen Browsern für eine Vielzahl von Hardware- und Geräte-APIs der Fall, z. B. NFC- und Bluetooth-Zugriff von clientseitige Webanwendungen) mit Fingerprinting und Bedenken im Hinblick auf den Datenschutz als Gründe angegeben, warum sie nicht implementiert wurden. Das kann sich natürlich auf Ihre Apps und Dienste auswirken: Sie können eine API in einem Browser, der sie nicht implementiert, überhaupt nicht verwenden. Dies kann die Auswahl einiger Hardwareansätze einschränken oder vollständig ausschließen.

Das Gateway für Nutzerberechtigungen

Ein zweiter Ansatz von Browseranbietern besteht darin, API- oder Datenzugriffe ohne ausdrückliche Benutzererlaubnis zu verhindern. Dieser Ansatz wird oft auch aus Sicherheitsgründen gewählt: Eine Website sollte nicht ohne Ihre Erlaubnis 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 Einzigartigkeit eines Fingerabdrucks bei. Berechtigung erforderlich zum Erkennen der Standortbestimmung, verschlechtert sich dadurch nicht die zusätzliche Entropie, die ein Standort zur Eindeutigkeit dieses Fingerabdrucks beiträgt, eliminiert im Grunde die Verwendung der Standortbestimmung für das Fingerprinting, da dies nicht mehr unsichtbar ist. Der Sinn von Mithilfe von Fingerprinting lassen sich Nutzer verstanden voneinander unterscheiden. Wenn Sie damit einverstanden sind, dass der Nutzer weiß, dass Sie versuchen, ihn zu identifizieren, benötigen Sie keine Fingerprinting-Techniken: Bitten Sie den Nutzer, ein Konto zu erstellen und sich damit anzumelden.

Unvorhersehbarkeit hinzufügen

Ein dritter Ansatz, der in einigen Fällen verwendet wird, besteht darin, dass Browseranbieter die Antworten von APIs „verschleiern“, um sie weniger detailliert und damit weniger identifizierbar zu machen. Dies wurde im Datenmodul als Teil des Zufallsmechanismus beschrieben, den Sie bei der Erhebung von Daten von Nutzern verwenden können, um versehentlich personenbezogene Daten zu erheben. Browseranbieter können diesen Ansatz auch auf API-Daten anwenden, die Web-Apps und Dritten zur Verfügung gestellt werden. Ein Beispiel hierfür ist der sehr genaue Zeit-APIs zur Messung der Seitenleistung von window.performance.now(). Der Browser kennt diese Werte bis auf Mikrosekundengenauigkeit, aber die Genauigkeit der zurückgegebenen Werte wird durch Rundung auf die nächsten 20 Mikrosekunden absichtlich reduziert. um deren Verwendung im Fingerprinting und die Sicherheit zu vermeiden, um zeitgesteuerte Angriffe zu vermeiden. Ziel dabei ist es, dafür zu sorgen, dass die APIs weiterhin nützlich sind, die Antworten aber weniger identifizierbar sind. Im Grunde geht es darum, eine „Herdenimmunität“ zu schaffen, indem Ihr Gerät eher wie das Gerät aller anderen aussieht, anstatt sich von anderen abzuheben. Safari stellt eine vereinfachte Version der Systemkonfiguration dar genau aus diesem Grund.

Durchsetzung eines Datenschutzbudgets

Privacy Budget ist ein Vorschlag, der darauf hinweist, dass Browser die durch die Fingerprinting-Oberfläche ermittelten 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 Vorschlag für ein Datenschutzbudget

Eine breite Testumgebung verwenden

All dies wirkt sich darauf aus, wie Sie Apps und Dienste entwickeln. Insbesondere gibt es in diesem Bereich eine große Vielfalt an Reaktionen und Ansätzen in verschiedenen Browsern und auf verschiedenen Plattformen. Das bedeutet, dass es wichtig ist, Ihre Arbeit in mehreren verschiedenen Umgebungen zu testen. Dies ist natürlich immer wichtig, aber es kann vernünftig sein, davon auszugehen, dass das HTML-Rendering oder CSS für ein unabhängig davon, in welchem Browser oder auf welcher Plattform sich die Engine befindet. Daher ist es verlockend, Tests nur in einem z. B. blinkbasierter Browser). Das ist bei der API-Nutzung jedoch nicht der Fall, da sich Browser mit derselben Rendering-Engine erheblich darin unterscheiden können, wie sie ihre API-Oberfläche gegen Fingerprinting schützen.

Do

Überprüfen Sie Ihre eigenen Analysen und Zielgruppen, um die Browser festzulegen, die Sie beim Testen priorisieren sollten.
Zum Testen eignen sich vor allem Firefox, Chrome, Edge, Safari auf dem Desktop, Chrome und Samsung Internet unter Android, und Safari unter iOS. So können Sie die drei wichtigsten Rendering-Engines (Gecko in Firefox, verschiedene Forks von Blink in Chrome, Edge und Samsung Internet sowie Webkit in Safari) und sowohl mobile als auch Desktop-Plattformen testen.
Wenn Ihre Website auch auf weniger gängigen Geräten wie Tablets, Smartwatches oder Spielekonsolen verwendet werden kann, sollten Sie sie auch dort testen. Bei einigen Hardwareplattformen kann es bei Browserupdates zu Verzögerungen im Vergleich zu Mobilgeräten und Desktop-Computern kommen. Das bedeutet, dass einige APIs in den Browsern auf diesen Plattformen möglicherweise nicht implementiert oder nicht verfügbar sind.
Testen Sie mit einem oder mehreren Browsern, die den Datenschutz als Motivation angeben. Fügen Sie nach Möglichkeit und sofern verfügbar anstehende Vorabversionen und Testversionen der gängigsten Browser hinzu: Technology Preview von Safari, Canary von Chrome und Beta-Kanal von Firefox. Damit haben Sie die beste Chance, API-Fehler und Änderungen, die sich auf Ihre Websites auswirken, zu erkennen, bevor sich diese Änderungen auswirken. Ihre Nutzenden. Berücksichtigen Sie bei Ihren Analysen auch die Umgebungen Ihrer Nutzer. Wenn Ihre Nutzerbasis viele ältere Android-Smartphones umfasst, sollten Sie diese in Ihre Tests einbeziehen. Die meisten Menschen haben nicht Hardware und neueste Releases eines Entwicklerteams.
Testen Sie das Gerät mit einem sauberen Profil und im Inkognito- bzw. privaten Surfmodus. ist es wahrscheinlich, dass Sie bereits Berechtigungen erteilen, die für Ihr privates Profil erforderlich sind. Testen Sie, was passiert, wenn Sie der Website die Berechtigung für eine Frage verweigern.
Ihre Seiten explizit mit dem Fingerabdruckschutz von Firefox testen . Dadurch werden Berechtigungsdialogfelder angezeigt, wenn Ihre Seite versucht, ein Fingerprinting zu erstellen, oder bei einigen APIs werden unscharfe Daten zurückgegeben. So können Sie prüfen, ob Drittanbieter in Ihrem Dienst Fingerprint-Daten verwenden oder ob Ihr eigener Dienst davon abhängt. Sie können dann überlegen, ob das vorsätzliche Fuzzing es schwieriger macht, das zu tun, was Sie tun müssen. Sie können entsprechende Korrekturen vornehmen, um diese Daten aus einer anderen Quelle zu beziehen, darauf zu verzichten oder weniger detaillierte Daten zu verwenden.
Wie bereits im Modul zu Drittanbietern erwähnt, ist es auch wichtig, Ihre Drittanbieterabhängigkeiten zu prüfen, um festzustellen, ob sie Fingerprinting-Techniken verwenden. Passives Fingerprinting ist schwer zu erkennen (und unmöglich, wenn ein Drittanbieter es auf seinem Server durchführt). Im Fingerprinting-Modus können jedoch einige Fingerprinting-Techniken gemeldet werden. Außerdem können Sie nach Verwendungen von „navigator.userAgent“ oder unerwarteter Erstellung von <canvas>-Objekten suchen, um weitere Ansätze zu finden, die einer genaueren Prüfung bedürfen. Es lohnt sich auch, nach Verwendung des Begriffs „probabilistische Übereinstimmung“ zu suchen. im Marketing oder im technisches Material, das Dritte beschreibt, kann dies auf die Verwendung von Fingerprinting-Techniken hinweisen.

Tools für browserübergreifende Tests

Das Testen Ihres Codes aus Datenschutzgründen lässt sich nur schwer automatisieren. Was Sie beim manuellen Testen beachten sollten, wurde bereits oben beschrieben. Was passiert, wenn Sie der Website die Berechtigung für alle APIs verweigern, auf die sie zuzugreifen versucht? Wie wird das dem Nutzer angezeigt? Ein automatisierter Test kann nicht beurteilen, ob die Website dem Nutzer Vertrauen entgegenbringt oder ihn zum Misstrauen ermutigt. oder glauben, dass etwas versteckt ist.

Sobald die Website jedoch überprüft wurde, das Testen von APIs, um sicherzustellen, dass in neueren Browser-Versionen (oder in anstehende "Beta" und „preview“ Versionen) können automatisiert werden und sollten größtenteils Teil deiner bestehenden Test-Suite sein. Etwas bei Ihren automatisierten Testtools ist, dass die meisten Browser bei der Arbeit mit API-Oberflächenabdeckung welche APIs und Funktionen verfügbar sind. In Chrome geschieht dies über Befehlszeilenoptionen, in Firefox über Befehlszeilenschalter. Wenn Sie in der Einrichtung des Testtools darauf zugreifen können, können Sie bestimmte Tests mit deaktivierten oder aktivierten APIs ausführen. Beispiele für Möglichkeiten zum Hinzufügen von Browser-Flags beim Starten finden Sie beispielsweise im Browser-Launch-Plug-in von Cypress und im Parameter „launch.args“ von Puppeteer.

Nur bei groben Informationen den User-Agent-String verwenden

Ein anderes Beispiel: Seit Beginn des Webs senden Browser mit jeder Anfrage eine Beschreibung ihrer selbst im HTTP-User-Agent-Header. Fast genauso lange werden Webentwickler dazu ermutigt, den Inhalt des User-Agent-Headers nicht zu verwenden unterschiedlichen Content für verschiedene Browser bereitstellen. in manchen (aber nicht allen) Fällen. Da Browser für eine schlechtere Nutzererfahrung nicht einzeln behandelt werden sollen, Dies führt dazu, dass jeder Browser vorgibt, jeder andere Browser zu sein, und die User-Agent-Zeichenfolge sieht in etwa so aus:

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

Unter anderem wird behauptet, dass es sich um Mozilla/5.0 handelt, einen Browser, der vor über zwei Jahrzehnten veröffentlicht wurde, als die ersten Astronauten die Internationale Raumstation bestiegen. Der User-Agent-String ist natürlich eine reiche Quelle von Entropie für das Fingerprinting. Um diese Fingerprint-Fähigkeit zu verringern, haben Browserhersteller den User-Agent-Header entweder bereits eingefroren oder arbeiten daran. Dies ist ein weiteres Beispiel dafür, wie die Daten geändert werden, die eine API bereitstellt, ohne die API unbedingt vollständig zu entfernen. Wenn Sie eine leere User-Agent-Header senden, funktionieren unzählige Websites nicht mehr, da sie davon ausgehen, dass eine solche vorhanden ist. Grundsätzlich also, was Browser einige Details daraus zu entfernen und sie von da an meist unverändert zu lassen. (Sie können hier sehen, Safari, Chrome und Firefox. Dieser Schutz vor detailliertes Fingerprinting bedeutet, dass ihr euch nicht mehr darauf verlassen könnt, dass der User-Agent-Header korrekt ist. ist es wichtig, alternative Datenquellen zu finden.

Hinweis: Die Daten im User-Agent werden nicht vollständig gelöscht, sondern sind mit geringerer Granularität verfügbar manchmal ungenau, da eine ältere, sich nicht ändernde Zahl gemeldet wird. Beispielsweise wird die gemeldete macOS-Version in Firefox, Safari und Chrome auf zehn begrenzt. Weitere Informationen finden Sie im Update zur Verkürzung von User-Agent-Strings. Genaue Informationen dazu, wie Chrome die Datenmenge im User-Agent-String reduzieren möchte, finden Sie unter User-Agent-Reduzierung. Kurz gesagt: Die angezeigte Versionsnummer des Browsers enthält nur eine Hauptversion, also die Versionsnummer. wie 123.0.0.0 aussieht, auch wenn der Browser die Version 123.10.45.108 hat, und die Version des Betriebssystems wird keine Details anzeigen und von einer kleinen Anzahl unveränderlicher Optionen fest. Die imaginäre Chrome-Version 123.45.67.89 wird also auf einem imaginären „Windows 20“ würde die Versionsnummer folgendermaßen melden:

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 für Windows. Die untergeordneten Informationen (Chiparchitektur, Windows-Version, Safari-Version, die nachgeahmte Browser-Nebenversion) sind nach dem Einfrieren jedoch 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,

Nur die Chrome-Versionsnummer (104) und die Plattformkennung unterscheiden sich.

Ebenso enthält der User-Agent-String von Safari eine Plattform und eine Safari-Versionsnummer sowie eine Betriebssystemversion unter iOS. aber alles andere ist eingefroren. So könnte der User-Agent einer fiktiven Safari-Version 1234.5.67, die auf einem fiktiven macOS 20 ausgeführt wird, so aussehen:

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 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**

Auch hier sind die grundlegenden Informationen (Safari, d. h. für iOS oder macOS) verfügbar und iOS Safari bietet weiterhin eine iOS-Versionsnummer. aber viele der bisher verfügbaren Zusatzinformationen sind seitdem eingefroren. Dazu gehört auch die Safari-Versionsnummer, 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 einige der Argumente und Gründe für die Änderung. Rowan Merewood bietet eine Folienpräsentation an. mit einigen Strategien für die Umstellung weg von der Verwendung des User-Agent zur Differenzierung. Diese sind im Kontext des weiter unten erläuterten Vorschlags „Client Hints“ in UA beschrieben.

Fuzzing

Fuzzing ist ein Begriff aus der Sicherheitspraxis, bei dem APIs mit unerwarteten Werten aufgerufen werden, in der Hoffnung, dass sie diese und führt zu einem Sicherheitsproblem. Webentwickler sollten mit Cross-Site-Scripting (XSS) vertraut sein. Bei diesem Verfahren wird einer Seite ein schädliches Skript hinzugefügt, oft weil die Seite eingeschleuste HTML nicht korrekt maskiert (Sie führen also eine Suchanfrage aus mit dem Text <script>). Backend-Entwickler werden über SQL-Injection informiert, Datenbankabfragen, die Nutzereingaben nicht korrekt validieren, stellen Sicherheitsprobleme offen (wie in xkcd mit Little Bobby Tables). Fuzzing bzw. Fuzzing ist sinnvoller. wird für automatisierte Versuche verwendet, viele verschiedene ungültige oder unerwartete Eingaben an eine API zu senden und die Ergebnisse auf Sicherheitslücken zu prüfen. Abstürze oder andere unangemessene Handhabung. Dies sind alles Beispiele für die vorsätzliche Angabe unrichtiger Informationen. Hier wird es jedoch präventiv durch Browser (indem der User-Agent absichtlich falsch gesetzt wird), um Entwickler zu ermutigen, sich nicht mehr auf diese Daten zu verlassen.

Do

Prüfen Sie Ihre Codebasis auf Abhängigkeiten vom User-Agent-String. Eine Suche nach navigator.userAgent wird wahrscheinlich die meisten Vorkommen in Ihrem clientseitigen Code finden. Im Backend-Code wird wahrscheinlich nach User-Agent als Header gesucht.
Wenn Sie Verwendungen in Ihrem eigenen Code finden, ermitteln Sie, wonach der Code sucht, und finden Sie eine andere Möglichkeit, diese Unterscheidung vorzunehmen. Sie können auch eine Ersatzabhängigkeit finden oder mit der Abhängigkeit upstream arbeiten, indem Sie Probleme melden oder nach Updates fragen. Manchmal zur Umgehung von Fehlern ist eine Browserdifferenzierung notwendig, aber der User-Agent wird dies nach Einfrieren zunehmend nicht mehr ermöglichen.
Du bist vielleicht in Sicherheit. Wenn ihr nur die Kernwerte Marke, Hauptversion und Plattform nutzt, sind diese und im User-Agent-String korrekt sein.
MDN beschreibt gute Möglichkeiten, die Abhängigkeit von dem User-Agent-String ("Browser-Sniffing") zu vermeiden. die Hauptfunktion ist die Funktionserkennung.
Wenn ihr euch in irgendeiner Weise auf den User-Agent-String verlässt (auch wenn ihr nur die wenigen Kernwerte verwendet, die noch nützlich sind), ist es eine gute Wahl, mit User-Agents testen, die in neuen Browser-Versionen verfügbar sein werden. Es ist möglich, mit diesen anstehenden Browserversionen selbst zu testen, indem Beta- oder Technologie-Vorabversionen verwendet werden. Es ist aber auch möglich, einen benutzerdefinierten User-Agent-String für den Test festzulegen. Sie können den User-Agent-String in Chrome, Edge Firefox und Safari bei der lokalen Entwicklung, um zu prüfen, wie Ihr Code mit verschiedenen User-Agent-Werten umgeht, die Sie möglicherweise von Nutzern erhalten.

Client-Hints

Ein wichtiger Vorschlag zur Bereitstellung dieser Informationen sind User-Agent-Client-Hinweise. Diese werden jedoch nicht von allen Browsern unterstützt. Unterstützte Browser geben drei Header weiter: Sec-CH-UA, wodurch die Marke und die Versionsnummer des Browsers Sec-CH-UA-Mobile: Gibt an, ob die Anfrage von einem Mobilgerät stammt und Sec-CH-UA-Platform, der das Betriebssystem heißt. Das Parsen dieser Header ist weniger einfach, als es scheint, da es sich hierbei nicht um einfache Strings, sondern um strukturierte Header handelt. Dies wird durch Browser erzwungen, die „schwierige“ Werte senden, die bei nicht ordnungsgemäßem Parsen falsch verarbeitet werden. Dies ist, wie bereits erwähnt, ein Beispiel für „Fuzz-Tests“, die vom Browser proaktiv durchgeführt werden. Ein Entwickler, der diese Daten verwendet, muss da die Daten so konzipiert sind, dass ein unsachgemäßes oder verzögertes Parsing wahrscheinlich zu schlechten Ergebnissen führt, z. B. dass Marken angezeigt werden, oder Zeichenfolgen, die nicht ordnungsgemäß geschlossen werden.) Glücklicherweise stellt der Browser JavaScript auch diese Daten direkt als navigator.userAgentData, der in einem unterstützenden Browser in etwa wie folgt aussehen könnte:

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