Verfahrensdokumentation für den Geocounter

Beispiellandkarte

Überblick

Das nachfolgend dargestellte Verfahrensverszeichnis zum Umgang mit den gesammelten IP-Adressen bezieht sich auf den "Geocounter", ein Dienst für Homepagebetreiber zur graphischen Darstellung der Herkunft ihrer Besucher.

Zu diesem Zweck wird eine kleine Grafik in diese Homepage eingebunden, die von geo.dianacht.de abgeholt wird. Dadurch erfährt geo.dianacht.de von jedem Besuch dieser Homepage. Diese Information wird dann zur Darstellung auf Karten wie in nebenstehenem Beispiel genutzt. Die Karte ist für jedermann abrufbar, auch der Betreiber der teilnehmenden Homepage bekommt nicht mehr zu sehen.

Die Anmeldung und das Einbinden der Zählergrafik erfolgt durch den Betreiber der teilnehmenden Homepage. Ausser der URL dieser Homepage sowie einem bei der Anmeldung eingegebenen Text für den Link zu derselben wird nichts gespeichert. Der Betreiber einer teilnehmenden Homepage, seine Mailadresse oder der Inhalt der Homepage ist hier zunächst unbekannt. Eine Besichtigung der teilnehmenden Seiten findet nur gelegentlich statt und ist keine Voraussetzung für die Funktion des Zähler.

Kommerzielle Absichten werden mit diesem Dienst nicht verfolgt, Einnahmen werden nicht erzielt. Eine Weitergabe der gespeicherten Daten an andere Stellen ist ausgeschlossen.

Widerspruch

Wer hier zukünftig nicht mehr gezählt werden will, kann seinen Browser entsprechend konfigurieren oder seinen Widerspruch per Cookie ausdrücken. Näheres findet man auf der Widerspruchsseite.

Verantwortliche Stelle

Max Berger, Kopernikusstraße 2, 85609 Aschheim, eMail: max@dianacht.de

Zweckbestimmung

Primärer Zweck und einzige Nutzung von nicht-pseudonymisierten Daten ist die Darstellung der Herkunft von Besuchern einer Homepage. Dazu werden drei Bytes (von vier) der IP-Adresse verwendet.

Pseudonymisierte Daten werden darüber hinaus auch für weitere Statistiken zu eigenen Zwecken verwendet, etwa zur regionalen Verbreitung eines bestimmten Browsers oder zur zeitlichen Darstellung der Nutzungshäufigkeit eines Betriebssystems. Nutzungsprofile einzelner Nutzer ("Das ist der User 123456, der kommt jeden Dienstag vorbei und sieht sich diese Seite an") werden weder mit echten noch mit pseudonymen Daten erstellt.

Betroffene Personengruppe und erhobene Daten

Von jedem Besucher einer hier teilnehmenden Homepage wird ein übliches Serverlog gespeichert:

Die ersten drei Bytes der IP-Adresse wird zur Lokalisierung des Besuchers verwendet, anschliessend wird die IP-Adresse pseudonymisiert. Ein Beispiel für Lokalisierung und Pseudonymisierung steht weiter unten im Text.

Empfänger dieser Daten

Die fertig ausgewerteten Daten in Form von Listen oder Landkarten mit Informationen der Art "von den letzten 200 Besuchern kamen 14 aus München" stehen jedermann offen. Auch der Betreiber der teilnehmenden Homepage hat nicht mehr Möglichkeiten. Mangels Authentifizierung bei der Anmeldung könnte sich der Betreiber hier auch nicht als solcher zu erkennen geben.

Speicherfristen

Zur Fehlersuche und Weiterentwicklung kann von der stündlichen Pseudonymisierung auch abgewichen werden. Die Speicherfrist beträgt dann maximal eine Woche. Von dieser Möglichkeit wurde allerdings seit der Einführung der Pseudonymisierung im Januar 2007 noch nie Gebrauch gemacht.

Datenübermittlung in Drittstaaten

... findet nicht statt

Eingesetzte Datenverarbeitungsanlagen

Zwei angemietete virtuelle Server bei zwei Providern. Betriebsystem ist Linux, Webserver ist Apache, einiges wird in einer MySQL-Datenbank gespeichert, den Rest machen selbst geschriebene Programme in den Sprachen C, perl, awk, bash und php.

Kernstück der Lokalisierung ist die frei verfügbare Datenbank "GeoLite City" der Firma Maxmind. Die Abfrage dieser Datenbank wird auf den beiden Servern erledigt, die Daten werden auch zur Lokalisierung nicht an Dritte übermittelt.

Zugriffskontrolle

Zugriff auf die Server erfolgt passwortgeschützt und verschlüsselt mit ssh oder https. Die Massnahmen der Provider, deren Personal und Dienstleister, sowie deren Möglichkeiten, auf die Hard- und Software und die gespeicherten Daten zuzugreifen, sind nicht bekannt.

Lokalisierung

Die Datenbank von maxmind hat IP-Adressbereichen Ortschaften zugeordnet. Die Adressbereiche umfassen in der Regel einige Dutzend bis einige Hundert IP-Adressen. Die Ortschaften haben als maximale Genauigkeit eine Gemeinde. Ortsteile, Strassen und Hausnummern werden also nicht erfasst.

Zum Beispiel ist dort erfasst, dass der Adressbereich 129.187.0.0 bis 129.187.255.255 dem Leibniz-Rechenzentrum in Garching zugeordnet ist, und dass dieses Garching bei 11.65 Ost / 48.25 Nord liegt.

Grössere Providern, etwa Arcor, weisen ihre IP-Adressen dynamisch zu, halten sich aber an regionale Grenzen. Zur Zeit wird laut maxmind bei Arcor z.B. folgende Zuweisung praktiziert:
88.66.124.0 bis 88.66.124.255 --> München
88.66.125.0 bis 88.66.125.255 --> Ingolstadt
88.66.126.0 bis 88.66.126.255 --> Landshut
88.66.127.0 bis 88.66.127.255 --> München

Diese Tabelle wird für jeden Besucher abgefragt und der Ort zu seinem Logeintrag notiert. Zuvor wird die IP-Adresse des Besuchers um das letzte Byte gekürzt. Diese Kürzung hat in obigem Beispiel keine Auswirkung (die IP-Adressen werden sowieso im 256er-Paket vergeben), kann aber bei Providern, die kleinere Netzbereiche zuteilen deutliche Unschärfen zur Folge haben.

Die Treffergenauigkeit dieser Datenbank ist recht unterschiedlich. Kleine Adressbereiche von kleineren Firmen sind häufig recht exakt. Grosse Firmen, etwa das Leibniz-Rechenzentrum, das als Provider der Münchner Universitäten mit vielen Standorten dient, werden nur in einer Gemeinde verortet. Arcor-Kunden aus obigen Bereichen, die irgendwo zwischen München, Landshut und Ingolstadt wohnen, werden einer dieser drei Ortschaften zugeordnet. Bei einigen Besuchern wird gar keine Ortschaft angegeben, z.B. bei Leuten, die mit mobilen Geräten im Internet unterwegs sind.

Weitere Möglichkeiten zur Ortung eines Besuchers, etwa mittels eines eingebauten GPS-Empfängers in seinem Smartphone oder durch Ermittlung seiner Funkzelle werden hier nicht genutzt.

Pseudonymisierung

Die IP-Adresse eines Besuchers wird im Serverlog gespeichert, aber nicht weiter ausgewertet. Nach maximal einer Stunde wird sie durch eine zufällige Kennung ersetzt. Vorher wird nach Möglichkeit der zugehörige Hostname dieser IP-Adresse ermittelt, um den Provider des Besuchers zu erfahren. Sollte der Hostname nicht ermittelbar sein, wird keine zufällige Kennung verwendet, sondern einfach die hintere Hälfte der IP-Adresse abgeschnitten.

Die zufällige Kennung zu einem bestimmten Besucher wird täglich gewechselt. Sollte also ein Besucher mehrmals innerhalb eines Tages ankommen, ist dieser Umstand erkennbar. Bei einem Besuch am nächsten Tag ist er nicht als "der von gestern" identifizierbar, sondern erscheint als neuer Besucher.

Beispiel

Angenommen, die Homepage "www.example.org" hätte den geocounter eingebaut und würde von einem Internetnutzer aus Landshut besucht. Seine IP-Adresse ist 88.66.125.10, der Hostname dazu ist "dslb-088-066-125-010.pools.arcor-ip.net". Dann erscheint in der Logdatei zunächst:

88.66.125.10 - - [18/Feb/2011:22:54:07 +0100] "GET /00001.gif HTTP/1.1" 200 16922 "http://www.example.org" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13"

Nach einer Stunde wird die Lokalisierung auf den ersten drei Bytes der IP-Adresse (das 4. wird auf 0 gesetzt) durchgeführt, der Hostname geholt und ein Teil davon durch die Zufallskennung ersetzt. Der fertige Logeintrag sieht dann so aus:

sawnejcfdc.pools.arcor-ip.net - - [18/Feb/2011:22:54:07 +0100] "GET /00001.gif HTTP/1.1" 200 16922 "http://www.example.org" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13" 12.15_48.533_DE_Landshut

Weggefallen ist also der individuellere Teil der IP-Adresse ("dslb-088-066-125-010"), der durch "sawnejcfdc" ersetzt wurde. Dafür kommt die Information "aus Landshut" dazu.

Sollte der gleiche Besucher eine Stunde später nochmal wiederkommen, werden die beiden Logeinträge genau so aussehen (ausser natürlich der Zeitpunkt). Sollte er allerdings nach einem Tag zurückkehren, sähen die beiden Einträge so aus:

88.66.125.10 - - [19/Feb/2011:11:14:07 +0100] "GET /00001.gif HTTP/1.1" 200 16922 "http://www.example.org" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13"

lcnynpjqbg.pools.arcor-ip.net - - [19/Feb/2011:11:14:07 +0100] "GET /00001.gif HTTP/1.1" 200 16922 "http://www.example.org" "Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13" 12.15_48.533_DE_Landshut

Das "sawnejcfdc" wird also durch "lcnynpjqbg" ersetzt, zwischen den beiden Zufallskennung gibt es keinen Zusammenhang, der eine Rekonstruktion der IP-Adresse ermöglicht.

Literatur

Die Vermutung, dass die IP-Adresse vor der Lokalisierung und weiteren Verarbeitung gekürzt werden muss, entnehme ich dem 24- Tätigkeitsbericht des Bayerischen Landesbeauftragten für den Datenschutz. Dass dazu eine Kürzung um 8 Bit genügt, ist z.B. die Auffassung des Hamburgischen Datenschützers, der einen Aufsatz (DuD, 12/2009 S.751) mit diesem Fazit auf seiner Seite zum Download anbietet.

Dass ein im Browser dauerhaft gespeichertes Cookie als Widerspruchsmöglichkeit genügt, entnehme ich ebenfalls der Seite des Hamburgischen Beauftragten für den Datenschutz. Für die von ihm betreuten Seiten wird eine Reichweitenmessung durchgeführt, die ihren Widerspruch ebenfalls per Cookie realisiert.(zur Pressemittelung)

Im wesentlichen orientieren sich die beiden Datenschützer an den Vorgaben des "Düsseldorfer Kreises" zur "Datenschutzkonforme Ausgestaltung von Analyseverfahren zur Reichweitenmessung bei Internet-Angeboten" vom November 2009.

Dass ein Widerspruch per Browsereinstellungen sowohl für Besucher als auch für Serverbetreiber eleganter und auch aus Sicht des Datenschutzes besser ist, ist meine persönliche Meinung, für die ich keine Quellen habe...

 

Max Berger, September 2011

 


Zaehler