Der User Agent-Header
Der User-Agent-Header wird seit Jahrzehnten verwendet, um den Browser zu identifizieren, der eine Verbindung zum Server herstellt, sowohl für statistische Zwecke als auch um Fehler in bestimmten Versionen des Browsers zu umgehen.
Leider wurde es auch verwendet, um Browser zu blockieren, weil sie nicht zu den „unterstützten Browsern“ gehörten. Dies wurde sowohl als reine Blockierung als auch als heimtückischere Maßnahme umgesetzt, z. B. indem nicht derselbe Inhalt gesendet wurde wie bei einem anderen Browser, „weil dieser Browser dies ohnehin nicht unterstützt“.
Um solche Probleme zu umgehen, begannen Browser damit, Teile der Identifikationszeichenfolgen einiger anderer Browser, vor allem der Hauptbrowser, zu übernehmen. Dies kann begonnen mit Internet Explorer, wenn nicht früher.
Bei Opera versuchten wir, uns einfach als „Opera“ zu identifizieren, ohne alle anderen Ansprüche, aber irgendwann mussten wir anfangen, an viele Sites falsche User Agents zu senden, weil diese uns blockierten oder uns fehlerhafte Daten schickten.
Einer der bemerkenswerteren Fälle war das, was ich das „Catch-22-Cookie“ nenne, ein schlechter Cookie-Checker, der normalerweise folgendermaßen funktioniert:
- Ein neuer Benutzer lädt die Site.
- Da der Benutzer über keine Cookies verfügt, prüfen Sie, ob der Client Cookies unterstützt, indem Sie ein Cookie senden.
- Leitet auf eine neue Seite weiter, die überprüft, ob das Cookie zurückgegeben wurde. Wenn nicht, fordert sie den Benutzer auf, Cookies zu aktivieren.
Das Problem in unserem Fall war, dass der Code in Schritt 2, der das Cookie sendete, zuerst die Zeichenfolge des User Agents mit einer Liste in einem Client Capabilities-Modul des Microsoft IIS-Servers glich. Er schickte dann nur dann ein Cookie, wenn die Liste angab, dass der User Agent Cookies unterstützte. Und da das Modul Opera nicht als Client aufgeführt hatte, der Cookies unterstützte, schickte es keine Cookies.
Als also Schritt 3 erreicht wurde, hatte Opera natürlich kein Cookie zum Senden, da es nie eines erhalten hatte, und der Benutzer wurde angewiesen, Cookies zu aktivieren. Zwickmühle!
Die betroffene Site war ziemlich groß und wichtig, also mussten wir sie reparieren. Letztendlich mussten wir jedoch Patches an Microsoft senden, um ihr Serverprodukt zu reparieren.
Damit eine solche Liste funktioniert, muss sie auf perfekten Kenntnissen aller bestehenden Kunden basieren, was schwierig und kostspielig, wenn nicht gar unmöglich ist.
Die richtige Art, diesen Test durchzuführen, wäre gewesen, immer ein Dummy-Cookie zu senden und es nach Abschluss des Tests zu entfernen. Und die Liste des Capabilities-Moduls hätte eine Sperrliste für Benutzeragenten sein sollen, an die der Server keine Cookies senden sollte.
Auch bei Vivaldi hatten wir Probleme, uns als „Vivaldi“ zu identifizieren. Wir haben versucht, angepasste User Agents für Websites zu verwenden, die nicht funktionierten. Irgendwann haben wir aufgegeben und uns für alle Websites nur noch als Chrome identifiziert, mit Ausnahme der wenigen, von denen wir wussten, dass sie unsere Vivaldi-ID korrekt verarbeiten würden (z. B. unsere eigene Website oder die unserer Partner).
Aber nicht nur der Name des Browsers kann Probleme bereiten, sondern auch die Versionsnummer.
Als Opera Version 10 erreichte, stießen wir tatsächlich auf Websites, die glaubten, die Version sei 1.0 und nicht 10.0. Der Grund dafür war, dass die Skripte, die den Header verarbeiten, so fest codiert waren, dass sie davon ausgingen, dass vor dem Versionspunkt nur eine Ziffer steht. Zweistellige Zahlen führten also dazu, dass das Skript nicht funktionierte. Wir mussten die Version daher bei 9.9 stoppen und einen zweiten Opera-spezifischen User-Agent-Namen hinzufügen, um die Versionen ab 10.x zu identifizieren.
Bei Vivaldi 1.10 stießen wir auf ähnliche Probleme. Auch hier gingen die Websites davon aus, dass die Nebenversionsnummer nur eine Ziffer enthielt, sodass 1.10 als 1.1 angesehen wurde. Stattdessen mussten wir 1.91 als Versionsnummer in der User-Agent-Zeichenfolge verwenden.
Als wir später 2.10 erreichten und immer noch auf umfangreiches Browser-Sniffing in einem Ausmaß stießen, das das Hinzufügen von Overrides unhaltbar machte, entschieden wir uns für „es!“ und hörten auf, „Vivaldi“ im allgemeinen User-Agent-Header zu senden.
Es sind nicht nur die Client-Versionsnummern, die Probleme verursachen. Vor ein paar Monaten entdeckte ich, dass der Chromium-Code die MacOS-Version in der User-Agent-Zeichenfolge bei 10.15.7, der letzten veröffentlichten Mac OSX 10.x-Version, eingefroren hatte, weil Websites Anfragen von Rechnern mit MacOS 11 (oder höher) ablehnten und diese im OS-Teil der User-Agent-Zeichenfolge verwendeten. Ups!
Dies ist tatsächlich ein Problem für unsere Fehlerberichte, da wir bei der Meldung von Fehlern die Betriebssystemversion aus der User-Agent-Zeichenfolge aufzeichnen. Wenn der Meldende also keine zusätzlichen Informationen hinzufügt, erkennen wir möglicherweise nicht, dass der Bericht für Mac OS 11, 12 oder 13 ist.
In einer ähnlichen Entwicklung musste das Chromium-Team vor einem Jahr tatsächlich eine lange Reihe von Tests durchführen, während es sich auf die Veröffentlichung von Chromium 100 vorbereitete, da die Möglichkeit bestand, dass sie auf die gleichen Probleme stoßen würden. Ich gehe davon aus, dass Mozilla etwas Ähnliches getan hat, bevor sie Version 100 erreichten.
In jüngerer Zeit wurde daran gearbeitet, den User-Agent-Header abzuschaffen. Dabei wurden zunächst die Versionsinformationen im User-Agent-Header reduziert. Chromium 106+ sendet keine detaillierten Informationen mehr zur Version, sondern nur noch „106.0.0.0“. Dies ist Teil des Übergangs zu einem neuen System zur Bereitstellung von Informationen über den Browser: „Client Hints“.
Kundenhinweise
In den letzten Jahren wurde daran gearbeitet, ein neues System erstellen um der Website genauere Informationen über den Browser bereitzustellen, sog. Kundenhinweise.
Dieses neue System basiert auf einer Reihe von HTTP-Headern mit dem Präfix „Sec-CH-“, z. B. „Sec-CH-UA“, dem neuen User-Agent-Header. Es gibt auch Header für andere Informationen, Browser-Engine, Gerät, Betriebssystem, Auflösung des Dokuments auf dem Display usw.
Standardmäßig basiert das System darauf, dass der Server angibt, welche dieser Header er empfangen möchte. Der Browser sendet sie dann, wenn er sie unterstützt. Chromium sendet derzeit jedoch immer mindestens drei dieser Header, darunter den User Agent (Sec-CH-UA), Mobil- und Plattforminformationen, und kann noch weitere senden.
Der Sec-CH-UA-Header von Chrome enthält Informationen zu Browsermarken und deren Version (Chrome und Chromium) sowie einen „Marken“-Wert namens „Keine Marke“.
Die Markenwerte werden im Header regelmäßig (basierend auf den Versionsnummern) durcheinandergewürfelt, und der Wert „Keine Marke“ wird ebenfalls regelmäßig durch Einfügen verschiedener Zeichen, die keine Buchstaben sind, wie „;“, „:“ und „.“ geändert. Dieser Vorgang wird „GREASE“ genannt und bewirkt, dass der Header variiert wird, sodass sich Websites nicht auf eine bestimmte Wertefolge oder den Text in den Werten verlassen können. Auf diese Weise werden sie dazu gezwungen, Parser zu schreiben, die den Standards entsprechen und keine Abkürzungen nehmen.
Vivaldi fügt derzeit keine Marke in diesen Header ein, sondern sendet nur „Chromium“ und die Werte „Keine Marke“.
Klientenlügen
Die große Frage zu Client Hints ist, ob sie (insbesondere Sec-CH-UA) für Browser besser funktionieren als die User-Agent-Zeichenfolge?
Werden Websites die Header richtig analysieren (wirklich??) und sie nur verantwortungsvoll verwenden (🤣 🙃). Oder werden sie anfangen, diese Informationen zu missbrauchen, um auch „nicht unterstützte“ Browser zu blockieren (😭)?
Leider deuten erste Anzeichen darauf hin, dass einige von ihnen die Analyse nicht richtig durchführen und andere sie verwenden, um „nicht unterstützte“ Browser zu blockieren.
Bisher sind uns jeweils zwei Fälle begegnet, bei denen Websites aufgrund der Art und Weise, wie die Sec-CH-UA-Headerinformationen verarbeitet wurden, mit Vivaldi nicht funktionierten.
Der erste Fall war eine Website, die in einer Version von Vivaldi funktionierte, in der nächsten jedoch aufgrund eines serverseitigen Problems nicht geladen werden konnte. Es stellte sich heraus, dass dies auf die Werteverschiebung und die GREASE-Änderung des Werts „Not A Brand“ zurückzuführen war. Chromium variiert die Wertefolge in jeder Chromium-Version unterschiedlich, z. B.:
„Chromium“;v=“108“, „Keine?Marke“;v=“8“
In der fehlerhaften Version lautete die Sequenz „Keine Marke“ und „Chromium“, und der Wert „Keine Marke“ enthielt ein Semikolon („;“), das zur Trennung von Werten in nicht zitiertText, ist aber nur ein normales Zeichen, wenn es in Anführungszeichen steht. Der Header-Parser der Website ignorierte die Anführungszeichen und das Ergebnis war, dass der Parser (und das Serverskript) abstürzte, wenn der Wert „Not A Brand“ an erster Stelle stand.
Weitere Untersuchungen ergaben, dass Browser mit einem Markenheader (z. B. Chrome und Microsoft Edge) niemals den Wert „Keine Marke“ am Anfang des Headers haben würden. Bei Browsern ohne Markennamen wäre dies bei jeder geraden Chromium-Version der Fall, d. h. bei den Extended Stable-Versionen wie 106 und 108. Und bei jeder dritten davon wäre ein Semikolon in der Zeichenfolge enthalten, was die Analyse unterbrechen würde.
Wir haben dieses Problem „gelöst“, indem wir die Reihenfolge eingefroren haben, sodass die Marke „Chromium“ in der Kopfzeile immer zuerst stand.
Meiner Meinung nach ist ein Teil des Problems hier, dass Chromium variiert den Header nicht genugUnd nicht häufig genug. Wie bereits erwähnt, würden die Markenbrowser niemals die Variante senden, die unser Problem verursacht hat. Und da Chromium den Inhalt nur für jede Chromium-Version und nicht öfter variiert, kann es lange dauern (Jahre), bis Parserprobleme wie das von uns festgestellt werden.
Ein Grund, warum der Header nicht häufiger variiert wird, besteht darin, dass der Header-Wert von Websites als Teil des Schlüssels verwendet werden kann, um zwischengespeicherte Webseiten zurückzugeben, die mit genau demselben Satz von URLs und bestimmten Headern angefordert wurden. Häufiges Ändern des Header-Werts würde die Belastung des Website-Cache-Systems und der Server erhöhen.
Ich bin dennoch der Meinung, dass dies kein Hindernis für häufigeres Variieren der Sequenz sein sollte.
Der zweites Problem war eine japanische Site, die die JavaScript-APIs verwendete, um auf die Sec-CH-UA-Werte zuzugreifen, und sich aus irgendeinem Grund weigerte, den angeforderten Inhalt bereitzustellen, wenn die Marke nicht „Chrome“ oder „Microsoft Edge“ war (Firefox wurde mit einem anderen Test akzeptiert).
Wir haben nicht noch Dieses Problem wurde umgangen, aber unseres Wissens nach besteht die einzige Lösung darin, einen der „zugelassenen“ Markennamen in unserem Header zu verwenden. „Vivaldi“ als Marke zu verwenden, würde nicht funktionieren.
Wenn wir auf weitere Probleme dieser Art stoßen, können wir das Problem meiner Vermutung nach nur vermeiden, indem wir es wie mit der alten User-Agent-Zeichenfolge machen: Wir geben uns als Google Chrome aus und stellen sicher, dass wir keine Vivaldi-spezifischen Informationen senden.
Das war vielleicht nicht das gewünschte Ziel von Client Hints, aber wenn die letzten Jahrzehnte der Verwendung von User-Agent-String-Informationen eines bewiesen haben, dann, dass nur die großen Anbieter (Betriebssystem oder Browser) in der Lage sind, die Wahrheit zu sagen. Alle anderen müssen auf die eine oder andere Weise lügen – sogar Microsoft musste lügen, als sie begannen, Internet Explorer zu vertreiben.
