Datenschutz

Moderne Abenteuer: Prefetching & Linkverkürzer

Stopp!Im Zusammenhang mit der Diskussion um die vom Familienministerium präsentierten „Stoppschild-Server“ bekommen derzeit zwei Problemfelder praktische Relevanz, über die bisher eher theoretisch diskutiert wurde: Prefetching und Linkverkürzer.

Wir finanzieren uns zu fast 100 % aus Spenden von Leserinnen und Lesern. Unterstütze unsere Arbeit mit einer Spende oder einem Dauerauftrag.

Meine These: Auch unbescholtene Internetnutzer ohne Interesse an kinderpornografischen Inhalten könnten demnächst das ein oder andere offizielle Stoppschild (missverständlicher Gestaltungsentwurf, PDF) zu sehen bekommen – und somit in den Fokus der Ermittlungsbehörden gelangen.

Der Einwand, dass wohl nur der etwas zu befürchten habe, der regelmäßig „gestoppt“ wird, beruhigt mich nicht. Zum einen sieht man das im Bundesjustizministerium bekanntlich ein wenig anders, …

Staudigl bestätigte in diesem Kontext, dass jeder Nutzer mit Strafverfolgung rechnen muss, wenn er dabei beobachtet wird, eine geblockte Webseite abzurufen (Quelle: Heise Online, 25.04.2009)

… zum anderen hat „Rick-Rolling“ gezeigt, dass es einen – entsprechende Neugierde vorausgesetzt – auch mehrfach pro Tag erwischen kann. Alternativ schlägt die Schere im Kopf zu. Auch nicht besser.

Linkverkürzer

Linkverkürzer sind praktisch. Ganz gleich, ob in Mails, bei Twitter oder auf Facebook: Überall, wo wenig Platz für lange Internetadressen ist, erleichtern sie Hinweise auf interessante Webangebote. Auf der anderen Seite sind sie aber auch prima geeignet, Zieladressen zu verschleiern. Der vermutlich einfachste Weg „gestoppt“ zu werden, dürfte daher über das Aufrufen scherzhaft oder in böswilliger Absicht verschleierter Links führen.

Nicht alle Linkverkürzer arbeiten schließlich mit zwischengeschalteten Informationseiten, wohin die Reise wirklich geht. Und selbst die helfen nur bedingt. Wer kennt schon das Internet auswendig? Ich schlage, analog zum „Rick-Rolling“, den Begriff „Stopp-Rolling“ vor, falls das Mem noch einen Namen braucht.

… und wieder zurück

Besonders problematisch werden in diesem Zusammenhang Greasemonkey-Scripte wie der „TinyURL Decoder“ von setomits, das am Samstag bei Lifehacker.com empfohlen wurde. Im Prinzip handelt es sich beim „TinyURL Decoder“ um ein äusserst nützliches Script. Ist es aktiviert, löst es im Hintergrund mit URL-Verkürzern verschleierte Links in ihre realweltlichen Zieladressen auf. Soweit, so gut.

In der aktuellen Version arbeitet der „TinyURL Decoder“ dabei allerdings mit automatischem Prefetching. D.h. das Script ruft im Hintergrund den oder die Kurz-URLs auf und schaut, was passiert (bzw. welche Zieladresse aufgerufen wird). Wären vom BKA indizierte Inhalte unter den verlinkten Angeboten, landet die eigene IP somit in den Logfiles eines Stoppschild-Servers. Das ist schlecht.

Etwas intelligenter gehen „Long URL Please“ und „LongURL“ das Problem verschleierter Links an. Bei beiden laufen die Anfragen zur Auflösung der Zieladresse eines Kurz-URLs über einen vermittelnden Server. Zur Verfügung stehen Firefox-Extensions, ein Greasemonkey-Script, ein Bookmarklet – oder die Möglichkeit, Kurz-URLs zahlreicher Anbieter per Webinterface zu dekodieren.

You should always know where a link takes you before clicking on it. Services like TinyURL.com make that difficult. LongURL Mobile Expander uses the LongURL.org web services to let you know where shortened links *really* go.

Ach, und eine API für Webbastler gibt’s bei beiden auch. Einen Nachteil haben freilich auch diese Lösungen: Dadurch, dass alle Requests über zentrale Server laufen, haben die Betreiber Zugriff auf eine Menge Daten – und die Möglichkeit zur Weiterverarbeitung. Aber irgendwas ist ja immer.

Prefetching

Prefetching bedeutet zunächst einmal nichts anderes, als das ein Internet-Browser im Hintergrund bereits Daten läd, während der User noch denkt. Oder, wie es die Wikipedia etwas akademischer formuliert:

Als Prefetching bezeichnet man in der Informatik das heuristische Laden von Speicherinhalten aufwärts in der Speicherhierarchie, bevor ein Bedarf evident geworden ist, um so im Falle des tatsächlich eintretenden Bedarfs eine höhere Zugriffsgeschwindigkeit zu erzielen.

Als bekannt wurde, dass bei Firefox 3 Prefetching standardmäßig aktiviert ist, war das Geschrei groß. Manch einer fürchtete um seine Bandbreite, andere Kritiker verwiesen auf die latent verbundene Problematik eines allzu selbstständigen Browsers, wie ich sie auch in diesem Beitrag beschreibe.

Was damals in der allgemeinen Empörung weitgehend unterging: Firefox läd nicht alle auf einer Webseite verlinkten Inhalte einer Webseite im Hintergrund, sondern nur solche, die mit einem entsprechenden Tag im Header gekennzeichnet sind. Das ist freilich problematisch genug.

Details dazu gibt es hier:

Anders verhält sich übrigens die Extension Fasterfox, die läd im Hintergrund tatsächlich alles, was nach einem Link aussieht.

Beim Internet Explorer gibt es serienmäßig kein Prefetching. Allerdings gibt es mit „IE7pro“ wohl ein recht beliebtes Addon, bei dem Prefetching in der Grundeinstellung aktiviert ist. Und hier gibt es ein Video, wie man das wieder abstellt. Eine weitere Falle können div. „Internet Beschleuniger“ darstellen, die dem IE ebenfalls Prefetching unterschieben.

Bei Opera heißt Prefetching „Fast Forward“ und ist vergleichsweise harmlos. Bevor etwas geladen wird, ist eine Interaktion des Users nötig:

Please note that Fast Forward does not use any external services to determine the next page. It only looks at the current page and tries to find things that indicate that there is a „next“ page. It does not look it up from an external server or contact any site to get this info.

Fast Forward does not download anything before the user opens the next page.

Google Chrome verfügt über eine spezielle Form des Prefetchings. Statt im Hintergrund komplette Webseiten zu laden, kümmert sich Chrome lediglich um die anstehenden DNS-Anfragen. Das allerdings konsequent. Googles Browser löst im Hintergrund alle Links auf einer Webseite auf. Golem.de schrieb letztes Jahr:

Ein typisches Beispiel, in dem das DNS-Prefetching seine Stärken ausspielen kann, sind Suchergebnisseiten. Diese enthalten in der Regel eine Vielzahl an Links zu Seiten, die der Nutzer zuvor noch nicht besucht hat. Chrome wertet diese Links aus und erledigt im Hintergrund die DNS-Auflösung für die in der aktuellen Webseite verlinkten Domains.

Siehe auch: http://blog.chromium.org/2008/09/dns-prefetching-or-pre-resolving.html

Je nach technischer Ausgestaltung der Überwachung könnte auch dieses Feature zum Problem werden.

PS: Ich bin mir fast sicher, dass ich beim Durchstöbern der Dokumentationen und Sourcecodes das ein oder andere Detail übersehen habe. Korrekturen und Ergänzungen daher bitte in die Kommentare. Danke.

Weitersagen und Unterstützen. Danke!
32 Kommentare
  1. Es gibt auch noch meinen Dienst: detinyfy.de . Dort gibt es ein Firefox-Plugin das automatisch jeden Klick auf eine Short-URL auf detinyfy umlenkt und da dann die URL+Titel anzeigt. Kommentarfunktionen usw. sind auch geplant!

  2. Das lustige durch das De-Tinify von TinyURL Decoder ist ja unter anderem, das dann schon mal wirklich die Stop-Seite geladen werden kann, man sie aber gar nicht sieht. Auch das DNS-Prefetching von Chrome kann problematisch sein, denn es kann auch sein, dass das BKA laienhaft vorschreibt, die DNS-Zugriffe auf die zu inkriminierenden Domains ebenfalls schon zu loggen und als „Zugriff“ zu werten. Und das, wo dies wirklich nur ein Blick ins Telefonbuch ist, und kein Besuch des Ladens.

    Das Problem ist auch nicht beeschränkt auf Browser, es gibt auch Twitter-Clients, die kurze URLs auflösen und das Ergebnis anzeigen, Nambu für OS X macht dies zum Beispiel. Und IRC-Clients wären dafür auch potentiell geeignet, ob es welche gibt, weiß ich aber nicht.

  3. Ein Punkt wurde bisher noch nicht angesprochen. Selbst wenn man nicht polizeilich verfolgt wird bei Zugriff auf die „verbotenen Seiten“ erhöht jeder Klick die Statistik des BKA mit der dann schön weiter Propaganda getrieben werden kann (ich schau mir mal die Public Timeline in meinem Twitter Client an und feuere ungewollt einige Klicks auf die bösen Seiten)

  4. Eigentlich spielt es doch bei einer einzigen URL keine Rolle, ob einmal gestoppt oder mehrmals – ein mehrmaliger Versuch kann ja nicht erfolgreicher sein als ein einmaliger – im Sinne der Strafverfolgungsbehörden dürfte hier eigentlich keine Unterschied gemacht werden (es ist ja eine logische Sperre, nach mehrmaligem Versuch gibt die Sperre nicht nach).

    In diesem Sinne ist auch die Verfolgung eines einmaligen „Versuches“ vollkommen abzulehnen (genaugenommen natürlich die gesamte Zensur a la CDU).

  5. Firefox wird ab Version 3.5 auch DNS-Prefetching haben. Man abgesehen davon, daß es mir hirnrissig vorkommt, bei jedem Klick Dutzende überwiegend nutzloser Queries herauszublasen (für diese Seite etwa sind es 51 Stück), ist es auch ein Privacy-Albtraum.

    Wer heute schon Shiretoko, Minefield oder SeaMonkey 2 benutzt, kann den Spuk mit user_pref(„network.dns.disablePrefetch“, true); abschalten.

    http://bitsup.blogspot.com/2008/11/dns-prefetching-for-firefox.html

  6. Ein weiteres praktisches Problem mit den Sperren habe ich mal hier skizziert: http://www.thomasmoehle.de/zensur/index.php/Datei:Netzsperren-Fruehwarnsystem.png

    Die Sperren ermöglichen es den Kriminellen, sich mittels eines Frühwarnsystems vor Strafverfolgung zu schützen.

    Frau von der Leyen stellt ja diese Kriminellen als hochprofessionalisiert dar. Deswegen werden sie sicher auch diesen Weg in Betracht ziehen, ihre „Dienstleistungen“ abzusichern. Und die Betreiber von Botnetzen hätten eine weitere Einnahmequelle.

  7. Spannend wird es auch noch zwecks Suchmaschinen. Reicht es, sich als User-Agent irgendwas mit Google-Bot einzustellen? Oder der Hinweis darauf, dass man auf seinem Rechner eine Suchmaschine betreibt – bspw. eine P2P-Suche? Oder ist das wieder was, das man politisch nicht verstanden hat?

  8. Ich finde, man sollte sich gar nicht so sehr an konkreten technischen Merkmalen irgendwelcher Softwareprodukte aufhalten.

    Fakt ist, dass wir auch ohne diese beiden Werkzeuge täglich jeder eine kaum vorstellbare Zahl von HTTP-Requests absetzen, von denen (für „Internetausdrucker“ unvorstellbar) oft nicht ein einziger durch eine Eingabe ins Adressfeld zustande kommt. Alle weiteren Anfragen entstehen durch Links, verknüpfte Bilder/Stylesheets/Skripte, Inline-Frames, Popups, Formulare, AJAX, etc. Und jeder Request kann vom Zielserver nochmal auf jeden anderen umgeleitet werden. Bei den allermeisten Anfragen sehen wir nicht einmal ein Ergebnis. Es gibt keine vollständige Kontrolle darüber, wohin unsere Browser Anfragen schicken, sonst würde das Web nicht funktionieren!

    Daher braucht man auch kein Prefetching, um — sofern es jemand anders darauf anlegt — täglich zigfach eine dieser virtuellen Tretminen zu erwischen und trotzdem nicht einmal das Stoppschild zu sehen zu bekommen. Die Lösung kann auf keinen Fall sein, dass wir darüber nachdenken, wie wir in Zukunft nur noch ganz, ganz vorsichtig Surfen könnten! Das Web funktioniert mit „guten“ und „bösen“ URLs einfach nicht.

    Ich habe keine Lust in einer Welt zu leben, in der ich nur noch auf die hellen Pflastersteine treten darf, weil beim Tritt auf einen dunklen mein gesamtes (digitales) Leben beschlagnahmt wird. Sollte die staatliche DNS-Manipulation kommen, können wir nur allen uns lieben Menschen dringend raten, nicht an diesem Wahnsinn teilzunehmen.

  9. Ich möchte darauf hin weisen, dass es noch eine weitere Möglichkeit gibt, den Nutzer sehr einfach auf die Sperrseite umzulenken:

    Bilder! Dahinter müssen nicht direkt Bilder stecken, sondern man gibt als Quelle einfach eine gesperrte Seite ab. Der Browser schickt dann automatisch eine HTTP Request

    Beispiel:
    In einem Forum, einfach mal ein Bild in die Signatur gehängt:
    [img]http://boese.de[/img]
    Und zack, rufen alle Forenbenutzer, die einen Beitrag, den dieser böse Mensch verfasst hat, ansehen, die Seite boese.de auf.
    Geht natürlich auch über E-Mail oder PMs. Und man kann sich nicht dagegen wehren. Also benutzt besser kein Internet.

    Achja, ich hatte übrigens schon vorgeschlagen DNS Prefetching standardmäßig zu deaktivieren:
    https://bugzilla.mozilla.org/show_bug.cgi?id=490503

  10. Viel interressanter als die hier diskutierten Probleme ist doch die Frage wo man einen schnellen, freien DNS herbekommt? Kennt jemand gute Adressen von freien DNS-Servern?

    Zum Thema Prefetching/Linkverkürzer:
    Das hilft alles nur wenig. Zum einen ist es sehr unbequem
    Forensignaturen: wurden schon angesprochen.

    Es würde auch genügen wenn eine Seite gehackt werden würde, eine gesperrte URL als IFRAME einzubinden.

    Und es ist vorher auch für den Betrachter nicht offensichtlich ob eine URL auf einer Sperrseite ist. Meinetwegen könnte auch Textlink bei Heise zu einem Bild auf einer vom Namen her unauffälligen Domain geblockt sein. Wumms. Erst wenn man die Seite sieht ist es zu spät.

    Da die Sperren auf DNS-Ebene ablaufen könnte ich mir auch vorstellen das z.B. Besucher von einer legitimen Seite z.B. freehoster.tld/legitim auf die Stopseite kommen wenn unter freehoster.tld/kipo Murks liegt.

    Es ist einfach nur traurig. Also her mit guten freien DNS-Servern. Ich kenne nur OpenDNS – aber da hört man auch immer verschiedene Geschichten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.