Artikel-Schlagworte: „IP“

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.

Schlagworte:, , , , , , , , , , , , , , , , , , , , , , , , ,
Veröffentlicht in Gesellschaft und Politik, Technik - IT - Computerkrams | 6 Kommentare »

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!

Schlagworte:, , , , , , , , , , , , , , ,
Veröffentlicht in Gesellschaft und Politik, Technik - IT - Computerkrams | 1 Kommentar »

Halbdynamische Netzwerkkonfiguration für und mit Debian Etch

Montag, 16. November 2009

Manchmal muss es einfach von hinten durch die Brust ins Auge gehen. Folgender Anwendungsfall:

Man nehme einen Debian Etch-basierenden LAMPP-Server, der für diese Funktion seit geraumer Zeit eine statische IP besitzt, die allen relevanten Clients mit Hilfe eines Eintrages in der /etc/hosts bzw. C:\winnt\system32\drivers\etc\hosts bekannt ist. Alles easy, alles Roger.

Bis – ja, bis mit unterschiedlichen Routern experimentiert wird, die mit wechselnder DHCP-Verantwortlichkeit mal einzeln, mitunter aber auch beide gleichzeitig im LAN hängen … dann natürlich zwingend mit unterschiedlichen IPs. Das verursacht keinem der DHCP-basierenden Clients jedweder Betriebssystem-Schubladen auch nur eine Spur von Ungemach: Neu booten oder auch nur die DHCP-Lease erneuern – und schon sind die Einträge für Standard-Gateway und DNS-Proxy korrekt.

Lediglich der Etch-LAMPP ist unzufrieden. Schließlich ist sein bisheriges Standard-Gateway und DNS-Proxy nach dem Routerwechsel nicht mehr erreichbar, oder zumindest unkooperativ – und das knarzt im Getriebe.

Eine pure DHCP-Konfiguration ist schnell gemacht: http://wiki.debian.org/NetworkConfiguration erklärt, dass man dazu in /etc/network/interfaces lediglich folgendes eintragen muss:


auto eth0
iface eth0 inet dhcp

Funktioniert auch prima – außer, dass die im LAN bekannte statische IP des LAMPPs nicht mehr funktioniert … Klar, der DHCP-Server hat der Kiste ja eine IP aus dem Pool der dynamische verteilten IPs zugeteilt, und die alte, bewährte IP ist nun stumm.

Also zurück zur statischen IP – nicht schwierig, stattdessen einfach folgendes schreiben:


iface eth0 inet static
address 192.168.42.2
netmask 255.255.255.0
gateway 192.168.42.254
dns-nameservers 192.168.42.254

Der aufmerksame Leser erkent, dass 192.168.42.254 den Router und DNS-Proxy bildet. Dessen IP statisch einzutragen wollten wir doch aber eigentlich ausdrücklich vermeiden, weil doch mal der .254, mal der .253 läuft, je nach Tageslaune bzw. Experimentiergeist des Hobby-Admins. *kopfkratz*

Gesucht ist also eine halbdynamische Konfiguration, bei der der LAMPP eigenverantwortlich eine feste IP verwendet, unter der er auch zu erreichen ist, er aber trotzdem irgendwie per DHCP das Standardgateway ermittelt. Wie geht das denn nur?

Des Rätsels Lösung: Wir verpassen dem Netzwerkinterface einen Alias – anders gesagt: eine gespaltene Persönlichkeit. Zusätzlich zum regulären eth0, das sich beim DHCP-Server mit einer dynamischen IP und anderen relevanten Details des LANs versorgen darf, bekommt es nun den Alias eth0:1 verpasst – und dieser bekommt die altbekannte statische IP zugewiesen. In der /etc/network/interfaces liest sich das so:


auto eth0
iface eth0 inet dhcp


auto eth0:1
iface eth0:1 inet static
address 192.168.42.2
netmask 255.255.255.0

Kommentiert: Der erste Block definiert wie gehabt die vollautomatische Konfiguration von eth0 via DHCP. Der zweite Block erstellt und konfiguriert dem Interface den Alias eth0:1 und weist ihm statisch eine zweite IP zu. Das Eintragen statischer IPs hinsichtlich Gateway und DNS-Proxy ist somit vollkommen unnötig.

Nach dem Reboot liefert ifconfig dann erfreulicherweise folgendes (gekürzt):


eth0 Protokoll:Ethernet Hardware Adresse 00:0C:29:54:43:A3
inet Adresse:192.168.42.22 Bcast:192.168.42.255 Maske:255.255.255.0
...
eth0:1 Protokoll:Ethernet Hardware Adresse 00:0C:29:54:43:A3
inet Adresse:192.168.42.2 Bcast:192.168.42.255 Maske:255.255.255.0

Quod erat demonstrandum: Dieselbe MAC-Adresse – die .22 kommt dynamisch vom DHCP-Server, die .2 aus der statischen Konfiguration. Und das Wichtigste: Der Webserver reagiert wieder brav unter Angabe der .2 bzw. unter dem per Hosttabelle(n) bekannten Hostnamen.

… Ich gehe davon aus, dass das mit Lenny auch funktionieren dürfte. Praxistauglich getestet ist o.a. Konfiguration allerdings mit Etch.

Schlagworte:, , , , , , , , , , , , ,
Veröffentlicht in Technik - IT - Computerkrams | Keine Kommentare »