Interessant ist zudem, dass F-Secure (und andere Hersteller von Antiviruslösungen) den Installer des Trojaners bereits seit mindestens Dezember 2010 kennt, offenbar wurde dieser auf Virustotal hoch geladen. Möglich, dass hier jemand so “kompetent” war und prüfen wollte, ob das Stück Malware, welches mit dem Installer untergejubelt werden soll, von Virenscannern erkannt wird. Der Installer verseucht den Rechner exakt mit den Dateien, die der CCC untersucht hat und lag als scuinst.exe vor. SCU steht für Skype Capture Unit und dabei handelt es sich um ein Stück Software, welches von DigiTask entwickelt wurde. Der Kreis ist also geschlossen, diese Informationen liegen bereits seit 2008 vor.

F-Secure bezeichnet 0zapftis intern als Backdoor:W32/R2D2.A, sie verweisen darüber hinaus auf ein Dokument, nach dem das Zollkriminalamt Köln die Malware 2009 bei DigiTaks bestellt hat, das Auftragsvolumen betrug über 2 Millionen Euro.

DigiTask hingegen scheint nun nicht zu bestreiten, die Malware geliefert zu haben, wehrt sich allerdings gegen den Vorwurf der Inkompetenz. Zitat:

“Die Software wurde vor fast drei Jahren geliefert – das sind in der IT-Branche Lichtjahre. Es ist durchaus möglich, dass im November 2008 gelieferte Software heute nicht mehr den Sicherheitsanforderungen entspricht.”

Für mich persönlich reißt die Aussage in der Kompetenzfrage allerdings eher ein weiteres großes Loch auf. Denn wie wir alle wissen sind Lichtjahre keinesfalls geeignet, einen Zeitabschnitt zu beschreiben, es ist ein Längenmaß. Aber das nur nebenbei…

All diese Punkte erhellen die Affäre um den Staatstrojaner in jedem Fall, allmählich zeigt sich mir, wie konsequent inkompetent und vor allem offensichtlich rechtswidrig hier insgesamt vorgegangen wurde, letzteres ist ja bereits gerichtlich bestätigt. Es ist für mich auch keine Ausrede, dass nur das Vorhandensein bestimmter Funktionen nicht automatisch den Einsatz der Malware rechtswidrig machen würde. Das Vorhandensein eines internetfähigen PCs in meinem Haushalt ist ja auch ausreichend, um die Eintreibung von GEZ-Gebühren zu rechtfertigen, ob ich nun einen Internetanschluß habe oder nicht. Sicherlich nicht das beste Beispiel, aber es zeigt deutlich, was ich meine. Funktionen, deren Einsatz illegal wäre, dürfen in einem solchen Tool schlichtweg nicht enthalten sein. Zumal die Steuerung offensichtlich problemlos einen Zugriff auf die Funktionen erlaubt. Ich kann mir keinen Ermittler vorstellen der nicht der Versuchung erliegen würde, auch mal auf den Button “Festplatteninhalte anzeigen” zu klicken. Das schaffen nicht mal die Ermittler in irgendwelchen Fernsehserien…

Ich hoffe das Thema verschwindet nicht so schnell wieder vom Tisch sondern wird schön weiter geköchelt. Hier muss es in jedem Fall personelle Konsequenzen geben, die weit über das eine oder andere Bauernopfer hinaus gehen. Aber die Aussichten sind recht gut, dass hier weiterhin viele am Ball bleiben und die Affäre restlos aufklären.

Übrigens glaube ich nicht einmal ansatzweise, dass Deutschland das einzige Land ist, welches derartige Werkzeuge einsetzt. Ich denke lediglich, dass es hier bei uns zum ersten Mal aufgefallen ist. Was eben auch auf andere Weise auch wieder für Inkompetenz spricht. Und auf eine gewisse Weise bin ich wirklich froh, dass die Verantwortlichen nicht mehr Kompetenz vorweisen können…

Nachtrag: Laut Aussagen auf der Bundespressekonferenz heute soll der Auftrag des Zollkriminalamts Köln aus 2009 herkömmliche Überwachungstechnik betreffen und nichts mit dem Trojaner zu tun haben.

Nachtrag 2: Die Karte oben kann nun komplett schwarz gefärbt werden. Inzwischen hat das Bundesinnenministerium sein Dementi vom Montag zurück gezogen und eingestanden, eine modifizierte Version des Trojaners im Einsatz zu haben. Wahrscheinlich wurde da der Dateiname geändert. Mehr dazu hat die FAZ. Man kann nun wohl sagen: Beim Bundesinnenministerium wurde zunächst erst einmal gelogen und dann heute, als es nicht mehr anders ging, dann doch die Lüge korrigiert. So zumindest würde ich meinen Sohn tadeln, wenn er so agieren würde.

(Updateinformationen werden am Ende des Artikels eingefügt, 12 Updates)

Heise hat eine meiner Meinung nach hervorragende Aktion mit dem Namen “2 Klicks für mehr Datenschutz” gestartet, um die beliebten Social-Buttons von Google, Facebook und Twitter datenschutzkonform in Webseiten einzubinden. Wer sich darüber etwas umfangreicher informieren möchte, macht das am Besten direkt auf der Seite des Heise Verlages.

Heute nun hat Heise den Code für ein JQuery-Plugin unter der MIT License (http://www.opensource.org/licenses/mit-license.php) veröffentlicht, was mich nun wiederum dazu angeregt hat, schnell mal ein Plugin für WordPress zusammen zu hacken, welches diese Funktion in WordPress einbindet. Wie das am Ende aussieht, kann man ab sofort sehr gut unterhalb meiner Beiträge sehen.

Das Plugin ist noch eine recht simple Version, wahrscheinlich werde ich in den nächsten Tagen an der einen oder anderen Stelle noch ein wenig basteln. Aber es funktioniert und erleichtert all jenen die Einbindung, die sich eben nicht sonderlich gut mit dem Bearbeiten von Templates auskennen.

Die Installation ist ziemlich simpel:

• Plugin herunterladen
• Datei entpacken und den Ordner xsd_wp_socialshareprivacy komplett in das Verzeichnis “wp-content/plugins” hoch laden
• Plugin in der Admin-Oberfläche aktivieren
• Facebook App-ID besorgen und unter “Einstellungen/XSD socialshareprivacy” in Eurer Admin Oberfläche eintragen (die Beschreibung, wie Ihr die App-ID erhaltet findet Ihr dort ebenfalls)

Das war auch schon alles. Die Buttons werden jeweils unterhalb der Beiträge in der Einzelansicht angezeigt. Wichtig ist, dass ohne eine Facebook App-ID der Facebook-Button nicht angezeigt wird.

Wie man sieht ist dieser Beitrag hier recht flott herunter geschrieben, wahrscheinlich ist an der Einen oder andere Stelle noch eine Frage offen. Fragt einfach nach, ich ergänze dann diesen Beitrag im Bedarfsfall, heute Abend habe ich etwas mehr Zeit als im Augenblick Ich werde auch schauen, dass ich das Plugin kurzfristig auf der WordPress-Seite zur Verfügung stellen kann, was natürlich Installation und Updates enorm vereinfachen wird.

Sollten Probleme mit dem Plugin auftauchen dann bitte einen Hinweis in den Kommentaren hinterlassen.

Update 08.09.11: Ich habe dem Plugin noch ein paar Verbesserungen gegönnt und ein paar Schönheitsfehler entfernt, die sich gestern beim herunterhacken eingeschlichen haben.

Die Änderungen im Detail:

• Das Script wird nun minified eingebunden, spart doch eine Menge Downloadzeit
• Infotexte für die Mouseover sind in der Admin-Oberfläche frei konfigurierbar. Per default werden die Original-Texte von heise angezeigt, wer hier andere Informationen sehen möchte, kann diese Texte nun anpassen.
• Menüeintrag unter “Einstellungen” heißt nun “XSD socialshareprivacy”
• Plugin ist nun im WordPress Plugin Directory unter dem Namen XSD socialshareprivacy gelistet. Updates ab sofort dann über wordpress.org

Update 09.09.11: Die letzte Version (0.6.2) ist bereits im Plugin Directory verfügbar. Wer am ersten Tag die Version installiert hatte, die ich hier zum Download bereit gestellt hatte, deinstalliert diese am besten und installiert von dort neu, somit erhaltet Ihr dann auch regelmäßig die Updates und müsst nicht mehr selbst nachschauen.

Die letzten Änderungen betreffen in erster Linie den Code, ich habe ein wenig aufgeräumt und aus dem Quick and Dirty Code nun so langsam eine etwas elegantere Lösung gestrickt. Die Parameter werden nun nicht mehr im Header übergeben sondern auf “anständige” Weise. Ich überlege, ob ich sämtliche Optionen des JQuery-Plugins von heise in die Admin-Oberfläche einbinden soll, so ganz bin ich mit mir da noch nicht im Reinen. Würde die Administration wieder recht unübersichtlich machen wie ich finde, aber falls der Bedarf da sein sollte, kann ich mich sicherlich breit schlagen lassen…

Update 11.09.11: Version 0.6.3 beseitigt einen kleinen Schönheitsfehler im JQuery-Plugin von heise. Der iframe für Twitter war zu groß, wodurch er den Bereich unterhalb der Buttons unsichtbar überlagerte und Links z.T. unklickbar machte. Dieser Fehler wurde entfernt.

Update 15.09.11: Soeben Version 0.6.4 eingecheckt, müsste im Laufe des Tages dann als Update angezeigt werden. Die Version beseitigt einen kleinen Anzeigefehler in manchen Templates, bei dem die Buttons für Twitter und Google+ in die nächste Zeile rutschen (siehe Kommentare unter diesem Beitrag).

Update 25.09.11: Version 0.6.5 bei WordPress.org hochgeladen. Nun kann auch der beim hovern von i angezeigte Infotext bearbeitet werden, wie in den Kommentaren gewünscht wurde.

Update 25.09.11 #2: Schwupps – und schon bei Version 0.6.7 (sollte bald via Update-Funktion in WordPress verfügbar sein). heise hat eine neue Version seines JQuery-Plugins bereit gestellt (Changelog), diese ist nun implementiert. Die neuen Optionen werde ich in den nächsten Tagen in die Admin-Oberfläche meines Plugins integrieren.

Update 25.09.11 #3: Version 0.6.9.1 ist nun aktuell. Das Admin-Backend wurde etwas aufgeräumt in Vorbereitung für die Erweiterung der Optionen. .1 am Ende, weil ich noch flott einen Bug beseitigt habe, der mir zu spät aufgefallen ist.

Update 27.09.11: Soeben Version 0.7 eingecheckt, Update sicherlich in Kürze für alle verfügbar. Beschreibung der Optionen nun änderbar, außerdem habe ich den Hinweis auf mich als Plugin-Entwickler wieder aus der Infobubble entfernt… zu aufdringlich.

Update 04.10.11: Version 0.7.1 steht nun zum Download zur Verfügung und wird wie gewohnt in Kürze über die Updatefunktion ausgeliefert. Ab dieser Version verwende ich wieder eine neue Version des JQuery-Plugins (aktuell 1.2). Für den Facebook-Button ist nun keine App-ID mehr erforderlich, daher wurden die Hinweistexte und die Funktionen rund um die App-ID aus meinem Code entfernt.

Update 06.10.11: Version 0.7.2 sollte nun allen via Updatefunktion zur Verfügung stehen. Neu ist die Möglichkeit, das Plugin auch für Seiten zu aktivieren, dafür gibt es in den Einstellungen nun einen neuen Eintrag. Aber bitte beachten: Bei der Verwendung von Caching-Plugins (z.B. W3TotalCache) kann es nach dem Umschalten dieser Option (aktivieren/deaktivieren) zum Teil lange dauern, bis die Änderung auf den Seiten Wirkung zeigt. Und übrigens: Über ein paar Bewertungen auf der Pluginseite würde ich mich echt freuen

Update 08.10.11: Schon wieder eine neue Version, wieder neue Features. 0.7.3 erlaubt es nun, jeden Button nach Belieben zu de-/aktivieren. Wer also keinen Facebook-Button anzeigen mag, kann diesen nun ausblenden. Darüber hinaus ist es nun auch möglich zu bestimmen, ob die Buttons vor oder nach dem Text angezeigt werden sollen. Ich persönlich bevorzuge immer die Position am Ende des Beitrags, andere mögen das aber anders sehen. Ihr könnt das nun wählen.

Update 08.10.11: Die Mehrsprachigkeit ist fertig, das Plugin kommt in Version 0.8 nun mit deutscher und englischer Oberfläche. Noch nicht übersetzt sind die Infotexte, die werden zunächst noch in Deutsch angezeigt, daran arbeite ich noch.

“Nach eingehender technischer und rechtlicher Analyse kommt das ULD zu dem Ergebnis, dass derartige Angebote gegen das Telemediengesetz (TMG) und gegen das Bundesdatenschutzgesetz (BDSG) bzw. das Landesdatenschutzgesetz Schleswig-Holstein (LDSG SH) verstoßen. Bei Nutzung der Facebook-Dienste erfolgt eine Datenweitergabe von Verkehrs- und Inhaltsdaten in die USA und eine qualifizierte Rückmeldung an den Betreiber hinsichtlich der Nutzung des Angebots, die sog. Reichweitenanalyse. Wer einmal bei Facebook war oder ein Plugin genutzt hat, der muss davon ausgehen, dass er von dem Unternehmen zwei Jahre lang getrackt wird. Bei Facebook wird eine umfassende persönliche, bei Mitgliedern sogar eine personifizierte Profilbildung vorgenommen. Diese Abläufe verstoßen gegen deutsches und europäisches Datenschutzrecht. Es erfolgt keine hinreichende Information der betroffenen Nutzerinnen und Nutzer; diesen wird kein Wahlrecht zugestanden; die Formulierungen in den Nutzungsbedingungen und Datenschutzrichtlinien von Facebook genügen nicht annähernd den rechtlichen Anforderungen an gesetzeskonforme Hinweise, an wirksame Datenschutzeinwilligungen und an allgemeine Geschäftsbedingungen.

Das ULD erwartet von allen Webseitenbetreibern in Schleswig-Holstein, dass sie umgehend die Datenweitergaben über ihre Nutzenden an Facebook in den USA einstellen, indem sie die entsprechenden Dienste deaktivieren. Erfolgt dies nicht bis Ende September 2011, wird das ULD weitergehende Maßnahmen ergreifen. Nach Durchlaufen des rechtlich vorgesehenen Anhörungs- und Verwaltungsverfahrens können dies bei öffentlichen Stellen Beanstandungen nach § 42 LDSG SH, bei privaten Stellen Untersagungsverfügungen nach § 38 Abs. 5 BDSG sowie Bußgeldverfahren sein. Die maximale Bußgeldhöhe liegt bei Verstößen gegen das TMG bei 50.000 Euro.”

Das ULD fährt also richtig scharfe Geschütze auf, auch wenn man sich derzeit vordergründig an WebSite-Betreiber in Schleswig-Holstein wendet. Genau genommen dürfte diese Aussage auch nicht allein für Facebook gelten, auch der “+1″-Button von Google wäre hiervon betroffen und diverse andere Social-Dienste sicher auch. Besonders krass finde ich, dass man nicht allein auf die Buttons abzielt sondern auch ganz klar Fanpages bei Facebook anspricht.

Ich finde immer wieder erstaunlich, mit welcher Schärfe Landesdatenschützer gegen derartige Dinge vorgehen und wie vergleichsweise harmlos die Äußerungen beispielsweise gegen das SWIFT-Abkommen oder das Fluggastdaten-Abkommen ausfallen, die weitaus tiefer in die Persönlichkeitsrechte jedes Einzelnen eingreifen als eine lächerliche Facebook-Fanseite. Ich wünschte, das ULD würde sich vorrangig um wirklich wichtige Dinge kümmern und nicht mit solchem Aktionismus eine seriöse Tätigkeit vorgaukeln.

Update: Rechtsanwältin Nina Diercks äußert sich im Social Media Recht Blog sehr ausführlich über diese Ankündigung des ULD. Ihr Fazit: Gewissermaßen hat das ULD irgendwie Recht, aber über die Folgen mag sie im Detail derzeit nicht nachdenken, wenn sie Übelkeit vermeiden will. Verständlich, ich konnte das Nachdenken leider nicht verhindern und kämpfe nach wie vor mit der Übelkeit. Auch Udo Vetter äußert sich im law blog zu dieser Meldung und nennt die Drohungen

“…gegen alle Schleswig-Holsteiner, die Plugins von Facebook verwenden, ein Armutszeugnis für das ULD. Statt sich mit dem wirklichen Gegner Facebook anzulegen und auf Verbesserungen zu drängen, versuchen es Weichert und seine Leute über die Einschüchterung harmloser Facebook-Nutzer.“

Exakt, dem gibt es nichts hinzu zu fügen.

Die Aussage allerdings, mit der der der BSI-Mensch Jens Bender auf die Kritik und Hinweise reagiert ist schon ein wenig amüsant:

“Er räumte ein, wenn ein Benutzer “den großen Fehler” mache, den elektronischen Personalausweis länger als nötig in einem Lesegerät zu lassen, könne sich ein Angreifer im Besitz der PIN tatsächlich für ihn ausgeben, zum Beispiel bei Altersverifizierungsdiensten.”

Erinnert mich an vergleichbare Fehleinschätzungen, die ich früher recht häufig gehört habe:
“Wenn man ihn beim Sex schnell genug raus zieht, dann kann nichts passieren.”

Dass sicheres Verhüten anderes geht, hat sich inzwischen allerdings herum gesprochen.

“In that blog post, and in a technical note sent to data protection authorities the same day, we said that while Google did collect publicly broadcast SSID information (the WiFi network name) and MAC addresses (the unique number given to a device like a WiFi router) using Street View cars, we did not collect payload data (information sent over the network). But it’s now clear that we have been mistakenly collecting samples of payload data from open (i.e. non-password-protected) WiFi networks, even though we never used that data in any Google products.”

Nun, Google gesteht also ein, Fragmente der Nutzdaten von offenen WLANS, anders als zuvor angegeben, ebenfalls gespeichert zu haben. Mit anderen Worten: Wenn Google beim Scannen der WLANs auf ein ungeschütztes und unverschlüsseltes WLAN gestoßen ist, dann liegen Teile des dabei erfassten Datenverkehrs im Klartext auf irgendwelchen Datenträgern bei Google. Das ist nun im Rahmen dieser Diskussion natürlich ziemlich blöd für Google, zugegeben. Auf das “mistakenly” da im Zitat mag ich nicht groß eingehen, einerseits ist ein Versehen schon vorstellbar, aber ebenso kann man hier mit etwas bösem Willen Absicht unterstellen.

Klar ist: Google hat sich damit keinen Gefallen getan und natürlich ist das für Gegner ein gefundenes Fressen. Auch wenn sicherlich mit den Datenfragmenten, die angefallen sind, nicht all zu viel angefangen werden kann. Google wechselt einerseits mehrmals pro Sekunde die Kanäle (“our in-car WiFi equipment automatically changes channels roughly five times a second“), andererseits ist das Fahrzeug in Bewegung und somit permanent in anderen Empfangsbereichen. Was für ein Datensalat da am Ende herauskommt, kann sich sicherlich jeder vorstellen. Trotz allem ist natürlich möglich, dass sich mancher Schnipsel persönlicher Informationen in diesem Datenwust finden lässt, die Möglichkeit einer Zuordnung solcher Datenfragmente halte ich aber dennoch für ausgeschlossen und vor allem für nutzlos.

Trotz allem will Google die Daten wieder los werden (sprich: löschen) und das Ganze sinnvollerweise unter Aufsicht. “We want to delete this data as soon as possible, and are currently reaching out to regulators in the relevant countries about how to quickly dispose of it.” In der Zwischenzeit wurden die Fahrten der Street View Cars gestoppt, weiterhin sollen unabhängige Parteien die Software zum sammeln der Daten sowie die gesammelten Daten selbst sichten können.

Angesichts dieses kleinen “GAUs” sind die vorgeschlagenen und begonnen Maßnahmen sicherlich das einzig sinnvolle, was Google tun kann. Und an meinen bisherigen Ausführungen zu diesem Thema ändern die neuen Erkenntnisse auch nichts. Allerdings wird Google nun damit rechnen müssen, NOCH genauer beobachtet zu werden.

Nachtrag: Heute (warum eigentlich erst heute?) finde ich einen wirklich hervorragenden Artikel dazu, wie man versehentlich WLAN-Daten mitschneiden kann. Sehr saubere und verständliche Erklärung, was technisch beim Erfassen von WLANs überhaupt passiert (bzw. passieren muss) und warum man durchaus von einem echten Versehen sprechen kann. Und ich schließe mich dem Fazit dieses Artikels an: Die Vorgehensweise Googles beim Erkennen dieses Problems ist definitiv vorbildlich. Die meisten anderen Unternehmen hätten solch einen Vorfall schlicht unter den Teppich gekehrt und die Daten stillschweigend entsorgt. Google hat das nicht getan sondern sich im Gegenteil aktiv gezeigt und sich freiwillig ins Target der Datenschützer und Medien gestellt. Was Google nun entgegen schlägt wird jedem anderen Unternehmen, dem Fehler passieren, einfach nur eins sagen: Am besten Klappe halten und still und leise aufräumen.

Aussage unter anderem:

“Nach gegenwärtigen Erkenntnissen ist davon auszugehen, dass neben der örtlichen Erfassung, dem Verschlüsselungsstatus der Geräte, der weltweit eindeutigen MAC-Adresse auch der vom Betreiber vergebene Name (sogenannte SSID) gespeichert wurde. Bei letzterer verwenden Privatpersonen nicht selten ihre Klarnamen oder andere auf sie hinweisende Informationen. Sowohl mit Blick auf die Benutzung des eigenen Namens als auch auf die Möglichkeit, die WLAN-Netze aufgrund ihrer örtlichen Lage Bewohnern von Häusern zuzuordnen, handelt es sich um die Erfassung und Speicherung personenbezogener Daten und deren Übertragung in die USA.”

Sacken lassen, kurz drüber nachdenken und – lachen.

Entschuldigung Herr Schaar, aber das, was sie da behaupten, ist einfach nicht korrekt. Aufgrund der Tatsache, dass ein WLAN-Netz im Umfeld von einigen Häusern empfangen werden kann, kann man nur eins erkennen: Dieses WLAN-Netz ist um Umfeld von einigen Häusern empfangbar. Mehr erst einmal nicht. Auf Details hierzu gehe ich weiter unten ausführlich ein.

Zudem kann ich die Behauptung, dass die Benutzung des eigenen Namens als SSID “nicht selten” sei, aus eigener Erfahrung und Praxis nicht mal ansatzweise bestätigen. Ich habe eher festgestellt, dass dieser Umstand sogar “extrem selten” ist. Viel wahrscheinlicher als den Namen des Besitzers als SSID eines WLANs wird man Namen wie beispielsweise “FritzBOX” oder dergleichen antreffen.
Im übrigen muss ich sagen: Wer tatsächlich seinen Namen als SSID seines WLANs nutzt, kann an seinem Fenster direkt ein großes Transparent “Hier wohnt Peter Müller” aufhängen. So viel dazu.

(Unter anderem) im Heise-Forum geht es nun wieder heiß her, es wird diskutiert und auf Google eingeprügelt, dass es eine wahre Pracht ist. Und dabei werden mit Unwahrheiten und technischem Halbwissen Szenarien konstruiert, dass einem schwindelig werden kann. Ich werde versuchen, aus mancherlei Geschwurbel mal die Inhalte heraus zu ziehen und die tatsächlichen Hintergründe zu erläutern.

Behauptung 1: Google kann anhand meiner SSID und der MAC-Adresse meines WLANs meinen Routern eindeutig mit den zu mir gesammelten Daten verknüpfen.

Das ist schlicht Unsinn. Was sehe ich denn, wenn ich mit einem WLAN-tauglichen Gerät mal nach verfügbaren WLANs scanne? Ich sehe die SSID, die MAC-Adresse und den Verschlüsselungsstatus. Das wars. Was kann ich mit diesen Daten nun anfangen?

Halte ich mich innerhalb des Empfangsbereiches dieses Netzes auf, kann ich versuchen, die (wahrscheinlich vorhandene) Verschlüsselung zu knacken. Dafür benötige ich aber nicht Google, dafür setze ich mich einfach irgendwo hin und lege los. Wenn ich für lau auf Kosten der WLAN-Betreiber ins Netz will, dann werde ich das an einem Ort tun, den ich bequem erreichen kann. Heutzutage gibt es sicherlich kaum einen Platz innerhalb einer Stadt, an der ich kein WLAN finden werde.

Aber kann Google diese Daten nun eindeutig einer Person zuordnen? Um es kurz zu machen: Nein.

Selbst wenn Google bereits jede Menge Daten über den Nutzer dieses WLAN-Routers gesammelt und gespeichert haben sollte, kann es diese Daten nicht mit der SSID und der MAC-Adresse eines WLAN-Routers in Verbindung bringen. Der Grund hierfür ist ganz einfach: Weder die SSID noch die MAC-Adresse des WLAN-Interfaces werden je von Google (oder jemand anderem im Netz) gesehen. Die SSID sieht noch Euer Notebook oder Handy, danach niemand mehr. Auch die MAC-Adresse des WLAN-Interfaces wird niemals an einen Anbieter eines Internetdienstes übertragen. Um das erschöpfend zu erklären, müsste ich jetzt das OSI-Modell erläutern und von Routing erzählen, wer da etwas mehr Hintergrundwissen erlangen möchte, mag einfach den Links folgen.

Wenn überhaupt eine MAC-Adresse Richtung Provider(!) übertragen wird, dann ist das die MAC-Adresse des Interfaces, welches direkt mit dem Provider verbunden ist. Beispielsweise das DSL-Interface. Spätestens beim Provider verschwindet diese Adresse aber wieder, sie wird für das Routing nicht mehr benötigt. Hier ist dann einzig Eure IP-Adresse des externen Interfaces interessant, die hat aber mit Eurem WLAN mal überhaupt nichts zu tun, eine Zuordnung ist unmöglich.
Und Google sieht von Euch: Eure IP-Adresse. Zuzüglich der Daten, die Ihr freiwillig im Internet preisgebt.

Behauptung 2: Google kann genau feststellen, wo sich mein WLAN-Router befindet und weiß dann, wo ich wohne.

Das ist gleich 2 mal Unsinn. Ich hatte eben bereits erläutert, warum Google (oder jemand anderes) ein WLAN-Netz keiner Person zuordnen kann (solange die betroffene Person nicht so selten dämlich ist, ihren Namen samt Anschrift als SSID zu verwenden).

Um aber den genauen Standort eines WLAN-Routers zu ermitteln, müsste man schon einen Schritt weiter gehen, als Google es tut. Technisch ist das ein alter Hut, das kann prinzipiell jeder mehr oder weniger genau mit ein paar Bauteilen aus dem Elektronik-Shop theoretisch problemlos tun. Aber Google tut es nicht, wie ich gleich erläutern werde.

Zur Standortermittlung eines Signals bedient man sich einer Peilung. Um möglichst verständlich zu erläutern, wie so etwas funktioniert, werde ich jetzt mal etwas “untechnisch”.

Nehmen wir an, auf einem Hügel steht ein Turm, den man aus großer Entfernung sehen kann. Um heraus zu finden, an welcher Position sich der Turm exakt befindet, gibt es 2 Möglichkeiten.
Variante 1: Ich nehme einen GPS-Empfänger, stelle mich in den Turm und sehe dann ganz genau, wo ich mich befinde und wo somit der Turm gebaut wurde.
Habe ich keine Möglichkeit, auch nur in die Nähe dieses Turms zu gelangen, bediene ich mich der Variante 2: Dazu nehme ich wieder den GPS-Empfänger in die Hand, dazu eine Karte. Nun bewege ich mich an einen Ort, von dem aus ich den Turm sehen kann. Hier schaue ich zunächst auf meinen GPS-Empfänger und sehe, wo ich mich befinde. Das zeichne ich in eine Karte mit einem Punkt ein. Nun ziele ich mit einem Kompass auf den Turm (dieses Zielen nennt man peilen) und merke mir die exakte Richtung. Diese kann ich nun als Linie, ausgehend von meinem aktuellen Standort, ebenfalls in meine Karte einzeichnen (die rote Linie in der folgenden Skizze). Wenn ich nun in die Karte schaue weiß ich: Der Turm befindet sich irgendwo auf dieser Linie.

Jetzt fahre ich einfach ein Stück um den Turm herum und wiederhole das Ganze, in der folgenden Skizze als grüne Linie dargestellt. Und nun stelle ich fest: Die beiden Linien kreuzen sich an einem bestimmten Punkt. Dieser Schnittpunkt ist der Standort des Turms. Für noch mehr Genauigkeit wiederhole ich das ein drittes Mal (blaue Linie). Dieses Verfahren nennt man übrigens auch Dreieckspeilung.

Übertragen wir das nun mal auf ein Funknetz wie beispielsweise ein WLAN, dann bedeutet das: Neben meinem aktuellen Standort muss ich zusätzlich auch noch die Richtung feststellen, aus der das Signal eintrifft. Genau das ist bei Funkwellen aber nicht ganz trivial, dafür gibt es spezielle Fahrzeuge. Die hierbei verwendete Spezialantenne ist drehbar und kann somit die Richtung, aus der das Signal am stärksten einfällt, feststellen. Damit wäre die Standortbestimmung eines WLAN-Routers/Accesspoint möglich. Nur: Das geht nicht im Vorbeifahren, hierfür muss sich das Fahrzeug eine gewisse Zeit an einem fixen Standort befinden, um genau einpeilen zu können.

Vergleichen wir nun den Peilwagen im obigen Bild mal mit einem dieser Fahrzeuge: Klick hier. Na, irgendwo eine vergleichbare Antenne zu finden? Eben, nix da.

Nun wird einfach zur Sicherheit behauptet: Braucht Google nicht, anhand der Signalstärke können die errechnen, wo sich der Sender befinden muss. Bis auf wenige Zentimeter genau. Tjaaa…ganz falsch ist das natürlich nicht. Aber eben auch nicht richtig.

Um anhand der Signalstärke an verschiedenen Orten errechnen zu können, muss man folgende Faktoren kennen: Mit welcher Leistung sendet der Sender das Signal überhaupt aus? Und wie breitet sich das Signal in der Umgebung aus?

Letzteres weiß man, wenn man sich auf einer freien Fläche befindet und irgendwo dort steht der Sender. Dann weiß man anhand der physikalischen Gesetzmäßigkeiten, wie stark das Signal in Entfernung zum Sender abnimmt. In einer Stadt ist genau das aber unmöglich zu bestimmen. Jedes Material schirmt die Signale unterschiedlich stark ab. Denkbar ist also, dass ein Signal in 2km Entfernung stärker zu empfangen ist als aus einer anderen Richtung in 100m Entfernung. Weil sich eben bei der 2. Messung ein Gebäude dazwischen befindet, welches die Signale wesentlich stärker abschirmt, als andere. Und schon sind die Messwerte nichts mehr wert.

Wir sehen also: Die Behauptungen sind wieder einmal Blödsinn. Nur, weil man irgendwo mal etwas aufgeschnappt hat, meinen nun manche, daraus ganz schlimme Szenarien konstruieren zu können. Ich denke ich habe gezeigt, dass da mehr Paranoia als Sachverstand im Spiel ist.

Wozu benötigt nun aber Google die Daten, die beim scannen der WLANs gesammelt werden?

Die Antwort ist ganz leicht: Die gesammelten Daten ermöglichen es, eine Standortbestimmung ganz ohne GPS durchzuführen.

Wenn ich an verschiedenen Punkten immer wieder überprüfe, welche WLANs mit welcher Signalstärke empfangen werden können, dann kann ich mit diesen Daten ziemlich exakt meinen eigenen Standort bestimmen, sofern exakt diese Informationen zuvor gespeichert wurden. Jeder Punkt innerhalb einer Stadt hat ein gewisses Schema, eine Art Fingerabdruck. Ich stehe beispielsweise mit dem Notebook vor meiner Haustür und stelle fest: Hier empfange ich die folgenden 8 WLAN-Netze, jedes mit einer ganz bestimmten Signalstärke. Jetzt gehe ich 50 Meter weiter und stelle fest: Es hat sich etwas geändert. Die Signalstärke der einzelnen Netze ist anders, 2 empfange ich hier nicht mehr, dafür ist ein neues hinzu gekommen. Speichere ich diese beiden Ergebnisse zusammen mit meiner aktuellen Position ab, kann ich später erkennen, wann ich mich wieder an dieser Position befinde. Ich kann also ziemlich exakt orten, wo ich mich gerade aufhalte, unabhängig davon, ob ich einen GPS-Empfänger besitze oder nicht. Ich kann allerdings nicht feststellen, wo sich die Sender befinden. Ich weiß nur, wo ich sie empfangen kann.

Dieses Verfahren ist nicht mal neu. Diverse Smartphones nutzen es bereits seit Jahren, allen voran das iPhone. Huch, Apple macht das auch? Dann kann es ja nicht schlimm sein… *hust

Schlimm finde ich an dieser Stelle, dass Peter Schaar sich nicht mal vernünftig informiert, bevor er eine solche Pressemitteilung verfasst. Mindestens seit 2008 ist bekannt, dass die Streetview Cars auch die Handy- und WLAN-Netze erfassen. Daran war nix “heimlich”, wie man nun behauptet. Und genau mit solchen Aktionen schadet Herr Schaar in meinen Augen dem Datenschutz wesentlich mehr, als er ihm nützt. Er sorgt dafür, dass Datenschützer mehr und mehr den Ruf von Paranoikern bekommen, die außer Panik verbreiten nichts können. Und das ist bitter.

Erstaunt hat mich allerdings, dass ausgerechnet der Spiegel in diesem Zusammenhang tatsächlich mal Sachverstand bewiesen hat und nicht einfach auf den Panikzug aufspringen wollte. Kreuz im Kalender.

Update: Ah, Basic Thinking springt auf den Panikzug auf und erzählt uns etwas von “unerlaubterweise“. Jungs, Jungs, Jungs… Euch hätte ich etwas mehr Recherche zugetraut. Siehe oben: Das ist seit 2008 bekannt, also alles andere als eine plötzliche Überraschung.

Noch mehr Panikmache und technischen Unsinn findet Ihr übrigens hier, hier, hier, hier und hier (für die, die drauf stehen), wesentlich mehr Augenmaß zeigen hingegen z.B. Telemedicus und zuihitsu.

Das ist, mit Verlaub, in dieser Form zunächst erst einmal vollkommener Schwachsinn.

IP-Adressen sind für den Betreiber einer WebSite oder eines Internet-Services NICHT personenbezogen. Der Betreiber eines solchen Dienstes kann die IP-Adresse eines Nutzers keiner Identität zuordnen. Die Möglichkeit ist praktisch nicht gegeben, es sei denn, der Nutzer hinterlässt während der Verwendung einer bestimmten IP-Adresse seine persönlichen Daten. Und selbst dann ist die Möglichkeit der Zuordnung in den meisten Fällen nur von kurzer Dauer, spätestens nach 24h werden die meisten Internetnutzer mit einer komplett neuen IP-Adresse unterwegs sein. Zudem ist eine Möglichkeit der Zuordnung auch dann nicht gegeben, wenn sich mehrere Benutzer einen Internetanschluss teilen (wie zum Beispiel in Universitäten, Internetcafes, Wohnheimen, Unternehmen etc.), da in diesem Fall all diese Nutzer mit identischer Adresse unterwegs sind. Selbst in vielen Haushalten ist eine eindeutige Zuordnung nicht möglich, da sehr häufig mehr als eine Person den Internetanschluss nutzt. Selbst in der Rechtssprechung wurde diesem Umstand in der Vergangenheit wiederholt Rechnung getragen.

Allein die Möglichkeit, dass ich denn die Identität einer Person ermitteln könnte, wenn ich denn den dazu erforderlichen Rechtsweg beschreiten würde, macht aus einer IP-Adresse noch lange kein personenbezogenes Datum. Die Tatsache, dass irgendwo der 10.05.1970 gespeichert ist, macht dieses Datum auch noch nicht zu einem personenbezogenen Datum, auch wenn man anhand dieses Termins mit Hilfe einer anderen Datenbank nach Beschreiten des Rechtsweges meinen Geburtstag herausfinden kann. Zumindest nach meinem Verständnis.

Unsere obersten Datenschützer weisen in ihrem Beschluss vom 26.11.09 (pdf) auf folgende Bedingungen hin:

Personenbezogene Daten eines Nutzers dürfen ohne Einwilligung nur erhoben und verwendet werden, soweit dies erforderlich ist, um die Inanspruchnahme von Telemedien zu ermöglichen und abzurechnen. Jede darüber hinausgehende Nutzung bedarf der Einwilligung der Betroffenen.

Die Analyse des Nutzungsverhaltens unter Verwendung vollständiger IP-Adressen (einschließlich einer Geolokalisierung) ist aufgrund der Personenbeziehbarkeit dieser Daten daher nur mit bewusster, eindeutiger Einwilligung zulässig. Liegt eine solche Einwilligung nicht vor, ist die IP-Adresse vor jeglicher Auswertung so zu kürzen, dass eine Personenbeziehbarkeit ausgeschlossen ist.
(…)

Diese Bedingungen werden aus meiner technisch begründeten Sichtweise erfüllt, speziell der erste Punkt. Für Betreiber einer WebSite oder eines Online-Dienstes ist die IP-Adresse eben kein personenbezogenes Datum, wie ich weiter oben schon erläutert habe. Insofern ist der 2. Punkt meiner Meinung nach schon genau aus diesem Grund obsolet. Meine Meinung ist hier sicherlich nicht zwingend rechtsgültig, ich betrachte dies, wie schon angesprochen, rein technisch. Dass Gesetze und Rechtsprechung von realen Situationen und Bedingungen durchaus abweichen, ist sicher jedem bekannt.

Vollkommen anders sieht der Sachverhalt bei reinen Zugangsanbietern aus. Für diese ist die IP-Adresse ein persönliches Datum, da sie die Adresse unmittelbar einem Anschlussinhaber zuordnen können (mit den oben beschriebenen Einschränkungen). Paradox ist hier nun in meinen Augen, dass genau Zugangsanbieter die Daten erheben und speichern müssen, obwohl sie es laut Datenschützern nach dem TMG nicht dürften. Klarheit und Rechtssicherheit ist etwas anderes.

Leider habe ich einen Link “verlegt”, der in meinen Augen durchaus recht deutlich eine gewisse Unsinnigkeit dieser Diskussion dokumentierte. Wenn ich ihn wiederfinde, reiche ich ihn nach. Sinngemäß stand dort auf der Seite, dass in den Lizenzbestimmungen zu Google Analytics zwar eine Verbindung von IP-Adressen mit anderen Daten ausgeschlossen wird, aber ebenso die Möglichkeit einer Änderung dieser Bestimmungen bestünde. (hier noch dokumentiert von der Zeit)

Dieses Argument ist für mich der größte Unfug überhaupt. Wollte man diesem Argument folgen, dann könnte man rechtliche Bedenken gegen Alles und Jeden anmelden, da die Klausel, dass Änderungen möglich sind, in sämtlichen AGB enthalten sind, die ich zu Gesicht bekommen habe.

Es gibt jede Menge weitere Argumente, die deutlich zeigen, wie unsinnig dieser Vorstoß gegen die Anbieter von Analysewerkzeugen ist. Ein Beispiel wären die häufig angesprochenen Logfiles, die jeder Webhoster anlegt. Laut Datenschützern ist die Speicherung der IP-Adressen in Logfiles nicht zulässig, laut verschiedenen Gerichtsurteilen ist der Hoster jedoch dazu verpflichtet. Was ist nun korrekt? Wer hat Recht?

Spinnt man das Thema zu Ende, wird bald Schluss sein mit dem Einbetten von Youtube-Videos oder Flickr-Fotos. Da drüben wird ja getrackt, das ist evil, haben wir ja gerade gelernt. Was sonst noch auf uns zukommen könnte, will ich mir mal gar nicht ausmalen.

Ich persönlich gewinne in letzter Zeit verstärkt den Eindruck, dass die Datenschützer gern solche Dinge heran ziehen, um eine gewisse Notwendigkeit ihrer Funktion an sich unter Beweis zu stellen (wobei ich die Notwendigkeit an sich ja nicht einmal in Frage stelle). Aber mich beschleicht immer mehr der Eindruck, dass mit solchem Gepolter wie aktuell rund um die Tracking-Dienste und speziell rund um Google Analytics nur davon abgelenkt werden soll, dass an anderen Stellen wie beispielsweise beim SWIFT-Abkommen Totalversagen an der Tagesordnung ist. Wären da auch nur ansatzweise die Bestimmungen angemahnt und durchgesetzt worden, die man einem Betreiber einer popeligen Internetseite auferlegen will, hätte Deutschland gegen das Abkommen stimmen müssen. Wir wissen, dass es nur zur Stimmenthaltung reichte…

Aber zurück zu den Trackingdiensten.

Ich werde natürlich keinesfalls irgendeine Empfehlung aussprechen, jeder Betreiber eines Online-Dienstes sollte da selbst entscheiden, wie er nun reagieren wird. Ich selbst weiß es im Augenblick auch nicht und ich bin mir auch nicht ganz sicher, ob hier einfach nur mal wieder sehr heiß gekocht und anschließend lauwarm gegessen wird. Die Diskussion an sich zeigt mir aber, wie realitätsfremd hier von Theoretikern argumentiert wird und wie widersprüchlich die deutsche Rechtslage wieder einmal ist. Und ich muss eingestehen, dass mir solche Diskussionen mehr und mehr auf den Zeiger gehen, weil wir damit wieder einmal der Lächerlichkeit preisgegeben werden. Datenschutz ist sicherlich auch in meinem Interesse, keine Frage. Welche Stilblüten das allerdings inzwischen treibt, ist ganz sicher nicht mehr normal.

In meinen Kommentaren verwies dann jemand auf das WordPress Plugin 123 AntiVDS 0.10, welches verhindert, dass eMail-Adresse, Name und IP-Adresse eines Kommentators gespeichert werden. Es wird einfach ein leerer String in die Datenbank geschrieben und gut ist. Schon mal nicht schlecht.

Stefan verweist in seinem Beitrag aber auch auf die Notwendigkeit, gewisse Störer erkennen zu können und schnell sämtliche Beiträge dieser Leute zu finden, wenn sie beispielsweise nachts aus Langweile das Blog vollmüllen. Ohne gespeicherte IP-Adresse in dieser Form unmöglich.

Ein Kompromiss wurde in Stefans Kommentaren auch vorgschlagen: Statt der IP-Adresse einfach einen Hash-Wert speichern. Es befindet sich dann keine IP-Adresse mehr in der Datenbank und der Blogger hat dennoch die Möglichkeit, Kommentare (bei gleichbleibender IP-Adresse) einem Kommentator zuzuordnen. Was für den Fall, den Stefan beschreibt, ausreichen sollte.

Genau das mach nun mein Mini-Plugin Hash Comment IP, welches ich mir gestern mal fix gestrickt habe und das seitdem hier Verwendung findet. Es hat keinerlei Einstellungsmöglichkeiten, einfach nur den entpackten Ordner in Euer WordPress Plugin-Verzeichnis kopieren, das Plugin aktivieren und fertig. Für sämtliche Kommentare wird dann ab sofort nur noch ein Hash-Wert statt der IP-Adresse gespeichert.

Hinweis: Bereits in der Datenbank gespeicherte IP-Adressen bleiben davon ausgenommen, sie werden (noch) nicht nachträglich durch einen Hash-Wert ersetzt!

Download Version 0.1

Stefan Niggemeier nutzt WordPress. Wer WordPress kennt weiß sicherlich, dass WordPress von Haus aus die IP-Adressen der Kommentatoren speichert. Man kann durchaus die Pflicht, beim Schreiben eines Kommentares Name und eMail-Adresse zu hinterlegen deaktivieren, aber mir ist keine Funktion bekannt, die auch die Speicherung der IP-Adressen deaktiviert. Möglich, dass so etwas mit einem Plugin nachrüstbar ist, ich kenne allerdings im Augenblick keins.

Neben der Tatsache, dass ausgerechnet Stefan Niggemeier ein solches Schreiben in seinem Briefkasten findet (ihm wurde vor Gericht ja schließlich klar gemacht, dass er für unzulässige Kommentare seiner Besucher haftet) finde ich interessant, dass man auf diese Weise mit einer schlichten anonymen Anzeige so ziemlich jeden Blogger gegen die Wand fahren lassen kann. Und nicht nur das – so ziemlich jeden Betreiber einer WebSite kann man auf diese Weise ganz simpel ans Bein pinkeln. Denn IP-Adressen werden (fast) überall gespeichert, zudem wurde wiederholt verneint, dass es sich bei IP-Adressen um personenbezogene Daten handelt. Als ein Beispiel für die Speicherung der IP-Adressen darf zum Beispiel die WebSite des Deutschen Bundestages herhalten, dort steht es auch in den Datenschutzhinweisen, dass die IP-Adressen der Besucher für 24h gespeichert werden. Würde ich mich jetzt durch ein paar weitere Seiten wühlen, fände ich unzählige weitere Beispiele. Denn die Speicherung ist letztlich Standard. Jeder Webserver speichert die IP-Adressen der Besucher in einem Log, schon immer. Man könnte somit auf einen Schlag nahezu alle deutschen Betreiber von Webservern/Webseiten/Blogs aus dem Verkehr ziehen bzw. um 50.000 Euro erleichtern. Möglicherweise eine interessante Methode, um die Haushaltskassen wieder etwas aufzufüllen…

Als Begründung, weshalb bspw. IP-Adressen nicht gespeichert werden dürfen, wird angeführt, dass es sich hierbei um personenbezogene Daten handelt. Interessant ist in diesem Zusammenhang jedoch folgender Abschnitt in einem Datenschutz-FAQ:

Das Datenschutzrecht fordert für die Personenbezogenheit von Daten, dass die Person, der die Daten zuzuordnen sind, ohne übermäßigen Aufwand „bestimmbar“ ist. Wer nicht als Provider unmittelbaren Zugriff auf die Zuordnung der IP-Adressen zu bestimmten Nutzern hat, hat keine realistische Möglichkeit, die Identität des jeweiligen Nutzers anhand der IP-Adresse festzustellen. Dies spricht dafür, IP-Adressen – ob statisch oder dynamisch – nur im Ausnahmefall als personenbezogene Daten anzusehen.

Wann ein solcher Ausnahmefall eintritt, steht da allerdings nicht.

Spannend finde ich angesichts solcher Fälle immer wieder, dass das Internet von unseren Politikern als “rechtsfreier Raum” bezeichnet wird. Ich kenne kaum einen anderen Bereich des öffentlichen Lebens, der in Deutschland DERART reglementiert ist wie das Internet und wo immer wieder (und immer häufiger) solche und ähnliche Ereignisse geschehen. Angesichts derartiger “Rechtsfreiheit” entsteht bei mir und anderen immer mehr der Eindruck, dass es besser ist, das Internet als passiver Konsument zu nutzen statt selbst irgendwelche Dinge zu veröffentlichen. Aber genau das ist möglicherweise gewollt.

Nachtrag: In den Kommentaren zu diesem Beitrag wurde ein WordPress-Plugin genannt, welches die Speicherung von Name sowie Mail- und IP-Adresse zu einem Kommentar verhindert. Außerdem gibt es nun auch ein Mini-Plugin von mir, welches statt der IP-Adresse einen Hash-Wert in der Datenbank speichert: Hash Comment IP.

Versteht mich nicht falsch, ich will jetzt hier keine Lanze für Google brechen, aber ich finde es gelinde gesagt erschreckend, welche Paranoia gepaart mit absoluter Ahnungslosigkeit und Sensationsgier hier zu den unmöglichsten, sachlich einfach falschen Aussagen führt. Deshalb will ich, basierend auf meinen gestrigen Untersuchungen, mal einige falsche Aussagen richtig stellen. Ich werde hier allerdings keinen der Beiträge verlinken, die diese vollkommen haltlosen Aussagen verbreiten.

Aussage 1: Chrome sendet meine eMail-Adresse an Google-Server.

Falsch! In keinem meiner Mitschnitte war auch nur ansatzweise eine Mailadresse zu finden. Ich habe gezielt verschiedene Online-Formulare ausgefüllt (und die dort verwendeten Adressen dann natürlich auch im HTTP-Stream gesehen, sofern die Formulare nicht per SSL übermittelt wurden), darüber hinaus jedoch nichts dergleichen finden können.

Aussage 2: Chrome übermittelt alles, was ich in die Adresszeile tippe, an Google-Server.

Diese Aussage ist nur halb wahr. Richtig ist: Chrome sendet sämtliche Eingaben in der Adresszeile an die voreingestellte Suchmaschine. Und das auch nur dann, wenn die Autosuggest-Funktion aktiviert ist! Ja, es ist ungeschickt, diese Funktionalität als Opt-Out zu gestalten, also in der Grundeinstellung aktiv zu lassen. Allerdings, und da werden mir sicherlich viele zustimmen, das ist es nun mal, was Otto-Normaluser wünscht. Falsch ist definitiv, dass Chrome diese Eingaben immer an Google-Server übermittelt. Die Anfragen werden in jedem Fall nur an die Suchmaschine übertragen, die als Standard eingestellt wurde (bei der Installation wird da auch nachegefragt). Stelle ich hier Yahoo ein, ist keine Kommunikation mehr mit Google-Servern zu sehen, dafür plötzlich jede Menge Verkehr mit Yahoo-Servern. Logisch, wie sollte solch eine Funktion auch anders realisiert werden? Hier aber zu behaupten, alles was man eintippt, landet bei Google, ist sachlich einfach nicht richtig.

Im übrigen passiert exakt das gleiche, wenn man Firefox nutzt. Nicht bei der Eingabe im Adressfeld (hier greift der Firefox ja auf die Browser-Historie zu), aber bei der Eingabe im Suchfeld. Auch hier gehen exakt die gleichen Anfragen übers Netz – zur voreingestellten Suchmaschine.

Verwendet man die Auto-Vervollständigen-Funktion im Chrome, dann wird die letzte, endgültige Eingabe NICHT mehr an die eingestellte Suchmaschine gesendet.

Aussage 3: Google speichert meine Surf-Historie auf seinen Servern.

Ebenfalls vollkommen falsch! Um dies zu realisieren, müsste jeder angeklickte Link zu einem der Google-Server übertragen werden, anderenfalls entgingen Google Unmengen an besuchten Seiten. Dies geschieht jedoch faktisch nicht. Wie in 2. bereits beschrieben, werden lediglich Anfragen an die voreingestellte Suchmaschine gesendet, wenn man etwas in die Adresszeile eintippt und die Autosuggest-Funktion noch aktiv ist.

Aussage 4: Google sendet mit jeder meiner Anfragen eine Identifikationsnummer, anhand derer der Browser eindeutig zu identifizieren ist.

Falsch! Googles eindeutige Identifikationsnummer wird lediglich bei Update-Check durch den GoogleUpdater gesendet. In keiner weiteren Anfrage von Chrome konnte ich sie entdecken. Im übrigen, wie bereits geschrieben: Firefox macht exakt das gleiche (und nahezu jede andere Software auch). Siehe unter anderem auch hier und hier.

Also: sicherlich ist es schön zu sehen, dass das Bewusstsein für Privacy und Datensicherheit steigt. Keine Frage, vor nicht all zu langer Zeit sah das noch vollkommen anders aus. Es ist allerdings nicht mal im Ansatz hilfreich, aufgrund vollkommen falscher Behauptungen eine Hysterie zu erzeugen, so etwas gibt über kurz oder lang sämtliche Bemühungen in dieser Richtung der Lächerlichkeit preis. Denn es ist tatsächlich erschreckend zu sehen, wie uninformiert viele hier in die Diskussion einsteigen: Ein Löwe brüllt es falsch vor (ja, manche Löwen gestehen es selbst immer wieder ein, von der Technik nicht wirklich viel Ahnung zu haben) und die ganzen Kojoten heulen es nach. Sorry, das hilft auf keinen Fall dabei, eine sachliche Diskussion zum Thema zu führen.

Allerdings muss ich feststellen: Auch das ist wieder nur Show ohne Substanz. Ich finde weder private PGP-Schlüssel, noch Zugangskennwörter für seine Online-Profile und eMail-Konten oder PINS für Scheckkarten oder ähnliches.

Also auch in diesem Fall wird wieder die Hälfte verheimlicht, Pfui Thomas! Auch Du bist ein Fall für den Bundestrojaner!

studiVZ hat heute um 12 Uhr einen Phishing-Angriff bemerkt und erfolgreich abgewehrt. Um die Datensicherheit von studiVZ für die Nutzer zu gewährleisten wurde die Seite offline geschaltet. Die Seite ist im Laufe des Abends wieder online.

Heute nun findet man dort einen neuen Beitrag “studiVZ Seite offline” und darin die folgende Meldung (Hervorhebung durch mich):

Wir haben einen weiteren XSS-Angriff auf unsere Seite entdeckt. Vorsichtshalber sind wir deshalb offline.

Bisher war (offiziell zumindest) noch nie die Rede von einem XSS-Angriff bei StudiVZ. Wie man oben deutlich lesen kann, war von einem Phishing-Angriff die Rede. Aber zumindest bestätigt man bei StudiVZ damit indirekt die bisher bekannten Gerüchte. Warum man aber nicht einfach mal jemanden die Meldungen schreiben lässt, der sich ein wenig auskennt, ist mir unbegreiflich. Ich hoffe jedoch nicht, dass man diese Entdeckung von Don Alphonso als XSS-Angriff bezeichnet… Das wär dann wirklich peinlich.

Bei der Volkszählung hagelte es noch Klagen und Proteste, damals gab es jedoch noch nicht die Möglichkeiten wie heute, personenbezogene Daten zu erfassen und zu verbinden. Warum stört es jetzt so gut wie niemanden? Interessiert es in Zeiten von Payback und StudiVZ eigentlich keine Sau mehr, was mit den persönlichen Daten geschieht?

Nun, es wär zumindest nicht das erste Mal, dass ein “Social Network” (bzw. die Nutzer) von einer Cross-Site-Scripting-Attacke betroffen ist: wir erinern uns an myspace. Aber, sollten die Aussagen zutreffen, die in dem folgenden Zitat eines Kommentators bei YAMB.BETA2 zu lesen sind – dann hätten sich wohl all die Warnungen und Befürchtungen der letzten Tage bewahrheitet. Sollte es wirklich so abgelaufen sein, wie es hier beschrieben wurde, wäre das ein heftiger Schlag ins Gesicht für die Betreiber und Entwickler von StudiVZ. Derartige Lücken dürfen einfach nicht auftreten, hier wurden augenscheinlich grundlegende Regeln bei der Entwicklung missachtet und die überdeutlichen Hinweise in letzter Zeit ignoriert.

Hier nun der eben erwähnte Kommentar:

XSS-Wurm!

Derzeit scheint es eher so, alsob die Notbremse wegen eines XSS-Wurmes gezogen wurde, welcher sich automatisch ueber die Pinnwand als Link verteilt hat
Sobald auf diesen Gruppenlink geklickt wurde, wurde die E-Mailadresse des aktuellen Users auf eine nicht oeffentliche Pinnwand geschrieben und die Loginseite angezeigt. Das hier angegebene Passwort wurde ebenfalls auf die Pinnwand geschrieben, der User wurde auf die Gruppe “Datenschutz im StudiVZ” weitergeleitet.
Gleichzeitig lief das Skript im Hintergrund weiter, fragte die Freundesliste ab und begann damit die Pinnwaende der Freunde mit einem aus Bloecken zusammengewuerfelten Text zu beschreiben “Hallo *vorname*, schau Dir mal die Gruppe an… *url* Gruss, *vorname des users*”. Da sich das Skript zwischen Browser und Web legte (als Man-in-the-middle) und die geklickten Links per XMLHttpobj abfragte und darstellte, ist/war es moeglich, dass es im Hintergrund weiterlief und sich somit effektiver verbreiten konnte.

Bis um 11:55 der Customer Support ebenfalls auf die Gruppe klickte – 4 Minuten spaeter stand “Kaffeepause” – weitere 2 Minuten spaeter wurde der Stecker gezogen.

Ich denke eher dass _dies_ der Grund fuer den “Ausfall” ist. Ein feiner Web2.0 Wurm/Virus, der im Browser des Besuchers und mit dessen angemeldeter Session lief, das JavaScript wurde ueber den im Titel nicht geparsten Gruppennamen eingefuegt.

Web2.0, viralen Marketing,
Wurm2.0, virale Verteilung

Ein Beispiel von der Pinnwand (Emailadresse von mir verschleiert,Passwoerter vom Wurm direkt – er ist nicht destruktiv gebaut-):

mail|1164558979|BTjk8z|thommybee@xxx
data|1164559219|5wn3jL|2904F****
mail|1164559217|5wn3jL|timonschroeter@xxx
mail|1164559778|Xg586z|m.stoeckemann@xxx
data|1164560080|Skw2Lz|bil****
mail|1164560069|Skw2Lz|hendrik-7-schulze@xxx
data|1164559857|n7SRkg|c****
mail|1164559854|n7SRkg|christian.schumacher@xxx

Hm.. ein Grund den Stecker zu ziehen?

StudiVZ – wann lernt ihr es endlich?

Schoen Gruss,
“Juergen Kuester”

Update: Vor 2 Minuten haben die Macher von StudiVZ nun ein Statement abgegeben. In ihrem Blog heißt es jetzt:

Alles wird gut

Liebe studiVZler,

liebe Blogger,

studiVZ hat heute um 12 Uhr einen Pishing-Angriff bemerkt und erfolgreich abgewehrt. Um die Datensicherheit von studiVZ für die Nutzer zu gewährleisten wurde die Seite offline geschaltet. Die Seite ist im Laufe des Abends wieder online.
Euer studiVZ Team

Ich werde das jetzt NICHT kommentieren.