Die Zukunft der Geräteerkennung im Web

Wenn Sie wissen, von welchem Gerät aus ein Besucher auf Ihre Website zugreift, können Sie die Bildauflösung anpassen oder gerätespezifische Entscheidungen treffen und Nutzern so ein besseres Erlebnis bieten. Ursprünglich bestand die Geräteerkennung hauptsächlich im Parsen des HTTP Headers User-Agent und im Ergreifen entsprechender Maßnahmen. In jüngerer Zeit verlässt man sich dabei auf eine ausgereiftere Methode: Client Hints. Inzwischen zeichnet sich sogar eine Abkehr vom User-Agent Header ab – aber noch besteht für Sie kein Grund zur Panik.

Die meisten Entwickler werden bestätigen, dass der User-Agent Header ein merkwürdiges Konstrukt ist. Nach drei Jahrzehnten des ungebremsten Wettrüstens zwischen Browser- und Webentwicklern herrscht beim typischen User-Agent Header ein heilloses Durcheinander. Der Header, den mein aktueller Browser mit jeder Anfrage sendet, sieht beispielsweise so aus:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Die darin enthaltenen Informationen sind irreführend, denn ich verwende weder „Mozilla“ (zumindest nicht wie hier angegeben!), noch besitzt mein Mac einen Intel Chip oder basiert mein Browser auf WebKit, KHTML oder Gecko. Ich nutze auch gar keinen Safari Browser. Die einzige Information in diesem Header, die wirklich zutrifft, ist „Chrome/120.0.0.0“. Alles andere ist nur Show, um die Kompatibilität mit naiven Filtern zu verbessern.

Reduzierung des User-Agents und Datenschutz

Die Länge und Informationsfülle des User-Agent Headers wirft auch Datenschutzbedenken auf. Die Technical Architecture Group (TAG) des W3C dokumentierte bereits im Jahr 2015 das Problem des sanktionslosen Trackings. (Ich selbst war zwei Jahre lang Mitglied der TAG.) Wenn Websitebetreiber sämtliche Werte aus den Headern, die Ihr Browser beim Surfen im Internet laufend übermittelt, miteinander kombinieren, können sie möglicherweise eindeutige Rückschlüsse auf Ihre Identität ziehen. 

Wenn Sie sich also an einer Stelle einloggen und dann woanders hin wechseln, wo Sie vermeintlich Anonymität genießen, übermitteln Sie möglicherweise weiterhin Ihren eindeutigen Fingerabdruck und geben weiterhin Ihre Identität preis, ob Sie es wollen oder nicht.

Um dieses Problem in den Griff zu bekommen, hat Google das Programm zur Reduzierung des User-Agents ins Leben gerufen, mit dem die Eindeutigkeit der übermittelten Information verringert werden soll. Das ist übrigens auch der Grund, warum in meinem eigenen User-Agent Header (siehe oben) bei der Chrome Version eine verdächtig runde Zahl genannt ist und warum ich angeblich einen Intel Mac besitze, obwohl das gar nicht der Fall ist.

Bei der Reduzierung des User-Agents geht es darum, einerseits ein gewisses Maß an nützlichen Informationen zuzulassen, andererseits aber nicht so viele spezifische Daten zu liefern, dass ein Nutzer am Ende als einzigartig eingestuft werden kann. Wie einzigartig Ihr eigener Browser ist, können Sie übrigens unter amiunique.org herausfinden.

Geräteerkennung auf der Edge

Wir bei Fastly unterstützen das Google Programm, denn davon profitieren sowohl die Nutzer als auch das Web. Fastly bietet aber auch Variablen für die Geräteerkennung, die automatisch in Antworten eingefügt werden, sodass Sie das Nutzererlebnis ganz einfach auf der Edge anpassen können. Diese basieren wiederum auf einer Auswertung des User-Agent Headers.  Damit lässt sich beispielsweise Folgendes erreichen:

if (client.display.width > 1000) {
   set req.http.Feature-Device-Size = "large";
} else {
   set req.http.Feature-Device-Size = "small";
}

Die Änderungen am User-Agent Header bedeuten, dass die betreffenden Variablen unspezifischere und ungenauere Informationen liefern als bisher. Einige Daten, die wir Ihnen in der Vergangenheit zur Verfügung stellen konnten, sind heute nicht mehr verfügbar, da diese Informationen nicht mehr im User-Agent String enthalten sind (oder nicht mehr aus diesem abgerufen werden können). Dies gilt insbesondere für sehr detaillierte Werte wie Bildschirmbreite und -höhe, die auf der Edge nicht mehr genutzt werden können.

Das bedeutet aber noch lange nicht das Ende der Geräteerkennung auf der Edge. Selbst der reduzierte UA Header enthält genügend Informationen, damit Fastly die wichtigsten (und glücklicherweise auch die beliebtesten) Variablen wie client.browser.name und client.platform.mobile senden kann. Diese Variablen lassen sich bei der Personalisierung des Nutzererlebnisses nach wie vor verwenden.

Außerdem senden Browser inzwischen eine neue Generation von gerätebezogenen Metadaten in Form einer Reihe spezifischer Header:

Sec-Ch-Ua: "Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "macOS"
Sec-Fetch-User: ?1

Hier werden die Daten auf strukturiertere Weise dargestellt, sodass sie leichter in einem Vary Header genutzt werden können und es für uns noch einfacher ist, die in Ihrem Fastly Service verwendeten Metadaten einzufügen. Diese Metadaten helfen sogar dabei, ein zu stark vereinfachtes Parsen zu vermeiden (siehe zum Beispiel die Angabe „Not_A Brand“). Aber wie sieht die Zukunft der Geräteerkennung denn eigentlich konkret aus?

Der Umstieg auf Client Hints

Was tun, wenn Sie wirklich dringend genauere Angaben zum Nutzer benötigen, die Ihnen die Browser nicht mehr bereitwillig mitteilen? An dieser Stelle kommen Client Hints ins Spiel – eine weitere Erfindung von Google, die den Zugriff auf die entsprechenden Daten bei gleichzeitiger Wahrung des Datenschutzes ermöglichen soll.

Das grundsätzliche Funktionsprinzip von Client Hints ist Folgendes: Als Webentwickler erstellen Sie eine Website mit einem responsiven Layout, und Ihre HTML-Seiten werden nur anhand der Gerätedaten angepasst, die (wie bereits erwähnt) in der ersten Anfrage des Nutzers verfügbar sind. Zusätzlich fügen Sie aber auch noch einen Antwort-Header namens Accept-CH ein, um dem Browser mitzuteilen, dass Sie gerne ein wenig mehr wissen möchten, damit Sie bei nachfolgenden Anfragen ein besseres Nutzererlebnis bieten können:

Accept-CH: Sec-CH-Viewport-Width, Sec-CH-UA-Arch, Device-Memory, RTT

Wenn der Browser eines Nutzers daraufhin die für die Darstellung Ihrer Seite erforderlichen Bilder, Stylesheets und Skripte anfordert, wird er (mit Einwilligung des Nutzers) die von Ihnen angeforderten zusätzlichen Informationen bereitstellen:

Sec-CH-Viewport-Width: 1000
Sec-CH-UA-Arch: "x86"
Device-Memory: 4
RTT: 125

Auf diese Weise erhalten Sie eine Fülle an Daten, mit denen Sie Ihren Nutzern großartige Erlebnisse bieten können! Und wenn Sie Fastly nutzen, ist die Edge der ideale Ort für die Arbeit mit Client Hints – insbesondere mit besonders chaotischen Hints, die eine große Anzahl möglicher Permutationen aufweisen können. 

Angenommen, Ihr Erlebnis verlangt dem Gerät eine hohe Rechenleistung ab, wie es zum Beispiel bei WebGL der Fall ist. Hier können Sie beispielsweise den Device-Memory Hint nutzen, um zu bestimmen, mit welcher Auflösung die Grafik gerendert oder welche Bildrate angestrebt werden soll. Für den Device-Memory Hint gibt es sechs mögliche Werte, aber vielleicht möchten Sie die von Ihnen angebotenen Erlebnisse ja nur in „hochauflösend“ und „niedrigauflösend“ unterteilen. Wenn Sie die Entscheidung auf Ihrem Server treffen, müssen CDNs wie Fastlys diese beiden Varianten dennoch in sechs Slots cachen, was nicht nur die Wahrscheinlichkeit eines Cache Hits, sondern somit auch die Möglichkeit verringert, Nutzeranfragen schnell und effizient zu bearbeiten.

Client Hints sind darüber hinaus nicht nur als HTTP API verfügbar, sondern es gibt auch die JavaScript Schnittstelle NavigatorUAData, um sie in JavaScript zu lesen.

Das alles ist schön und gut, aber Client Hints sind nach wie vor mit großen Herausforderungen verbunden:

• Fehlende Unterstützung durch Firefox und Safari. Derzeit sind Client Hints nur mit Chromium-basierten Browsern nutzbar, und da Google bereits seit über einem Jahrzehnt um eine breitere Unterstützung buhlt, ist mit dieser nicht in absehbarer Zeit zu rechnen.

• Herausforderungen bei der Personalisierung von HTML-Seiten mithilfe von Client Hints. Client Hints müssen vom Browser „angefordert“ werden, und dies geschieht in einer Antwort auf eine frühere Anfrage (in der Regel, die Anfrage nach der HTML-Seite). Mögliche Lösungen für dieses Problem lauten Critical-CH (und in der Vergangenheit auch Accept-CH-Lifetime). Diese sind aber bei Weitem nicht perfekt.

Allen Herausforderungen zum Trotz scheinen sich Client Hints dennoch etabliert zu haben. Es bleibt also zu hoffen, dass sie sich weiterentwickeln, um Lösungen für weitere Anwendungsfälle und Unterstützung für sämtliche Browser zu bieten.

Best Practices bei der Geräteerkennung mit Fastly

Der ideale Ansatz besteht in der Verknüpfung von Signalen aus verschiedenen Quellen, um ein möglichst umfassendes Bild der Eigenschaften des Geräts zu erhalten und gleichzeitig die Privatsphäre der Nutzer zu schützen. Egal ob Sie VCL oder eines unserer Compute SDKs verwenden, Header lassen sich ganz einfach zu Antworten hinzufügen. So können Sie Browser dazu auffordern, Ihnen die Client Hints zu übermitteln, die Sie interessieren. Wenn Sie zum Beispiel einen VCL Service nutzen, können Sie ein VCL Snippet oder individuelles VCL verwenden, um eine Liste der gewünschten Client Hints zu vcl_deliver hinzuzufügen:

set resp.http.accept-ch = "Sec-CH-Viewport-Width, Sec-CH-UA-Arch, Device-Memory, RTT";

Anschließend können Sie auf die Hint-Informationen in Form von HTTP Headern wie req.http.sec-ch-viewport-width zugreifen. Zu Gunsten optimaler Entscheidungen ist es üblich, diese Informationen mit Variablen für die Geräteerkennung zu kombinieren. Wenn Sie die Daten einfach an einen Echtzeit-Logging-Endpoint senden möchten, fügen Sie in etwa folgenden Code zu Ihrem vcl_log hinzu:

log "syslog " + req.service_id + " my-endpoint-name :: {"
  {" "client-hints": { "}
    {" "viewport-width": ""} + req.http.sec-ch-viewport-width + {"","}
    {" "ua-arch": ""} + req.http.sec-ch-ua-arch + {"","}
    {" "device-memory": ""} + req.http.device-memory + {"","}
    {" "rtt": ""} + req.http.rtt + {"""}
  {" },"}
  {" "device-detection": { "}
    {" "mobile": ""} + client.platform.mobile + {"""}
    {" "touch": ""} + client.display.touchscreen + {"""}
  {" },"}
  {" "ua": { "}
    {" "sec-ch-ua": ""} + req.http.sec-ch-ua + {"","}
    {" "sec-ch-ua-mobile": ""} + req.http.sec-ch-ua-mobile + {"","}
    {" "sec-ch-ua-platform": ""} + req.http.sec-ch-ua-platform + {"""}
  {"}"}
{"}"}
;

Dieser Code führt die Daten aus den neuen UA Headern („sec-ch-ua-*“-Headern), den Geräteerkennungsvariablen von Fastly („client.*“-Variablen) und Client Hints, für die ein Opt-in erforderlich ist, wie beispielsweise „device-memory“, zusammen. Die entsprechenden Daten können Sie dann nach Belieben nutzen, um Anfragen mit Anmerkungen zu versehen, eine spezielle Antwort zu triggern, den Cache-Schlüssel zu ändern und vieles mehr.

Wenn Sie mit Fastly gerätespezifische Erlebnisse bieten möchten, chatten Sie mit uns unter community.fastly.com. Wir freuen uns auf Sie!