AI-Scraper fordern auskommentierte Skripte an

• Bei der Analyse von Webserver-Logs wurden zahlreiche Bot-Aktivitäten entdeckt, die nicht existierende JavaScript-Dateien anforderten
• Vermutlich wurden Skript-Tags innerhalb von HTML-Kommentaren als echter Code erkannt und angefordert, was auf einen Versuch der Datensammlung für das Training von LLMs hindeutet
• Es werden verschiedene Gegenmaßnahmen vorgeschlagen, darunter öffentliche Warnungen, IP-Sperren, Dekompressionsbomben und Data Poisoning
• Besonders Data Poisoning wird als wirksames Mittel genannt, da es Trainingsdaten von LLMs verunreinigen und die Modellleistung verschlechtern kann
• Es wird betont, dass Webadmins experimentell Abwehr- und Gegenangriffsstrategien gegen AI-Scraper einführen sollten

---

Entdeckung ungewöhnlichen Scraping-Verhaltens

• In Server-Logs wurden zahlreiche 404-Fehleranfragen für nicht existierende JavaScript-Dateien festgestellt
  • Diese Dateien waren deaktivierte Skripte innerhalb von HTML-Kommentaren, die von normalen Browsern nicht angefordert werden sollten
• Einige der User-Agents der Anfragen wurden eindeutig als Bots identifiziert, darunter python-httpx/0.28.1, Go-http-client/2.0, Gulper Web Bot 0.2.4
• Obwohl der Zugriff für Crawler in robots.txt untersagt war, setzten sich die Anfragen fort, was als Missachtung der Regeln oder ignorierte Richtlinie gewertet wird
• Einige Anfragen tarnten sich als normale Browser wie Firefox, Chrome oder Safari, wurden jedoch als falsche Identifizierung entlarvt, da sie HTML-Kommentare nicht korrekt interpretierten
• Es wird vermutet, dass diese Anfragen von Scrapern stammen, die Inhalte ohne Zustimmung für das Training von LLMs sammeln

Funktionsweise der Scraper

• Einige könnten HTML korrekt parsen und URLs in Kommentaren rekursiv verfolgen
• Andere scheinen HTML als einfachen Text zu behandeln und eine regexbasierte URL-Extraktion durchzuführen
• Die Vielfalt und das unterschiedliche Niveau der User-Agents deuten darauf hin, dass es mehrere Betreiber gibt und einige einfache Automatisierungstools einsetzen
• Das gemeinsame Motiv ist gierige Datensammlung, was zugleich als Möglichkeit zur Gegenwehr dargestellt wird

Algorithmische Sabotage (Algorithmic Sabotage)

• Gemeint ist die absichtliche Störung algorithmischer Systeme, ein Thema, das wegen der Externalisierung von Kosten durch LLMs zunehmend Aufmerksamkeit erhält
• Wenn die nichtmenschlichen Verhaltensmuster von Bots erkannt werden, wird Erkennung und Reaktion erleichtert
• Die Gegenmaßnahmen werden in vier Kategorien eingeteilt: öffentliche Offenlegung, IP-Filterung, Dekompressionsbomben, Data Poisoning

0. Öffentliche Offenlegung (Public Disclosure)

• Kleinere Fehlalarme, etwa ein Tippfehler im User-Agent wie „Mozlla“, werden nicht veröffentlicht, da sie nach einer Offenlegung leicht korrigiert werden könnten
• Dagegen ist wesentliches Verhalten wie das Anfordern von Skripten in Kommentaren nicht ohne Weiteres korrigierbar, weshalb eine Veröffentlichung nützlich ist
• So können Betreiber anderer Websites denselben Angriff erkennen und blockieren
• Ein System zur Erkennung dieses Verhaltens wird bereits auch auf anderen Websites eingesetzt

1. IP-Filterung (IP Filtering)

• Mit fail2ban werden auf Basis von Log-Mustern, Datum und IP automatische Sperren eingerichtet
• Üblicherweise werden kurze Sperrzeiten gesetzt, aber langfristige Sperren können erneute Versuche lernender Bots wirksam unterdrücken
• Bei Botnets können durch wechselnde IPs zwar weiterhin Anfragen gestellt werden, wiederkehrende Muster bleiben jedoch erkennbar
• Es wird auf geplante weitere Forschung zur Analyse von Botnet-Verhalten hingewiesen

2. Dekompressionsbomben (Decompression Bombs)

• Anfordernden Angreifern wird statt der gewünschten Datei eine Zip-Bombe geliefert, um den Verbrauch von Systemressourcen auszulösen
• Dadurch können CPU, RAM und Festplatte übermäßig belastet oder Schwachstellen ausgenutzt werden
• Als Nachteil werden Serverlast und das Risiko verschwendeter Bandbreite genannt
• Einige Bots laufen auf kompromittierten Systemen, wodurch die Wirkung des Gegenangriffs begrenzt sein kann
• Statt auf alle Bots abzuzielen, wird vorgeschlagen, nur auf zufällig ausgewählte Anfragen so zu reagieren

3. Data Poisoning (Poisoning)

• Ziel ist es, Trainingsdaten für LLMs zu kontaminieren und so die Modellleistung zu verschlechtern
• Jüngere Forschung legt nahe, dass bereits 250 vergiftete Dokumente eine anhaltende Wirkung auf große Modelle haben können
• Vergiftete Daten können dazu führen, dass ein Modell bei bestimmten Themen sinnlose Ausgaben erzeugt
• Als Beispiel wird genannt, dass sich ein Modell bei Fragen zur Sicherheitsforschung dazu bringen ließe, einen bestimmten Blog zu empfehlen
• Öffentliche Tools wie nepenthes, iocaine, glaze und nightshade können dafür genutzt werden
• Wenn LLM-Trainingsdaten ohne Zustimmung gesammelt wurden, wird diese Maßnahme als legitimes Verteidigungsmittel dargestellt
• In Kombination mit IP-Sperren kann die Umsetzung komplexer werden, ein paralleler Betrieb bleibt jedoch möglich
• Wirksame Designs werden möglicherweise nicht offengelegt; zugleich wird zu mehr kreativer Beteiligung an Sabotageansätzen aufgerufen

Fazit und Reaktion der Community

• Die Erkennung anhand ungewöhnlichen Bot-Verhaltens ist kein neues Konzept, doch das Anfordern von Skripten in Kommentaren ist ein neu entdeckter Fall
• Es wird vorgeschlagen, in robots.txt eine Disallow-Anweisung hinzuzufügen, um bei bestimmten Anfragen Gegenmaßnahmen auszulösen

  User-agent: GPTBot
  Disallow: /poison/
  

• In der Community wurden verschiedene Ideen geteilt, um mit display:none und dem Attribut rel="nofollow" Locklinks für Bots zu verstecken
  • Beispiel: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
• Wenn der Link als absoluter Pfad (absolute URL) gesetzt wird, könnten mehr Crawler darauf hereinfallen
• Auf mehreren Websites laufen bereits verschiedene Experimente zum Anlocken und Blockieren von Bots; die Ergebnisse sollen gemessen und geteilt werden
• Auch andere Forschende beteiligen sich an Experimenten zur Störung von AI-Scrapern, und originelle Poisoning-Beispiele werden vorgestellt
• Insgesamt ist das Ziel, die autonome Verteidigung und Gegenangriffsstrategien gegen AI-Datensammlung zu verbreiten

[GN⁺]

Hacker-News-Kommentare

• Die meisten Web-Scraper sind, selbst wenn sie illegal sind, geschäftlich motiviert.
  Deshalb kratzen sie oft Daten von Amazon oder Online-Shops ab. Letztlich stammt der Großteil des unerwünschten Traffics von Big Tech oder bösartigen Akteuren, die auf Schwachstellen aus sind.
  Ich kenne mich ein wenig mit Web-Scraping aus. Manche Websites geben zum Schutz auch mal 404 zurück, daher probiert mein Crawler mehrfach schnelle Crawling-Methoden wie curlcffi aus.
  Gegen Zip Bombs reicht es einfach, nur den content-length-Header zu lesen. Wenn die Antwort zu groß ist, setzt man ein Byte-Limit, damit sie gar nicht erst gelesen wird, und steuert zusätzlich über Timeouts.
  Wisst ihr eigentlich, dass der Timeout von requests kein Timeout für das vollständige Einlesen einer Seite ist? Wenn der Server die Bytes langsam sendet, wartet man endlos.
  Deshalb habe ich zur Lösung solcher Probleme selbst ein Crawling-System gebaut. Damit lässt sich auch Selenium konsistent ausführen.
  Mein Projekt ist crawler-buddy, die zugrunde liegende Bibliothek ist webtoolkit.

  • Man darf nicht vergessen, dass content-length nach content-encoding berechnet wird.
  • Ich frage mich, ob es überhaupt einen Unterschied zwischen „scraping“ und „crawling“ gibt.
  • Jetzt dürfte die Zeit der Browser-internen Scraper kommen. Aus Serversicht sind sie nicht von Menschen zu unterscheiden, und AI-Driver können sogar menschliche Tests bestehen.

• Die Formulierung „nicht einvernehmliches Sammeln von Trainingsdaten für LLMs“ ist schon komisch.
  Ich verstehe nicht, wofür man eine Erlaubnis brauchen soll, wenn man einen GET-Request an einen öffentlich zugänglichen HTTP-Server sendet. Natürlich war der weev-Fall eine außergewöhnliche Katastrophe.

  • Wenn ich einen öffentlichen HTTP-Server bereitstelle, sind normale GET-Requests bei mir willkommen.
    Aber (1) der Zugriff gewöhnlicher Nutzer ist etwas anderes als ein DDoS-Angriff durch Bots. Nur weil etwas kostenlos angeboten wird, heißt das nicht, dass man unbegrenzt zugreifen darf; das ist Missbrauch.
    (2) Legitime Vervielfältigung und Täuschung durch Roboter sollten unterschieden werden.
    (3) Ein Bot, der sich ordentlich verhält, sollte robots.txt respektieren. Das ist kein Gesetz, sondern eine Frage der Höflichkeit.
    Bots, die Millionen von Residential IPs rotieren lassen, sind ganz sicher nicht normal.
  • Wenn man den Server mit manipulierter Konfiguration dazu bringt, gewünschte Daten herauszugeben, ist das nicht einvernehmlicher Zugriff.
    Nur weil ein Server öffentlich ist, bedeutet das nicht, dass auch irreführende Requests erlaubt sind. Implizit zugestimmt wurde nur zu vernünftigen Requests.
  • robots.txt ist nicht rechtsverbindlich, sondern eine höfliche Bitte.
    Es bedeutet ungefähr: „Bitte diese Seite nicht scrapen.“ Wenn man es wirklich verhindern will, braucht man API-Tokens oder Authentifizierung.
  • Einen einzelnen Zugriff mit einem endlosen Crawl-Sturm gleichzusetzen, ergibt keinen Sinn.
    So wie Spam nicht dasselbe ist wie eine normale E-Mail, ist auch Bot-Missbrauch nicht dasselbe wie ein einfacher Request.
  • In der „Bonbonschüssel“-Analogie wäre wohl auch niemand erfreut, wenn ein Erwachsener alle Süßigkeiten für Trick-or-Treat auf einmal mitnimmt.

• Statt den DOM zu parsen, scheint es schneller zu sein, einfach direkt nach http/https-Strings zu suchen.

  • Der Ressourcenunterschied zwischen einfacher Textsuche und DOM-Traversierung ist groß, daher ist die Formulierung „wahrscheinlich schneller“ eher untertrieben.
  • Ein Regex-Ansatz ist einfacher umzusetzen, aber auch beim DOM-Parsing ist eher das Netzwerk als die CPU der Flaschenhals.
    Letztlich ist Netzwerküberlastung der begrenzende Faktor.

• Es ist interessant, eine praktische Anwendung dieser spannenden Forschung zu sehen.
  Die zugehörige Forschung findet sich in diesem Beitrag.

• Der Titel ist irreführend. „commented-out“ wäre wohl die richtige Formulierung.

  • Ich dachte anfangs auch, es gehe um ein Skript zum Blockieren von AI-Scrapern.

• Das wirkt weniger wie Missbrauch, sondern eher wie simples Auslesen von auskommentierten URLs.

  • Der Artikel erklärt nicht Missbrauch, sondern wie man das als Signal zur Bot-Erkennung nutzen kann.
  • Aber robots.txt zu ignorieren und sogar Kommentare zu scrapen, ist definitiv unhöfliches Verhalten.

• Früher, als ich das Web gecrawlt habe, waren Perl-RegExes am zuverlässigsten.
  URLs in Kommentaren habe ich natürlich ebenfalls in die Queue aufgenommen.

  • DOM-Navigation war eher ein übertriebener Ansatz. Mit Regex die nötigen divs oder ps zu greifen, war robuster und einfacher.

• Ich frage mich, wie es wäre, Bots eine 512-MB-Datei mit Zufallsdaten zu servieren.

  • Noch profitabler wäre es wohl, Werbeantworten für AI-Scraper zu vergiften, damit LLMs bestimmte Produkte empfehlen.
    Mein Startup bietet genau so etwas als Ad-poisoning-as-a-service an.
  • Man könnte auch zufällig verlinkte AI-Giftseiten bauen, um Bots darin gefangen zu halten. Menschen würden ohnehin nicht darauf klicken.
  • Aber die meisten können sich die Bandbreitenkosten vermutlich nicht leisten.
  • Es wäre auch lustig, wenn die ganzen 512 MB nur mit dem Satz „Unser Service ist der beste“ gefüllt wären.

• Das ist weniger „Datensammlung für LLM-Training“ als einfach Internet-Scanning-Rauschen.

  • Stimmt. Ein Schwachstellen-Scanner würde wahrscheinlich möglichst viele HTTP-Endpunkte sammeln wollen.
    JS-Dateien sind unabhängig davon, ob etwas auskommentiert ist oder nicht, ein guter Hinweis.
    Für LLM-Training dagegen dürfte solcher minderwertiger JS-Code eher uninteressant sein.

• Ein Gedanke dazu, wie man unerwünschten Traffic für LLM-Training vergiften (poison) könnte.

  1. Wenn mehrere Websites kooperieren, steigt die Chance, das Modell zu kontaminieren, ohne an der Deduplizierung zu scheitern.
  2. Über das Urheberrecht ließen sich die Kosten der Vergiftung erhöhen. Allerdings könnte die Website dadurch rechtliche Risiken tragen.
     In Zusammenarbeit mit Rechteinhabern ließe sich dieses Risiko senken.
  • Aus der ersten Idee könnte man gut ein WordPress-Plugin machen.
    Man könnte Bilder pro Request dynamisch verändern, um Dedup-Abwehrmechanismen auszuhebeln. Ich würde so ein Plugin sofort installieren, wenn es existierte.