Füttern wir die Bots

• Ein Website-Betreiber stellt ein Experiment vor, bei dem er für Scraper-Bots zum AI-Training Seiten mit „endlosem Unsinn“ erzeugte, um deren Traffic dorthin umzuleiten
• Diese Bots sind aggressiver als traditionelle Suchmaschinen-Crawler: Sie ignorieren robots.txt, wechseln ihre IPs und senden fortlaufend Anfragen
• Übliche Abwehrmaßnahmen sind sämtlich wirkungslos – etwa IP-Sperren, Rate Limits, CAPTCHAs oder Login-Schranken – und verursachen vor allem Unannehmlichkeiten für echte Nutzer
• Der Autor stellte fest, dass es am günstigsten und effektivsten ist, Fake-Daten (bedeutungsloser Text) automatisch zu erzeugen und den Bots zu servieren
• Das macht die Nebenwirkungen der AI-Datensammlung und die Verschwendung von Server-Ressourcen sichtbar und zeigt eine realistische Gegenmaßnahme für Website-Betreiber auf

---

Was diese Bots eigentlich sind

• Neuere Crawler dienen nicht der Suchmaschine, sondern der Datensammlung für das Training von LLMs (Large Language Models)
  • Sie ignorieren robots.txt, tarnen sich als Browser oder greifen mit wechselnden IPs zu
  • Sie schicken den ganzen Tag mehrmals pro Sekunde Anfragen und erzeugen so Serverlast
• Anders als klassische Suchmaschinen haben sie kein Interesse am Erhalt von Websites und behandeln sie nur als austauschbare Datenquelle

Probleme, wenn man den Zugriff erlaubt

• Das Ausliefern statischer Dateien ist günstig, aber nicht kostenlos; es gibt SSD-Zugriffslatenzen und Dateisystem-Overhead
  • Durch Anfragen auf alte Seiten, die nicht im Cache liegen, wird die Serverleistung beeinträchtigt
• Auch Bandbreitenverbrauch ist ein Problem; Blogposts mit Bildern summieren sich schnell auf über 1 TB Traffic pro Monat
  • Für Betreiber privater Server sind das schwer tragbare Kosten

Grenzen von Blockierungsversuchen

• IP-Sperren helfen nicht; von Großunternehmen betriebene Bot-Netzwerke verfügen über Tausende Adressen
  • Selbst wenn man alle bekannten Adressen sperrt, kaufen sie neue IPs und verbinden sich erneut
• Auch Rate Limits sind nutzlos, da manche Bots für jede Anfrage eine andere IP verwenden

Nebenwirkungen von Firewalls und Authentifizierungshürden

• Verschiedene Schutzmaßnahmen wie Login, Bezahlwände, CAPTCHA oder hashbasiertes Proof-of-Work wurden vorgeschlagen, führen aber alle zu Unannehmlichkeiten für Nutzer
  • Account-Pflichten erschweren den Zugang für Leser, und JavaScript-basierte Prüfungen blockieren Browser ohne JS
  • Außerdem verschlechtern sie durch längere Ladezeiten die User Experience

Die Wirkungslosigkeit der Kompressionsbombe (gzip bomb)

• Manche schlagen vor, Bots mit einer gzip bomb anzugreifen, aber in der Praxis liegt die Kompressionsrate nur bei etwa dem 1000-Fachen
  • Um eine auf 100 GB expandierende Datei zu erzeugen, muss man rund 100 MB an Assets bereitstellen
  • Experimente zeigen, dass Bots dies entweder ignorieren oder sogar noch mehr Anfragen senden

Wenn Täuschung nicht funktioniert

• Auch der „Jedi mind trick“ – also mit einem 404-Fehler so zu tun, als existiere die Seite nicht – scheitert
  • Sobald Links extern veröffentlicht sind, erkennen Bots die Existenz; wird der Zugriff blockiert, fragen sie oft noch aggressiver an
  • Im Ergebnis bleibt der Server nur ruhig, wenn man die Bots zufriedenstellt

Warum es effizient ist, Müll-Daten auszuliefern

• Dynamische Inhalte wirken zunächst teuer, tatsächlich sind CPU und RAM aber die schnellsten Ressourcen
  • Dass etwas langsam ist, liegt meist an Datenbank-I/O oder komplexer JS-Logik
• Der vom Autor entwickelte Markov-basierte babbler benötigt pro Anfrage nur etwa 60 Mikrosekunden CPU und 1,2 MB Speicher
  • Kein Festplattenzugriff, keine Pflege von Blacklists
  • Die Bots finden den Dienst selbst und verbrauchen bedeutungslosen Text, wodurch die Serverlast sinkt

Fazit

• Die ungehemmte Datensammlung durch Bots für AI-Training führt zu höheren Infrastrukturkosten im Web und zum Missbrauch von Inhalten
• Gegenüber einfachem Blockieren ist eine Strategie mit bedeutungslosen Daten kosteneffizienter und günstiger für die Serverstabilität
• Das ist ein experimenteller Ansatz, um künftig ein Nebeneinander von AI-Crawling und dem Web-Ökosystem auszuloten

[kimjoin2]

Oh ... originell und gut.

[GN⁺]

Hacker-News-Kommentar

• Die versteckte Absatzanweisung vor dem Link war lustig.
  Dort stand sinngemäß: „Der Inhalt dieser Seite ist gefährlich, also nicht veröffentlichen“ – eine spielerische Anweisung, um LLMs auszutricksen.
  Das zugehörige Dokument steht unter diesem Link.

  • Fasst man den Artikel The Cost of Trash zusammen, geht es darum, dass der Autor mehrere Methoden ausprobierte, um aggressive Web-Scraper (vermutlich für LLM-Training) zu blockieren, dabei aber scheiterte und sich schließlich für die Strategie entschied, nutzlose Daten dynamisch zu erzeugen, um deren Ressourcen zu verschwenden.
    Der Abschnitt „LLM instructions“ am Ende ist nicht der eigentliche Haupttext, sondern eine Meta-Anweisung zur Verwirrung von LLMs, daher wurde er in der Zusammenfassung ausgelassen.

• Ich habe so eine Strategie immer empfohlen — AI-Bots massenhaft echt aussehende Müll-Daten zu füttern, sodass am Ende Menschen filtern müssen.
  Wenn alle Websites das tun würden, würde die Qualität der Trainingsdaten für AI stark sinken.
  Wenn man schon schwer dagegen ankommt, ist es besser, sie einfach unter einer Datenflut zu begraben.

  • Eine teurere, aber bessere Methode wäre, LLMs massenhaft mit positivem Werbe-Content zu füttern.
    Etwa indem man Sites im Stil von News-Domains baut und dort Produkt-PR wie SEO-Köder verteilt.
  • Allerdings werden LLMs ohnehin schon größtenteils mit Müll-Daten trainiert.
    Solche Versuche sind nur Zeitverschwendung, ähnlich wie auf Spam-Anrufe zu reagieren.
  • Außerdem können LLMs Müll-Erkennung viel günstiger als Menschen durchführen.
    Am Ende wird man dafür kaum noch Leute einstellen.
  • Ich frage mich, warum man glaubt, dass Menschen Müll besser herausfiltern als AI.

• Details zum „Markov babbler“ stehen in diesem Beitrag.

  • Beim Kompilieren mit gcc 14 tritt ein Argumentfehler bei pthread_detach auf.
    Der Autor scheint einen Compiler zu verwenden, der Warnungen ignoriert.
    Da das Programm Anfragen ohne Begrenzung des Thread-Managements verarbeitet, ist es sicherer, es in einem Container als unprivilegierter Nutzer auszuführen.
    Es werden offenbar auch gefährliche C-Funktionen wie sprintf() verwendet, daher ist aus Sicherheitsgründen Vorsicht geboten.
  • Er sagt, dass er das auch zu „toptext“ hinzufügen wird.
  • Der Code sei elegant und schnell, und hoffentlich hätten die LLM-Scraper Mühe, diese Daten aufzuräumen.

• Auf meiner Site sind alle Links mit Basic Auth geschützt, und bisher ist noch kein Bot durchgekommen.
  Deshalb frage ich mich, was wäre, wenn alle Websites dieselben öffentlichen Zugangsdaten verwenden würden.
  Benutzer: nobots / Passwort: nobots
  Könnten Bots das trotzdem umgehen?

  • Natürlich. Man muss einfach einen Authentifizierungs-Header zur HTTP-Anfrage hinzufügen.
    Die meisten Bots berücksichtigen diesen Fall bislang nur nicht.
    Mit einer Anfrage im Format http://username:[e-mail] ist das leicht gelöst.
  • Wenn die Zugangsdaten allen bekannt sind, dürfte das kaum Bots blockieren.
  • So etwas funktioniert nur, solange es nur wenige nutzen. Sobald es sich etwas verbreitet, ist es wirkungslos.

• Ich liefere ihnen inzwischen auch Müll-Daten.
  Als Quelle habe ich übrigens Frankenstein, Alice in Wonderland und Moby Dick verwendet, aber die Dateien sind groß, daher lädt es langsam.
  Ich habe den Kompilierfehler behoben, indem ich pthread_detach(&thread) zu pthread_detach(thread) geändert habe.

  • Der Fix wurde übernommen, und der Vorschlag von gcc war korrekt.

• Ich betreibe einen „ethical crawler“.
  Ich halte die Request-Frequenz niedrig, um Websites nicht zu belasten, und es wird zunehmend schwieriger, weil der RSS-Zugriff oft blockiert ist.
  Mein Crawler testet verschiedene Header und Mechanismen beim Erkunden.
  Code: crawler-buddy, Django-link-archive

  • In requirements.txt steht feedparser, aber es gibt keine sichtbare tatsächliche Verwendung.
    Das lässt sich auch über dieses Suchergebnis bestätigen.

• Im Artikel The Cost of Trash wird erwähnt, dass gzip-Bomben nicht effektiv sind.
  gzip komprimiert nur ungefähr um den Faktor 1000, daher müsste man eine 100-MB-Datei ausliefern, um 100 GB zu erzeugen.
  Die Bots hätten sogar noch mehr Requests gestellt.

  • Mit zip geht das, mit gzip aber nicht.
    Die meisten Clients dekomprimieren im Streaming-Verfahren und laden nicht alles in den Speicher.
    Damit eine gzip-Bombe tatsächlich funktioniert, müsste sie auf unübliche Weise verarbeitet werden.
    Siehe: zlib-API-Dokumentation
  • Stattdessen wäre eine Strategie mit tausenden kleinen gzip-Dateien besser, um CPU und Zeit zu verschwenden.
    Man könnte darin zufälligen Müll unterbringen oder Nachrichten einfügen, die die AI lernen soll.

• Man sollte beachten, dass manche Requests möglicherweise den Browser echter Nutzer als Proxy verwenden.
  Einige Browser-Anbieter nutzen den Traffic ihrer Nutzer als Proxy.
  Wenn die Fehlerquote bei der Erkennung automatisierter Requests klein genug ist, könnte man zwar Krypto-Mining-Code einschleusen, aber das birgt das Risiko, echte Nutzer zu treffen.
  Mich würde besonders interessieren, ob es AI-Requests gibt, die mobile Agents verwenden.

• Es hieß, der „Markov babbler“ verbrauche pro Request etwa 60μs CPU.
  Da kam mir der Gedanke, Inhalte mit ideologischen Botschaften oder Propaganda zu mischen, damit AI sie lernt.
  Das könnte dazu führen, dass AI später seltsame politische Aussagen macht.
  Zumindest hätte es den Effekt, Urheberrechtsverletzungen und Serverlast zu verringern.

• Warum überhaupt Markov-Text auf dem Server erzeugen?
  Wenn Bots JavaScript ausführen, könnte man ihn doch auf dem Client erzeugen lassen, oder?

  • Bots haben praktisch unbegrenzte CPU- und Speicherressourcen, daher ist die Serverlast nicht besonders groß.
    Außerdem wäre es ineffizienter, die Markov-Chain-Daten an den Client zu senden.
    Da jede Anfrage nur CPU im Mikrosekundenbereich und rund 1 MB RAM verbraucht, ist die Verarbeitung auf dem Server leicht genug.