datensal.at

Ok, halt... stop! Datensammelwut, Panik. Wo ist jetzt genau das Problem?
Jetzt weiß man doch sofort, wo die Kacke am Dampfen ist und man kann vorsorglich - tja, was denn eigentlich? Am besten gleich zu Hause bleiben? Sich mit Vitaminen zudröhnen? (die amerikanischen Pillenhersteller bekommen schon Wunde Hände vor reiben) Grandios!

"Datenschützer sind Spaßbremsen"

Ich weiß, Datenschutz ist ein trockenes, oftmals stinklangweiliges Thema. Aber nicht alles im Leben ist mit Spaß verbunden. Deshalb... face the facts:

Zunächst mal die besagte Datensammelwut. Google weiß, was man sucht. Klar, man schreibt es ihnen ja auch in das kleine Eingabefeld. Wie sollte die Suchmaschine auch sonst funktionieren?
Nur - Google merkt sich, was, wann, von wem, von woher gesucht wurde. Müsste nicht sein, ist aber so.
Gut, die Daten sind da. Was tun damit? Klar! Werbung, Nutzungsverhalten blabla. Und natürlich tolle Grippeverbreitungskarten. Dazu gleicht man gesammeltes mit anderen Datenbeständen ab (Data-Mining) und bastelt daraus was total cooles neues:

Während der letzten Grippe-Saison 2007/2008 hat Google mit der zuständigen Stelle des CDC (Centers for Disease Control) Daten abgeglichen. Google und CDC kamen gemeinsam zu dem Schluss, dass es eine konsistente und starke Korrelation zwischen den Suchanfragen und den Grippe-Daten der CDC gibt.

Golem.de

Nicht nur Grippe

Nun mag man über Sinn und Unsinn einer durch Surf-Verhalten untermauerten Grippeverteilungsstatistik ausgelassen streiten können. Wie gesagt, ich sehe keinen großartigen Nutzen darin, sondern zum einen eher ein Instrument, mit Angst und Panik einem oder mehreren Industriezweig(en) erhöhten Umsatz zu bescheren, zum anderen noch mehr Möglichkeiten für Arbeitgeber, verallgemeinerte Personenprofile für potentielle neue Mitarbeiter zu erstellen, aufgrund deren sie sich dann für oder gegen sie entscheiden. Die Liste kann beliebig lange fortgeführt werden.
Bedenklich ist aber, dass Google eben nicht nur Suchergebnisse zum Thema Grippe regionalisiert, gar personalisiert vorliegen, sondern auch zu jeglichen anderen Themengebieten.
Diese mögen aus ethischen Gründen teilweise der Allgemeinheit sogar verborgen bleiben (was wiederum Zensur ins Spiel bringt). Aber sie sind verfügbar und werden genutzt. Nicht vom Wald-und-Wiesen-Internetsurfer, aber von Stellen, die diese Informationen letztendlich zum Nachteil des einzelnen verwenden können: Versicherungen, Krankenkassen, Arbeitgeber, Ämter, um nur ein paar wenige zu nennen.

Was tun?

Die Entwicklung zu lenken oder gar aufzuhalten ist alles andere als trivial und wahrscheinlich gar nicht oder nur teilweise möglich. Aber man kann dem Datenschlund einfach keinen (aussagekräftigen) Input mehr liefern. Mit dem Verbieten von Cookies für google* Domains (also google.* sowie googlesyndication.com) ist schon viel erreicht. Für die direkte Google-Suche stehen vorgeschaltete Proxys wie Scroogle zur Verfügung (sogar SSL-verschlüsselt), wodurch die bei Google ankommenden Anfragen stets die selben IPs des Proxy-Pools tragen.
Durch diese Vorkehrungen, die natürlich auch für Suchmaschinen anderer Anbieter getroffen werden sollten, dürfte noch nicht einmal der Surf-Komfort eingeschränkt werden.

Als Alternative zu GnuPG/PGP macht sich zunehmend das symmetrische OTR- (Off-The-Record) Verfahren einen Namen, das speziell für Instant-Messaging entwickelt wurde.

Anders als bei PGP, werden die Datenpakete nicht mit einer eindeutig zuordenbaren Signatur versehen, wodurch Absenderanonymität gewährleistet werden kann. Das bedeutet, allein auf Grund eines vorliegenden Datenpakets kann nicht schlußgefolgert werden, von wem dieses gesendet wurde.
Wie OTR genau funktioniert, darüber möchte ich in Kürze einen ausführlicheren Artikel schreiben. Schließlich kann man den Nachwehen der Krypto-Diplomprüfung auch noch etwas positives abgewinnen und informatives daraus produzieren.

Leider hält sich die Auswahl der Messenger mit OTR-Unterstützung, sei es nativ oder via Plugin, noch in Grenzen. Mein Favorit Psi kam bzw. kommt ohne native Unterstützung daher, selbst die langersehnte Plugin-Schnittstelle ist selbst im aktuellen SVN-Trunk noch nicht vollständig implementiert. Darüber hinaus sind, laut Foreneinträgen, die Core-Entwickler nicht sehr an der Implementierung von OTR interessiert. Daher hat Timo Engel das Zepter selbst in die Hand genommen.

Damit Psi nun OTR spricht, bedarf es einem Patch, der Psi um die Plugin-Schnittstelle bereichert. Hierzu bediene man sich entweder des gepatchten Quellcodes, den bereits gebauten inoffiziellen Debian-Packages, oder man patcht den aktuellen SVN-Trunk selbst (was mir mit vorliegendem Patch leider nicht gelingt).
Ich hatte mich für den gepatchten Quellcode entschieden, da die verfügbaren Packages der Version 0.11-1 noch einen Bug enthalten, der die Eingabe des PGP-Mantras verhindert.
Zuerst gilt es also, den Bug zu eliminieren. Dazu muß in der Datei src/passphrasedlg.cpp lediglich eine Zeile geändert werden:

--- src/passphrasedlg.cpp       (revision 856)
+++ src/passphrasedlg.cpp       (working copy)
@@ -34,7 +34,7 @@
 void PassphraseDlg::promptPassphrase(const QString& name)
 {
        setWindowTitle(tr("%1: OpenPGP Passphrase").arg(name));
-       resize(minimumSize());
+       resize(minimumSizeHint());
 }
 
 QString PassphraseDlg::getPassphrase() const

./configure

DEFINES += PSI_PLUGINS
CONFIG += psi_plugins

make
make install

Mehr Lesenswertes über verschlüsseltes Instant-Messaging (PGP und OTR) mit anderen Messengern (Pidgin,Kopete,Trillian) und deren Konfiguration hat bereits Annika in aller Ausführlichkeit im FreiheIT-Blog geschrieben.