Datenschutz & Google Analytics für WordPress

[toc]

Auch wenn in letzter Zeit wieder häufiger davon zu lesen ist, Google Analytics bzw. das von Google bereitgestellte Browser-Plugin zum „opt-out“ aus Google Analytics sei immer noch nicht mit deutschem Datenschutzrecht vereinbar[ref]vgl. hierzu beispielsweise den Bericht von Jan Tißler auf t3n, aus dem u.a. hervorgeht, dass IP-Adressen trotz verwendetem Browser-Plugin z.T. immer noch übermittelt würden.[/ref], existieren Möglichkeiten, um das Analytics-Tracking zumindest nach bisher vorherrschender Rechtspraxis[ref]vgl. dazu auch Pressemitteilung des bayerischen Landesbeauftragten für den Datenschutz Dr. Thomas Petri unter http://www.datenschutz-bayern.de/presse/20100906_google_analytics.html.[/ref] durch serverseitige Maßnahmen datenschutzkonform zu machen.

Rechtsgrundlage

Grundsätzlich ist in Deutschland die Erhebung von Nutzungsdaten digitaler Medien, wie beispielsweise Webseiten, im Telemediengesetz (TMG) geregelt. Hiernach ist die Erhebung von pseudonymisierten Nutzungsdaten nach §15 (3) zunächst zulässig[ref]vgl. auch http://www.gesetze-im-internet.de/tmg/__15.html.[/ref]:

Der Diensteanbieter darf für Zwecke der Werbung, der Marktforschung oder zur bedarfsgerechten Gestaltung der Telemedien Nutzungsprofile bei Verwendung von Pseudonymen erstellen, sofern der Nutzer dem nicht widerspricht.

Nachdem sehr viele Internetseitenbetreiber Google Analytics oder vergleichbare Werkzeuge zur Auswertung des Besucherverkehrs einsetzen, ohne sich explizit an die geforderte Pseudonymisierung zu halten, hat der Düsseldorfer Kreis im November 2009 (hauptsächlich für öffentliche Einrichtungen) die Verwendung von IP-Adressen als Pseudonym für explizit unzulässig erklärt, da die Anonymisierung hier nicht in ausreichendem Maße gewährleistet sei[ref]vgl. öffentlich zugängliche PDF-Version des damaligen Beschlusses unter http://www.lfd.m-v.de/dschutz/beschlue/Analyse.pdf.[/ref].

Serverseitige IP-Anonymisierung

Google hatte daraufhin reagiert und im Mai vergangenen Jahres eine Möglichkeit bereitgestellt, um die IP-Adressen der Webseitenbesucher nur noch (teil-)anonymisiert abzuspeichern[ref]Details im original Blogbeitrag dazu aus dem Analytics-Blog unter http://analytics.blogspot.com/2010/05/greater-choice-and-transparency-for.html.[/ref]. Außerdem zeigt sich Google neueren Berichten zufolge auch sehr bemüht, weitere Unstimmigkeiten bzgl. eventuell vorhandener Datenschutzbeeinträchtigungen beizulegen[ref]vgl. Beitrag von Falk Hedemann dazu auf t3n: http://t3n.de/news/google-analytics-deutschland-google-dementiert-293164/.[/ref]. Die Voraussetzung für die Zulässigkeit der Google-Analytics-Nutzung ist damit allerdings immer noch, dass das eingesetzte Tracking-Verfahren den Parameter zur Anonymisierung der IP-Adressen (bzw. besser gesagt des letzten Oktetts der IP-Adressen) nutzt, um die u.a. vom Düsseldorfer Kreis geforderte Pseudonym-Eigenschaft zu gewährleisten[ref]vgl. dazu auch „Webanalyse datenschutzkonform betreiben: Google Analytics anonymisieren“ von Markus Vollmert.[/ref].

Technische Umsetzung

Webseitenbetreiber, die den Tracking-Code händisch einfügen, konnten entsprechend der Google API die Anonymisierung relativ einfach einsetzen, in dem sie den entsprechenden Parameter (synchron / asynchron) direkt in den Tracking-Code einbinden.

Anpassung des synchronen Tracking-Codes

<script type="text/javascript">
	var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
	document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
	var pageTracker = _gat._getTracker("UA-XXXXXX-XX");
	_gat._anonymizeIp();
	pageTracker._initData();
	pageTracker._trackPageview();
</script>

Geändert hat sich hier lediglich die Zeile 7. Ähnlich verhält es sich bei Nutzung des performanteren und die Ladezeit der Website weniger beeinträchtigenden asynchronen Trackings.

Anpassung des asynchronen Tracking-Codes

<script type="text/javascript">
	var _gaq = _gaq || [];
	_gaq.push(['_setAccount', 'UA-XXXXXX-XX']);
	_gaq.push(['_gat._anonymizeIp']);
	_gaq.push(['_trackPageview']);

	(function() {
		var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
		ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
		var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
	})();
</script>

Hier hat sich entsprechend Zeile 4 geändert. Insbesondere in der Übergangszeit nach Einführung des Zusatzparameters fand man häufig auch folgende falsche Verwendungsform, die nicht zum gewünschten Ergebnis führt[ref]vgl. auch Diskussion auf http://kress.it/2010/07/google-analytics-anonymizeip-ip-adressen-kurzen-richtiger-code/ oder http://1336.de/google-analytics-datenschutz/.[/ref]. Hier ist also Vorsicht geboten:

_gaq.push(['_anonymizeIP']);

Verwendung in WordPress

Nachdem von den verfügbaren WordPress-Plugins nicht alle eine benutzerfreundliche („dazuklickbare“) Option zur Einbindung des Parameters mitbringen, ist man bei der Plugin-Auswahl schon etwas eingeschränkt. Nach einem kurzen Funktionsvergleich der aktuell populärsten WordPress Plugins für Google Analytics

fiel meine Auswahl in diesem Fall schnell auf Google Analytics for WordPress, nicht zuletzt da es neben der expliziten Option zur Konfiguration der IP-Maskierung im Vergleich zu den anderen Plugins auch sonst den robustesten und flexibelsten Eindruck machte. Wichtig ist nur, unter „Einstellungen > Google Analytics > Advanced Settings > anonymize IP“ das entsprechende Häkchen zu setzen.

Wer zusätzlich gerne eine Dashboard-Übersicht hätte, wie sie die anderen Plugins z.T. mitbringen, kann als Ergänzung das Plugin Google Analytics Dashboard einsetzen, das trotz aktuell nicht ausgewiesener WordPress 3.0 Kompatibilität zumindest bei ersten Tests auch in dieser Version einwandfrei funktionierte.

Hinweispflicht im Impressum

Unabhängig von der IP-Maskierung besteht natürlich weiterhin die Verpflichtung im Impressum einer Website auf die Nutzung von Google Analytics hinzuweisen. Hierzu bietet Google eine verwendbare Vorlage, die nach eigener Aussage die wesentlichen Bestandteile enthält[ref]vgl. http://www.google.com/intl/de_ALL/analytics/tos.html.[/ref]:

Diese Website benutzt Google Analytics, einen Webanalysedienst der Google Inc. („Google“). Google Analytics verwendet sog. „Cookies“, Textdateien, die auf Ihrem Computer gespeichert werden und die eine Analyse der Benutzung der Website durch Sie ermöglichen. Die durch den Cookie erzeugten Informationen über Ihre Benutzung dieser Website (einschließlich Ihrer IP-Adresse) wird an einen Server von Google in den USA übertragen und dort gespeichert. Google wird diese Informationen benutzen, um Ihre Nutzung der Website auszuwerten, um Reports über die Websiteaktivitäten für die Websitebetreiber zusammenzustellen und um weitere mit der Websitenutzung und der Internetnutzung verbundene Dienstleistungen zu erbringen. Auch wird Google diese Informationen gegebenenfalls an Dritte übertragen, sofern dies gesetzlich vorgeschrieben oder soweit Dritte diese Daten im Auftrag von Google verarbeiten. Google wird in keinem Fall Ihre IP-Adresse mit anderen Daten von Google in Verbindung bringen. Sie können die Installation der Cookies durch eine entsprechende Einstellung Ihrer Browser Software verhindern; wir weisen Sie jedoch darauf hin, dass Sie in diesem Fall gegebenenfalls nicht sämtliche Funktionen dieser Website vollumfänglich nutzen können. Durch die Nutzung dieser Website erklären Sie sich mit der Bearbeitung der über Sie erhobenen Daten durch Google in der zuvor beschriebenen Art und Weise und zu dem zuvor benannten Zweck einverstanden.

Natürlich kann ich als Nicht-Jurist keine Nutzungsempfehlungen aussprechen (das sollte jeder eigenverantwortliche entscheiden), aber in dieser Form scheint Google Analytics zumindest den aktuell geltenden Datenschutzbestimmungen (auch für öffentliche Einrichtungen) zu genügen.

Nicht lesbare Thumbnails bei WordPress / Buddypress mit suPHP

Auf unserer Multiblogging-Plattform setzen wir aus Sicherheitsgründen suPHP statt mod_php ein. Einer der großen Vorteile ist, dass Skripte so unter dem Benutzer des jeweiligen vHosts ausgeführt werden und so weder schreibbar noch ausführbar für andere Benutzer sein müssen. Da die Dateien dem vHost-Besitzer „gehören“ genügt für normale Dateien, wie z.B. Bilder, eine Linux-Dateisystem-Berechtigung von umask 644 bzw. -rwxr–r– oder auf Deutsch:  Besitzer (vHost owner) darf lesen und schreiben, der Rest – insbesondere der Apache-User www-data darf nur lesen.

Das Problem …

In der Debian / Ubuntu Default-Konfiguration für von Skripten erstellte Dateien, also z.B. für von WordPress / Buddypress erzeugte Profilbilder oder vom Plugin NextGEN Gallery erstellte Thumbnails, setzt suPHP die Berechtigung 600 bzw. -rw——-, wodurch die Dateien nicht durch den Apache-User gelesen werden können. Das führt i.d.R. zu klassischen 404-Fehlermeldungen beim Zugriff auf die URLs oder dazu, dass Bilder einfach nicht dargestellt werden, sondern lediglich deren Alternativtext (sofern überhaupt verfügbar).

Die Lösung …

… ist prinzipiell relativ einfach. Allerdings ist zur Änderung Zugriff auf die Webserverkonfiguration erforderlich, was jedoch inzwischen aufgrund der immer häufiger genutzten eigenen vServer mit Root-Zugriff vielfach gegeben ist. In diesem Fall muss lediglich der umask-Eintrag der Datei /etc/suphp/suphp.conf von 0077 (entspricht 600 in Oktalnotation) auf 0022 (entspricht 644 in Oktalnotation) geändert werden:

;Umask to set, specify in octal notation
;umask=0077

Sicherheitshalber ggf. noch den Apache-Prozess neu starten, so dass die Änderungen auch auf jeden Fall übernommen werden und ab sofort sollten von PHP-Prozessen erzeugte Dateien mit den korrekten und v.a. von Apache lesbaren Berechtigungen 644 erzeugt werden:

/etc/init.d/apache2 restart

„jQuery is not defined“-Fehler im WordPress Backend

Mehr oder weniger zufällig haben wir gestern nach einem Update auf Version 3.0.4 einen „Bug“ im WordPress-Backend gefunden, durch den kein Umschalten des WYSIWYG-Editors zwischen „Visuell“ und „HTML“ mehr möglich war. Da die Eingrenzung des Fehlers doch etwas gedauert hat, poste ich das hier, für den Fall, dass es sonst noch jemandem weiterhilft.

Interessant daran: Scheinbar hatte sich WordPress per Cookie / Einstellung zuvor gemerkt, welchen Modus ein Benutzer beim Schreiben / Editieren zuletzt aktiviert hatte, denn entdeckt wurde der Fehler dadurch, dass bei einem Benutzer scheinbar der Editor nicht mehr funktionierte, bei anderen alledings erschien der Editor (TinyMCE) problemlos. Genau lässt sich auch nicht sagen, seit wann das Problem wirklich existiert, vermutlich schon seit einer der früheren 3.0.X-Versionen.

Das Problem

Die Identifikation des genauen Symptoms war per Firefox-Fehlerkonsole relativ schnell erledigt. jQuery wurde scheinbar nicht korrekt geladen, wodurch darauf aufbauende Javascripts Fehler wie z.B. „jquery is not defined“ oder „edButtons is undefined“ auswurfen.

[singlepic id=1 w=614 h=420]

Die Herkunft des Problems lag allerdings etwas tiefer….

Vorgeschlagene Lösungen

Erste Amtshandlung nach Identifikation der Fehlerquelle war (wie vermutlich bei den meisten) Googlen nach der Meldung aus der Fehlerkonsole. Resultat: http://lmgtfy.com/?q=wordpress+jquery+is+not+defined.

Unter den Support-Forum-Posts der Google-Ergebnisse wurde das Deaktivieren von Plugins zur Eingrenzung der Ursache (z.B. http://wordpress.org/support/topic/javascript-error-jquery-is-not-defined) oder noch häufiger ein erneuter Upload der entsprechenden Javascript-Dateien per FTP-Binärmodus (z.B. http://wordpress.org/support/topic/jquery-is-not-defined) vorgeschlagen.

Lösen ließ sich das Problem in unserem Fall damit allerdings nicht, denn die JS-Dateien kommen bei uns über ein Shell-Update-Skript direkt aus dem WordPress-SVN und auch nachdem alle Plugins deaktiviert waren, bestand der Fehler weiter, obwohl wir z.B. auch das (wie ich persönlich finde) sehr gute, im ersten Link erwähnte Admin Dropdown Menü verwenden.

Die tatsächliche Lösung

Bei der weiteren Suche bin ich dann schnell an der Javascript-Quelle hängen geblieben, die – wie man im Screenshot oben gut erkennen kann – das PHP-Skript „load-scripts.php“ nutzt, um verschiedene Einzeldateien zur Verkürzung der Ladezeit zu konkatenieren. Dieser Mechnismus hat wohl auch schon in anderen Konstellationen Fehler verursacht, siehe z.B. http://wordpress.org/support/topic/wp-28-jquery-error. Durch einfaches Abschalten der Skriptverkettung sowie (sicherheitshalber) auch der gleichzeitig von WP durchgeführten Kompression mittels gzip, konnte der Fehler schließlich relativ einfach beseitigt werden. Hierzu müssen lediglich die beiden folgenden Zeilen in die Datei wp-config.php eingefügt werden, die sich im Root-Verzeichnis der WordPress-Installation befindet:

define('CONCATENATE_SCRIPTS', false);
define('COMPRESS_SCRIPTS', false);

WordPress XML Sitemap für Multisite-Installationen

[toc]

Inzwischen dürfte die Möglichkeit eigene Seiten sowie deren Aktualisierungen (z.B. Blogposts) per sitemap.xml an Google zu übermitteln wohl den meisten Webseitenbetreibern geläufig sein. Für den Fall der Fälle finden sich in den Webmaster Tools bei Google weitere Informationen dazu.

Klassische WordPress-Plugin-Lösung

Für WordPress gibt es schon seit einiger Zeit ein sehr einfaches und gutes Plugin von Arne Brachhold, das die automatische Erzeugung und Aktualisierung dieser sitemap.xml sowie deren komprimiertem Pendants „sitemap.xml.gz“ übernimmt. Wir haben dieses Plugin u.a. auf dem offiziellen Internetauftritt der Forschungsgruppe München www.kooperationssysteme.de im Einsatz. Nachdem diese aktuell extern gehostete Seite allerdings in unsere inzwischen stetig gewachsene und weiterentwickelte WordPress Multiblogging-Plattform umziehen sollte und die aktuelle „stable“ des Plugins nicht Multisite-fähig war, ging die Alternativensuche los.

Multisite-fähige Plugins

Sucht man in den WordPress Plugins nach „google sitemaps multisite“ findet man als ersten Treffer zunächst das vielversprechend klingende Plugin Google XML Sitemaps with Multisite support von Mario Kostelac, das nach näherer Begutachtung auf der oben erwähnten Erweiterung aufbaut und nach eigenen Angaben einen Großteil des Codes von Arne Brachhold verwendet:

99% percent of work is done by Arne so, thank you Arne. I hope that our projects will merge into the one in the near future.

Haupteinschränkung des Plugins: Es verwendet immer noch von Zeit zu Zeit (statisch) erzeugte Sitemap-Dateien und legt diese in einem Unterordner „sitemaps“ im Webroot bzw. WordPress-Installationsverzeichnis ab. Diese müssen dann bei einer Multisite-Installation für die einzelnen Blogs per manuellem Rewrite oder über Anpassungen der robots.txt integriert werden, was mit Zusatzaufwand verbunden ist.

Bei der weiteren Recherche nach brauchbaren Plugins bin ich anschließend sehr schnell über eine Weiterentwicklung der ursprünglichen Erweiterung gestolpert, die sich zwar aktuell noch in der Beta-Phase befindet, Ihren Dienst aber mit ein paar minimalistischen Einschränkungen schon sehr gut macht. Details auf der entsprechenden Website von Arne Brachhold. Wie man dem Changelog entnehmen kann, unterstützt die Beta nicht nur Multisite-Installationen, sondern erzeugt die sitemap.xml für die einzelnen Blogs „on the fly“, wodurch keine umständlichen Rewrites oder Eintragungen in der robots.txt mehr erforderlich sind:

  • No static files anymore, sitemap is created on the fly!
  • Sitemap is split up into sub-sitemaps by month, allowing up to 50.000 posts per month!
  • Reduced server resource usage due to less content per request.
  • 100% Multisite compatible, including by-blog and network activation.
  • New API allows other plugins to add their own, separate sitemaps.

Nachdem ich das Plugin im Root-Blog einer WordPress-Installation (3.0.4) getestet habe, die u.a. auch Buddypress (1.2.7) nutzt, scheint es wohl aus diesem oder einem mir unerfindlichen anderen Grund ein Problem mit dem Rewrite der url blog.de/sitemap.xml zu geben, das mich erst zu dem Glauben veranlasst hat, das Plugin würde überhaupt nicht funktionieren. Nach etwas Recherche und Testen in anderen (nicht-root) Blogs der Multisite-Installation wurde dann aber schnell klar, dass die Sitemaps jeweils korrekt erzeugt wurden. Lediglich im Root-Blog konnte die Sitemap nicht über blog.de/sitemap.xml, sondern ausschließlich über die Non-Permalink-Variante blog.de/index.php?xml_sitemap=index aufgefrufen werden.

Anpassung der .htaccess-Datei

Durch einen Blogpost von Jan Dembowski zu einer Anpassung des verwendeten Plugins (der zwar in dieser Form inzwischen aufgrund der aktuellen Beta veraltet ist, jedoch für den vorliegenden Fall sehr hilfreich war), ließ sich auch das Problem mit dem Root-Blog durch Einfügen einer weiteren Rewrite-Rule in der .htaccess-Datei von WordPress lösen:

RewriteRule ^sitemap.xml index.php?xml_sitemap=index [L]