NextGen Gallery ¹ ist meiner Meinung nach eine der sinnvollsten und am besten durchdachten Erweiterungen für WordPress. Das Plugin ermöglicht eine galerie- und albumbasierte Verwaltung von Bilder aller Art und darüber hinaus die Zuordnung von Schlagwörtern / Tags zur zusätzlichen (flachen) Strukturierung. Hierdurch wird es möglich, Bilder in Artikeln mithilfe des nggtags-Shortcodes ² dynamisch einzubinden, d.h. statt einer festen Referenz auf eine Auswahl von Bildern wird nur noch festgelegt, welche Schlagwortkombinationen für eine bestimmte Artikelstelle relevant sind. Beispielsweise würden mit folgendem Shortcode alle Bilder als Thumbnails angezeigt, die mit „Auto“ (Groß- und Kleinschreibung egal) verschlagwortet wurden ³

[ nggtags gallery=Auto ]

Das Ganze hat meiner Meinung nach drei entscheidende Vorteile:

1. Kommen weitere Bilder mit den entsprechenden Tags in irgendeiner Galerie hinzu, werden sie automatisch im Artikel mit angezeigt.
2. In der Galerie angegebene Metadaten, wie Titel und Beschreibung werden automatisch übernommen und müssen so im Vergleich zur Nutzung der WordPress Mediathek nicht redundant gepflegt werden – v.a. dann nicht, wenn sie sich nachträglich ändern.
3. Der Tagging-Mechanismus funktioniert galerieübergreifend, d.h. neben der in NextGEN vorhandenen intuitiven Strukturierung in verschiedene Galerien (z.B. zu einem bestimmten Ereignis wie „Doktorandenseminare“ oder einer bestimmten Bilderkategorie wie „WordPress Screenshots“), lassen sich sehr einfach übergreifende Selektionen vornehmen ⁴.

Problem bei externen Bildquellen

Ein „Problem“ mit dem Plugin ergibt sich dann, wenn man Bilder z.B. im wissenschaftlichen Kontext von anderen Quellen referenzieren und dennoch auf den Komfort des Plugins nicht verzichten möchte. Aktuell bietet NextGEN Gallery keine Möglichkeit, Bildquellen oder Ähnliches direkt anzugeben. Natürlich könnte man dafür das Beschreibungsfeld nutzen bzw. zweckentfremden und die entsprechende Quelle einfach als Text dort mit aufnehmen. Für den Fall, dass man die Anzeige der Quelle allerdings gezielter steuern möchte, ist diese Möglichkeit nicht geeignet. Auch widerspräche das Vorgehen klar dem Atomaritätsprinzip bzw. der semantischen Bedeutung des Beschreibungsfeldes. Prinzipiell bietet NextGEN auch hierfür einen eingebauten Mechanismus zur Angabe weiterer Metadaten, allerdings ist dieser in neueren Versionen des Plugins nur sehr umständlich erreichbar und wird v.a. nicht in den Übersichten angezeigt.

Lösungsschritte

Nachdem bis zu einer sinnvoll nutzbaren Lösung zur Quellangabe einige Schritte erforderlich waren, halte ich das hier kurz fest.

1. Zusätzliches Feld zur Quellenangabe bei jedem Bild

Zur Bereitstellung des benötigten Metadatenfeldes im Backend von NextGEN hilft das Plugin NextGEN Custom Fields, mit dem nach erfolgter Installation über den neuen Menüpunkt „NGG Custom Fields“ sehr einfach ein neues  Image Custom Field mit  Bezeichnung „Source“ für Quellenangaben angelegt werden kann. Die Eingabe erfolgt anschließend wie gewohnt über den Punkt „Galerie verwalten“, wie im folgenden Screenshot auf der rechten Seite zu sehen.

NextGEN Gallery Source Feld

2. Anpassen des Galerie-Templates

Damit das neu erstellte Feld auch in Thumbnail-Übersichten oder bei Einzelbildern im Frontend angezeigt wird, muss es entsprechend eingebunden werden. Mein erster Ansatz war, ein eigenes NextGEN Gallery Template für die Ausgabe zu nutzen, allerdings funktioniert der folgende Shortcode leider nicht, da NextGEN seltsamerweise bei tagbasierten Galerien bisher keine Tamplates unterstützt.

[ nggtags gallery=Auto template=source]

Dieser Missstand ließe sich zwar entsprechend http://wordpress.org/support/topic/plugin-nextgen-gallery-nggtags-caption beseitigen, allerdings müssten hierzu die Funktion nggShowGalleryTags in der nggfunctions.php und die Funktion show_tags in der shortcode.php von NextGEN entsprechend angepasst werden, was logischerweise nicht update-sicher und damit wenig sinnvoll ist. Hier heißt es also abwarten, ob diese durchaus sinnvollen Erweiterungen für nggtags irgendwann durch den Autor Alex Rabe ihren Weg in das Plugin finden, wovon ich fest ausgehe.

Somit blieb nichts anderes, als direkt das gallery.php Template entsprechend anzupassen. Nachdem wir hier im Blog allerdings sowieso ein einheitliches Galerieformat verwenden, ist dem auch nichts entgegenzusetzen – insbesondere da es so (ohne den zusätzlichen template-Parameter im Shortcode) noch einfacher ist, später Galerien in Blogartikeln einzufügen.

Um sicherzustellen, das die Templates nicht bei einem Plugin-Update direkt wieder überschrieben werden, sollten die folgenden Anpassungen ausschließlich (!) in einem zu erstellenden Unterordner „nggallery“ des verwendeten Themes durchgeführt werden:

1. Kopieren der gallery.php und der singlepic.php aus /wp-content/plugins/nextgen-gallery/view/ nach wp-content/themes/AKTUELLES-THEME/nggallery/.
2. Einfügen von $image->ngg_custom_fields[„Source“] an der gewünschten Stelle, z.B. hinter echo $image->caption.

Problem hierbei ist, dass die Quellangaben (zumindest in unserem Fall) meist URLs sind, die i.d.R. eine Länge haben, durch welche die schön gefloateten Thumbnail-Übersichten unruhig würden oder falscch umbrechen, sicher aber schlecht lesbar wären (s. Screenshot):

Fehlerhafte Darstellung bei Thumbnails mit Quellen

3. Fußnoten für Quellenangaben

Da wir hier im Blog ein Plugin zur Erzeugung von Fußnoten für zusätzliche Anmerkungen oder wissenschaftliche Quellenangaben verwenden, war es naheliegend, dieses Plugin auch für die Galeriebilder zu nutzen. In unserem Fall handelt es sich um das Plugin Simple Footnotes, das sich durch eine sehr einfache Handhabung sowie Multisite- und WP 3.1-Kompatibilität auszeichnet. Im Prinzip sollten die folgenden Schritte aber auch auf andere Plugins übertragbar sein.

Statt der Einbindung der Quellangabe direkt in der Caption, muss hierzu das Source-Field von oben lediglich mit der entsprechenden Shortcode-Funktion das Simple Footnotes Plugins „gewrappt“ werden. Da das Gallery-Template das Plugin allerdings nicht kennt, ist es erforderlich, zunächst eine entsprechende lokale Instanz zu erzeugen:

n
$footnotes->shortcode('', "Bildquelle: " . imagesourcelink($image->ngg_custom_fields["Source"]) . "."));

Damit die Fußnoten nur dann erzeugt werden, wenn auch tatsächlich eine Quellenangabe vorhanden ist, sollte zusätzlich noch folgende Abfrage integriert werden:

if ($image->ngg_custom_fields["Source"]){
	echo ($footnotes->shortcode('', "Bildquelle: " . imagesourcelink($image->ngg_custom_fields["Source"]) . "."));
}

Mit diesem Code wurden die Fußnoten auch erzeugt, allerdings leider für jedes Bild wieder bei 1 beginnend, da bei jedem Aufruf innerhalb der Bilderschleife des Gallery-Templates eine neue Instanz des Footnote-Plugins erstellt wurde. Abhilfe schafft hier das Auslagern der Instanzerzeugung außerhalb der Schleife und verwenden von $footnotes als globale Variable. Wichtig: Ähnlich wie bei einem Singleton ⁵ sollte die globale Plugin-Referenz nur initialisiert werden, sofern sie noch null ist:

global $footnotes;
if (!$footnotes){
	$footnotes = new nacin_footnotes();
}

Resultat sind wie gewünscht in Fußnoten ausgelagerte Quellenangaben der Bildergalerie. Allerdings tritt das Problem doppelter Fußnoten weiterhin auf, sofern auf einer Seite, wie in diesem Beitrag, normale (textbasierte) Fußnoten und Bildergalerien gleichzeitig verwendet werden. Das liegt daran, dass das Plugin Simple Footnotes seinen Content Filter so angelegt hat, dass es sich selbst bzw. besser gesagt eine Instanz von sich selbst dem Filter übergibt:

add_filter( 'the_content', array( &$this, 'the_content' ), 12 );

Durch den WordPress-Filter-Registrierumgsmechanismus ⁶ wird bei jeder neuen Instanz von nacin_footnotes() auch jeweils ein entsprechender Content-Filter eingehängt, was a) inperformant ist und b) dazu führt, dass der Fußnotenblock in seiner Gesamtheit mehrfach am Ende eines Posts angezeigt werden kann. Leider habe ich für dieses Problem keine Optimallösung parat, so dass nur die Anpassung des der Datei simple-footnotes.php des Plugins bleibt. Hier muss ganz am Ende der Datei folgende Änderung durchgeführt werden:

//new nacin_footnotes();
global $footnotes;
$footnotes = new nacin_footnotes();

Hierdurch wird sichergestellt, dass das Plugin nur einmal erzeugt wird, egal ob direkt oder über das Gallery-Template. Zusätzlich ist es ggf. noch erforderlich, die folgende Änderung an der shortcode-Funktion des Plugins vorzunehmen. Hierdurch wird sichergestellt, dass die Fußnoten immer korrekt durchgezählt werden und bei 1 beginnen:

//FO we have to check if the footnote text is already present, otherwise the gallery plugin mechanism will not work (don't know why)
/*
if ( ! isset( $this->footnotes[$id] ) )
	$this->footnotes[$id] = array( 0 => false );
$this->footnotes[$id][] = $content;
$note = count( $this->footnotes[$id] ) - 1;
*/
if (!in_array($content,$this->footnotes[$id])){
	$this->footnotes[$id][] = $content;
	$note = count( $this->footnotes[$id] ) - 1;
}
else{
	$note =  array_search($content,$this->footnotes[$id]);
}

Ersetzt man nun noch den von NextGEN für die Bildunterschriften verwendeten span-Tag im Gallery-Template nun noch durch den von WordPress standardmäßig genutzten p-Tag der Klasse wp-caption-text und fügt dem ngg-gallery-thumbnail-Container die Klasse wp-caption hinzu, erhält man das folgende „fertige“ Gallery-Tempalte:

<?php
/**
Template Page for the gallery overview

Follow variables are useable :

	$gallery     : Contain all about the gallery
	$images      : Contain all images, path, title
	$pagination  : Contain the pagination content

 You can check the content when you insert the tag <?php var_dump($variable) ?>
 If you would like to show the timestamp of the image ,you can use <?php echo $exif['created_timestamp'] ?>
**/

// FO: muss global erzeugt werden, da sonst die Nummerierung für jede Galerie neu beginnt
global $footnotes;
if (!$footnotes){
	$footnotes = new nacin_footnotes();
}
if (!function_exists('imagesourcelink')) {
	function imagesourcelink($text){
		// text starts with http://
		if (strpos($text, "http://") === 0){
			return '<a href="' . $text . '" title="Go to external Source" >' .$text . '</a>';
		}
		else{
			return $text;
		}
	}
}

/*	FO: Da $gallery->ID als Group-ID für jQuery Colorbox / Slimbox nur dann funktioniert,
	wenn echte Gallerien verwendet werden, nicht aber bei nggtags (Tag-basierter Auswahl)
	muss hier noch einmal gesondert mitgezählt werden
*/
global $lightboxgroup;
if (!$lightboxgroup){
	$lightboxgroup = 0;
}

?>
<?php if (!defined ('ABSPATH')) die ('No direct access allowed'); ?><?php if (!empty ($gallery)) : ?>

<div id="<?php echo $gallery->anchor . $lightboxgroup ?>">

<?php if ($gallery->show_slideshow) { ?>
	<!-- Slideshow link -->
	<div>
		<a href="<?php echo $gallery->slideshow_link ?>">
			<?php echo $gallery->slideshow_link_text ?>
		</a>
	</div>
<?php } ?>

<?php if ($gallery->show_piclens) { ?>
	<!-- Piclense link -->
	<div>
		<a href="<?php echo $gallery->piclens_link ?>">
			<?php _e('[View with PicLens]','nggallery'); ?>
		</a>
	</div>
<?php } ?>

	<!-- Thumbnails -->
	<?php foreach ( $images as $image ) : ?>

	<div id="ngg-image-<?php echo $image->pid ?>" <?php echo $image->style ?> >
		<div >
			<a rel="lightbox-<?php echo $lightboxgroup ?>" href="<?php echo $image->imageURL ?>" title="
			<?php
			echo $image->description;
			if ($image->ngg_custom_fields["Source"]){
				echo ', Quelle: ' . $image->ngg_custom_fields["Source"] . ".";
			}
			?>
			" <?php echo $image->thumbcode ?> >
				<?php if ( !$image->hidden ) { ?>
				<img alt="<?php echo $image->description ?>" src="<?php echo $image->thumbnailURL ?>" <?php echo $image->size ?> />
				<?php } ?>
			</a>
			<p-caption-text><?php 

			echo $image->alttext;

			if ($image->ngg_custom_fields["Source"]){
				echo ($footnotes->shortcode('', "Bildquelle: " . imagesourcelink($image->ngg_custom_fields["Source"]) . "."));
			}

			?></p>
		</div>
	</div>
	<?php if ( $image->hidden ) continue; ?>
	<?php if ( $gallery->columns > 0 && ++$i % $gallery->columns == 0 ) { ?>
	<br style="clear: both" />
	<?php }
	endforeach;
	$lightboxgroup++;
	?>

	<!-- Pagination -->
 	<?php echo $pagination ?>

</div>

<?php endif; ?>

Zusätzlich zu den hier beschriebenen Punkten ist in diesem Template von Zeile 32-39 auch eine Zählervariable für Bildergruppen in Lightboxen, wie beispielsweise Slimbox oder Colorbox enthalten, die es auch bei tagbasierten Galerien ermöglicht, Bilder einer Galerie nacheinander durchzuklicken. Außerdem enthält das Template die Funktion imagesourcelink (Zeile 20-30), die im Source-Feld eingetragene URLs in den Fußnoten automatisch verlinkt.

Endergebnis

Das Ergebnis der Bemühungen sieht anschließend wie folgt aus:

Thumbnails mit Fußnoten

Für den Fall, dass noch kein CSS für die Galerie-Darstellung existiert, sind ggf. noch folgende ergänzenden CSS-Angaben erforderlich, um die Darstellung der Thumbnails gleichmäßig über die Seite zu verteilen. Die Größenangaben basieren hierbei auf einer in NextGEN eingestellten Thumbnail-Größe von 126x100px. Die Pixeldifferenz zu 146px Breite rührt von den CSS-Einstellungen des hier verwendeten Twentyten Child-Themes bzw. den dort vorgegebenen Paddings:

.ngg-gallery-thumbnail{
	width: 146px;
	height: 160px;
	overflow: hidden;
}

Die ggf. erforderlichen Änderungen an der singlepic.php zur Darstellung von Einzelbildern erfolgen analog.

Das Berliner Startup placeboard (http://www.placeboard.com) versucht das Prinzip des Schwarzen Bretts in der Nachbarschaft ins Internet zu übertragen.

placeboard ¹

Im Gegensatz zu anderen Internet-basierten Kleinanzeigen-Plattformen steht hier der Ortsbezug einer Mitteilung und die Filterung nach dem Ort im Vordergrund.

Neben einer recht nett gemachten Web-Schnittstellen erlauben die placeboard-Macher auch eine einfache Erweiterung der Plattform in die reale Welt: Selbst erstelle Nachrichten können mit einem QR-Code ausgedruckt werden und so an reale Schwarze Bretter geheftet werden ohne den Bezug zur digitalen Version des Aushangs zu verlieren.

Meiner Meinung nach schreit das Ganze nach einer CommunityMirror-Schnittstelle (und natürlich nach mobilen Apps dafür).

Verwandte Dienste (ausserhalb von Deutschland): BlockChalk (http://blockchalk.com)

BlockChalk ²

placeboard ¹

Wie viele andere wissenschaftliche Einrichtungen nutzen wir in der Foschungsgruppe Kooperationssysteme die Möglichkeit, unsere SSL-Serverzertifikate durch die Zertifizierungsstelle (CA) des Deutschen Forschungsnetzes (DFN) zertifizieren zu lassen. Die Zertifizierung findet durch die lokale Zwischenzertifizierungsstelle innerhalb der DFN Public Key Infrastruktur (PKI), unsere Universität der Bundeswehr München (UniBwM), statt . Großer Vorteil ist, dass die CA des DFN-Vereins („DFN-Verein PCA Global – G01″) als Root-Zertifikat das in gängigen Browsern enthaltene „Deutsche Telekom Root CA 2″ des T-TeleSec Trust Center der Deutschen Telekom AG für seine Zertifizierung verwendet. Somit wird der Zertifizierungspfad der ausgestellten Zertifikate ohne Zusatzinstallation eines Root-Zertifikats validiert.

Beantragen eines Serverzertifikats

Zur Zertifizierung lässt man sich unter ausführlicher Prüfung der persönlichen Daten und der Zugehörigkeit zur jeweils ausstellenden Einrichtung sowie der Sicherheit des zu zertifizierdenden Systems für einen ausgewählten Hostnamen ein Apache-taugliches PEM-Zertifikat generieren. Dabei handelt es sich um ein Base64-kodiertes X.509 Zertifikat im Format:

-----BEGIN CERTIFICATE-----

Zertifkatinhalt

-----END CERTIFICATE-----

Einbinden in die Apache-Konfiguration

Dieses Zertifikat kann anschließend in die Webserver-Konfiguration integriert werden. Bisher haben wir hierzu das Zertifikat sowie den von Apache benötigten privaten Schlüssel (Private Key) auf folgende einfache und der Standard-Dokumentation entsprechende Art in die Konfiguration des jeweiligen vHosts unter /etc/apache2/sites-enabled eingebunden:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/ZERTIFIKATSNAME.pem
SSLCertificateKeyFile /etc/ssl/private/PRIVATE_KEY.key

Hierzu ist natürlich das Apache2 SSL-Modul erforderlich, das sich bei Bedarf über

a2enmod ssl

aktivieren lässt.

Anschließend muss Apache neu gestartet werden:

/etc/init.d/apache2 restart

Probleme bei der bisherigen Nutzung

In gängigen Browsern, wie Firefox, Internet Explorer, Chrome oder Safari hatten wir damit nie Probleme und das Zertifikat wurde immer als gültig angezeigt. Dies ist darauf zurückzuführen, dass diese Browser beim Validieren des Zertifikats im lokalen Cache nach den verschiedenen in der Zertifikatskette enthaltenen Authority-Zertifikaten suchen und sie – sofern vorhanden – für die Validierung verwenden. Allerdings gelten in größeren Unternehmen oder bestimmten öffentlichen Einrichtungen häufig erhöhte Sicherheitsrichtlinien. Dort werden häufig Web-Proxies eingesetzt, die bei der Validierung des Zertifizierungspfades nicht auf einen lokalen Zertifikats-Cache zurückgreifen können (oder sollen), sondern für die alle Informationen direkt über den Webserver erreichbar sein müssen. In unserem Fall hat dies auf einigen Verwaltungsrechnern dazu geführt, dass bestimmte SSL-verschlüsselte Login-Seiten über den genutzten Web-Proxy nicht erreichbar waren, da die Verbindung als nicht sicher angezeigt wurde.

Zertifikat-Validierung mit openSSL

Grundsätzlich lassen sich ausgestellte Zertifikate mit dem Linux-Programm openSSL relativ einfach validieren. Hierzu verwendet man einfach den s_client mit der entsprechenden Adresse des Apache vHosts:

openssl s_client -connect vhost-adresse.de:443

Resultat sollte bei gültigen Zertifikaten ein

Verify return code: 0 (ok)

sein. In unserem Fall bekamen wir allerdings trotz der Gültigkeitsanzeige in Brwosern von openSSL ein

Verify return code: 21 (unable to verify the first certificate)

weshalb das Zertifikat auch vom Web-Proxy abgelehnt wurde.

Korrektur durch Einfügen eines SLCACertificateFile

Beseitigen ließ sich das Problem schließlich durch Nutzung eines SLCACertificateFile in der Apache-Konfiguration. Nachdem der Weg dorthin allerdings etwas steinig war, hier ein paar kurze Erläuterungen.

Zunächst muss das „Chain-File“ der jeweils genutzten DFN-Zwischenzertifizierungsstelle heruntergeladen werden, das die CA-Zertifikate aller Zwischenzertifizierungsstellen sowie der Root-CA in einem File enthält. Die jeweilige Datei ist auf den öffentlich zugänglichen Servern des DFN-Vereins verfügbar. In unserem Fall beispielsweise unter dem Link https://pki.pca.dfn.de/uni-bundeswehr-muenchen-ca/pub/cacert/chain.txt.

Diese Datei muss mit der Endung PEM (streng genommen spielt die Endung in Linux keine Rolle) in den Zertifikatsordner auf den Server (in Debian- und Ubuntu-basierten Distributionen i.d.R. /etc/ssl/certs) geladen und in der vHost-Konfiguration mittels SSLCertificateChainFile entsprechend ergänzt werden. Außerdem war es in unserem Fall erforderlich, Apache den Pfad, in dem die CA-Zertifikate zu finden sind, ebenfalls mitzuteilen:

SSLCertificateChainFile /etc/ssl/certs/CHAIN-FILE.pem
SSLCACertificatePath /etc/ssl/certs

Anschließend muss Apache wieder neu gestartet werden:

/etc/init.d/apache2 restart

Erneute Validierung

Interessant ist das Ergebnis der erneuten Validierung, denn hier liefert openSSL im Falle eines DFN-Zertifikats:

Verify return code: 19 (self signed certificate in certificate chain)

oder in anderen Worten, dass ein selbst-signiertes Zertifikat im Zertifizierungspfad gefunden wurde. Dies ist darauf zurückzuführen, dass das openssl nichts vom oben bereits erwähnten Root-CA-Zertifikat („Deutsche Telekom Root CA 2″) weiß. Durch Anhängen des CAfile-Parameters lässt sich das Zertifikat allerdings doch noch validieren:

openssl s_client -connect vhost-adresse.de:443 -CAfile /etc/ssl/certs/deutsche-telekom-root-ca2.pem

Das Resultat ist nun wie gewünscht ein

Verify return code: 0 (ok)

Auch von Clients, die den Web-Proxy nutzen, ließ sich die Seite damit problemlos validieren.

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 ¹, existieren Möglichkeiten, um das Analytics-Tracking zumindest nach bisher vorherrschender Rechtspraxis ² 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 ³:

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

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 ⁵. Außerdem zeigt sich Google neueren Berichten zufolge auch sehr bemüht, weitere Unstimmigkeiten bzgl. eventuell vorhandener Datenschutzbeeinträchtigungen beizulegen ⁶. 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 ⁷.

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

• Google Analyticator,
• Web Ninja Google Analytics,
• Google Analytics for WordPress und
• Ultimate 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 ⁹:

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.