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.

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!

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.

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).

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.

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.

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.

  

• Schritt 2: Den Warnhinweis akzeptieren.

  

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

  

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

  

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

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.