Archiv der Kategorie: Web-Tracking

Kein Schutz beim Offline-Tracking

Hallo zusammen,

in der Informationssicherheit lassen sich viele Probleme durch einfache Lösungsmuster erschlagen. Beispiele sind z.B. der Einsatz SSL/TLS zur Gewährleistung der Vertraulichkeit der Informationen auf dem Transportweg oder der Einsatz von Hash-Verfahren, um der Klartextspeicherung eines Passwortes zu entgehen. Diese Denkmuster wird man sowohl in der Hochschullehre, als auch (in abgeschwächter Form) bei beruflichen Weiterbildungen finden. Kritisch wird es jedoch dann, wenn diese Denkmuster nicht mehr länger für den jeweiligen Anwendungsfall durchdacht und blind angewendet werden.

Das passiert leider häufiger als man denkt und an dieser Stelle muss ich mich schonmal bei Tom Lukaß, Autor des wirklich tollen Artikels Offline-Tracking: Kundenfrequenzmessung in Ladengeschäften (vom 06.07.2016) entschuldigen, allerdings liefert mir dieser ein gutes Beispiel. Der Beitrag behandelt das WLAN-Tracking: Dabei werden die Mobilgeräte zur Besucherverfolgung (z.B. in einem Supermarkt) verwendet und durch spezielle Hardware kann ebenfalls eine Positionsbestimmung durchgeführt werden. Der Autor empfiehlt die Anwendung eines Hashverfahrens, damit die genauere Identifikation des Besuchers ausgeschlossen bzw. die MAC-Adresse anonymisiert wird:

Das WLAN-Tracking sollte aufgrund von anonymisierten MAC-Adressen durchgeführt werden. Die MAC Adresse lässt sich anonymisieren, in dem man sie gleich nach dem Eingang auf dem Router mit einer zufälligen Zahlenreihe ergänzt (sog. SALT) und aus der erweiterten Adresse einen Hashwert bildet. Das kann man sich wie einen einmaligen digitalen Fingerabdruck vorstellen.

Um dieser Identifizierung zu entgehen, soll also die MAC-Adresse verändert bzw. anonymisiert verarbeitet werden. Den hier geschilderten Anonymisierungsvorgang, also die Erweiterung um einen SALT-Wert mit anschließender Hashwertbestimmung, kennt man bereits von der Passwortspeicherung.

Dies findet auch so Anwendung, wie aus einer FAQ eines Geräteherstellers für solche Trackingsysteme ersichtlich wird:

Datenschutz ist eines der Kernthemen der infsoft Plattform. So bieten unsere Systeme zahlreiche Methoden wie Hash-Algorithmen (SHA-1) zur Anonymisierung von MAC Adressen bei Analyse- und Trackingverfahren. […]

Die Vermutung dabei ist, dass MAC-Adressen sich in in gleicher Weise durch einen Hashwert „verdecken“ lassen, wie dies bei Passwörtern der Fall ist. Das ist auch prinzipiell nicht falsch, aber nicht ganz zu Ende gedacht. Das Problem ist hier die geringe Diversität an MAC-Adressen: Eine MAC-Adresse ist eine 48 Bit langer Identifikator einer Netzwerkschnittstelle, welcher üblicherweise in hexadezimaler Darstellung in Erscheinung tritt (z.B. 50-7B-9D-CB-C0-22). Durch die 48 Bit ist die maximale Anzahl existierender MAC-Adressen schon gleich auf 281.474.976.710.656 (281 Billionen) festgesetzt. Wenn ich also alle denkbaren MAC-Adressen durchrechne, ist die getrackte MAC-Adresse natürlich ebenfalls dabei.

Noch vor 10 Jahren wäre dies auch hinreichend „schwierig“ gewesen. Seit jedoch die Kryptowährungen (z.B. Bitcoin) so einen Hype erlebt haben, sind genau für diese Probleme extrem starke Berechnungslösungen verfügbar. Der Antminer R4 kostet derzeit ca. 1000 USD und erbringt eine Leistung von 8,6 TH/s. Das sind 8.600.000.000.000 (8,6 Billionen) Hashes pro Sekunde. Das macht offensichtlich: Im worst case werden 32 Sekunden benötigt, um die MAC-Adresse, mit beliebigem SALT, aus dem Hashwert herauszurechnen. Ein einfaches Hashen einer MAC-Adresse erbringt weder eine Pseudonymisierung, noch eine Anonymisierung. Ist der SALT-Wert fest, können die Berechnungen gespeichert und erneut verwendet werden (Rainbowtable), womit die Deanonymisierung in Echtzeit erzielt wird. In diesem Fall können auch günstigere 1 TH/s Lösungen für ca. 100 USD verwendet werden.

Somit wird klar, dass ein einfaches Hashen hier keinen Mehrwert bietet. Es ist stellt sogar eine Gefahr dar, da das Datum aus juristischer Perspektive fälschlicherweise als anonymisiert betrachtet werden könnte und damit seinen datenschutzrechtlichen Schutz verliert.

Okay Google, wer gewinnt die Bundestagswahl?

Hallo zusammen,

Für einen Vortrag habe ich mir mal den Spaß gemacht zu schauen, wie viel Webtracking auf den Webseiten der „großen“ politischen Parteien zu finden ist… ich war erschrocken. Daher habe ich heute die Daten nochmal aktualisiert und mich zu diesem Blogeintrag entschlossen.

8 Parteien, basierend auf „etablierte Parteien“ nach http://bundestagswahl-2017.com/parteien/, Sortierung (dort) nach Zweitstimmen bei letzter Wahl. (CC BY-SA 3.0 DE)

Nur 2/8 Parteien gelingt es, ihre Webseite halbwegs sauber zu gestalten. Platz 3 geht an die CDU, die immerhin nur durch Google Analytics (GA) auffällt. Beim Rest war stets Google und häufig Facebook dabei. Das bedeutet, dass bei 6/8 Parteiwebseiten mindestens ein Google Service zu finden ist.

Hier nun eine Einzelwürdigung der Ergebnisse:

  • cdu.de: Meiner Meinung nach hat google-analytics dort nicht verloren. Sonst soweit in Ordnung.
  • spd.de: Muss nochmal lobend erwähnt werden.
  • die-linke.de: Der Youtube Content erzeugt auch das Doubleclick Cookie. Altruja.de, wohl zum Sammeln von Spenden, bekommt man sicher auch ohne Einbettung gelöst.
  • gruene.de: Das YT Problem, darüber hinaus eine Verbindung zu Facebook. Interessanterweise hervorgerufen durch die FB SDK und nicht durch einen Like-Button.
  • csu.de: Drittparteien wie adform und intelliad klingen nicht nach funktionalen Bestandteilen der Webseite. Neben recht viel Inhalt von Facebook findet man natürlich auch GA.
  • fdp.de: Der Beitrag von „cloudflare.com“ auf der Webseite beschränkt sich auf eine Ressource. Cloudinary wird zum Hosting der Bilder verwendet. Doubleclick, so alleine für sich, war recht überraschend und ist ein Indikator für Tracking zu Werbezwecken.
  • afd.de: Ähnlich wie bei den anderen Parteien.
  • piratenpartei.de: Die Seite ist wie erwartet sauber.

Und auch wenn ich verstehen kann, dass für Parteien das „Wer ist auf meiner Seite?“ relativ wichtig ist, finde ich diese massive Einbindung von Google Services sehr befremdlich. Natürlich lässt sich darüber streiten, welchen Wert die Parteiwebseite bei einer Wahl wirklich hat. Als normaler Bürger wäre ich jedoch der naiven Vorstellung erlegen, dass ich mich auf diesen Seiten bewegen kann, ohne von Google oder Facebook getrackt zu werden. Dies ist nachweislich überwiegend nicht der Fall.

Ob diese Einbettungen rechtlich in Ordnung sind, möchte ich als Informatiker nicht entscheiden und lasse dies daher offen. So oder so hoffe ich, dass mit der Privacy Verordnung dies in Zukunft klarer entschieden werden kann, auch wenn ich diesbezüglich eher pessimistisch bin und eine rechtliche Legitimation des Status quo erwarte.

Abschließend noch kurz ein paar Worte zur Technik der Erhebung. Während ich in diesem Blogeintrag eher meine persönliche und fachliche Meinung zum Ausdruck bringe, ist es mir sehr wichtig, die Ergebnisse der Erhebung auch transparent und nachvollziehbar offenzulegen. Aus diesem Grund finden sich die HAR-Dateien (HTTP Archive) zum Download bereit. Durchgeführt wurde die Analyse mit einem Firefox 55.0.3 ohne weitere Addons gesteuert durch Selenium (Python) 3.5.0 wobei nur die Landingpage geöffnet wurde.

However, in Anbetracht der massiven Einbettung von Google ist die Frage im Titel vielleicht doch nicht so weit hergeholt.

Privacy Badger im Vergleich

Hallo zusammen,

im Vortrag zu Web-Tracking auf Klinikwebseiten, den ich schon im vorherigen Beitrag kurz angesprochen hatte, zeigte ich einen Vergleich der Restriktivität zwischen Ghostery, NoScript, Disconnect und natürlich Addon-freies surfen.

UPDATE: Der Inhalt bzw. die Ergebnisse des Vortrags wurden auf Netzpolitik.org nochmal zusammengefasst, was mich sehr gefreut hat!

Blocker_Vergleich_v01

Abbildung 1: Netzwerkverbindungen zwischen Erstparteien (schwarz) und Drittparteien (rot) bei Abruf von 839 Webseiten (jeweils die Hauptseite) von Krankenhäusern und Kliniken.

In Abbildung 1 ist das Trackingnetzwerk als Graph zu sehen und zeigt wie ungewollte Verbindungen zu Drittanbietern durch die entsprechenden Addons blockiert werden. Dies erkennt man insbesondere daran, dass der äußere Rand breiter wird (mehr unverbundene Erstparteien) und der innere Kern schwacher ausgeprägt ist (weniger Konnektivität). Es ist wichtig einzusehen, dass hierbei nur die Restriktivität gemessen wurde, was alleine noch kein Qualitätsmerkmal darstellt. So würde NoScript den „normalen Benutzer“ möglicherweise überfordern. Ghostery und Disconnect bedürfen, abgesehen von einer ersten Konfiguration, sonst keiner weiteren Benutzerinteraktion.

Nach dem Vortrag kam die Frage auf, wie es sich mit dem Privacy Badger verhält. Dies hatte ich leider nicht vorbereitet, ist aber durchaus berechtigt. Aus diesem Grund habe ich heute die Analyse auch mal mit diesem Addon durchgeführt. Aufgrund der Tatsache, dass der Privacy Badger erst noch „Erfahrungen“ sammeln muss, habe ich vor dem Test 200 deutsche Webseiten (.de-Adressen aus der Alexa Top 1M) besucht die dabei entstandene Konfigurationsdatei für die weitere Analyse verwendet. Darüber hinaus wurden keine weiteren (manuellen) Konfigurationen vorgenommen.

In Abbildung 2 ist das entstandene Trackingnetzwerk abgebildet. Dieses unterscheidet sich äußerlich zunächst nur wenig vom Surfen ohne Addon.

Blocker_PrivacyBadger_v01

Abbildung 2: Trackingnetzwerk mit und ohne Privacy Badger.

Ähnliches zeigt sich auch in der Top 20 der am häufigsten eingebetteten Drittparteien und Vergleichswert ohne Privacy Badger (Messung vom 12.08.2016). Es wird gezeigt, wie viele Erstpartien (First Parties) eine entsprechende Drittpartei einbetten (absteigend sortiert).

# Hosts Mit Privacy Badger Ohne Privacy Badger
1 www.google-analytics.com 285 (34.0%) 287 (34.2%)
2 fonts.gstatic.com 209 (24.9%) 210 (25.0%)
3 fonts.googleapis.com 202 (24.1%) 204 (24.3%)
4 ajax.googleapis.com 134 (16.0%) 134 (16.0%)
5 www.google.com 74 (8.8%) 78 (9.3%)
6 ssl.google-analytics.com 47 (5.6%) 49 (5.8%)
7 s.ytimg.com 45 (5.4%) 48 (5.7%)
8 maps.google.com 42 (5.0%) 43 (5.1%)
9 www.youtube.com 41 (4.9%) 45 (5.4%)
10 i.ytimg.com 40 (4.8%) 38 (4.5%)
11 maps.googleapis.com 39 (4.7%) 40 (4.8%)
12 stats.g.doubleclick.net 38 (4.5%) 43 (5.1%)
13 csi.gstatic.com 35 (4.2%) 36 (4.3%)
14 maps.gstatic.com 31 (3.7%) 32 (3.8%)
15 code.jquery.com 29 (3.5%) 30 (3.6%)
16 piwik.sana.aspr.de 29 (3.5%) 29 (3.5%)
17 www.facebook.com 29 (3.5%) 28 (3.3%)
18 code.etracker.com 25 (3.0%) 26 (3.1%)
19 connect.facebook.net 24 (2.9%) 23 (2.7%)
20 cdnjs.cloudflare.com 22 (2.6%) 21 (2.5%)
googleads.g.doubleclick.net 39 (4.6%)
static.doubleclick.net 38 (4.5%)

In der Tabelle ist zu sehen, dass nur sehr wenige Hosts kategorisch ausgeschlossen worden sind. Hier muss man allerdings aufpassen, denn (anders als Ghostery) bietet der Privacy Badger drei Optionen mit Drittparteien umzugehen: Neben An und Aus gibt es noch eine „Mittel“-Einstellung, die das Tracking durch unterdrücken von Referer und Cookies minimieren soll. Diese „Mittel“-Einstellung findet sich häufig, sind jedoch in den oben gezeigten Statistiken nicht sichtbar. Ich halte jedoch die Wirksamkeit dieser Maßnahme für sehr fragwürdig, was allerdings nochmal intensiverer Analyse bedürfte.

Auch wenn ich den Privacy Badger als ein sympathisches Tool empfinde, sehe ich die getroffenen Grundeinstellungen als zu schwach an. Sehr viel wird zunächst akzeptiert und die Entscheidung auf den Benutzer geschoben. Diese können auch nicht pauschal getroffen, sondern müssen für jeden Tracker einzeln eingestellt werden. So ist es hier, anders als bei Ghostery, mir (über die Oberfläche) nicht möglich, vor dem Test eine restriktive Konfiguration festzulegen bzw. möglichst viel zu blockieren. Und so sehr ich es begrüße, dass der Algorithmus zur Identifizierung von Trackern so offen einsehbar ist, kann ich mir durchaus vorstellen, dass Web-Tracking Firmen dieses Wissen ausnutzen. Letzteres soll jedoch nicht als Kritik verstanden werden.

Alles in allem ist es sicher eine gute Ergänzung und hilft bei der Entscheidungsfindung deutlich besser als RequestPolicy (was zunächst alles blockiert), stellt jedoch leider kein Wundermittel dar. Ohne aktives Handeln durch den Benutzer ist dieses Tool, in meinen Augen, keine wirkliche Verbesserung zu vorher. Man muss jedoch erwähnen, dass der Benutzer nach der Installation auch darauf hingewiesen wird, dass er tätig werden muss.

Die Ergebnisse der anderen Addons sollten jedoch nicht als Produktwerbung missinterpretiert werden. Andere denkbare Gefährdungen, z.B. die interne Datenweitergabe, können nicht ausgeschlossen werden.

Caching Vorteile bei CDNs

Hallo zusammen,

am kommenden Freitag werde ich auf dem mrmcd 2016 in Darmstadt einen Vortrag über Web-Tracking auf Webseiten von Krankenhäusern und Kliniken halten. Dabei werde ich die Ergebnisse meiner letzten DuD-Publikation vortragen sowie noch einige dafür neu erarbeitete Inhalte.

In Vorbereitung dessen habe ich gestern noch einen Test durchgeführt, was Content Delivery Networks (CDN, auch: Content Distribution Network) eigentlich bringen. Solche Dienste sind darauf spezialisiert, Daten (die in Webseiten integriert werden) mit hoher Geschwindigkeit und geringen Antwortzeiten den Besuchern bereitzustellen. Nicht selten wird jedoch auch hervorgebracht, dass der User die verlinkten Bibliotheken und Schriftarten selbst auf seinem Rechner cachen, über mehrere verschiedene Webseiten hinweg „konservieren“ und die Netzwerklast darüber minimieren kann. So z.B. hier (Nummer 2).

Diesen zuletzt genannten Vorteil wollte ich mir mal genauer ansehen. Es ist weniger eine repräsentative Studie, sondern dient mehr dazu einen Eindruck zu bekommen. So habe ich 150 Webseiten auf zwei verschiedene Wege betreten: mit einem jeweils neuen (unbenutzten) Firefox Profil und mit einem persistenten Profil. Da Selenium persistente Profile eigentlich nicht unterstützt, musste hier noch ein Workaround geschaffen werden.

Die Ergebnisse sind für mich doch sehr überraschend. Die Anzahl der Verbindungen zu den Erstparteien (Webseiten) und darin verlinkten Drittparteien blieb konstant (nur 2 Verbindungen weniger bei ca. 7200 Verbindungen). D.h. die Anzahl der geladenen Ressourcen hat sich nicht (signifikant) verändert. Wenn man sich die HTTP Header der Responses anschaut sieht man, dass nur 16 Ressourcen mehrfach verwendet wurden (304 Not Modified). Dabei überwiegend JavaScript-Dateien von Trackern und ein paar Schriftarten. Die Top 10 der am häufigsten eingebetteten Drittparteien sowie die Anzahl der Verbindungen blieb konstant. Verbindungen spare ich also nicht, maximal etwas Traffic.

Nun könnte man argumentieren, dass 150 Webseiten zu wenig sind um vom Caching-Vorteil zu profitieren. Während jedoch das normale Standardprofil nur 24 MB groß ist, ist das persistente nach den 150 Webseiten auf 222 MB gewachsen. Auch wenn Speicherplatz heute kein so großes Thema mehr ist: beliebig Luft nach oben ist hier auch nicht. Zu prüfen wäre noch, wie die Cache-Strategie von Firefox im Detail aussieht.

Es ist, wie gesagt, nicht repräsentativ. Es erwächst jedoch der Eindruck, dass der Cache Vorteil eines CDN geringer ist als erwartet. Dies ist auch der überwältigenden Vielfalt verschiedener Bibliotheken und Schriftarten geschuldet. Die verbleibenden Vorteile von CDNs bleiben natürlich unberührt.

Kleines Pflaster: Mehr Privacy mit wenigen Klicks

Hallo zusammen,

wenn man sich im Web bewegt, hinterlässt man überall Spuren – das ist schon fast jedem bekannt. Aktuelle Studien aus dem Jahr 2015 zeigen, dass durch Einbettungen (wie z.B. ein YouTube-Video) auf 9 von 10 Webseiten Informationen an Dritte weitergegeben werden [1].

Durch solche Einbettungen in Webseiten werden Drittparteien exakt über die besuchte Webseite informiert. Ein Beispiel um das Problem zu verdeutlichen: Ist auf einer Webseite eine Schriftart, z.B. von googlefonts oder Fonts.com, eingebunden, bewirkt dies eine Weitergabe der IP-Adresse UND der besuchten Webseite an den jeweiligen Anbieter.

Auch wenn ich dies als klaffende Wunde ansehe, möchte ich jedem ein kleines Pflaster in die Hand geben. Während sich aktive Inhalte, wie z.B. der Facebook „Like“-Button oder das JavaScript von Google Analytics, nur durch Browsererweiterungen vernünftig unterbinden lassen, können andere Formen der Datenweitergabe (z.B. durch ein eingebettetes Bild) schon mit einfachen Mitteln reduziert werden. Damit Google & Co. es also nicht ganz so einfach haben, sollte zumindest ein Teil dieser Weitergabe abgeschaltet werden.

Dies geht in Firefox (erstellt für 46.0.1) mit nur vier Schritten:

  • Schritt 1: „about:config“ in die Adressleiste eingeben.

    referer_step_1

  • Schritt 2: Den Warnhinweis akzeptieren.

    referer_step_2

  • Schritt 3: Nach „referer“ bzw. dem Einstellungsnamen „network.http.sendRefererHeader“ suchen.

    referer_step_3

  • Schritt 4: „network.http.sendRefererHeader“ auf den Wert „1“ setzen.

    referer_step_4

Tatsächlich ist die Einstellung „0“ noch restriktiver, kann jedoch zu Komplikationen bei Web-Anwendungen führen, die auf den Referer angewiesen sind (z.B. Formulare). Dies ist bei „1“ nicht zu erwarten. Ich surfe mit dieser Konfiguration schon eine ganze Weile ohne Probleme. Sollte es widererwarten doch Komplikationen geben, kann das Setting zurück auf „2“ und das mit Firefox 28 eingeführte „network.http.referer.XOriginPolicy“ Feld auf „1“ gesetzt werden.

Für Chrome gibt es beispielsweise das Addon Referer Control. Dies ist jedoch, in meinen Augen, unbedienbar. Der eingebaute Programm-Schalter, der den Referer komplett deaktiviert, ist ebenfalls nicht alltagstauglich. Da Google von der Übermittlung des HTTP-Referer profitiert, ist es nicht so überraschend, dass er im Chrome-Browser nur schwer zu unterbinden ist.

Zugegeben ist diese Referer-Problematik schon eine sehr alte. Wie jedoch hier schon erwähnt zeigen meine jüngsten Erkenntnisse, dass dies aktuell problematischer ist, als es noch vor 10 Jahren war [2].


[1] Timothy Libert: Exposing the Hidden Web: An Analysis of Third-Party HTTP Requests on 1 Million Websites. CoRR abs/1511.00619 (2015)
[2] Wambach T. and Bräunlich K. (2016). Retrospective Study of Third-party Web Tracking. In Proceedings of the 2nd International Conference on Information Systems Security and Privacy ISBN 978-989-758-167-0, pages 138-145. DOI: 10.5220/0005741301380145

 

WebTracking.org

Hallo zusammen,

wie bereits erwähnt beschäftige ich mich derzeitig mit den Auswirkungen von Web Analytics auf Privacy und Security. Wie in einem vorherigen Beitrag berichtet, wurden dazu Daten von Archive.org ausgewertet, um die Entstehtung von Third Praty Web Tracking während der vergangenen 16 Jahre zu erfassen.

Zu diesem Thema ist nun auch ein eigener Webaufritt geschaltet: https://webtracking.org

In einem dafür bereitgestellten Graphen kann (ausschnittsweise) der Aufbau und Wandel des Internets in Bezug auf Web-Tracking betrachtet werden.

Viel Spaß bei der Zeitreise!

Retrospective Study of Third-party Web Tracking

Hallo zusammen,

seit vorgestern ist mein Paper zur ICISSP 2016 Konferenz (Februar 2016 in Rom) nun online verfügbar:

Wambach T. and Bräunlich K. (2016). Retrospective Study of Third-party Web Tracking. In Proceedings of the 2nd International Conference on Information Systems Security and Privacy , ISBN 978-989-758-167-0, pages 138-145. DOI: 10.5220/0005741301380145
URL: http://scitepress.org

Das Thema Web-Tracking ist ein aktuelles Forschungsgebiet von mir. In der klassischen Informationssicherheit findet dieses nur wenig Erwähnung und eine Vermutung für diesen Umstand ist, dass diese Bedrohung noch vergleichsweise neu ist. Um diese Vermutung zu belegen, zeigt das Paper wie sich Web-Tracking im Laufe der letzten 15 Jahre verändert hat.

Dazu bin ich derzeit einen Web Auftritt am konstruieren: dort wird man die erhobenen Daten „Live“ einsehen können. Ich werde darüber berichten, sobald die Webseite online ist.

Nachtrag (04.05.2016):
Die Webseite https://webtracking.org ist nun fertig wie hier berichtet.