Ich habe mir vor kurzem die Erweiterung IPvFoo im Firefox eingerichtet, weil ich von zu Hause aus jetzt nativ IPv6 nutze und sehen will, wie viele Webseiten IPv6 anbieten. Das kleine Symbol in der Adresszeile zeigt aber nicht nur die IP-Version für die Seite selbst, sondern auch für die genutzten Ressourcen an. Meist fällt dabei ein Mix auf, weil einige Teile zum Beispiel über ein CDN abgerufen werden, das noch kein IPv6 unterstützt, oder es gibt auch umgekehrte Fälle.

Bei einem Besuch der Seiten jena.de und deutschland.de (im Februar 2018) fiel mir solch eine Mischung auf: Die Seiten selbst werden über IPv4 bezogen, eingebundene Inhalte aber zum Teil über IPv6, weshalb ich an der Stelle nachsah, was genau passiert. Beim Klick auf das Symbol von IPvFoo wurde angezeigt, dass Ressourcen von fonts.googleapis.com, fonts.gstatic.com, translate.google.com, www.google.com und anderen Servern geladen wurden.

Hinweis: Die Seite jena.de hat mittlerweile (Juli 2020) nachgebessert und alle Fremdressourcen entfernt. Aber der Veranstaltungskalender strotzt (Nov. 2020) vor Google-Bezügen.

Ressourcen von Fremdanbietern sind attraktiv

Ungewöhnlich ist es heutzutage nicht, dass Webseiten einige Ressourcen von anderen Anbietern einbinden, eher würde ich auch sagen, dass dies in den letzten Jahren zugenommen hat. Früher gab es das Problem, dass viele Fremdanbieter – zum Beispiel auch Google – nicht sehr schnell die Daten geliefert haben und die Darstellung der Seite blockiert wurde. Dies führte zu unerwünschten Effekten, weshalb die Seitenbetreiber solche Fremdressourcen gemieden haben.

Die Verhältnisse haben sich aber geändert und meist sind die Server der Fremdanbieter besser angebunden als der eigene Server. Daher ist es für viele Webseitenbetreiber attraktiv geworden, Bilder, Schriftdateien, CSS- oder JavaScript-Dateien für Bibliotheken wie jQuery oder React von zentralen Stellen anstatt dem eigenen Server zu laden. Dies entlastet natürlich den eigenen Server und die eigene Leitung, zum Teil kümmern sich die zentralen Stellen auch gleich mit um die Aktualisierung der Bibliotheken und bei Programmen wie Wordpress werden zum Beispiel Module von wp.com geladen, was beim Zusammenklicken der Webseite nicht unbedingt auffällt.

Der süße Reiz und die Hoffnung, nichts passiere

Diese Vernetzung der Seiten bzw. die Bündelung der Zugriffe an zentraler Stelle hat jedoch auch einen Nachteil. Die Anbieter mögen vielleicht selbstlos einen ungenutzten Teil ihrer Infrastruktur, die sie für ihr Geschäft betreiben müssen, vielen (Open-Source-)Projekten zur Verfügung stellen, aber mit jedem Abruf der Daten von einem Server, hinterlässt der Nutzer notwendige Informationen wie seine Adresse und den gesuchten Dateinamen. Bei einem Browser geht es sogar so weit, dass über den Referer-Header dem Server die URL mitgeteilt wird, auf der die Ressource eingebunden ist. Die zentrale Stelle wird also indirekt über jede besuchte Seite informiert.

Google stellt hierfür vielleicht ein Extrem dar. Mit dem Klick auf einen Treffer in den Suchergebnissen verlässt man scheinbar die Google-Welt. Aber bei Seiten, die Schriften oder Bibliotheken von Google-Servern einbinden, werden weiterhin Anfragen an Google gesendet – inklusive dem Referer. Google ist also in der Lage, die Bewegungen auf der Webseite zu rekonstruieren, ohne dass offensichtliche Werkzeuge wie Google-Analytics einsetzt werden.

Da viele Webseiten die Angebote von Google nutzen, kann Google sehr wahrscheinlich den gesamten Weg eines Benutzers durchs Internet rekonstruieren. Aber Google ist die diesem Sinne eh super aufgestellt: Mit DNS-Servern, Google-APIs und Diensten wie YouTube, Translate und Calendar, die einen echten Mehrwert bieten, begleitet es die Surfer fast lückenlos durchs Internet.

Und Google ist nicht allein: Dienste wie Akamai, Cloudflare oder CloudFront von Amazon werden auch häufig genutzt, um die eigenen Server vom Abruf sich selten ändernder Dateien zu entlasten (CDN) oder DDOS-Angriffe abzuwehren. Dabei werden aber diesen Anbietern en passant Informationen über die Benutzer im Internet geliefert, die diese gewinnbringend verwerten können.

Es mag vielleicht gesetzliche Bestimmungen geben, die eine solche Nutzung untersagen, aber besser wäre es, wenn die Möglichkeit gar nicht erst gegeben wird. Wenn man vor jemanden auf den Tisch eine Schale mit Schokolade stellt und sagt »Du darfst aber nichts nehmen« und anschließend den Raum verlässt, dann ist es illusorisch zu glauben, derjenige greife niemals zu – noch dazu wo die Anbieter hier Hunger haben und ihr Geschäftsmodell genau auf der Verwertung solcher Daten beruht.

Zerschneidet das Internet!

Eine ähnliche Diskussion gab es schon einmal um die Social-Media-Buttons von Facebook, Twitter & Co. Diese kamen vor einigen Jahren total in Mode und auf jeder Seite im Internet waren die Bilder eingebunden, die immer von den Servern von Twitter oder Facebook geladen wurden. Somit konnten diese Anbieter auch schön den Weg der Benutzer verfolgen, vor allem auf Nachrichtenseiten, womit sie die Interessen der Benutzer auch über Webseiten erkunden konnten, die sie gar nicht steuerten.

Eine datensparsame Lösung für die Social-Media-Buttons fand sich dann in der Form, dass die Bilder nicht von den Fremdservern eingebunden wurden oder durch eine Vorstufe der Abruf der Bilder erst bestätigt werden musste.

Ebenso sollte es auch mit den oben erwähnten Dateien passieren. CSS-, JavaScript- und Schriftdateien sollten vom Server der Webseite oder einem anderen Server des Betreibers geladen werden. Die jetzige Ausprägung der Vernetzung ist zu viel und läuft auch den ursprünglichen Gedanken den Internets von Dezentralisierung und Redundanz zu wider.

Es ist zwar unwahrscheinlich, dass die Server dieser CDN-Betreiber ausfallen, aber dennoch sind die Webseitenbetreiber von diesen abhängig und das sollten sie bedenken. Soll die Seite nur so lange funktionieren, bis der CDN-Betreiber die Datei löscht? Sind die 500 Kilobyte die Abhängigkeit wert?

Für externe Dienste wie Google-Translate, das zum Beispiel auf jena.de eingesetzt wird, sollte es eine zweistufige Lösung geben, bei der zuerst die Einbindung von Google-Translate bestätigt werden muss, bevor die relevanten Elemente geladen werden.

Referer im Firefox einschränken

Als Besucher von Webseiten kann man diesem Problem teilweise entgehen. Ich habe im Firefox unter about:config die Einstellung network.http.sendRefererHeader gefunden. Mit dem Wert 1 sendet der Firefox nicht mehr den Referer-Header für die Ressourcen, die in einer Seite eingebunden sind. Bei einem Klick auf einen Link wird jedoch der Referer mitgeschickt (für die dortigen Unterressourcen nicht).

Man kann auch komplett den Referer unterbinden, jedoch würde ich aus Sicht der Seitenbetreiber davon abraten, um doch noch die Möglichkeit zu haben, eine gewisse Statistik über die Seitennutzung zu erstellen.

Leider funktioniert damit Twitter nicht mehr vollständig. Bei allen XMLHttpRequests ohne einen Referer antwortet Twitter mit 403 Forbidden.

Auch vom Server aus kann die Übermittlung des Referer-Headers gesteuert werden. In den Antworten über den Header Referrer-Policy dem Browser mitgeteilt werden, wann er den Referer setzen soll. Im Abschnitt See also der MDN-Referenz für Referrer-Policy sind noch weitere Möglichkeiten wie HTML-Attribute erwähnt.

Siehe auch Datenzugriffe im HTML steuern.

YouTube ohne Cookies

Für die Einbindung von YouTube-Videos auf der eigenen Seite wird von YouTube auch eine datensparsamere Variante über youtube-nocookie angeboten. Statt youtube.com im Verweis kann man youtube-nocookie.com verwenden und YouTube wird dann keine Cookies einsetzen.

Anhand der IP-Adresse, des Referer-Headers und weiterer Informationen wird Google zwar weiterhin herausfinden können, wer der Nutzer ist, aber ein klein wenig aufwändiger ist es und man setzt ein klares Zeichen für Datensparsamkeit.

Meinungen anderer

Bei Kuketz gibt es auch eine Darlegung des Themas.