Privacy Leaks: WordPress, der Spion in deinem Nest.

Prolog

In der US-amerikanischen Krimi-Science-Fiction-Fernsehserie Person of Interest [1] des britischen Drehbuchautors Jonathan Nolan hat der Milliardär und Programmierer Harold Finch im Nachlauf der Terroranschläge vom 11. September 2001 [2] zusammen mit seinem Freund Nathan C. Ingram für die US-Regierung ein streng geheimes Überwachungssystem mit einer künstlichen Intelligenz entworfen, das durch Zuhilfenahme modernster Technik seine Bürger rund um die Uhr ausspioniert. Mobiltelefone und das Internet gehören dazu, ebenso wie Überwachungskameras mit Gesichtserkennung. Die gesamte Kommunikation und jede Bewegung wird in Echtzeit erfasst und durch das System analysiert.

Durch die Auswertung der gesammelten Daten können zukünftige geplante, nicht spontane Ereignisse antizipiert werden. Die Rechtfertigung für diese Spionage ist die Prävention von terroristischen Anschlägen. Die im Sommer 2013 veröffentlichten Enthüllungen des am 21. Juni 1983 in Elizabeth City, North Carolina geborenen und späteren CIA-Mitarbeiter Edward Joseph Snowden [3] geben auch nach vier Jahren weitreichende Einblicke in das Ausmaß der weltweiten Überwachungs- und Spionagepraktiken von Geheimdiensten – überwiegend jenen der Vereinigten Staaten und Großbritanniens.

Dass Freemail-Anbieter sowohl private wie auch geschäftliche Kommunikation maschinell mitlesen und auswerten, Internet-Browser statistisch erfasstes Surfverhalten an Datensammelserver übermitteln, Tracking-Verfahren jegliche Art der Bewegung im Netz protokollieren und ca. 70% aller Apps (lt. einer Studie des International Computer Science Insitute [4]) personenbezogene Daten sammeln und an Dritte weitergeben, wird nur von wenigen Anwendern wahrgenommen, noch weniger schützen sich dagegen oder ändern das eigene Verhalten zum Schutze ihrer Privatsphäre.

Noch geringer dürfte die Anzahl derer sein, die über das Verhalten des beliebten Weblog- und derzeit meist genutzten (Pseudo-)Content-Management-System WordPress [5] informiert ist: WordPress [5] reicht Informationen von Seitenbesuchern, Redakteuren und Kommentatoren weiter, dessen Umfang sich im datenschutzkritischen Ausmaß wiederfindet und weder von Webseitenbetreibern noch von Webseitenbesuchern in dieser Art erwünscht ist.

WordPress - das CMS schlechthin

Mit einer unüberschaubar großen Gemeinschaft an Entwicklern, Förderern und Anwendern steht WordPress als ein Paradebeispiel für Eigendynamik, die eine GPL [6] (General-Public-License) lizenzierte Open-Source-Software hervorbringen kann. In genau diesem Fall ist aber auch eindeutig ersichtlich, dass der Begriff „Allgemeine Öffentlichkeit“ (General-Public) nicht mit demokratischen Grundrechten assoziiert werden darf, sondern aus rein ökonomischer Sichtweise zu betrachten ist.

Die Argumente für den Einsatz von WordPress sind selbsterklärend:

WordPress ist generell kostenlos. Dazu zählen auch unzählige Erweiterungen (PlugIns) und Themes (Vorlagen für die Seitengestaltung). Ausnahmen sind Premium-Themes und -PlugIns, kommerzieller Support und kundenspezifische Entwicklung und Anpassung.
Einfache Handhabung bei Core-, Update- und PlugIn-Installationen.
WordPress-Core ist relativ einfach zu bedienen.
Das Core-System läuft stabil. Fehlverhalten konnte ich nur bei Erweiterungen und Themes feststellen.
WordPress ist durch sog. Hooks sehr flexibel an individuelle Bedürfnisse anpassbar.
Offener Quellcode.
Rasche Weiterentwicklung durch gut organisierte Developer-Community, regelmäßige Updates und Sicherheitspatches.

Gegenargumente:

Themes [7] [8] und Erweiterungen, hauptsächlich von Drittanbietern zeichnen sich des Öfteren durch schlechte Codequalität und Tracking aus.
Das WordPress-Core-System und sehr viele Erweiterungen werden in den USA entwickelt. Datenschutzrechtliche Bestimmungen unterschiedlich zu denen in der EU, Mitwirkung von Google [10] und weiteren kann nicht ausgeschlossen werden.
?

Fokussierung

Betreibern von WordPress-Websites sollte, zumindest nach dem Lesen des Beitrags, bewusst sein, dass mit großer Wahrscheinlichkeit die in der eigenen Datenschutzerklärung vorgehaltenen Versprechen meist Versprechen bleiben und nicht wie erwartet umgesetzt werden. Unter Berücksichtigung der am 25. Mai 2018 in Wirkung tretenden DSGVO2018 werden noch zahlreiche Website-Betreiber Hand auf das Verhalten des eingesetzten CMS und die eigenen Datenschutzrichtlinien anlegen müssen.

WP Webfonts und das Google-Fonts-API

Kurz vor der Veröffentlichung von WordPress 3.8 Ende 2013 hat die geplante stilistische Veränderung der Administrationsoberfläche durch das Einbinden der Schriftfamilie Open Sans [12] auf wordpress.org zu einer heftigen Diskussion unter WordPress Entwicklern geführt. Die Frage nach Open Sans - bundling vs. linking [13] hat unter den Kommentierenden Bedenken in Beziehung zu Privacy aufgeworfen [14]. Auch die technische Blockade von Google in einigen Ländern wie z.B. China und die dabei entstehenden Probleme beim Nachladen von Schriftdateien oder auch der gänzliche Verzicht auf kosmetische Korrekturmaßnahmen, wurde von vielen angesprochen. Die Widerlegung aller aufgeworfenen Bedenken wurde bereits zehn Minuten nach Eröffnung des Threads durch Matt Miklic [15] beschlossen. Am 11. November 2013 um 08:43 Uhr gab WordPress-Gründer Matt Mullenweg [16] seine Entscheidung, Google eine Hintertür ins WordPress-Backend ab der Version 3.8 zu öffnen, bekannt.

Das eigentliche Problem am Google Fonts API [17] ist, dass innerhalb der HTTP Request-Header auch der Cookie übertragen wird. Google verwendet sog. Domain-Cookies [18] -- und da alle Google Angebote unter derselben Domain laufen, kann Google bei jedem Zugriff auf seine Dienste dasselbe Cookie abfragen. Das Cookie enthält nicht mehr als eine eindeutige Identifikationsnummer die, beim Aufruf verschiedener Domains und somit bei der Nutzung weiterer Google-Dienste wie etwa Google Adsense, Google Analytics oder Google Maps ausreicht, ein eindeutiges Bewegungsprofil des Anwenders zu erstellen. Auch lässt sich erkennen, ob ein Anwender eine Seite nur aufruft oder sich an dieser auch anmeldet. Im Zusammenhang mit WordPress kann Google daraus schließen, dass der Anwender Administrations- oder Redaktionsrechte an einer WordPress-Webseite hat. Verwendet der Anwender letztendlich selbst einen Google-Dienst, der mit einer Anmeldung verbunden ist wie z.B. Google-Plus, YouTube-Login, Google-Kalender, Google-Kontakte, Gmail etc., weiß Google natürlich, welche Person hinter der Identifikationsnummer steht.

Im technischen Detail geht es hier ausschließlich um Metadaten, welche aus der Sicht einer einzelnen Webseite betrachtet, als harmlos erscheinen. Führt man die Metadaten verschiedenster Websites zusammen, wird ein vollständiges Tracking ermöglicht. Lassen sich die Daten durch die weitere Nutzung einer Anwendung, die eine Anmeldung erfordert, kombinieren, erhält Google ein personenbezogenes Internet-Nutzungs-Profil.

In WordPress 4.6 (seit Mai 2016) haben die WordPress -Core-Entwickler zurück gerudert: Open Sans kommt im WP Core-System nicht mehr zum Einsatz. WordPress Lead Entwicklerin, Helen Hou-Sandi, in einem Commit [19] vom April 2016:

"Rejoice, for your admins will feel more native to your surrounding computing environment and likely load faster, especially when offline, as they no longer have to talk to The Google Overlord."

Einzig als Fallback wird unter /wp-includes/script-loader.php Open Sans aktiviert, falls ein (älteres) Theme oder PlugIn auf diesen Font besteht. Durch das Einbinden der folgenden Funktion in die function.php des Child-Themes kann das Nachladen des Stylesheets jedoch umgangen werden:

add_action ( 'admin_enqueue_scripts', function() {
    wp_deregister_style( 'open-sans' );
    wp_register_style( 'open-sans', false );
}, 1, 0 );

Diese Angaben beziehen sich ausnahmslos auf WordPress 4.6 Core und später, nicht jedoch auf die mit WordPress ausgelieferten Standard-Themes Twenty Fifteen, Twenty Sixteen, Twenty Seventeen oder auf zahlreiche Free- und Premium-Themes, die sich das Google Fonts API [17] zunutze machen.

Web-Fonts können auf unterschiedliche Weise eingebunden werden, in vielen Fällen werden individuelle Lösungen notwendig sein um sich von diesem Übel zu befreien. Oft lässt sich das Nachladen der Stylesheets durch die Nutzung mehr oder weniger gut funktionierender PlugIns verhindern. Der Einsatz von zahlreichen WordPress-PlugIns innerhalb ein und derselben Instanz wirft aber weitere Fragen auf.

Zugegeben, die Nutzung verlinkter Webfonts ist nicht nur ein WordPress-Problem, Google Fonts APIs werden vielerorts eingesetzt. Bei einer flächendeckenden Nutzung, beinahe 30% aller Webseiten basieren derzeit auf WordPress, sollte dieser Umstand neu überdacht werden. Auch die Nutzung von Google-reCaptcha [42] oder Google-Maps [43] zählen zu den datenschutz-bedenklichen Diensten auf Webseiten. Ein geplanter Beitrag setzt sich intensiv mit dieser Thematik auseinander.

WP Gravatar und Mullenwegs Server

"Ein Avatar ist ein Bild, das dich von Website zu Website begleitet und neben deinem Namen erscheint, wenn du auf Websites kommentierst, die Avatare unterstützen. Hier kannst du aktivieren, dass von Leuten, die auf deiner Website kommentieren, Avatare angezeigt werden."

Ist die Nutzung verschiedener Google-Dienste eher als ein allgemein zu umgehendes Problem zu verstehen, so haben wir es an dieser Stelle ausschließlich mit einem WordPress Phänomen zu tun.

In Verbindung mit einer E-Mail-Adresse lässt sich ein beliebiges Bild auf die in den USA lokalisierten Gravatar-Server hochladen. Dieser Dienst wird von Automattic Inc. [20], dem Betreiber von WordPress.com [5], Gravatar.com [21] und weiteren, zur Verfügung gestellt. WordPress kann beim Anlegen eines Kommentars diese Server nach der entsprechenden E-Mail-Adresse bzw. einem MD5-Hash derselben abfragen und das dazugehörende Bild in den Kommentar einbinden. Die Zuordnung von Avataren zu Kommentierenden wird dementsprechend über deren E-Mail-Adressen hergestellt. Bei jedem Aufruf einer WordPress-Seite die Kommentare enthält werden nun HTTP-Requests an die Gravatar-Server abgesetzt und in Form von MD5-Hashes die E-Mail-Adresse der Kommentierenden übertragen, das hinterlegte Avatar abgerufen und ein Footprint [22] erstellt.

Das geschieht aber auch dann, wenn keine Registrierung des Kommentierenden bei Gravatar vorliegt und dieser Dienst gar nicht genutzt wird. Der Begriff Gravatar steht für "Globaly Recognized"-Avatar.

Der hier beschriebene MD5-Hash der E-Mail-Adresse ist in der Nutzung ähnlich zu verstehen wie die oben beschriebene Identifikationsnummer in Googles Domain-Cookie (technisch Versierte mögen mir an dieser Stelle verzeihen): die Zugriffe auf die Gravatar-Server werden protokolliert und gespeichert. Ein ebenso großes Übel ist, dass der MD5-Hash bei aktivierter Avatar-Funktion im Quelltext jeder generierten WordPress-Kommentar-Seite sichtbar und somit frei zugänglich und verfolgbar ist. Auch für Web-Crawler von Google und anderen Suchmaschinen. Der als praktikabel erscheinende Gravatar-Dienst steht folglich am Beginn eines Tracking-Verfahrens, das spätestens in Zusammenarbeit mit weiteren Webdiensten und -anbietern eine durchaus kommerzielle Wirkung entfalten kann.

Die Privacy Policies [23] von Automattic Inc. sind so nichtssagend wie andere auch. Unter anderen räumt Automattic Inc. ein, personenbezogene Daten an eigene bzw. an kooperierende Unternehmen und Partner weitergeben zu können, solange diese im Auftrag oder zugunsten von Automattic Inc. handeln und ihrerseits diese Daten nicht an andere weitergeben:

"Automattic discloses potentially personally-identifying and personally-identifying information only to those of its employees, contractors and affiliated organizations that (i) need to know that information in order to process it on Automattic’s behalf or to provide services available at Automattic’s websites, and (ii) that have agreed not to disclose it to others.[…] "

Eine Auflistung, welche Projekte zum Imperium von Mullenweg gehören, sind auf automattic.com [24] gelistet. Nicht (mehr) gelistet ist der Dienst intensedebate.com [25], der eine Ausbaustufe der Kommentar-Funktion mitsamt Avatar-Idee zur Datensammlung umfasst. Desweiteren kooperiert Automattic Inc. mit Datenanalysten wie kissmetrics.com [26] oder inspectlet.com [27] und stellt APIs zur einfachen Interaktion mit PlugIns wie z.B. WooCommerce zur Verfügung.

Weiterblickend werfen die gesammelten Erkenntnisse datenschutzrechtliche Fragen auf: der sicherlich bekannte Hinweis auf fast jeder WordPress-Kommentarseite

"Deine E-Mail-Adresse wird nicht veröffentlicht"

ist in dieser Form nicht zutreffend sondern definitiv falsch: die Aussage suggeriert ein gewisses Maß an Datenschutz und Sicherheit, beides in dieser Art nicht zutreffend. Außerdem stellen sich Fragen des Datenschutzes der in der möglicherweise eigenen Datenschutzerklärung festgelegten Erklärung:

"…zum Schutze unserer Kunden werden keine personenbezogene Daten an Dritte weitergegeben..."

Die Auswirkungen dieser Schnüffelaktionen werden spätestens mit Wirkung der DSGVO2018 [28], ab 25. Mai 2018, ihr wahres Ausmaß zeigen.

Die einzige Einstellung für Avatare ist im WordPress-Backend unter Einstellungen/Diskussion/Avatare/ Zeige Avatare zu erreichen: mit einer Abwahl der Checkbox lässt sich die Anzeige von Avataren abschalten. Diese "globaly recognized" Funktion ist in der Standardeinstellung von WordPress aktiviert.

Bei genauerer Analyse des WP-Installationsablaufs wird ersichtlich, dass durch die standardmäßige Aktivierung dieser Funktion bereits bei der Erstkonfiguration von WordPress benutzerspezifische Daten an Mullenwegs-Gravatar-Server übermittelt werden, ohne dass der Anwender/Administrator Einfluss darauf nehmen kann: so wird die E-Mail-Adresse des WordPress-Administrators bereits vor der Möglichkeit zur Deaktivierung der Avatar-Funktion als MD5-Hash an https://*.gravatar.com/avatar/<md5-hash-email> übermittelt und damit auch der Hostname, die dazugehörige IP-Adresse, der Referer und ein Footprint des Browsers. Der folgende Screenshot stammt vom erstmaligen Aufruf des WordPress-Backends durch die Installationsroutine unmittelbar nach der Erstinstallation.

Aber auch bei Nichtnutzung der Avatar-Funktion werden bei Aufruf von Einstellungen/Diskussion/ im WordPress-Backend sieben Anfragen an die Gravatar Server gesendet (siehe Abb. Pkt.4). Außerdem bezieht sich die Nichtnutzung ausschließlich auf einige im WordPress -Core-System verankerte Darstellungs- bzw. Ausgabefunktionen wie z.B. die Darstellung von Avataren auf Kommentarseiten oder im WordPress-Backend (obere rechte Ecke, siehe Abb. Pkt.3). Eine unmittelbare Auswirkung auf eine Funktion oder auf die Ausgabe eines Filters besteht allerdings nicht. Dies hat wiederum zur Folge, dass Themes und PlugIns weiterhin alle gravatar-spezifischen Funktionen und Eigenschaften von WordPress uneingeschränkt nutzen können und nicht an die Abwahl der Funktion durch den Administrator gebunden sind.

Um WordPress diesbezüglich mundtot zu machen, ist ein manueller Eingriff notwendig. Durch die Manipulation der Ausgabe eines Filters werden Gravatar-Requests auf ein lokal zur Verfügung gestelltes Image umgeleitet.

add_filter( 'pre_get_avatar_data', function( $args ) {
    $args['url'] = get_template_directory_uri() .  '/pfad/zum/lokalen/avatar.image';
    return $args;
});

Den oben gezeigten Filter-Hook setze ich bei WordPress in der Version 4.8.x erfolgreich ein. In einer zukünftigen WordPress Version könnten die Core-Entwickler jedoch einen weiteren Hook auf den Filter setzen um die Ausgabe des Array-Eintrags $args['url'] auf einen Match von http.://.*.gravatar.com/avatar/.* prüfen und so eine Manipulation der Ausgabe feststellen. Sollte es jedoch soweit kommen, wäre der Umstieg auf ein alternatives CMS zwingend anzuraten.

Gravatare werden bereits von einigen Werkzeugen wie z.B. Ghostery [44] als Tracker erkannt und können durch dessen Einsatz im Browser geblockt werden.

WP Emojis - die neue Grütze

Einige Funktionen, die WordPress bei den regelmäßigen Updates mitbringt, mögen für den einen oder anderen durchaus von Nutzen sein. Seit Version 4.2 haben die WordPress-Emoticons "Emoji" Einzug in das WordPress-Core-System gehalten. Benötigt werden diese für Webseiten und Blogsysteme eher nicht. Seit Version 4.3 wurde die Option zum Deaktivieren von Smileys aus dem Backend entfernt [29]. Umso ärgerlicher ist, dass WordPress den Code für Javascript und CSS direkt in jeden Seiten-Header packt, vollautomatisch - sowohl im Front- als auch im Backend, ob benötigt oder nicht, mit direkten Einfluss auf die Performance und ohne die Möglichkeit einer Deaktivierung - ganz offiziell, zumindest [30].

Warum packt man diese Grütze nicht in ein separates PlugIn, oder bietet zumindest eine Möglichkeit der Deaktivierung an?

Der eigentliche Zweck des Codes besteht darin, die Browser-Features und -Fähigkeiten für eine spätere Verwendung von WordPress -Emojis vorzucachen. Die Tatsache, dass diese auf jeder Seite geladen werden, unabhängig davon, ob diese Funktionen verwendet werden und die Kombination mit stark verschleiertem Java-Script-Code - ist äußerst schlechte Praxis, oder Absicht.(!) Der eingefügte Code ist von einem echten Tracking-Versuch nicht zu unterscheiden und als solcher sehr anfällig für Warnungen, die von diversen Canvas [31] - API - Monitoring - Plugins ausgegeben werden.

Privacy-Aktivisten, Journalisten und Menschen, die ein hohes Maß an Privatsphäre voraussetzen, während sie surfen, verwenden mit großer Wahrscheinlichkeit Tor [32]. Der Tor Browser und dessen Entwickler sind bekannt dafür, jeden möglichen Weg, Menschen im Internet zu verfolgen, zu unterbinden. Beim Besuch einer WordPress-Seite mit aktivierten WordPress -Emojis und dem Standard Theme Twenty Seventeen [33] wird die unten dargestellte Warnung ausgegeben.

Der technische Aspekt steckt in Canvas, ein HTML5-API, das verwendet wird, um Grafiken und Animationen auf einer Webseite mittels JavaScript zu zeichnen. Abgesehen davon kann Canvas als zusätzliche Entropie [34] zur Erstellung von Footprints [35] im Web-Browser und somit für Online-Tracking-Zwecke [36] verwendet werden.

Die Tracking -Technik basiert auf der Tatsache, dass das gleiche Canvas, also das gleiche WordPress -Emoji, auf verschiedenen Computern unterschiedlich dargestellt werden kann (unterschiedliche Meta-Daten). Die Gründe dafür sind Unterschiede in der Bildformat-Ebene, die der Web-Browser verwendet, verschiedene Bildverarbeitungs-Engines, Bild-Export-Optionen, Komprimierungs-Ebenen und unterschiedliche Prüfsummen der endgültigen Bilder, auch dann, wenn sie Pixel-identisch sind. Auf Betriebssystem-Ebene tragen unterschiedliche Schriftarten, sie verwenden verschiedene Algorithmen und Einstellungen für Anti-Aliasing und Sub-Pixel-Rendering, zur eindeutigen Identifizierung des Canvas und somit des Benutzers bzw. den Computer desselben, bei.

Den WordPress-Core Entwicklern wurde dieser Umstand bereits vor mehr als zwei Jahren als Bug-Report zugetragen [37]. Außer dem Versuch, den Tor Browser zugunsten von WordPress zu verbiegen [38], wurden diesbezüglich keine Änderungen unternommen.

Die Beantwortung der Frage, ob von WordPress tatsächlich aktives Tracking und somit eine mögliche Verletzung der Privatsphäre von Seitenbesuchern stattfindet, kann an dieser Stelle nicht eindeutig geklärt werden und bleibt jedem selbst überlassen. Belastend für Automattic Inc. sind die Vorgehensweisen bei der Implementierung einer nicht notwendigen Funktion in das Core-System von WordPress, ohne Möglichkeit der Deaktivierung und das Ignorieren des verzögerten Seitenaufbaus. Das Vertrauen der Besucher von Webseiten mit WordPress - Emojis wird allenfalls grob beeinträchtigt. Für Website-Betreiber in Gebieten, in denen Tracking ohne vorherige Zustimmung des Nutzers nicht gestattet ist, könnten zuzüglich ernsthafte Haftungsprobleme entstehen.

Was zu tun ist

Gute Frage. Die Antwort lautet: nachdenken!

Internet-Benutzer und Anwender: über die Wahl des Browsers, dessen Konfiguration und die zu installierenden Add-Ons zum Schutze der Privatsphäre;
Betreiber von WordPress-Websites: über die Auswahl und Verwendung entsprechender Themes und PlugIns;
Web-Entwickler: über deren DevOps [39].

Alle der oben genannten Eigenschaften von WordPress ließen sich durch gezielte Manipulation der function.php [45] an die jeweiligen Voraussetzungen anpassen. Trotzdem habe ich in diesem Artikel sehr bewusst auf Copy & Paste Quellcode-Beispiele verzichtet. Der Grund: Kurzlebigkeit! Eine mögliche Anlaufstelle für Quellcode-Beispiele wäre z.B. github.com [40].

Auch von einer generellen Referenzliste an PlugIns halte ich, vor einer Prüfung von Verhalten und Quellcode derselben, Abstand: "…drum prüfe wer sich ewig bindet…" von Schiller Friedrich [41] lautet das Zitat der Stunde.

Zwei Ausnahmen meiner Zurückhaltung an dieser Stelle wären zum einen das bereits erwähnte Tor [32] - Projekt. Zum anderen eine Eigenentwicklung: für die Umsetzung von WordPress-Projekten bieten wir unseren Kunden beispielsweise das WDNS Theme C an. Das Theme C unterhält seit Version 2.0.3 mehr als 30 Einstellungen zur Manipulation des WordPress-Core-Systems, - per Mausklick. Unser Theme wird kontinuierlich (bei fast jedem Neu-Projekt) weiterentwickelt, an Kundenwünsche angepasst bzw. evaluiert.

Quellen- und Linknachweis: