Archiv für März 2010

Kleine Datenkraken: Social Bookmarking Buttons

Mittwoch, 17. März 2010

Schnell mal Problembewusstsein schaffen: Wer auf Google Analytics verzichtet, aber weiterhin Social Bookmarking Buttons a’la „AddThis“ oder „AddToAny“ in seine Homepage einbaut, hat bzgl. BDSG-Konformität leider noch nicht viel gewonnen.


Was war nochmal das Problem mit Google Analytics? Dass IP-Adressen (als personalisierte Daten) gesammelt und darüber hinaus auch noch an Dritte außerhalb europäischer Jurisdiktion herausgegeben werden. Das lässt sich nur verhindern, indem man als Website-Betreiber Google Analytics von der Website verbannt und fortan Web Analytics gar nicht mehr oder zumindest lokal und nur mit anonymisierter IP-Adresse betreibt.

Was ist aber mit diesen allüberall im Web anzutreffenden, superpraktischen “Bookmark”-Buttons?

Ein kurzer Abriss für diejenigen, die überhaupt nicht wissen, wozu die Dinger gut sind: In der Steinzeit des Internets sammelte man seine Bookmarks auf dem eigenen Computer und freute sich über seine virtuelle Schatztruhe an spannenden Websites. Natürlich konnte man eine URL mit dem Hinweis “… musst Du Dir unbedingt ansehen!” per E-Mail an Freunde weiterschicken, aber das war uncool. Zu dieser Zeit kamen “Tell-A-Friend”-Buttons in Briefumschlag-Form auf Webseiten auf, mit der man die aktuell betrachtete URL unter Angabe seiner eigenen und einer Ziel-E-Mail-Adresse bequem weiterleiten konnte. Aber das war immer noch unbequem.

Im Web 2.0, in dem sich für jede noch so abstruse Community-Idee sofort tausende Leute zusammenrotten, die das cool finden, kam dann das so genannte „Social Bookmarking“ auf. Dienste wie digg, del.icio.us, Mr. Wong und viele andere mehr dienen einerseits dazu, seine eigenen Bookmarks statt auf dem eigenen Computer immer verfügbar online im Internet zu speichern. In Zusammenhang mit der unvermeidlichen Community-Bildung, in der jeder gefriendete Buddy postwendend über die neuesten Aktivitäten informiert wird, trommelt man durch Hinzufügen eines Online-Bookmarks lesenswerte Surftipps direkt an seinen interessierten Freundeskreis weiter.

Unnötig zu sagen: Twitter, Facebook & Co. machen das, zusätzlich zu den Spezialfeatures des jeweiligen Portals, beim Posten von Web-URLs haargenau so. Und so verwundert es nicht, dass laut aktuellen Studien Facebook mitunter mehr Besucher auf bestimmte Webseiten leitet als der Suchmaschinengigant Google.


Folglich kamen auf Seiten der Webmaster der Wunsch auf, es den Besuchern der eigenen Website so leicht wie möglich machen, die gerade betrachtete Website nicht nur per “Tell-A-Friend”-E-Mail weiterzuleiten, sondern mit so wenigen Mausklicks wie möglich im eigenen Twitter- oder Facebook-Profil zu veröffentlichen. Denn: Die aktuelle URL kopieren, ein neues Browserfenster öffnen, dort zu Twitter navigieren, die URL einkopieren, den Titel der Webseite dazu tippen – das ist viel zu umständlich. Mit Hilfe der APIs der Social Bookmarking-Dienste geht das viel einfacher: Man kann z.B. einen „Add to Twitter“- und/oder „Add to Facebook“-Button auf der Homepage platzieren – dieser erledigt o.a. Handlungsfolge wie von Geisterhand mit nur einem Mausklick. Also: Einen Button für Twitter. Und einen für Facebook. Und einen für Digg. Und einen für del.icio.us. Und … und … und …

Dummerweise weiß man als Website-Betreiber nicht unbedingt, welchen Bookmarking-Dienst die Besucher bevorzugen. Und mitunter ändern sich die APIs. Es ist also ein Hase- und Igel-Rennen, um einerseits so viele derzeit hippe Social Bookmarking-Buttons wie möglich auf der eigenen Website zu versammeln, und andererseits die zugehörigen API-Anbindungen aktuell und funktionstüchtig zu halten.

In diese Bresche springen Anbieter wie die eingangs erwähnten AddThis oder AddToAny – um nur zwei der bekannteren Dienste zu nennen, es gibt derer unzählige. Die Grundidee ist simpel: Statt sich selbst um die ganzen Buttons zu kümmern, bindet man nur einen etwas größeren „AddThis”- oder „Bookmark“-Button ein – und nach Klick darauf öffnet sich ein Auswahlfenster mit den derzeit meistgenutzten Bookmark-Diensten – und Dutzenden anderen, wenn man weiter nach unten scrollt. Das Ganze ist für den Webmaster in wenigen Minuten in die eigene Website eingebettet – und vor allem kostenlos.

Dabei weiß man doch: „Hüte dich vor den Danaern, wenn sie Geschenke bringen.“


Problem dabei: Der Button liegt nicht auf dem eigenen Server, der Besucher holt also unfreiwillig Daten von einem externen Server ab. Das ist erst einmal noch kein Verbrechen – es kommt vor, dass man mal in eine Newsmeldung ein externes Bild einbettet (Obacht: Urheberrechte beachten!).

Jedoch: Sinn der Übung mit dem „Bookmark“-Button ist ja, dass er allgegenwärtig auf jeder einzelnen Seite eingebettet wird – klar, der Besucher soll ihn ja auf jeder Seite sofort anklicken können. Und hier bewegen wir uns aus extrem dünnes Eis: Ähnlich wie ein Web Analytics-Scriptlet, das auf jede einzelne Seite eingebettet wird, gelangt das fremde „Bookmark“-Scriptlet auf jede einzelne eigene Seite. Beim bloßen Laden der „Bookmark“-Grafik liefert der Besucher der eigenen Website also wiederum seine Verkehrsdaten, primär seine IP-Adresse, sekundär allerhand andere Konfigurationsdaten, bei einem wildfremden Dienst ab.

Sicher – wer liest schon Kleingedrucktes. Aber  wer es doch tut, der findet etwa in der Privacy Policy von AddThis folgenden Passus:

In addition, we collect certain information which cannot be used to personally identify any user, and which may be provided to third parties. Such non-personal data ordinarily includes non-identifiable aggregate, summary, usage data, and other behavioral data and may include, by way of example, statistics regarding total users, information regarding types of Internet browsers used by users, and behavioral usage patterns.

Aha  – AddThis betreibt im Hintergrund also Web Analytics – und gibt diese auch an Dritte weiter. Pssst … Bei AddThis kann man sich diese sogar ansehen, wenn man sich die Mühe macht, sich nicht nur ein „Bookmark“-Scriptlet für die eigene Homepage generieren zu lassen, sondern sich zu diesem Zweck einen personalisierten AddThis-Account anlegt.

Weiter im Text – direkt im nächsten Satz steht:

We also collect non-personal data about each user’s IP address to help diagnose problems with our servers, and to administer our website and Services.

Blöd nur, dass IP-Adressen ja laut aktueller Rechtssprechung bereits persönliche Daten sind. – Wohlgemerkt: Wir reden hier noch nicht einmal von den Besuchern, die den „Bookmark“-Button tatsächlich anklicken. Wer auf diese Weise Informationen über sein Surf-Verhalten in Form öffentlicher Bookmarks auf einer Web 2.0-Community preis gibt, der hat bzgl. Datenschutz und Wahrung der eigenen Privatsphäre offensichtlich eine höhere Toleranzschwelle. Betroffen sind in diesem Fall vor allem diejenigen, die mit dem ganzen Social Bookmarking eigentlich überhaupt nichts zu tun haben, aber trotzdem ungefragt und unbewusst Informationen zu ihrem Surf-Verhalten an externe Dienste abgeben.

… AddThis ist hier nur exemplarisch genannt, das Problem besteht nach genauer Ansicht der jeweiligen AGBs ebenfalls bei anderen Social Bookmark-Button-Providern.


Lange Rede, kurzer Sinn: Wer einen Social Bookmark-Button auf seiner Homepage einbaut, der zwingt seine Besucher unbewusst dazu, seine IP zusammen mit den üblichen Web Analytics Daten an den dortigen Provider abzuliefern. Wenn dieser in seinen AGBs zugibt, dass IPs gespeichert werden, am besten noch im außereuropäischen Ausland, dann ist das vor dem Bundesdatenschutzgesetz (BDSG) nichts anderes als die Verwendung von Google Analytics.

… Außer, dass Google viel größer ist und viel mehr Daten aggregieren kann. Insofern sind die Social Bookmark-Button-Provider aus meiner Sicht zwar vergleichsweise kleine, aber unzweifelhaft ebenfalls vielarmige Datenkraken.


UPDATE:

Dank Frank Koehl und seinem Artikel “Free and open source alternative to ShareThis, AddThis, AddToAny” bin ich auf iBegin Share a/k/a Enthropia Share gekommen. Ähnlich wie beim Wechseln von Google Analytics zu Piwik ist iBegin Share ein OpenSource-Tool, das lokal auf dem eigenen Webserver installiert ist – also nicht irgendwohin „nach Hause telefoniert“.

Es kann Statistiken sammeln, man kann das aber per Mausklick deaktivieren (click!). Und: Ein WordPress-Plugin liegt freundlicherweise auch direkt vor – herrlich, das war einfach! Daher sind hier bei GZB die Share-Buttons nun blau statt orange.

Die Zeit ist reif für display:inline-block

Sonntag, 14. März 2010

Ist für CSS-Formatierung die Zeit endlich reif für “display:inline-block”, mit dem sich so etwas wie das logischerweise nicht vorhandene, aber schmerzhaft vermisste “float:center” realisieren lässt? Ja, denn der letzte inkompatible Dinosaurier Firefox 2.x wird nur noch homöopathisch eingesetzt.

Laut browser-statistik.de liegt Firefox 2.0 nunmehr im Bereich von 1% – wohlgemerkt: Im Vergleich zu allen anderen firefoxoiden Gecko-Browsern – die laut o.a. Statistik rund und roh jeder 2. Surfer benutzt (yay!). Folglich ist der letzte Browser, der mit Inline-Blocks so gar nichts anfangen konnte, quasi ausgestorben. Internet Explorer wollen dahingehend je nach Version immer noch ein wenig gepampert werden, und je nach Statistik dürfen wir (leider) den IE6 aufgrund von 5-10% Gesamtmarktanteil immer noch nicht ignorieren. Aber ich bin bereit, das letzte unbeugsame gallische Dorf von Firefox 2-Usern ab sofort zu ignorieren.

Konkretes Beispiel: Wir haben ein Reihe von Bildern, die wir zeigen wollen – bild1.jpg, bild2.jpg und bild3.jpg. Egal, ob wir ein liquides, d.h. variabel breites oder  was sonst für ein Webdesign auch immer verwenden wollen: Es wäre schön, wenn man die Bilder (man verzeihe meine Wortwahl) einfach nebeneinander klatschen und den umgebenden Container einfach zur Zentrierung überreden könnte. Beispiel 1:

<div style=”text-align:center;”>
<img src=”bild1.jpg” />
<img src=”bild2.jpg” />
<img src=”bild3.jpg” />
</div>

So weit, so einfach. Das funktioniert deshalb, weil Bilder inline formatiert werden, d.h. sie sind im weitesten Sinne “große Buchstaben”. Wird das Browserfenster zu schmal (bei mehr als 3 Bildern keine Seltenheit), bricht die Bildfolge um und das nächste Bild landet wiederum zentriert in der nächsten Reihe untendrunter. Ist die Anzahl der Bilder dynamisch (z.B. im CMS), packt man einfach eins neben das andere – und das Design (egal ob mit fluider oder fester Breite) kümmert sich um den Rest.

Aber was, wenn wir nun Bildunterschriften unter den Bildern haben wollen? Dummerweise ist das alles andere als trivial. Holzhammer-Methode eins: Eine fette Tabelle mit zwei Zeilen. (Kids, never try this at home!) Beispiel 2:

<div style=”text-align:center;”>

<table style=”margin:0px auto;”>
<tr>
<td><img src=”bild1.jpg” /></td>
<td><img src=”bild2.jpg” /></td>
<td><img src=”bild3.jpg” /></td>
</tr>
<tr>
<td>Bild 1</td>
<td>Bild 2</td>
<td>Bild 3</td>
</tr>
</table>

</div>

Holzhammer-Methode zwei, damit die jeweils zueinander gehörigen Texte zumindest halbwegs in der Nähe der betitelten Grafik stehen. (Kids, depending on how bad the neighborhood is, you’ll end up in jail, crucified, or crucified head-down when you do something like that. So – don’t.) Beispiel 3:

<div style=”text-align:center;”>

<table style=”margin:0px auto;”>
<tr>
<td>
<table style=”margin:0px auto;”>
<tr><td><img src=”bild1.jpg” /></td></tr>
<tr><td>Bild 1</td></tr>
</table>
</td>
<td>
<table style=”margin:0px auto;”>
<tr><td><img src=”bild2.jpg” /></td>
</tr><tr><td>Bild 2</td></tr>
</table>
</td>
<td>
<table style=”margin:0px auto;”>
<tr><td><img src=”bild3.jpg” /></td></tr>
<tr><td>Bild 3</td></tr>
</table>
</td>
</tr>
</table>

</div>

Beide Tabellenlösungen haben den Nachteil, dass sie keinesfalls fluide sind.

Sprich: Wird das Browserfenster zu schmal, erscheint ein Scrollbalken. Ist die Anzahl der Bilder dynamisch, muss sich das CMS Gedanken über die verfügbare Breite machen und immer neue Tabellen erstellen. Nein, nein – und nochmals nein.

Zurück zum eigentlichen Problem: Warum haben wir eigentlich kein Blockelement, das sich inline verhält wie ein Bild? Also sowas in der Art (ja, das geht sicher eleganter – das ist ja hier auch nur ein grobes HowTo). Beispiel 4:

<div style=”text-align:center;”>
<div><img src=”bild1.jpg” /><br/>Bild 1</div>
<div><img src=”bild2.jpg” /><br/>Bild 2</div>
<div><img src=”bild3.jpg” /><br/>Bild 3</div>
</div>

Gute Idee – funktioniert aber nicht.

Denn die inneren Divs erstrecken sich über die volle Browserbreite – und ein Div ist ein Blockelement, das einen Zeilenumbruch erfordert.

Beispiel 5: Selbst wenn wir die inneren Divs schmaler machen …

<style>
<!–
.bild { width:150px; }
–>
</style>

<div style=”text-align:center;”>
<div class=”bild”><img src=”bild1.jpg” /><br/>Bild 1</div>
<div class=”bild”><img src=”bild2.jpg” /><br/>Bild 2</div>
<div class=”bild”><img src=”bild3.jpg” /><br/>Bild 3</div>
</div>

… hilft uns das immer noch nichts: Auch die schmalen Divs sind Blockelemente. Sie stehen untereinder – und außer im IE kleben sie nun trotz umgebendem “text-align:center” in vielen anderen Browsern links am Rand.

Lassen wir die Jungs doch “floaten” – Beispiel 6:

<style>
<!–
.bild { width:150px; float:left; }
–>
</style>

vorher

<div style=”text-align:center;”>
<div class=”bild”><img src=”bild1.jpg” /><br/>Bild 1</div>
<div class=”bild”><img src=”bild2.jpg” /><br/>Bild 2</div>
<div class=”bild”><img src=”bild3.jpg” /><br/>Bild 3</div>
</div>

nachher

Die Reihenfolge stimmt – aber so links und nicht zentriert ist auch nicht schön, und überhaupt gibt es Stress mit nachfolgenden Elementen.

Psst … “float:right” macht die Sache nicht besser. Beispiel 7:

<style>
<!–
.bild { width:150px; float:right; }
–>
</style>

vorher

<div style=”text-align:center;”>
<div class=”bild”><img src=”bild1.jpg” /><br/>Bild 1</div>
<div class=”bild”><img src=”bild2.jpg” /><br/>Bild 2</div>
<div class=”bild”><img src=”bild3.jpg” /><br/>Bild 3</div>
</div>

nachher

Dabei verkehrt sich dann auch noch die Reihenfolge, weil die Bilder der Reihe nach von rechts nach links schweben – das ist Quatsch mit Soße.

Wie schön wäre also, wenn wir die inneren Divs ohne Floats mit “display:inline-block” dazu zwingen könnten, sich wie unbeschrifteten Bilder zu verhalten. Obacht: Firefox, Safari und Opera können das in der Tat – aber nicht der Internet Explorer. Dort gilt: Ein Blockelement kann man nicht nachträglich dazu zwingen, sich wie ein Inline(-Block)-Element zu verhalten.

Dann also andersrum: Man nehme ein Inline-Element, das wir zum Blockelement umfunktionieren – also “span” statt “div”. Beispiel 8:

<style>
<!–
.bild { display:block; width:150px; }
–>
</style>

<div style=”text-align:center;”>
<span class=”bild”><img src=”bild1.jpg” /><br/>Bild 1</span>
<span class=”bild”><img src=”bild2.jpg” /><br/>Bild 2</span>
<span class=”bild”><img src=”bild3.jpg” /><br/>Bild 3</span>
</div>

Das sieht haargenau selbstredend (und absichtlich) haargenau so aus wie die schmalen Divs in Beispiel 5.

Doch jetzt kommt der Moment, wo der Frosch ins Wasser rennt: Wir zwingen die Spans, sich wie Inline-Blöcke zu verhalten. Wir können dabei sogar auf die Breitenangabe verzichten. Beispiel 9:

<style>
<!–
.bild { display:inline-block; }
–>
</style>

<div style=”text-align:center;”>
<span class=”bild”><img src=”bild1.jpg” /><br/>Bild 1</span>
<span class=”bild”><img src=”bild2.jpg” /><br/>Bild 2</span>
<span class=”bild”><img src=”bild3.jpg” /><br/>Bild 3</span>
</div>

Das ist haargenau das, was wir wollten:

Die Bilder samt Unterschriften in den Spans stehen brav nebeneinander, das Design ist fluide bzw. (bei variabel vielen Elementen) dynamisch um beliebig viele Bilder erweiterbar, die zeilenweise umbrechen und anschließend brav zentrieren.

Das funktioniert in dieser Form ab Internet Explorer 5.5 (aktuell: 8), Firefox 3.0 (aktuell: 3.6), Opera 7 (aktuell: 10) und mit aktuellen Webkit-Browsern wie Safari und Chrome ebenfalls.

Psst … Wer es sich mit der schwindenden Firefox 2-Community nicht verscherzen will, baut noch notdürtig einen kleinen Hack ein – in etwa so. Beispiel 10:

<style>
<!–
.bild { display:inline-block; }
:root .bild { display:-moz-inline-stack; }
–>
</style>

<div style=”text-align:center;”>
<span class=”bild”><img src=”bild1.jpg” /><br/>Bild 1</span>
<span class=”bild”><img src=”bild2.jpg” /><br/>Bild 2</span>
<span class=”bild”><img src=”bild3.jpg” /><br/>Bild 3</span>
</div>

Der “:root”-CSS-Hack erreicht nur Firefox bis einschließlich 2.x – Firefox 3+ ignoriert ihn. Das Resultat (siehe Screenshot) sieht zwar nicht wirklich schön aus, funktioniert aber notfalls sogar mit Firefox 1.

Aufgrund der Statistik-Entwicklung weg von Firefox 2 postuliere ich jedoch, das wir “Web Guys” andere Sachen zu tun haben, als uns für diesen höchst seltenen Fall etwas noch Abenteuerlicheres zu überlegen.

Update: Aua – die ganzen Codebeispiele hier im Blog waren durch idiotisches Copy & Paste meinerseits fehlerhaft – die Beispiel-Listings funktionierten aber. *seufz* Sollte nun aber alles korrigiert sein.

Piwik Web-Analytics ohne IP-Speicherung

Freitag, 5. März 2010

Melde gehorsamst: Das auf blog.gerozahn.de seit geraumer Zeit eingesetzte “Piwik – Open source web analytics” speichert seit heute die IP-Adressen meiner Besucher nur noch anonymisiert – und auch alle bisher gespeicherten IPs wurden nachträglich ebenfalls erfolgreich verkürzt.

Wer die qualifizierte Fachpresse (nein, nicht Computer-Bild, vielleicht eher c’t) verfolgt, der weiß wie “Iieh-bah-bah” es in heutiger Zeit ist, IP-Adressen zu sammeln. Klar – teilweise kann man als Benutzer eines zentral administrierten Hostings-Pakets oder eines Managed Servers beim Provider seines Vertrauens gar nicht anders, denn die IPs wandern dort ja in der Regel brav in die Access Logs. Aber angesichts der heuer neu hochkochenden Diskussion hat auch dort bereits hier und da ein Umdenken eingesetzt, und einige Provider anonymisieren die Zugriffe bereits – d.h. packen keine vollständigen IP-Adressen mehr in die Logs.

Zur Erinnerung: Alles hängt ab von der Frage, ob IP-Adressen personenbezogene Daten sind oder nicht, in letzterem Fall also lediglich umständlich personenbeziehbare Daten.

Die aktuelle Rechtssprechung deutet in erstere Richtung, d.h. sie seien personenbezogen – was vor allem bei festen IPs in Universitäten oder anderen Einrichtungen absolut nicht wegzudiskutieren ist. Bei täglich wechselnden dynamischen IPs beim DSL-Connect kann man darüber streiten, ob “personenbezogen” schon gegeben ist, wenn man im Ernstfall erst den Zugangsprovider zur Nennung des jeweiligen IP-Inhabers zu gegebener Zeit überreden muss. Nichtsdestoweniger: Die Gerichte entscheiden momentan vermehrt derart, dass IPs in jedem Fall personenbezogene Daten sind. Punkt, aus – damit müssen wir nun leben.

Wer als Betreiber einer Website nun Web Analytics betreibt, also Tracker-Code in die Webseite einbettet, um mehr über seine Besucher herauszubekommen (beispielsweise so etwas Lapidares wie Browserversion und Bildschirmgröße, gern aber auch Tiefergehendes wie Nationalität, Einstiegsseite, Verweildauer, angeklickte Links, Zugriffstrail und hassenichgesehn), der kommt dadurch allzu leicht in Teufels Küche. Vor allem, wenn er dazu Google Analytics einsetzt.

Denn Google Analytics speichert IPs nicht nur – nein, diese werden sogar “außer Landes” geschafft – und zwar in die USA, die vor dem EU-Recht datenschutzrechtlich als Schurkenstaat angesehen werden müssen. Googles “Don’t be evil” hin oder her – aber dieses gebetsmühlenartig vorgetragene Mantra hilft einem mit Hinweis auf das Bundesdatenschutzgesetz (BDSG) abgemahnten deutschen Website-Betreiber leider herzlich wenig.

Erste Idee: Verabschieden wir uns doch von Google Analytics und installieren wir ein Analyse-Tool direkt auf dem eigenen Server. Das Mittel der Wahl, weil nicht nur kostenlos, sondern sogar OpenSource, ist hier ausdrücklich oben genanntes Piwik. Das ist zwar nicht ganz so schlau wie Google Analytics – aber hochentwickelt genug für die meisten drängenden Fragen, was an der eigenen Website “Hot” oder “not” ist – und vor allem, wieso. Dummerweise sammelt Piwik ebenfalls IPs – und macht in der Basiskonfiguration auch keinerlei Anstalten, diese entweder zu löschen oder zumindest zu anonymisieren.

Als brauchbare IP-Anonymisierung ist akzeptabel, wenn aus der üblichen 111.222.333.444 die hinteren beiden Nummernblöche gestrichen werden. Aus dem resultierenden 111.222.0.0 lässt sich weiterhin der Zugangsprovider und die grobe geographische Herkunft des Besuchers ermitteln. Und mit der Browserkonfiguration plus gesetztem Tracking-Cookie lassen sich wiederkehrende Besucher trotzdem hinreichend gut wiedererkennen.

Genau dieser Idee hat sich Martin Gamnitzer verschrieben. Er hat ein erschreckend simples Piwik-Plugin entwickelt, das justament o.a. IP-Verkürzung realisiert. Dem Vernehmen nach wird das Plugin in erweiterter Form sogar im Lieferumfang der kommenden Piwik-Version 0.55 enthalten sein.

Wer wie ich auf dieser Website (und von Berufs wegen auch bei einem Sack voll anderer Portale) noch die aktuelle Piwik-Version 0.54 verwendet, geht wie folgt vor:

  1. Plugin herunterladen
  2. Ins Plugin-Verzeichnis ./piwik/plugins auspacken
  3. Im Piwik-Backend aktivieren
  4. Fertig

Oder nicht?

Das ist leider nur die halbe Miete. Korrekt: Alle neuen Besucher werden ab sofort nur noch mit verkürzter und damit wirksam anonymisierter IP geloggt.

Dummerweise hilft das rein gar nichts gegen die bereits in der Datenbank befindlichen Logs. Denn bis zur Aktivierung des Plugins hat Piwik ja munter IPs gesammelt – und denkt auch gar nicht daran, diese nachträglich zu anonymisieren.

Wer Zugriff auf seine Datenbank hat, z.B. per phpMyAdmin, sollte also unbedingt die gesammelten IPs nachträglich anonymisieren. Da die IPs freundlicherweise nicht in der ASCII-Schreibweise mit den Punkten, sondern vielmehr als Vier-Byte-BIGINT-Ganzzahl gespeichert sind, hilft eine einzige MySQL-Anweisung (dabei ggf. das Prefix “piwik_” an die eigene Installation anpassen):

UPDATE piwik_log_visit
SET location_ip=(location_ip >> 16 << 16)
WHERE 1

Denn “>> 16″ verschiebt die beiden höhersignifikanten Bytes nach rechts und schneidet dabei die beiden niedrigersignifikanten Bytes ab. Aus “111.222.333.444″ wird also “0.0.111.222″.

“<< 16″ zieht anschließend die beiden nun niedrigersignifikanten Bytes wieder an ihre ursprüngliche Stelle und zieht 16 blitzeblanke Null-Bits nach. Aus “0.0.111.222″ wird folglich “111.222.0.0″.

Fertig, abputzen!