Wie die WordPress Admin Bar als Datenkrake missbrauchbar ist

2. Februar 2012, 11:28

TL;DR

Über die mit WordPress 3.3 eingeführte erweiterte Admin Bar kann eine in den USA angesiedelte Firma E-Mail-Adressen von Nutzern der selbstgehosteten WordPress-Variante mit den Adressen der von ihnen bearbeiteten Blogs zusammenführen.

Matt Mullenweg erfährt, was du gestern getan hast

In der Version 3.3 hat WordPress die erweiterte Admin Bar erhalten, eine Kopfleiste im Dashboard zum schnellen Zugriff auf viele häufige Funktionen des WordPress-Administrationsbereichs. Diese Admin Bar ist bei jeder Aktion am oberen Seitenrand im Dashboard sichtbar.

In der rechten Ecke zeigt die Admin Bar ein individuelles Avatar des angemeldeten Benutzers.

Kennst du den: Kommt ein Gravatar in die "Admin Bar"...

Um diese Grafik anzeigen zu können, führt das Dashboard folgende Schritte durch:

  1. Die E-Mail-Adresse aus dem Profil des angemeldeten Benutzers wird an Gravatar.com1 übertragen.
  2. Der Browser übergibt bei dieser Gelegenheit auch die URL des Dashboards als Referrer an Gravatar.com.
  3. Gravatar.com verwendet die übertragene E-Mail-Adresse und sucht den zugehörigen Benutzer.
  4. Kennt Gravatar.com den Benutzer zu dieser E-Mailadresse, wird sein Avatarbild an den Browser des Benutzers zurückgeliefert.
  5. Ist die E-Mailadresse bei Gravatar.com unbekannt, wird ein neutrales Ersatzbild geliefert.
  6. In beiden Fällen erhält Gravatar.com die E-Mailadresse des Benutzers und die Adresse des Blogs.
  7. Nach Ablauf der Cache-Dauer von fünf Minuten wiederholt sich dieser Vorgang.

Ich habe die relevanten Passagen in diesem Netzwerkprotokoll gelb markiert:

Hardcore: Protokoll des Datenaustauschs zwischen Browser, dem Dashboard und gravatar.com

Nach meinen Recherchen lässt sich die Informationsübertragung an Gravatar.com weder über eine Einstellung noch durch ein Plugin unterbinden, ohne die Gravatar-Funktionalität vollständig stillzulegen und damit zum Beispiel auch für die Anzeige der Kommentator-Avatare zu verlieren.

Gravatar.com weiß klarerweise, welches Bild zu einer bestimmten E-Mail-Adresse gehört:

E-Mail-Adresse redigiert. Aus Gründen.

Matt Mullenweg hält dich für uninteressant

Ich glaube nicht, dass sich die WordPress-Entwickler bei Automattic diese Verbindungen bewusst gemacht oder gar mit Absicht eingebaut haben.

Aber ich halte es für eine eklatante Lücke, dass die Datenübertragung an Gravatar.com praktisch fortlaufend während jeder Benutzersession im Dashboard passiert, während fast jedes andere Fitzelchen im Dashboard über Einstellungen, Plugins und Filter beeinflussbar ist.

Eine Offenlegung dieses Verhaltens habe ich weder in der Privacy Policy von Automattic noch bei der rein nominell ja von Automattic Inc. unabhängigen2 WordPress Foundation finden können.

Noch ein Grund für “German Internet Angst”

Deutsche Datenschützern beginnen ja schon wegen der Übertragung von IP-Adressen an ausländische Unternehmen zu hyperventilieren. Ich wäre gespannt auf deren Reaktion, wenn die wüssten, dass eine kleine Firma in San Francisco mit über den ganzen Globus verteilten Mitarbeitern Zugang zu den E-Mail-Adressen der Betreiber eines großen Teils der deutschen Websites hat.

Gegenmaßnahmen

Am schönsten wäre es aus meiner Sicht, wenn die Darstellung des Gravatars im Dashboard über einen Filter oder eine Einstellung unterbindbar wäre. Der Unterhaltungswert des Bildchens für den Benutzer ist ohnehin gering, und ein paar hundert Millisekunden für den doppelten Roundtrip zu Gravatar.com würden auch noch eingespart.

Eine Ausweichlösung wäre die Verwendung des verschlüsselten Protokolls HTTPS für den Zugriff auf das Dashboard. Dann würde die URL des Dashboards nicht mehr via Referer an Gravatar.com übertragen.

Und schlussendlich lässt sich das Problem auch noch mit der Holzhammermethode erledigen: Admin Bar komplett ausschalten.

1 Gravatar.com ist ein Dienst der Automattic Inc.

2 Wer die Trennschicht zwischen Automattic (gewinnorientiertes Startup, Arbeitgeber diverser WordPress-Entwickler) und der WordPress Foundation (karitativer Verein zur Förderung demokratischen Publizierens via GPL-Software und Inhaber der Rechte an der Marke “WordPress”) durchschaut, darf mich bitte in den Kommentaren erleuchten.

Kommentare [15]

Erste Screenshots vom WordPress 3.2-Dashboard

5. Mai 2011, 08:05

Für WordPress 3.2 wird das Dashboard ein wenig aufgefrischt. Verschwunden sind die vielen abgerundeten Ecken, statt dessen hat das Menü deutlichere Kanten und eine solide Trennung zwischen den Funktionsgruppen für die Inhalte einerseits und die Präsentation und Technik des Blog andererseits.

WordPress 3.2 - Dashboard

WordPress 3.2 - Neuer Artikel

Mir gefällt die neue Optik.

Kommentare [3]

Warum die deutsche Sprachdatei WordPress um 44 Prozent langsamer macht

13. April 2011, 22:32

Jeder deutschsprachige WordPress-Anwender kennt vermutlich diese kurze PHP-Zeile:

define ('WPLANG', 'de_DE');

Mit dieser einen Zeile wird WordPress deutschsprachig – und jeder Seitenaufruf rund 44 Prozent langsamer.

Im Folgenden zeige ich, warum dieser Performance-Einbruch eintritt und welche Möglichkeiten existieren, dem entgegenzuwirken.

Warum kann WordPress Deutsch?

WordPress verwendet im gesamten Code englische Originaltexte. Zur Lokalisierung der Software in anderen Sprachen muss WordPress Übersetzungen aus zusätzlichen Dateien im verbreiteten PO-Format einlesen. Die deutschsprachige Lokalisierung von WordPress 3.1.x enthält fast 3.200 Textschnippsel für den WordPress-Kern und 87 Übersetzungen für das Theme “TwentyTen”. Je nach Konfiguration kommen dann noch lokalisierte Texte der aktiven Plugins dazu.

Was kostet Zeit?

Ziemlich früh bei jedem Request wird innerhalb von wp-settings.php die Funktion load_default_textdomain() aufgerufen.

Über ein paar weitere Aufrufebenen erreicht WordPress dann import_from_reader(), die tausende kurzer Textschnippsel aus der Sprachdatei des WP-Cores einliest. Wenig später ruft das Theme “TwentyTen” über den Wrapper load_theme_textdomain() ein zweites Mal import_from_reader() auf, um die Übersetzungen der Theme-Texte zu laden.

Die lokalisierten Texte werden für jeden Aufruf der öffentlichen Website, bei jeder Aktion im Backend, bei jedem AJAX-Request und bei der Generierung der XML-Feeds geladen. load_default_textdomain() verbraucht nach meinen Messungen etwa 30 bis über 50 Prozent der gesamten Zeit, die für die Bearbeitung eines Requests nötig ist.

Zusammengefasst heißt das: Ein deutschsprachiges Blog ist für menschliche Besucher, Googlebot und Administratoren wesentlich langsamer als das exakt gleiche Blog auf einem englischen WordPress.

Messmethode

Zur Auswertung der Laufzeit-Unterschiede zwischen der deutsch- und der englischsprachigen Variante habe ich eine lokale WordPress-Installation mit Xdebug vermessen und die so gewonnenen Profiling-Daten für folgende drei Requestrouten mit webgrind visualisiert:

  1. Darstellung von zehn einfachen Posts auf der Blog-Homepage mit dem Standardtheme “TwentyTen”
  2. Aufruf der Dashboard-Übersicht im Backend
  3. Darstellung des RSS-Feeds

Der Testaufbau bestand aus:

  • WordPress 3.2-bleeding r17633
  • Theme “TwentyTen” 1.1
  • Keine aktiven Plugins
  • Lokaler Webserver ohne Last
  • Apache 2.2.9
  • PHP 5.2.6
  • MySQL 5.0.67
  • Xdebug 2.1.1
  • webgrind 1.1
  • Windows 7 SP1

Messergebnisse

Die Zeit, die WordPress benötigt, um einen einzelnen Request zu erfüllen, variiert je nach Route (Frontend, Backend, RSS). In jedem Fall verschlechtert der Wechsel auf die deutsche Sprachdatei die Geschwindigkeit um zweistellige Prozentsätze.

Für die Darstellung der Frontpage mit zehn Blogbeiträgen benötigt die deutsche Fassung fast doppelt so lange wie das englische Pendant, das Backend wird um etwa ein Drittel gebremst und die RSS-Feeds werden über 60% langsamer erzeugt.

Der Webgrind-Report liefert die Laufzeiten jeder einzelnen Funktion, die WordPress zur Generierung der Frontpage aufruft. Sehr schön sieht man hier, dass MO->make_entry() für jedes einzelne Textschnippsel ein Mal aufgerufen wird. 3.273 übersetzte Texte werden in 618 ms geladen.

Webgrind-Analyse der Laufzeiten für das WP-Frontend in Deutsch

Man erkennt deutlich, dass gerade die Lokalisierungsfunktionen aus der POMO-Bibliothek den Löwenanteil der Zeit verbrauchen.

Mit MO->import_from_reader, MO->make_entry, Translation_Entry->key und POMO_REader->substr sind vier der fünf zeitaufwändigsten Funktionen bei jedem Seitenaufruf für die deutsche Übersetzung nötig. Es gilt ein annähernd linearer Zusammenhang: Je mehr übersetzte Texte, desto höher der Zeitbedarf.

Der selbe Ablauf in der englischsprachigen Variante sieht zum Vergleich so aus:

Webgrind-Analyse der Laufzeiten für das WP-Frontend in Englisch

Ein ähnliches Verhältnis ergibt sich auch für das Backend1 und Feeds2.

Die Messung eines Profiling-Durchlaufs auf meinem Testsystem ergab diese in weiteren Durchläufen recht gut reproduzierbaren Laufzeiten:

Route Laufzeit [en] Laufzeit [de] Relative Leistung [de]
Frontend 2343 ms 4327 ms 56%
Backend 3003 ms 4283 ms 70%
RSS-Feed 1129 ms 2952 ms 38%

Diese Zahlen sollte man auf jeden Fall mit ein wenig kritischer Distanz werten: Ich habe Messungen auf einem einzigen System durchgeführt und auf einem zweiten Rechner auf Plausibilität geprüft. Ergebnisse mit Webspace auf anderen Betriebssystemen oder Dateisystemen können abweichen, und ich würde sehr gerne Zahlen von Apple- oder Linux-Systemen zum Vergleich sehen. Trotzdem glaube ich, dass das Lokalisierungspackage in WordPress einen merklichen Anteil an der Performance einer WordPress-Site hat.

In der grafischen Darstellung wird deutlich, wie eklatant der Leistungseinbruch der deutschen Fassung ausfällt:

Leistungsvergleich [en] vs. [de]

Verbesserungspotential

Was kann man tun, um diesen Klotz am Bein los zu werden? Leider habe ich dazu keine ideale Lösung, sondern nur ein paar Denkansätze:

Ein Frontend-Cache ist immer nützlich und hilft auch hier. Die negativen Auswirkungen der Lokalisierung im Backend lindert ein Cache aber nicht.

Eine weitere Möglichkeit wäre, auf die deutsche Sprachdatei komplett zu verzichten. Im Backend findet man sich eventuell auch auf Englisch zurecht, und für das Frontend setzt man einfach ein Theme ein, dass auch ohne Lokalisierung Deutsch spricht.

Drittens könne man einen Vorteil aus der Tatsache ziehen, dass der Leistungseinbruch mit der Zahl der übersetzten Texte zusammenhängt, und eine auf das Wesentliche verkürzte deutsche Sprachdatei einsetzen. Ein radikaler Löschkreuzzug in der Sprachdatei, dem ein paar hundert Hilfetexte oder unbenutzte Texte für WP-Multisite zum Opfer fallen, ist mit Hilfe von Poedit nicht schwierig. Die Ladezeit sinkt mit jedem entfernten Eintrag in der Sprachdatei um etwa 0,3 Promille.

Weitere Verbesserungen erfordern, dass seitens der WordPress-Programmierer an der Optimierung der POMO-Bibliothek selbst gearbeitet wird und zum Beispiel persistente Caches für die translation entries genutzt werden. Das Trac-Ticket dafür gibt es schon

Fußnoten

1 Profilingdaten für das Backend in Englisch und Deutsch.

2 Profilingdaten für den RSS-Feed in Englisch und Deutsch.

Kommentare [17]

Exploit Scanner: Hashwerte fürs deutsche WordPress

30. Dezember 2010, 20:27

Das Plugin Exploit Scanner hat ja aus aktuellem Anlass trotz der Feiertage wohl ein paar Downloads mehr als üblich erlebt. Wer versucht, dieses Plugin in einer deutschsprachigen WordPress-Variante einzusetzen, wird gleich zum Einstieg damit überrascht, dass sieben von 707 Dateien des WordPress-Cores verändert wurden:

  • wp-admin/setup-config.php
  • wp-config-sample.php
  • wp-includes/functions.php
  • wp-includes/load.php
  • wp-includes/version.php
  • wp-includes/wp-db.php
  • wp-load.php

Die Meldung “Modified core file” sollte eigentlich die Alarmglocken klingeln lassen.

WordPress Exploit Scanner: Modified core file

Aber immer mit der Ruhe: Die angemeckerten sieben Dateien sind absichtlich gegenüber den Originalen verändert, weil sie nicht über die Sprachdatei ins Deutsche übersetzbare Texte enthalten. Davon weiss leider das Plugin nichts – aber es ist lernfähig: Die Prüfung auf den Originalzustand läuft über eine MD5-Prüfsumme, die im Plugin mit einem mitgelieferten Sollwert aus einer Hashdatei verglichen wird.

Ich habe die MD5-Hashwerte für ein unmodifiziertes deutsches WordPress, wie es von hier herunterzuladen ist, neu errechnet und die Hashdatei dazu passend erstellt. Wenn du also das Plugin Exploit Scanner auf einem deutschsprachigen WordPress einsetzt (was ich jedem verantwortungsvollen WordPress-Anwender unbedingt empfehlen würde) und sicher sein willst, dass sich kein Virus oder WordPress-Hack auf deinem Webspace eingenistet hat, solltest du folgende Schritte durchführen:

Hashwerte für WordPress 3.3.1 de_DE

  1. Aktualisiere WordPress jetzt auf die allerneueste Version.
  2. Stelle sicher, dass das Plugin Exploit Scanner installiert und aktiviert ist.
  3. Lade die Hashdatei hashes-3.3.1.php für die deutsche Fassung von hier herunter.
  4. Speichere diese Hashdatei über FTP im Verzeichnis <wordpress_ordner>/wp-content/plugins/exploit-scanner/ auf deinem Webserver.
  5. Prüfe deine WordPress-Installation auf unbefugte Veränderungen mit dem Menüpunkt “Werkzeuge > Exploit Scanner”.

Der MD5-Hash der Datei hashes-3.3.1.php selbst ist f61b81bf61a98c34ac3b5c5d1164a1a6. Dieser Wert sollte auch am Fuß der Seite unter “Werkzeuge > Exploit Scanner” angezeigt werden.

FAQ: Wie kannst du sicher sein, dass ich ehrlich bin und es in Ordnung ist, Code von meiner Site auf deinem Server zu installieren? Tja… No risk, no fun.

Hashwerte für aktuelle und ältere WordPress-Versionen

Obwohl es sicher nicht sicher genug ist, alte WordPress-Versionen zu lange weiter zu verwenden, gibt es doch manchmal technische Umstände, die ein Update auf die neueste WordPress-Version unmöglich machen. Passende Exploit-Scanner-Hashdateien sind hier herunterladbar:

Version Download Hash
3.3.1 hashes-3.3.1.php 46deb2248e224023a3c27c39cad0dea5
3.2.1 hashes-3.2.1.php f61b81bf61a98c34ac3b5c5d1164a1a6
3.1.2 hashes-3.1.2.php 1615a43c16bcea8c036a6820d1b3e2a1
3.1.1 hashes-3.1.1.php e3d3191f21c5821354548edd3213041a
3.1 hashes-3.1.php 50a8ad99d47b6fb57297f575142b4259
3.0.5 hashes-3.0.5.php 9a24c6dbcb1e6028bd854f7ca8136259
3.0.4 hashes-3.0.4.php 81543a22aee2ea03a4b9e39a03fca384

Diese Hashdateien werden mit einem weiteren Plugin erzeugt, das ich zur Zeit nur privat einsetze. Im Prinzip wäre es mit diesem Plugin für jeden User möglich, Hashes für jede Version oder Lokalisierung von WordPress zu berechnen, darum will ich das Plugin später wie alle anderen auch im WordPress-Plugin-Repository veröffentlichen, sobald die dazugehörige Dokumentation brauchbar ist.

FAQ

Wie kannst du sicher sein, dass ich ehrlich bin und es in Ordnung ist, Code von meiner Site auf deinem Server zu installieren? Tja… No risk, no fun.

Kommentare

WordPress beschleunigen - mit nur einem Klick

14. Dezember 2010, 13:08

Weil’s in diesem Beitrag um Geschwindigkeit geht, gibt’s gleich vorweg die Kernaussage für alle Eiligen:

Wenn du dein Blog mit einer Version von WordPress vor 3.0 aufgesetzt hast und “schöne” Permalinks verwendest, speichere jetzt die Permalink-Einstellungen noch einmal. Dein Blog wird dadurch schneller – sonst ändert sich nichts.

WordPress-Einstellungen "Permalinks"

Und nun das Ganze noch mal langsam zum Mitlesen1

Um schöne Permalinks nach dem Muster http://www.example.com/2010/12/hello-world an Stelle der “hässlichen” Variante http://www.example.com/?p=123 erzeugen zu können, benötigt WordPress das Apache-Modul mod_rewrite und einige Zeilen in der Datei .htaccess, die im Wurzelverzeichnis des Blogs am Webspace liegt. In diesen Zeilen definiert WordPress, wie der Webhost auf Anfragen nach diesen “schönen” Permalinks reagieren soll.

Das macht WordPress schon seit Urzeiten so. Aber erst am 9. Januar 2010 wurde bekannt, dass die bisher benutzen Regeln für mod_rewrite den Webserver dazu angeleitet hatten, diese Regeln häufig zwei Mal für jeden Seitenaufruf durchzuackern – mit der damit einhergehenden Geschwindigkeitseinbusse für jeden Besucher. Diese Scharte wurde am 11. März 2010 ausgewetzt und mit dem Release von WordPress 3.0 im allgemein genutzten Produkt beseitigt.

Bessere RewriteRules ab WordPress 3.0

Ab Version 3.0 schreibt WordPress also bessere Rewrite-Regeln in die .htaccess – aber nur auf Aufforderung: Beim automatischen Update werden zwar alle Programmdateien aktualisiert und auch Datenbankstrukturen angepasst, aber etwaige Verbesserungen in der Konfiguration des Webservers bleiben aus Stabilitätsgründen außen vor.

So sieht der Block mit Rewrite-Regeln in .htaccess auf einer Installation von WordPress vor Version 3.0 häufig aus:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Erst mit dem Klick auf “Speichern” in den Permalink-Einstellungen werden die Rewrite-Regeln aktualisiert und um die eine Zeile ergänzt, die den zweiten Durchlauf durch das Regelwerk verhindert:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Schnellere Seiten, zufriedene Besucher

Diese eine zusätzliche Zeile erhöht im Fall von Hosting auf einem günstigen Webspace die Geschwindigkeit, mit der Seiten an die Besucher und auch an Google ausgeliefert werden, um etwa 10 bis 20 Prozent. Das ist zwar nicht atemberaubend, aber sowas von “geschenkter Gaul” wie nur irgend möglich.

Wie schaut die Situation bei dir aus?

1 …für die G’studierten ;)

Kommentare [14]