Qbi's Weblog

Risiken von Suchanfragen sind in der Vergangenheit vielfältig diskutiert worden. Die Freigabe der Suchanfragen durch AOL hat vielen Menschen gezeigt, wie schnell sie durch ihre Suchanfragen identifizierbar sind. Doch was kann man dagegen tun?

Die Wahl der richtigen Suchmaschine ist ein probates Mittel. Auf der einen Seite gibt es welche, die am liebsten jeden Nutzer identifizieren möchten. Sei es durch Logins, lebenslange Cookies oder andere invasive Techniken. Auf der anderen Seite gibt es Anbieter, die eben keine Cookies setzen oder sie schnell löschen. Manche bieten verschlüsselte Suchanfragen an. Ganz neu ist nun das Angebot, einen Tor-Server zu betreiben.

Duckduckgo (DDG) ist ein Anbieter mit einigen vielversprechenden Ansätzen. Unter anderem machen sich die Betreiber Gedanken zum Schutz der Privatsphäre ihrer Nutzer:

Keine Speicherung von IP-Adresse und Browserversion

Üblicherweise speichert fast jeder Anbieter die IP-Adresse und andere Daten der Besucher. DDG hat sich entschlossen, weder IP-Adresse noch die Identifikation des Browsers zu speichern.

Keine Cookie

Standardmäßig verwendet die Seite keine Cookies. Erst wenn jemand seine Einstellungen anpasst, wird ein Cookie gespeichert. Allerdings ist es auch möglich, die Einstellungen als Parameter in der URL zu übergeben. Dann entfällt die Speicherung eines Cookies.

Verschlüsselung

Seit langem gibt es eine verschlüsselte Seite für Suchanfragen.

Keine Referer

Wer auf das Suchergebnis bei den Suchmaschinen klickt, überträgt ungewollt Informationen über seine Suchanfrage mittels des so genannten Referer. Das ist nicht immer gewollt. DDG ist so eingestellt, dass diese Daten nicht mehr an die Ergebnisseite übertragen werden

Seiten über Proxy besuchen

DDG bietet eine so genannte Bang-Syntax. Mit einem Ausrufezeichen und einem Befehl kann die Suche eingeschränkt oder Zusatzfunktionen aufgerufen werden. Die Eingabe von !proxy kubieziel.de führt direkt zu einem Aufruf meiner Webseite. Ihr solltet dabei jedoch aufpassen. Denn bestimmte Elemente der Webseite (Bilder, CSS) werden über eure normale Internetverbindung geladen. Damit verschwindet der Effekt des Proxys.

Seit heute bietet Duckduckgo ein spezielles Feature, einen Tor-Server. Der Entwickler schrieb in seinem Blog, dass er sich entschieden hat, einen Server aufzusetzen. Dieser leitet Verkehr innerhalb des Tor-Netzwerks weiter und stellt für DDG einen Endpunkt dar. Das heißt, wenn ihr bei DDG suchen wollt, kann dieser Server der Ausgang sein. Das hat den Vorteil, dass die Abrufe unter Umständen schneller funktionieren. Zusammen mit der verschlüsselten Seite bietet sich guter Schutz für den Suchenden.

Probiert die Seite mit der Ente mal aus. Ich hoffe, sie gefällt euch!

Vor nicht allzu langer Zeit sass ich entspannt bei einem Kaffee und wollte meinen Rechner starten. Einschaltknopf gedrückt und der Bildschirm lächelte mich mit einer Fehlermeldung an:

error: unexpectedly disconnected from boot status daemon
Begin: Waiting for root file system ...

grml, warum muss das ausgerechnet jetzt passieren? Sehr schnell war klar, dass ich an dieser Stelle nicht weiter komme. Also bootete ich einen alten, funktionierenden Kernel und änderte meine grub-Einstellungen entsprechend. Damit lebte ich einige Zeit gut, bis mir mal wieder der Workaround auffiel. Jetzt wollte ich das Problem mal genauer angehen.

Die Fehlermeldung, die irgendwas von dem Boot Status Daemon erzählte, schien auf plymouth hinzudeuten. Der Sinn der Software ist es, den Bootprozess zu verschönern. Das heißt, es macht schicke Bildchen anstatt der Kernelmeldungen.

Der Bugtracker von Debian hatte einen Eintrag zu meiner Meldung. Die in dem Bugreport genannten Einstellungen änderten bei mir nichts am Problem. In meinem nächstem Versuch wollte ich plymouth deinstallieren. Aber da gab es eine winzige Abhängigkeit zu mountall(8). Der Zufall führte mich zu einem angepasstem Paket, mit dem plymouth deinstalliert werden kann. In freudiger Erwartung startete ich den Rechner neu. Aber es wäre nur zu schön gewesen, wenn sich das Problem so leicht lösen ließe.

Zu diesem Zeitpunkt kam mir in den Sinn, die Bootoptionen quiet und splash zu entfernen. Siehe da, ein wenig mehr kam zum Vorschein:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ...

Warten, warten und nochmal warten. Oh, nun noch eine BusyBox-Shell:

(initramfs) Gave up waiting for root device. Common problems:
...
ALERT! /dev/disk/by-uuid/.... does not exist. Dropping to a shell!

Nebenbei stellte ich dann fest, dass die Meldung mit dem Boot Status Daemon nur bei einer speziellen Kernelversion auftrat. Die Meldung oben konnte ich mit jeder Standard-Ubuntu-Kernelversion größer als 2.6.32-20 erzeugen. Für mich wäre es viel wichtiger zu erfahren, woher denn diese Meldung stammt!

Ein Hinweis brachte mich dann zu den Mainline-Builds. Das sind spezielle Pakete des Ubuntu Kernelteams, die recht nahe am Original-Kernel sind. Ich versuchte wieder diverse Versionen. Alle brachten mir die Fehlermeldung. Na gut, dann baue ich eben einen eigenen Kernel.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cp /boot/config-2.6.32-24-generic /usr/src/linux-2.6/.config
make oldnoconfig
make deb-pkg
dpkg -i ../linux*.deb
reboot

Beim ersten Reboot startete der Kernel tatsächlich korrekt. Sollte Ubuntu wirklich einen Bug in den eigenen Kernel eingebaut haben? Plötzlich fiel mir ein, dass die Zeile im grub einen kleinen, aber feinen Unterschied zu den restlichen Einträgen aufwies. Ich hatte root=/dev/sda1 angegeben. Alle anderen Einträge trugen root=UUID=.... Also versuchte ich die Änderung bei den anderen Kerneln und es klappte. Jede Kernelversion bootete mit dieser Änderung.

Jetzt muss ich nur noch herausfinden, warum das nicht klappt und ich bin wieder ein glücklicher Mensch.

Das Bild stammt vom Blog Linux und ich