qrios

IT ist kurios!

Strategien gegen Browser-Fingerprinting

5 Kommentare

Über Browser-Fingerprints wird immer häufiger berichtet und es wird möglicherweise noch viel häufiger eingesetzt. Allerdings ist es nicht so einfach, zu ermitteln, wie weit diese Technik zu Wiedererkennung eines Nutzers respektive dessen Systems wirklich verbreitet ist. Zuletzt gab (die Tochter des Axel Springer Verlages) Zanox zu, Fingerprinting zu verwenden. Die verwendeten Verfahren sind allerdings sehr vielfältig und zielen auf unterschiedliche Eigenschaften der Browser und Systeme. Eine funktionierende Strategie gegen Fingerprinting ist also abhängig von der Erhebungsmethode.

Verwendete Daten

Ausgangspunkt für alle Browser-Fingerprints sind die User Agent Strings. Darüber teilt der Browser bei jedem Request mit, zu welcher Familie er gehört und auf welchem System er läuft. Manche Browser (IExplorer) sind geschwätziger als andere (Safari). Häufig meinen auch PlugIns und Browsererweiterungen, heraus posaunen zu müssen, dass der Nutzer so nett war, die Erweiterung zu installieren. Eine solche Installation kann durchaus auch unbeabsichtigt und sogar unbemerkt vom User stattfinden. Nach wie vor installieren Firmen, wie Adobe, HP oder Oracle – gerne unbemerkt – Browser-PlugIns.

Je länger ein System genutzt und angepasst wird, desto geringer ist die Wahrscheinlichkeit, dass der User Agent String weltweit mehrfach auftaucht. Zanox behauptet zwar, dass die Daten nur wenige Tage verwendbar sind, dies gilt aber nur in Hinblick auf die Tatsache, dass Zanox das Verfahren tatsächlich auch zur Berechnung der Kosten ihrer Kunden verwendet. Effektiv dürften mindestens 2/3 aller Nutzer sicher auch über mehrere Wochen erkennbar sein. Insbesondere in Zusammenhang mit ergänzenden Techniken (z.B. Browser-Update-Informationen) lässt sich eine Historie herstellen.

Neben dem User Agent String werden Informationen über den Browser vor allem mittels JavaScript erfasst. Wichtigste Quelle für Browser-Unterschiede ist das JavaScript-Object navigator und dort besonders die Liste der unterstützten Mime-Types: navigator.mimeTypes. Mit über 100 unterschiedlich sortierten Einträgen in einem typischen Browser liefert diese Liste eine hervorragende Quelle für Differenzen. Mit ein wenig Datenanalyse lässt sich damit selbst ein Nutzer mit verschiedenen Browsern auf dem gleichen Rechner und mit der gleichen IP-Adresse erkennen.

Während die bisher beschriebenen Verfahren darauf basieren, dass der WebServer Daten abfragt, die unabhängig von ihm existieren, verwenden weitergehende Techniken Methoden, die die relevante Information zuvor auf dem Rechner ablegen. Insofern fallen diese Techniken direkt in den Bereich des Cookie-Ersatzes. Basis aller dieser Verfahren ist der Browser-Cache. Eine sehr simple Methode ist die Übermittlung von IDs als Bilder, die dann gecached werden und dem Server beim nächsten Besuch ermöglichen, die ID wiederherzustellen.

Wesentlich verbreiteter ist jedoch die Verwendung von ETags. Dabei handelt es sich um eine ID, die von den WebServern im http-Header an den Browser sendet. Das Protokoll sagt, dass diese ETag-ID bei einem Aufruf an den Server senden kann, falls der Browser das entsprechende Element zuvor bereits geladen hat. Solche ETags wurden mit http Version 1.1 eingeführt und werden von allen aktuellen Browsern unterstützt. Bisher wurden sie jedoch extrem selten verwendet. Sie bedeuten aus Sicht eines Content Management Systems mehr Probleme als Vorteile. Eine gute Demonstration der Funktionsweise findet sich hier.

ETag-basierte Erkennungssysteme sind schwer zu erkennen und funktionieren auch ohne JavaScript oder PlugIns. Besonders für Netzwerke, die Nutzer-Identitäten austauschen bieten sie sich an. Die beteiligten Unternehmen müssen lediglich ein IMG-Tag einbauen. Dieser kann ein Bild von einem unabhängigen Server laden. Der Server überträgt dann den Referer, die IP-Adresse und den User Agent String zusammen mit einer eindeutigen ID an die beteiligten Partner. Verbessert werden solche Daten mitunter durch Verfahren wie dem Post-Hack zur Umgehung einer möglichen Sperre von 3rd-Party-Cookies. Dabei wird das Bild nicht direkt aus der Seite aufgerufen sondern über einen Iframe, dessen URL und damit auch der Referer dann die Informationen aus dem Cookie enthält.

Schutzmöglichkeiten der Nutzer

Die Verknüpfung unterschiedlichster Identifikationsverfahren bedeutet für den Nutzer, dass lediglich einzelne Strategien zur Anonymisierung nicht ausreichen. Gegen ETags wirkt auf jeden Fall das Löschen des Browser-Caches. Gegen die Erkennung der Mimetypes und PlugIns mit Hilfe von JavaScript wirkt das Abschalten von JavaScript. Das regelmässige Löschen von Cookies ist inzwischen ebenfalls verbreitet. Der Privatsphären-Modus schützt nur vor dem dauerhaften Speichern von Cookies und den Einträgen im Local Storage. Gegen das Fingerprinting auf der Basis des User Agent Script gibt es darüber hinaus Browsererweiterungen und Einstellungen (Safari Entwicklermenü). Tools wie Ghostery sind zwar sehr interessant, weil sie zeigen, wer auf einer Seite tatsächlich Daten erheben will, sie schützen jedoch nur vor den allgemein bekannten Firmen. Partnernetze agieren häufig unter dem Radar der Öffentlichkeit und basieren auf Eigenentwicklung oder Lösungen von kleinen IT-Anbietern, die selbst nicht in Erscheinung treten. Das PlugIn für Firefox FireGlovs wird inzwischen nicht mehr verbreitet. Es war tatsächlich nicht in der Lage, den Nutzer vor kombinierten Fingerprint-Verfahren zu schützen. [Update] Gábor Gulyás von Privacy Enhancing Technologies (pet-portal.eu) wies darauf hin, dass FireGlove ein Proof of Concept und nicht für zur generellen Benutzung gedacht war. Er hat unter anderem auch die gut recherchierte und wesentlich tiefer gehende Arbeit “Tracking and Fingerprinting in E-Business: New Storageless Technologies and Countermeasures” mitverfasst.[/Update]

Die effektivste Methode ist eine Kombination aus dem Löschen von Cache und Cookies, der Verwendung eines verbreiteten User Agent Strings und dem Deaktivieren von JavaScript und PlugIns. Für Sites, die eine solche Funktion erzwingen, verwendet man am besten einen separaten Browser. Ausschalten sollte man auch die Wiederherstellung der alten Tabs. Idealerweise schliesst man auch den Browser und löscht alle Daten bevor man in ein anderes Netz wechselt oder per DSL eine neue IP-Nummer bekommt.

Falls es nicht so sehr auf die Geschwindigkeit ankommt und wem die genannten Maßnahmen zu kompliziert sind, dem empfiehlt sich natürlich ein Tor-Browser.


Written by qrios

October 2nd, 2013 at 2:42 pm

Posted in analytics,privacy,web

5 Responses to 'Strategien gegen Browser-Fingerprinting'

Subscribe to comments with RSS or TrackBack to 'Strategien gegen Browser-Fingerprinting'.

  1. Wäre nicht wenigstens die Technik mit den Etags ein zustimmungspflichtiges Speichern von Daten auf der Festplatte des Nutzers? Müsste also als solche auch in den Datenschutzbestimmungen aufgeführt werden?

    Heller

    8 Oct 13 at 10:33 pm

  2. Natürlich müssten solche Sachen aufgeführt werden. Aber wie immer: wo kein Kläger, da kein Richter. Wenn selbst die Justizministerin mit dem Thema überfordert ist wundert einen das doch überhaupt nicht mehr. Die Datenschutzbeauftragten müssten umfassende Rechte bekommen und selbst Klagen können.

    gnn

    8 Oct 13 at 10:36 pm

  3. [...] gegen Browser Fingerprinting hat übrigens neulich Rene Meissner zusammengestellt. Sein [...]

  4. Gegen das widerliche ETag-Zeug müsste doch ein gut konfigurierter Squid-Proxy helfen. Dort kann man den ETag-Header überschreiben. Was die Daten vollkommen wertlos macht.

    N.

    Norbert

    25 Oct 13 at 4:16 pm

  5. @Norbert: Das wäre tatsächlich ein schöner Weg. Es müsste ja nur der Header beim Request gelöscht werden.

    qrios

    25 Oct 13 at 6:23 pm

Leave a Reply