Google Goggles meets iPhone

Seit Ende 2010 ist Google Goggles auch für das iPhone verfügbar. Bei Google Goggles handelt es sich um eine mobile Bilderkennungssoftware, welche eine Web-Suche auf Basis von Bildern ermöglicht, die über das eigene Mobilgerät aufgenommen wurden.

Ursprünglich ist Google Goggles als eigenständige App für Android entwickelt worden. Für iOS-Devices verbirgt sich die Funktionalität dagegen innerhalb der Google Mobile App for iPhone.
Um Goggles auf dem iPhone zu verwenden, ist initial die Aktivierung über die Einstellungen erforderlich. Anschließend erscheint Goggles als Kamera-Symbol neben der Suchleiste.

[nggallery id=29]

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.

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]