Crawler sind kleine Programme, die dabei helfen, den Informationsdschungel des World Wide Webs systematsich zu durchforsten. Ausgehend von einer Startadresse sammeln und strukturieren die Programme nach vorab definierten Kriterien verschiedene Informationsfussel eines Pools festgelegter Seiten. Indem auch Links zu neuen Seiten aufgenommen und angesteuert werden können, führt dieser Pool mitunter in ungeahnte Tiefen. Nachdem Methoden zur Sammlung und Strukturierung der Daten je nach Aufgabenstellung unterschiedlich Form annehmen, gilt das Hauptaugenmerk hier dem Aufsetzen eines Crawlers. Seine Aufgabe wird es sein, einzelne Adressen anzusteuern und jeweils den gesamten Inhalt dieser Seiten an eine Funktion zur Datenreduktion/-strukturierung zu übergeben – an den Scraper.
Während sich ein simples Ansteuern von einzelnen Seiten sehr einfach gestaltet und es hier eigentlich keine großen Worte zu verlieren gibt, materialisieren sich Interessenskonflikte zwischen Datenhungrigen und Informationsanbieter*innen in Form der ein oder anderen Stolpersteine. Anders gesagt: Seiten beschränken die Zugangsrechte für Crawler oder die eigene IP wird – nach einer kurzen Interaktion – einfach geblockt und der Informationszugang verwehrt. Erkennt mensch an, dass das Virtuelle nur aus dem Substrat des Matriellen erwachsen kann, gibt es durchaus gute Gründe für diese Beschränkungen. Sowohl das Bereitstellen, als auch das Sammlen von Informationen ist an begrenzte Ressourcen gebunden. Im Sinne kooperativen Handelns ergibt es daher durchaus Sinn, sich mit ein zwei Gedanken einer kleinen Ethik des Datensammelns zu widmen, bevor die Grenzen des Möglichen in geiferndem Egozentrismus ausgelotet werden. Denn auch wenn Crawler selbst keine Drüsen besitzen, bringen sie mit ihrem Datenhunger vermutlich doch irgendwo irgendwen zum Schwitzen.
Unabhängig davon sollte es – schon allein aus emanzipatorischer Sicht – möglichst leicht gemacht werden, Zugang zu Daten zu erhalten. Im Gegensatz dazu entpuppt sich die Motivation hinter dem Legen vieler Stolpersteine oft schlicht als eine Kombination aus Monopolismus, Egozentrismus und einem Hauch falsch verstandenen Protektionismus. An das Substrat des Matriellen gebunden, scheint es daher wenig verwunderlich, dass das Virtuelle sich in dornigen Ranken reproduziert, deren Blüten nur jenen vorbehalten sind, die die passenden Gärtner*innenhandschuhe beim letzten Baumax-Schlussverkauf ergattern konnten.
Vermutlich ist es am Einfachsten, die Gärtner*innen zu bitten, uns eine Blüte abzuschneiden oder einen vorbereiteten Blumenstrauß vom API-Ladentisch zu wählen. Oft wird unsere Bitte wohl aber auch auf Taube Ohren stoßen und die vorbereiteten Arrangements sind entweder schon halb verwelkt oder treffen schlicht nicht unseren Geschmack. Vielleicht wollen wir beim Sammeln aber auch einfach nicht erkannt werden und unsere Identität schützen oder die Gärtner*innen nicht mit unserer kleinen Sammeltour belästigen.
Es gibt gute also gute Gründe sich eigenständig durch diesen Dornenwald zu kämpfen. Und nachdem kurz die vier größten Stolpersteine auf dem Weg des Datensammelns umrissen worden sind, will ich – das Wanderlied der Informationsfreiheit pfeifend – den Versuch unternehmen, die passenden Stiefel für den vor uns liegenden Pfad zu schustern. Gleichzeitig wird versucht unsere Sohlen gerade so sehr abzuschleifen, um unsere Standfestigkeit zu behalten ohne dass jeder Abdruck im Matsch dabei gleich auf unseren Fuß verweist.
Die vier größten Stolpersteine
Das bisher Gesagte im Hinterkopf, lassen sich auf dem Weg zum erfolgreichen Crawl besonders vier Stolpersteine aufzeigen, die der Wanderlust das Haxl stellen. Versucht mensch diese im Auge zu behalten, ist die halbe Strecke sicher geschafft.
Fehlende Empathie auf beiden Akteursseiten erschwert wohl am gravierendsten ein gemütliches Vorankommen. Seitens Datenhungriger ist damit vorwiegend das Ignorieren der robots.txt-Anweisung gemeint. Die Datei findet sich im Grundverzeichnis der meisten Websites, regelt spezielle Zugriffsrechte/-einschränkungen und führt eine Liste geblockter user agents. Verstößt mensch oder Crawler gegen diese Grundbedingungen, muss (mittelfristig) mit einem Ban von der Website oder mit rechtlichen Folgen gerechnet werden. Scheinen die dargelegten Hausregeln legitim, sollte ihnen also durchaus Folge geleistet werden.
Da Crawler es ermöglichen eine Vielzahl von Seiten in sehr kurzer Zeit anzusteuern, verstopfen sie mitunter den Weg für andere User*innen und bringen die Straße zum Bröckeln. Im Sinne des kooperativen Handelns und der eigenen Bewegungsfreiheit (um nicht geblockt zu werden), kann es daher durchaus sinnvoll sein, ein zwei Gänge runterzuschalten, die Szenerie zu genießen und den Weg entlang zu flanieren. Wie schnell wir uns bewegen können, ohne auf die ein oder andere Weise zu stolpern, lässt sich schwer quantifizieren und bestimmt sich sowohl durch die vorhandenen Ressourcen der Wegbereiter, als auch durch die Zeit, die wir für die Zurücklegung des Weges haben. Es ist aber wohl zu empfehlen, nach jedem Schritt eine kurze Verschnaufpause einzulegen. Es kann auch sinnvoll sein, einen Crawl zwischenzeitlich zu stoppen und den ganzen Weg verteilt über Tage hinweg in kleinen Etappen zu bewältigen.
In der Regel nähern sich Crawler stets auf dem gleichen Weg ihrem angstrebten Ziel. Gerade aus. Und – sofern vernünftig konzipiert – auf möglichst direkter Linie. Damit unterscheiden sie sich aber auch deutlich von fleischlichen User*innen, die Fehltritte machen, sich verklicken, willkürlich die Gangart wechseln, kurz mal eine Klopause einlegen oder Umwege in Kauf nehmen, wenn sie auf einem anderen Pfad etwas Interessantes erspähen. Dieser Unterschied macht es mitunter recht leicht, die beiden Gruppen voneinander zu unterscheiden. In der Regel dürfte die Analyse des Website-Traffic zwar nicht so tiefgreifend ausfallen, sollte mensch aber die Zeit haben, kann es sicherlich nicht schaden, dieses Verhalten zumindest im Ansatz nachzuahmen, die Abstände zwischen den Seitenaufrufen etwas zu variieren und manchmal auch Umwege oder Sackgassen in Kauf zu nehmen.
Sobald wir uns mit einer Seite verbinden, stellen wir uns mit Name und Adresse vor. Schüchternheit, das Bedürfnis nach Privatsphäre oder die fehlenden Anerkennung der Legitimation der Hausregeln, geben aber gute Gründe gegen eine all zu offenherzige Begrüßungspraxis. Wie schon im Punkt zuvor, gilt auch hier die Annahme: je weniger System unsere Anfragen haben, desto schwerer wird es, systematische Rückschlüsse auf unsere Person oder unser Anliegen zu ziehen. Da wir aber nicht umhin kommen unsere Fragestellung zu systematisieren, kann es hilfreich sein, auf unserem Weg das Schuhwerk zu wechseln und eine neue Identität anzunehmen. Dadurch zeigen wir einerseits weniger Präsenz, andererseits wird die Systematik unserer Routine so durch die Normalität des Handelns der Masse verwischt. Kurz: mit Proxies oder dem TOR-Browser wechseln wir Abschnittsweise die Wanderstiefel und mit verschiedenen user agents wechseln wir das Logo auf unserem Schuh.
Das Grundgerüst für den Crawler
Während die meisten Stolpersteine auf einer anderen Ebene zu verorten sind und eine Interessensabwägung oder die Vorgehensweise bei der Datenstrukturierung und -ansteuerung betreffen, fasst das Grundgerüst des Crawlers das Identitätsproblem ins Auge und greift den Gedanken einer gewissen Empathie mit den Eigentümer*innen auf.
Zuerst muss der TOR-Browser installiert werden. Grundsätzlich wechselt TOR in vordefinierten Zeitintervallen (etwa alle 10 Minuten?) automatisch die verwendete IP-Adresse. Wem dieser Intervall ausreichend Anonymität bietet, der sollte mit einer TOR-Instanz zufrieden sein. Da ich persönlich damit aber nicht zufrieden war und Probleme hatte den Intervall zu ändern, wählte ich den Umweg über mehrere eigenständige Instanzen des Browsers.
Nachdem die schmutzige Konfigurationsarbeit erledigt ist, kann das Ansteuern der Instanzen in R vorbereitet werden. Zuvor legen wir uns aber noch ein Set an unterschiedlichen user agents zu, die beim jeweiligen Ansteuern ausgewiesen werden. Im nachfolgenden Fall eine Liste, die sich auf Mozilla-Browser beschränkt. Es können aber auch andere Browser gewählt werden, die auf der Website zu finden sind. Mit der Einschränkung auf die gewünschten Browser, werden alle vorhandenen user agents eingelesen und gespeichert. Später wird bei jedem Aufruf des Crawlers ein neuer, zufällig gewählter user agent verwendet.
In einem zweiten Schritt werden die Tor-Instanzen vorbereitet. In diesem Beispiel: zwei Instanzen. Die beiden Instanzen des TOR-Browsers müssen davor/währenddessen auch wirklich gestartet und konfiguriert werden.
Nun gilt es noch den eigentlichen Crawler in Szene zu setzten. Die nachfolgende Funktion sollte es ermöglichen, sowohl mit verborgener, als auch offener Identität zu crawlen und auf dem Weg kleine Verschnaufpausen einzulegen. Um diese drei Codeschnippsel danach miteinander zu verbinden, wird die Crawler-Funktion dann innerhalb einer Funktion zur Datenstrukturierung jeweils mit frischen URLs aufgerufen.
Was noch bleibt …
In der exemplarischen Konfiguration werden zwei TOR-Instanzen verwendet, wodurch ein mehrfacher IP-Wechsel innerhalb des vorgegebenen 10-Minuten-Fensters von TOR möglich ist. Damit sollte das Problem all zu hoher/offensichtlicher Interaktion gelöst sein. Das Setzen von Wartezeiten sollte auch auf Serverseite eine gewisse Entlastung bringen. Durch Übergabe variabler Wartezeiten können diese auch flexibel an die jeweilige Interaktion angepasst werden (z.B. längere Pausen, nach großen Downloads etc.).
Unbeantwortet bleiben demgegenüber andere Aspekte. Die Anweisungen der robots.txt werden nicht automatisch berücksichtigt (wobei dieser Arbeitsschritt vermutlich in der Scraper-Funktion anzusiedeln wäre). Auch Statusmeldungen und mögliche Fehlercodes werden nicht systematisch ausgewertet. Es wäre wohl auch sinnvoll, eine verwendete IP während ihres Lebenszyklus stets mit einem bestimmten user agent zu verbinden. Es darf auch gefragt werden, ob es Sinn ergibt die eigene IP-Adresse zu verwenden, wenn das Crawlen via TOR ausgewählt wurde. Der Rückgriff auf die eigene IP wurde gewählt, um all zu lange Timeouts und all zu viele, fehlgeschlagene Proxy-Verbindungen zu umgehen. Sollte ein Rückgriff auf die eigene IP aber nicht erwünscht sein, lässt sich das durch hohe timeout/try.con-Werte aushebeln.
Um das Paket abzurunden gilt es auf Ebene des Scrapers auch noch Fragen zu den gesammelten Links zu klären: Bis zu welcher Link-Tiefe dringt der Crawler vor? In welcher Reihenfolge werden Links angesteuert? Und wie werden Wiedereinstiegspunkte definiert, um den Crawl pausieren zu könnnen?
Unabhängig davon sollte ein erstes und recht niederschwelliges – sicher aber noch optimierbares – Eintauchen in die Tiefen der Informationsfreiheit mit dem beschriebenen Code jedenfalls ermöglicht werden. In diesem Sinn: crawl like there’s nobody watching 