FOSS-Infrastruktur wird von KI-Unternehmen angegriffen

 (thelibre.news)
1 Punkte von GN⁺ 2025-03-21 | 1 Kommentare | Auf WhatsApp teilen
  • Mehrere FOSS-Infrastrukturen wie SourceHut, KDE GitLab, GNOME GitLab, LWN, Fedora, Inkscape, Diaspora und Read the Docs leiden unter Ausfällen, Sperren und zusätzlichem Betriebsaufwand durch KI-Crawler und KI-generierte Sicherheitsberichte
  • Die Crawler ignorieren robots.txt oder rufen wiederholt teure Endpunkte wie git blame, Git-Logs und Commit-Seiten ab und versuchen, sich mit Zehntausenden IPs und gefälschten User-Agents unter normalen Nutzer-Traffic zu mischen
  • GNOME führte den Anubis-Proof-of-Work ein, doch in rund 2 Stunden und 30 Minuten kamen von 81.000 Anfragen nur 3 % durch, was nahelegt, dass der Großteil des Traffics Bots gewesen sein könnte
  • Als Gegenmaßnahmen folgten das Blockieren bestimmter Edge-Versionen, Einschränkungen für nicht angemeldete Nutzer, Subnetz- und Ländersperren, IP-Blocklisten sowie robots.txt- und .htaccess-Regeln für KI-Crawler; auch echte Nutzer erlebten dadurch Verzögerungen oder Zugriffssperren
  • Open-Source-Projekte, die auf öffentliche Zusammenarbeit angewiesen sind, haben eine größere Angriffsfläche als private Dienste; KI-Scraping und halluzinierte LLM-Sicherheitsberichte zehren direkt an der Zeit und Betriebskapazität der Maintainer

Wiederholte Ausfälle bei mehreren FOSS-Infrastrukturen

  • Drew DeVault, Founder und CEO von SourceHut, kritisierte, dass LLM-Unternehmen Daten crawlen, ohne robots.txt zu respektieren, und dadurch schwere Störungen bei SourceHut verursachen
  • Die KDE-GitLab-Infrastruktur wurde durch KI-Crawler von IPs aus dem Alibaba-Bereich überlastet, sodass KDE-Entwickler zeitweise nicht auf GitLab zugreifen konnten
  • Auf GNOME GitLab erschien erstmals der Standard-Ladebildschirm der Anubis-Proof-of-Work-Challenge, die störende KI-Scraper abwehren soll
  • Mit der Häufung solcher Fälle werden KI-Scraper aggressiver, und der Betriebsaufwand für FOSS-Communities, die auf öffentliche Zusammenarbeit ausgelegt sind, steigt

Funktionsweise der Crawler und Schwierigkeiten beim Blockieren

  • Laut Drew DeVault halten sich LLM-Crawler nicht an robots.txt-Vorgaben und durchsuchen ganze Repositories bis hin zu besonders kostspieligen Seiten
    • Dazu gehören git blame, alle Seiten der Git-Logs und sämtliche Commits eines Repositories
    • Die Crawler verwenden zufällige User-Agents von Zehntausenden IPs aus, wobei jede IP höchstens eine HTTP-Anfrage sendet, um im Nutzer-Traffic unterzugehen
  • Diese Vorgehensweise erschwert Gegenmaßnahmen, und bei SourceHut verzögerten sich Arbeiten mit hoher Priorität um Wochen oder Monate
  • Weil Bots und Menschen schwer zu unterscheiden sind, wurden auch echte Nutzer zeitweise beeinträchtigt, was zu Ausfällen bei SourceHut führte
  • Drew unterscheidet dabei nicht, ob alle KI-Unternehmen robots.txt oder die Angabe von User-Agents auf dieselbe Weise behandeln

Reaktionen von KDE und GNOME

  • Laut Ben aus dem KDE-Sysadmin-Team gaben sich alle IPs, die bei KDE GitLab einen DDoS verursachten, als MS Edge aus; verantwortlich seien chinesische KI-Unternehmen gewesen
    • Ben geht davon aus, dass westliche LLM-Betreiber wie OpenAI und Anthropic zumindest korrekte User-Agents setzen
    • Die temporäre Lösung bestand darin, die Edge-Version zu blockieren, als die sich die Bots ausgaben
    • Da Bots dazu neigen, den User-Agent zu ändern, um sich besser einzufügen, ist dies als endgültige Lösung kaum geeignet
  • GNOME hatte seit vergangenem November Probleme und führte Rate Limits ein, die nicht angemeldete Nutzer daran hinderten, Merge Requests und Commits anzusehen
    • Diese Maßnahme verursachte auch Probleme für echte, nicht angemeldete Nutzer
  • Später wechselte GNOME zu Anubis
    • Anubis stellt dem Browser eine Rechenaufgabe; wenn der Browser nach einiger Zeit die Lösung an den Server sendet, wird der Zugriff erlaubt
    • Ein Entwickler beschrieb dies als „nahe an einer nuklearen Option“ und sah es als erzwungene Wahl, weil KI-Scraper-Bots Standards wie robots.txt nicht befolgen
  • Auch Anubis hat Auswirkungen auf Nutzer
    • Wenn viele Personen am selben Ort einen Link öffnen, kann eine schwierigere Aufgabe gestellt werden
    • Ein Nutzer erlebte eine Verzögerung von 1 Minute, ein anderer musste auf dem Smartphone etwa 2 Minuten warten
    • Solche Situationen traten auf, wenn ein GitLab-Link in einem Chatraum gepostet wurde oder ein Triple-Buffering-GNOME-Merge-Request auf Hacker News Aufmerksamkeit erhielt
  • Nach Zahlen, die GNOME-Sysadmin Bart Piotrowski teilte, bestanden in rund 2 Stunden und 30 Minuten von insgesamt 81.000 Anfragen nur 3 % den Anubis-Proof-of-Work
    • Anubis-Erfolgsquote: {p:3}
    • Das deutet darauf hin, dass 97 % des Traffics Bots gewesen sein könnten

Blockierfälle bei LWN, Fedora und Inkscape

  • Jonathan Corbet, Betreiber von LWN, informierte Nutzer, dass die Website wegen eines DDoS durch KI-Scraper-Bots „gelegentlich langsam sein kann“
    • Der Traffic, der echten menschlichen Lesern bereitgestellt wird, sei nur ein kleiner Teil des Gesamttraffics
    • Die Bots hätten zeitweise gleichzeitig von Hunderten IPs zugegriffen, sich nicht als Bots identifiziert und lediglich robots.txt nicht gelesen
  • Auch Kevin Fenzi, Sysadmin des Fedora-Projekts, hatte Probleme mit KI-Scrapern
    • Vor einem Monat musste er Maßnahmen ergreifen, um pagure.io am Laufen zu halten
    • Danach verschlechterte sich die Lage, sodass mehrere Subnetze blockiert wurden; auch echte Nutzer waren betroffen
    • In einer Notlage wurde ganz Brasilien blockiert, und diese Sperre besteht nach seinem Verständnis weiterhin
  • Neal Gompa wies darauf hin, dass auch das Blockieren ganzer Länder Grenzen hat und die Fedora-Infrastruktur wegen KI-Scrapern „über Wochen hinweg regelmäßig ausgefallen“ sei
  • Auch Inkscape hatte in der vergangenen Woche dasselbe Problem
    • Martin Owens sah darin nicht den üblichen chinesischen DDoS des Vorjahres, sondern eine Situation, in der mehrere Unternehmen Spider-Einstellungen ignorierten und Browserinformationen fälschten
    • Er erstellte die Prodigius-Blockliste und sagte, wer bei einem großen KI-Unternehmen arbeite, könne möglicherweise nicht mehr auf die Inkscape-Website zugreifen

IP-Blocklisten und Versuche gemeinsamer Gegenmaßnahmen

  • Auch BigGrizzly von Frama software wurde von schlechten LLM-Crawlern geflutet und erstellte eine Blockliste mit 460.000 IPs, die gefälschte User-Agents verwenden
    • Er sagte, er könne diese Liste teilen
  • Das Projekt ai.robots.txt ist ein umfassenderer Versuch, eine öffentliche Liste von Webcrawlern im Zusammenhang mit KI-Unternehmen zu erstellen
    • Es stellt eine robots.txt bereit, die das Robots Exclusion Protocol implementiert
    • Außerdem bietet es eine .htaccess-Datei, die für Anfragen der gelisteten KI-Crawler Fehlerseiten zurückgibt

Traffic-Zahlen von Diaspora und Read the Docs

  • Dennis Schuberts Analyse der Diaspora-Infrastruktur zeigt, dass ein erheblicher Teil des gesamten Web-Traffics von Bots von KI-Unternehmen stammt
    • Bots mit OpenAI-User-Agent machen ein Viertel des gesamten Web-Traffics aus
    • Amazon kommt auf 15 %, Anthropic auf 4,3 %
    • Insgesamt wurden etwa 70 % aller Anfragen KI-Unternehmen zugerechnet
  • Schubert sagt, diese Bots crawlen nicht einmal und verschwinden dann wieder, sondern kommen alle 6 Stunden erneut und kümmern sich nicht um robots.txt
    • Wenn Rate Limits gesetzt werden, wechseln sie auf andere IPs
    • Wenn man sie über den User-Agent-String blockiert, ändern sie ihn zu einem String, der nicht nach Bot aussieht
    • Er bezeichnete dies als DDoS gegen das gesamte Internet
  • Read the Docs erklärte im Beitrag „AI crawlers need to be more respectful“, dass der Traffic nach dem Blockieren aller KI-Crawler um 75 % sank
    • Traffic-Rückgang: {p:75}
    • Der Traffic fiel von 800 GB pro Tag auf 200 GB pro Tag
    • Dadurch werden monatlich rund 1.500 US-Dollar eingespart
    • Es gab auch Fälle, in denen Crawler innerhalb weniger Tage Dutzende TB Daten herunterluden
    • Wegen der Verwendung mehrerer IPs ist eine vollständige Blockierung schwierig
  • Laut Schubert machen „normale“ Crawler wie Google und Bing zusammen weniger als 1 % aus

Wartungsaufwand durch KI-generierte Sicherheitsberichte

  • Das Problem beschränkt sich nicht auf Scraper, sondern greift auch auf KI-generierte Bug-Reports über
  • Daniel Stenberg vom Curl-Projekt behandelte das Problem KI-generierter Bug-Reports in seinem Beitrag „The I in LLM stands for Intelligence“
    • Curl betreibt ein Bug-Bounty-Projekt
    • In letzter Zeit wurden viele Bug-Reports mit KI generiert, und sie wirken oberflächlich plausibel, sodass Entwickler Zeit für ihre Prüfung aufwenden müssen
    • Die Berichte enthalten jedoch typische Halluzinationen, wie man sie von KI erwartet
  • Seth Larson, der in den Security-Report-Triage-Teams von CPython, pip, urllib3 und Requests mitarbeitet, erlebt ähnliche Probleme
    • Bei Open-Source-Projekten nehmen extrem minderwertige und spamartige halluzinierte LLM-Sicherheitsberichte zu
    • Solche Berichte können auf den ersten Blick legitim wirken, weshalb Zeit nötig ist, um sie zu widerlegen
  • Die Bearbeitung von Sicherheitsberichten ist teuer, und der Umgang mit plausibel wirkenden, aber erfundenen Bug-Reports verursacht für Maintainer einen erheblichen zusätzlichen Aufwand
  • Larson bittet darum, keine KI- oder LLM-Systeme zur Erkennung von Schwachstellen zu verwenden
    • Aktuelle Systeme könnten Code nicht verstehen; die Erkennung von Sicherheitslücken erfordere Codeverständnis sowie ein Verständnis menschlicher Konzepte wie Absicht, übliche Nutzungsmuster und Kontext

Strukturelle Belastung, die FOSS besonders trifft

  • FOSS-Projekte haben oft weniger Ressourcen als kommerzielle Produkte
  • Bei Community-getriebenen Projekten sind größere Teile der Infrastruktur öffentlich, wodurch sie stärker Crawlern ausgesetzt sind
  • Weil öffentliche Issues, Sicherheitsmeldungen und Kollaborationsinfrastruktur nötig sind, werden KI-Scraper und KI-generierte Issues gleichzeitig zur Belastung
  • Letztlich verbrauchen Ausfallbehebung, Blockierregeln, Schadensbegrenzung für Nutzer und die Prüfung falscher Sicherheitsberichte die Zeit von Open-Source-Maintainern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-21
Meinungen auf Hacker News

  • Hier gibt es auch so einen Fall: https://about.readthedocs.com/blog/2024/07/ai-crawlers-abuse... Das ist ein Beitrag, der auch im Original zitiert wird; Bekannte von mir, die große Internet-Infrastrukturen betreiben, erleben alle Ähnliches.
    Dieser Artikel sammelt solche Fälle sehr gut an einem Ort. Wie ich schon beim Schreiben sagte: Sie verbrennen gerade einfach ihr Vertrauenskapital vollständig.
    Eines der großen Startups in diesem Bereich hat direkt mit uns zusammengearbeitet, die Kosten erstattet und auch den Crawler-Bug behoben. Facebook dagegen hat nicht auf E-Mails geantwortet, und der Link im User Agent führte zu einem 404. Ein Ingenieur des Unternehmens sah den Beitrag und gab uns die richtige E-Mail-Adresse, aber selbst nachdem wir dreimal dorthin geschrieben hatten, kam keine Antwort.

    • AI-Unternehmen scheinen so zu agieren, als wäre Vertrauenskapital nicht wichtig. Sie verhalten sich wie ein 800-Pfund-Gorilla mit 100 Milliarden Dollar Kapital und tun, was sie wollen.
      Die Haltung ist: Ob man will oder nicht, AI wird in jedes Produkt eingebaut, und ob man will oder nicht, alle Daten werden aufgesaugt.
    • Bei der Stelle „Ein Crawler hat im Mai 2024 73 TB komprimierte HTML-Dateien heruntergeladen, was mehr als 5.000 Dollar Bandbreitenkosten verursachte“ musste ich noch einmal nachlesen.
      Ich betreibe eine Infrastruktur, die vor allem auf dedizierten Servern monatlich mehrere Hundert TB Traffic verarbeitet, und die Traffic-Kosten liegen grob bei 0,50 bis 3 Dollar pro TB. Das hängt zwar von der Region ab, aber die Kosten für AWS-Egress-Traffic sind wirklich völlig verrückt.
    • Wenn es keine Antwort gibt, kann man statt einer E-Mail einfach eine Rechnung an das Accounts-Payable-Team schicken.
    • Wenn auch nach drei E-Mails keine Antwort kam, müsste man das Crawling ab diesem Zeitpunkt nicht als Bug oder Versehen, sondern als DDoS betrachten?
    • Wie wäre es, ihnen einfach dynamisch generierten Müll als Informationen zu füttern? Klingt interessanter, als gar keine Informationen zu liefern.

  • Es fühlt sich wirklich surreal an, mein Projekt so im Vorschaubild zu sehen. Großartig! Wenn ihr es ausprobieren wollt, ist es hier: https://github.com/TecharoHQ/anubis
    Soweit ich bisher sehe, scheint es tatsächlich zu funktionieren. Ich habe es auf xeiaso.net ausgerollt, um in Produktion zu sehen, wie es auf meinem Blog scheitert.

    • Es wäre gut, Menschen ein wenig zu erklären, was sie gerade tun sollen und was auf dieser Seite passiert.
      Es gibt zwar so etwas wie ein Ladeanimations-Widget, aber als ich es vor ein paar Wochen zum ersten Mal im Gnome-Issue-Tracker sah, dauerte der Proof of Work etwa 20 Sekunden, und ich wusste nicht, was los war. Zuerst dachte ich, ich sei blockiert worden oder das Captcha sei nicht geladen.
      Jetzt weiß ich, was es ist, aber wenn man nur die Seite „Prüfen, ob du ein Bot bist“ sieht, wirkt es nicht zu 100 % eindeutig.
    • Mir gefällt dieser Ansatz wirklich. Dass sich das Internet wie der Wilde Westen verhält, ist in Ordnung, aber ich mag es nicht, wenn es keine Verantwortlichkeit gibt.
      Das ist eine gute Methode für Leute, die ihre Website weiterhin kostenlos offen halten wollen, die wirtschaftliche Last auf die Crawler zu verlagern. Wenn sie die Daten wollen, sollen die Abholer das Geld ausgeben.
      Der Nachteil ist, dass man aus Suchmaschinen herausfallen kann, aber es gibt keinen Grund, warum man den Dienst nicht in globale oder P2P-Indexer eintragen könnte.
    • Gefällt mir; wie immer gut gebaut.
      Und zu https://news.ycombinator.com/item?id=43422781: Wenn man eine Methode anhängt, um winzige Beträge irgendeines gewünschten Shitcoins zu berechnen, entstünde vielleicht ein weiterer tatsächlich nützlicher Anwendungsfall für Kryptowährungen.
    • Anubis wird nur funktionieren, solange es nicht bekannt ist. Sobald es bekannt wird, werden die Crawler anfangen, den Proof of Work mit GPU/ASIC zu erledigen, und dann ist es vorbei.
    • Ich mag es, gelegentlich zufällig auf etwas zu stoßen, das du gebaut hast. Mir gefällt auch die erklärende Blog-Form, daher werde ich mir Anubis genauer ansehen.

  • Bei diesem Tempo ist das nicht nur ein Problem der freien und Open-Source-Infrastruktur. Natürlich ist sie der Kanarienvogel im Kohlebergwerk, deshalb berührt es besonders, aber am Ende geht es um anonymen Internetzugang insgesamt.
    Man kann eine Website zwar hinter eine Authentifizierungswand stellen, aber neue Bots lösen Captchas und imitieren echte Nutzer, anders als früher. Erst recht, wenn sie private IP-Adressen und gefälschte User Agents nutzen – oder, wie im Artikel beschrieben, sogar echte User Agents, die an Dinge wie Playwright gekoppelt sind.
    Was bleibt am Ende anderes übrig, als dass Websites anfangen, Kreditkarten, Worldcoin oder ähnlich deprimierende Alternativen zu verlangen?

    • Wir sind schon etwa auf halbem Weg. Das merke ich jedes Mal, wenn ich beim Mapping für OpenStreetMap nach lokalen Unternehmen suche, die keine eigene Website haben.
      Sie nutzen Facebook, Instagram, X usw. wie digitale Visitenkarten. Ich nutze Facebook oder Instagram normalerweise nicht, habe X aufgegeben und habe dort auch keine Konten. Wenn man solchen Links folgt, sieht man nur einen Teil der Informationen, dann erscheint ein Dialog, der einen auffordert, ein Konto zu erstellen oder zu gehen, oder es kommt ein unbekannter Fehler.
      Einer privaten Community beizutreten ist in Ordnung, aber es ist wirklich nervig, wenn solche Barrieren vor Informationen auftauchen, die die Leute offenbar in der Annahme gepostet haben, sie seien öffentlich sichtbar.
    • Um den leisen Teil laut auszusprechen: Einer der deprimierendsten Aspekte daran ist, dass es nicht nur Zerstörung ist, sondern Zerstörung, bei der sich für die beteiligten Bösewichte der Nutzen mit Zinseszins aufbaut. Das Abgreifen von Inhalten ist nur der Anfang.
      Steigende Kosten führen dazu, dass eine Website dauerhaft offline geht? Großartig, dann müssen die Leute für alle Dokumente KI nutzen. Man drängt sie weg von Captchas und hin zu Kreditkarten oder Telefonnummern? Großartig, dann nimmt die Anonymität im Internet weiter ab.
      Datenlecks führen zu mehr Betrug? Großartig, dann wird man KI brauchen, um das zu verhindern. Für böswillige Akteure ist das fast ein Spiel, in dem alle gewinnen.
      Über die Balkanisierung des Internets wird seit Langem gesprochen. Man könnte meinen, solche Bedrohungen oder die Tatsache, dass es ohnehin schon eine außer Kontrolle geratene Müllhalde ist, würden eine gewisse Zurückhaltung schaffen, die Lage noch weiter zu verschlechtern. Aber das Ausreizen der Grenzen dessen, wie viel Belästigung und Reibung Menschen ertragen können, spielt letztlich keine Rolle. Denn sie haben keine echte Wahl.
    • Ich weiß nicht so recht. Ich betreibe ein kleines Browsergame, und mein Server wird regelmäßig von LLM-Scrapern komplett verprügelt, aber ich habe bisher noch kein einziges neues Konto gesehen, das nach Bot-Erstellung aussieht.
      Auch die Rate neuer Registrierungen hat sich nicht merklich verändert. Das gilt sowohl für das Spiel als auch für das Wiki, wobei sich der Scraping-Traffic größtenteils auf das Wiki konzentriert hat. Wenn das Scraping nicht zurückgeht, werde ich das Wiki wahrscheinlich fast vollständig hinter eine Authentifizierungswand stellen müssen.
    • Es könnte darauf hinauslaufen: Um die nächsten X Anfragen stellen zu dürfen, musst du so und so viele Tokens verarbeiten. Klingt natürlich ziemlich utopisch.
    • Man muss es nicht unbedingt hinter eine Authentifizierungswand stellen. Es wäre durchaus möglich, für jede Anfrage einen anonymen Micropayment-Dienst zu verwenden.
      Wenn ein Internet, in dem zu viele Besucher zur Existenzbedrohung für eine Website werden, unser Internet ist, dann ist es nicht auf langfristiges Überleben ausgelegt.

  • Als Suchmaschinen früher so etwas verursachten, einigte sich die Branche, um gesetzliche Regulierung zu vermeiden, und schuf die robots.txt-Spezifikation. Deshalb entstand kein rechtlicher Rahmen.
    Heute gibt es eine neue Generation hungriger Indexer, die an dieser Einigung nicht beteiligt war, unter Wettbewerbsdruck so viele Daten wie möglich zusammenkratzen will und robots.txt einfach ignoriert.
    Eigentlich hätte es trotzdem Gesetzgebung geben müssen, und wer robots.txt ignoriert, hätte blockiert, mit Geldstrafen belegt oder per Rate Limit gedrosselt werden müssen.

    • Ich bin mir nicht sicher, ob mir dieser Plan gefällt. Illegale KI darf nicht mehr Wissen und Nützlichkeit haben als legale KI.
      Es gibt auch andere Optionen als ein vollständiges Verbot.
    • Ich wäre überrascht, wenn auch nur ein einziges Mitglied des US-Repräsentantenhauses oder des Kongresses wüsste, was robots.txt ist.
    • Wie sollen Gesetze der USA oder der EU Traffic aus China, Thailand oder Russland stoppen? Im besten Fall würde das das Internet fragmentieren, und das ist weder „das Beste“ noch eine gute Idee, sondern furchtbar.

  • Ich wurde kürzlich ebenfalls angegriffen [0]. Es ist eine kleine Forgejo-Instanz, auf der ich Code für mehrere Open-Source-Pakete hoste, sie muss also öffentlich sein. Sie wurde völlig zerlegt, und die erzeugten ZIP-Archive füllten die Festplatte.
    Ich bin nicht der Einzige, dem das passiert ist. In meinem Fall ließ der Angriff vorerst nach, nachdem ich die IP-Bereiche von Alibaba Cloud blockiert hatte.
    Wenn ihr eine Forgejo-Instanz betreibt, empfehle ich dringend, DISABLE_DOWNLOAD_SOURCE_ARCHIVES auf true zu setzen. Die Crawler werden weiterhin die CPU fest im Griff haben, aber wenigstens wird eure Festplatte nicht mit ZIP-Dateien volllaufen.
    [0] https://blog.nytsoi.net/2025/03/01/obliterated-by-ai

    • Dass „die erzeugten ZIP-Archive die Festplatte füllten“, ist schlicht schlechtes Softwaredesign, das ZIP-Dateien ad hoc erzeugt.
    • Vielleicht wäre es besser, auf gut gemachte Software umzusteigen, die ordentlich dafür entworfen wurde, im öffentlichen Internet betrieben zu werden.
      Ein Design, das ZIP-Dateien erzeugt, sie komplett auf die Festplatte schreibt und sie dann auf einmal an den Client schickt, ist völlig grauenhaft und unbrauchbar. Ein ordentliches Design würde sie inkrementell erzeugen und an den Client streamen, mit minimalem Speicherverbrauch und ganz ohne Festplattennutzung.
      Dass es ein derart unsinniges Design gibt, ist ein Signal dafür, dass den Entwicklern Effizienz ziemlich egal war, und wahrscheinlich gibt es noch viele ähnliche gravierende Probleme.
      Wenn man zum Beispiel grob in den Forgejo-Quellcode schaut, scheint es so, als würde für alle Git-Operationen ein „git“-Prozess gestartet, statt eine dedizierte Bibliothek zu verwenden. Ich habe das nicht überprüft, aber es würde mich nicht überraschen, wenn solche Operationen sehr weit von der effizientesten Art entfernt sind, die jeweilige Operation auszuführen.
      Wenn man derart extrem mangelhafte Software betreibt, ist es auch nicht überraschend, dass die CPU bei 100 % festhängt und der Server unbenutzbar wird.

  • Die große Schlussfolgerung hier ist, dass Googles und generell die Web-Dominanz der Werbung verschwindet.
    Die einzige Möglichkeit, Bots zu blockieren, sind Captchas; dann können aber auch Such-Indexer die Website nicht mehr indexieren. Am Ende können Suchmaschinen Websites nicht mehr indexieren und liefern keinen Mehrwert mehr.
    Es wird zwar eine gewisse Verzögerung geben, bis das in LLMs enthaltene Wissen austrocknet, aber niemand wird das Web noch automatisiert scrapen können.
    Es wirkt, als würde alles abbrennen.

    • In der Praxis wird es wohl eher eine Ljapunow-Stabilität wie bei Wolf- und Kaninchenpopulationen. In diesem Szenario sind wir die Kaninchen.
      Wenn die KI-Population schrumpft, nimmt menschlicher Content zu; das liefert der KI mehr Nahrung, sodass sie wieder wächst. Dann wird menschlicher Ausdruck übertönt, und Menschen werden leiser. Wenn die Nahrung für KI abnimmt und die KI zurückgeht, sinkt der Lärm, und Menschen werden wieder größer. Dieser Kreislauf wiederholt sich bis zum Überdruss.
    • Persönlich glaube ich, dass genau das eine der eigentlichen Motivationen hinter Web Environment Integrity war: Google kann indexieren, andere nicht.
      Wir stecken in einer unangenehmen Entweder-oder-Situation. Wollen wir die fest etablierten Platzhirsche, oder wollen wir günstiges, offenes Hosting?
    • Google scraped Websites schon jetzt und zeigt die Antwort direkt in den Suchergebnissen. Wenn mir Traffic wichtig ist und ich Werbeflächen verkaufen will: Warum sollte ich dann noch wollen, dass Google meine Website indexiert?
      Viele werbefinanzierte Websites werden dunkel werden. Die Besucher werden schließlich nur Bots sein.
    • Wenn wir zu authentifiziertem Crawling übergehen müssen, wird das die Position der bestehenden Suchmaschinen weiter stärken. Denn nur eingeladene Crawler erhalten Zugriff.
      Wenn es ein einfaches Tool gibt, werden die meisten nur Google, Bing und höchstens noch ein oder zwei weitere zulassen.
    • Das KI-Unternehmen mit der besten Captcha-Umgehungstechnik wird gewinnen und Werbung auf ausgefeiltere Weise in LLM-Ausgaben einfügen.

  • Falls jemand Interesse an kleiner Sabotage hat: Ich glaube, ich habe es geschafft, die echten Informationen in meinem Mikroblog ein Stück weit zu „ertränken“.
    Ich habe mit LLaMa pro echtem Beitrag Dutzende widersprüchliche Beiträge erzeugt und sie unsichtbar verlinkt, damit Menschen nicht darauf klicken. Sozusagen im Bannon-Stil die Zone mit Müll fluten.

    • Ich habe schon gesehen, dass dieser Ansatz verwendet wird, kenne aber die Erfolgsquote nicht. Logisch klingt es plausibel.
      Man verweist explizit auf Pfade, die Menschen praktisch nicht sehen können, und betrachtet Traffic auf diese Pfade als Bots. Bots können einfach nicht widerstehen.
    • Stimmt. Allerdings sollte man es unbedingt in robots.txt aufnehmen, damit nur die bösen Roboter Schaden nehmen.
    • Ich habe das gestern gelesen und darüber nachgedacht, wie man es in größerem Maßstab abmildern könnte: Eine Website erzeugt zufällige virtuelle Pfade oder Endpunkte, leitet Bots in eine lokal bereitgestellte Library of Babel[0] und kontaminiert Spider mit nutzlosem Text.
      Gegen gut strukturierte Sites, bei denen der Bot genau weiß, welche Endpunkte er scrapen will, funktioniert das nicht, aber explorativere Spider-Threads könnte es verlangsamen.
      [0] https://libraryofbabel.info/
    • Statt nur mit Müll zu fluten: Wie wäre es mit direkter Sabotage, etwa ZIP-Bombs auszuliefern oder Rechenressourcen zu verschwenden?

  • VideoLAN hier.
    Bei uns werden Forum und GitLab ebenfalls von Bots von KI-Unternehmen bombardiert.
    Die meisten halten sich nicht an robots.txt.

    • Habt ihr dokumentiert, welche Maßnahmen ihr ergriffen habt, um das zu lösen?

  • Verrückt. Ich frage mich, ob wir am Ende bei einer Version des Webs landen, die nicht von Suchmaschinen indexiert wird. Also eher wie Browsing in den 90ern, wo Websites einander verlinken mussten, um bekannt zu werden.
    Mir gefällt, dass die Lösung gegen LLM-Scraping darin besteht, den Browser vor dem Zugriff einen Arbeitsnachweis erbringen zu lassen. Ich frage mich, ob neue Websites anfangen werden, so etwas einzuführen.
    Dann wären sie zwar nicht in Suchmaschinen indexiert, aber es würde helfen, geistiges Eigentum zu schützen.

  • Ich hatte bisher nie darüber nachgedacht, aber es ist verrückt, dass Unternehmen, die sowohl LLM-Produkte als auch Cloud-Computing-Dienste anbieten, doppelt verdienen.
    Sie bekommen ein LLM-Produkt, das sie verkaufen können, und kassieren zugleich die Egress-Traffic-Kosten und Compute-Kosten der gestiegenen Last. So gesehen: Welchen Anreiz hätten sie, sich um ineffizientes LLM-Scraping zu kümmern? Je chaotischer sie es lassen, desto mehr Geld verdienen sie über die Egress-Kosten für Cloud Storage in ihrem anderen Imperium.