Kernel.orgs Creepy Crawlies verwandeln offenen Zugang in eine CPU-Steuer

Konstantin Ryabitsev zufolge halten Creepy Crawlies inzwischen 14 bis 16 CPU-Kerne bei git.kernel.org beschäftigt – trotz Schutzmaßnahmen, die automatisiertes Scraping teuer machen sollen. Die Crawler rufen Millionen einzelner Commit-Seiten ab, statt die zugrunde liegenden Git-Repositories zu klonen. Damit verwandeln sie ein effizientes öffentliches Archiv in einen dauerhaften HTML-Rendering-Dienst für nicht identifizierte Maschinen.

Ryabitsev, ein an der kernel.org-Infrastruktur beteiligter Systemadministrator der Linux Foundation, veröffentlichte die Zahlen am 29. August 2026. Simon Willison hob sie am 7. September hervor, weil Datasette ein ähnliches Risikoprofil aufweist. Es kann eine Datenbank über eine enorme Sammlung nützlicher, crawlbarer Seiten zugänglich machen.

Die unmittelbare Geschichte betrifft die Linux-Infrastruktur, doch der Konflikt reicht weit darüber hinaus. Offene technische Archive wurden geschaffen, damit Menschen Informationen prüfen, referenzieren und bewahren können. Clients im Maschinenmaßstab können diese Offenheit in eine nicht bepreiste Rechenverpflichtung verwandeln.

Besonders deutlich ist diese Umkehrung bei git.kernel.org. Die Maintainer stellen die vollständige Repository-Historie bereits über Git bereit, ein Protokoll, das für die effiziente Übertragung dieser Historie entwickelt wurde. Berichten zufolge wählen Scraper dennoch den rechenintensiven Weg und fordern separat gerenderte Seiten für Commits, Patches und Diffs an.

Dieses Verhalten setzt Maintainer unter Druck, Schnittstellen einzuschränken, die legitime Entwickler nutzen. Der Dienst bleibt laut Ryabitsev reaktionsschnell, deaktiviert jedoch bereits Funktionen und stellt weitere Aktionen hinter Zugriffskontrollen. Die Kosten des Crawler-Ansturms werden daher nicht nur in CPU-Zeit, sondern auch in verlorener Offenheit gemessen.

Creepy Crawlies erzeugen sechs Millionen Anfragen pro Tag

Das Ausmaß ist groß genug, um Infrastruktur dauerhaft zu beanspruchen – selbst wenn die Website für menschliche Besucher gesund wirkt.

Ryabitsevs Crawler-Messungen beschreiben rund 6 Millionen tägliche Anfragen nach offenbar zufälligen Commits. Anubis, eine dem Hauptdienst vorgeschaltete Browser-Challenge, weist sofort etwa 66 % dieser Anfragen ab. Weitere 33 % lösen die Challenge und gelangen zu git.kernel.org.

Die Zahlen belegen nicht, dass jede abgewehrte Anfrage von einem KI-Unternehmen stammt. Ryabitsev sagt ausdrücklich, dass Betreiber nicht jeden Client mit Sicherheit identifizieren können. Eine Person kann einen alten Commit öffnen, während ein Bot einen aktuellen Browser imitieren kann.

Die Anfragemuster liefern die stärksten Hinweise. Ein Client, der sich durch nicht zusammenhängende Commits in alten, inaktiven Forks bewegt, ähnelt keinem Entwickler, der einer Patch-Serie folgt. Ryabitsev schätzt, dass legitime Aktivitäten selbst unter nutzerfreundlichen Annahmen etwa 2 % des Gesamtverkehrs ausmachen.

Die daraus resultierende Last belegt 14 bis 16 von 90 CPU-Kernen auf fünf geografisch verteilten Knoten. Das entspricht im Durchschnitt ungefähr 20 % der gesamten Verarbeitungskapazität des Dienstes. Der tatsächliche Bedarf kommt in Wellen, weshalb die Last weniger geordnet ist als eine feste Zuweisung von 20 %.

Diese Kerne erfüllen eine eng umrissene Aufgabe. Sie wandeln Git-Objekte in HTML-Seiten für Clients um, die anschließend die gerenderte Ausgabe parsen. Ryabitsev zufolge verbraucht diese Aktivität mehr CPU-Zeit als sämtliche Formen legitimen Zugriffs zusammen, einschließlich Git-Klonvorgängen.

Dieser Unterschied ist wichtig, weil ein Klon ein Repository über das native Objektmodell von Git überträgt. Der Client erhält die Historie und kann Commits lokal durchlaufen. Der Server muss nicht für jedes Objekt, das der Client prüfen möchte, erneut eine Darstellungsseite erzeugen.

HTML-Anfragen kehren diese Effizienz um. Jede Anfrage fordert den Server auf, Repository-Daten zu finden, cgit auszuführen und eine menschenlesbare Antwort zu erstellen. Nach dem Extrahieren des gewünschten Texts verwirft der Client einen Großteil der umgebenden Oberfläche.

Über Millionen von URLs hinweg wird eine einzeln betrachtet vernünftige Seite zu einem teuren Maschinenendpunkt. Herkömmliche Kapazitätsplanung behandelt Seitenaufrufe oft als Einheiten vergleichbarer Arbeit. Der Fall git.kernel.org zeigt, warum dieses Modell versagt, wenn eine URL deutlich mehr Berechnung auslösen kann als eine andere.

Der Dienst ist unter der derzeitigen Grundlast nicht zusammengebrochen. Ryabitsev zufolge können schlecht konzipierte Continuous-Integration-Systeme weiterhin akutere Ausfälle verursachen, insbesondere wenn viele Knoten gleichzeitig flache Klone durchführen. Crawler-Traffic schafft ein anderes Problem, weil er dauerhaft operative Reserven aufzehrt.

Diese verlorenen Reserven verringern die Toleranz gegenüber Traffic-Spitzen, Wartungsereignissen und legitimer Automatisierung. Außerdem zwingt sie Betreiber dazu, Zeit mit der Untersuchung gegnerischen Verhaltens zu verbringen, statt Dienste für Kernel-Entwickler zu verbessern. Eine scheinbar stabile Website kann somit erhebliche versteckte Kosten tragen.

Die entscheidende Veränderung besteht nicht darin, dass öffentlicher Quellcode heruntergeladen werden kann. Kernel.org unterstützt diese Nutzung bewusst. Die Veränderung besteht darin, dass nicht identifizierte Clients eine kostspielige Repräsentation wählen und sie im industriellen Maßstab anfordern.

Git macht die Daten günstig, aber HTML macht sie teuer

Im Kern geht es nicht um Zugang versus Geheimhaltung. Es geht um effizienten Massenzugang versus verschwenderische Extraktion Seite für Seite.

Die Linux-Entwicklung hat stets von Replikation profitiert. Git-Repositories können geklont, Mailinglisten-Archive kopiert und Spiegelungen über die Lebensdauer einzelner Server hinaus erhalten werden. Kernel.org fördert diese Redundanz, statt jeden Download als Bedrohung zu behandeln.

Git macht dieses Modell wirtschaftlich, indem es Objekte entsprechend ihrer Beziehungen überträgt. Ein Repository speichert Commits, Bäume und Dateiinhalte als adressierbare Objekte. Client und Server handeln aus, welche Objekte dem Client fehlen, und übertragen anschließend die notwendigen Daten, ohne um jeden Commit herum erneut eine Webseite zu erstellen.

Die Weboberfläche erfüllt einen anderen Zweck. Sie hilft Entwicklern, eine Änderung zu prüfen, einen stabilen Link zu teilen, Revisionen zu vergleichen oder einen Patch herunterzuladen, ohne ein großes Repository zu klonen. cgit, die von git.kernel.org verwendete Oberfläche, bietet mehrere Ansichten, weil jede einen legitimen menschlichen Arbeitsablauf unterstützt.

Diese Optionen vervielfachen auch die crawlbare Oberfläche. Das Haupt-Repository von Linux enthält laut Ryabitsevs Darstellung etwa 1,48 Millionen Commits. Git.kernel.org hostet etwa 922 Forks, die weitgehend dieselben zugrunde liegenden Objekte teilen.

Ein Crawler kann daher viele URLs entdecken, die zu doppeltem Commit-Inhalt führen. Er kann außerdem Patch-Ansichten, Klartext-Renderings, Repository-Bäume und beliebige Vergleiche anfordern. Der Inhalt ist endlich, doch der mögliche URL-Raum wird deutlich größer.

Dies ist ein bekanntes Fehlermuster bei datenbankgestützten Websites. Eine Datenbank kann eine überschaubare Zahl von Datensätzen enthalten, während ihre Oberfläche unzählige Kombinationen aus Filtern, Sortierungen, Seitennummerierungen und Vergleichen zulässt. Für einen wahllosen Crawler wirkt jede generierte Route wie ein weiteres Dokument.

Willison verknüpfte dieses Muster mit Datasette, seinem Open-Source-Tool zur Veröffentlichung durchsuchbarer Datenbanken im Web. Eine Datasette-Instanz kann strukturierte Informationen in durchsuchbare Seiten und Abfrageergebnisse verwandeln. Diese Zugänglichkeit ist für Menschen, Suchmaschinen, Forschende und assistive Werkzeuge wertvoll.

Sie kann jedoch auch kostspielige Parameterkombinationen offenlegen. Ein Bot benötigt keinen bösartigen Code, um schädliche Last zu erzeugen. Er muss lediglich Links aufzählen oder gültige URLs schneller konstruieren, als die Anwendung sie kostengünstig bedienen kann.

Dasselbe Risiko gilt für Dokumentationssysteme, Issue-Tracker, Code-Browser, Portale für öffentliche Aufzeichnungen und persönliche Archive. Websites, die strukturierte Daten bei Bedarf transformieren, sind anfälliger als statische Seiten, weil jeder Abruf Datenbankarbeit oder serverseitiges Rendering auslösen kann.

Caching hilft, wenn viele Clients dieselbe Ressource anfordern. Es hilft weniger, wenn Crawler Anfragen absichtlich oder versehentlich über einzigartige URLs verteilen. Abfrageparameter, beliebige Diffs und alte Forks können die Wiederverwendung unterlaufen, die einen Cache wertvoll macht.

Betreiber können populäre Seiten vorab rendern, doch jedes mögliche Vergleichsergebnis vorab zu rendern ist unmöglich. Sie können auch Massenexporte bereitstellen, doch ein auf Weblinks ausgelegter Crawler entdeckt oder wählt möglicherweise nie den effizienten Weg. Technische Verfügbarkeit garantiert kein vernünftiges Client-Verhalten.

Für Entwickler, die durchsuchbare Archive erstellen, ist dies eine architektonische Warnung. Maschinenzugang sollte, wo immer möglich, über begrenzte APIs, Feeds, Exporte oder Repository-Protokolle erfolgen. Menschliche Oberflächen benötigen Grenzen, die die Kosten für die Erzeugung jeder Antwort widerspiegeln.

Teams, die diese Entscheidungen dokumentieren, sollten operative Beschlüsse zudem gemeinsam mit dem Code bewahren. Eine durchsuchbare Engineering-Wissensdatenbank kann Crawler-Richtlinien, kostspielige Routen und Belege aus Vorfällen verbinden, bevor die nächste Traffic-Welle eintrifft.

Der Vorfall bei kernel.org zeigt, dass Bandbreite nur ein Teil der Rechnung ist. CPU-Zeit, Cache-Churn, Kosten für Observability und die Aufmerksamkeit von Betreibern können dominieren, wenn automatisierte Clients wiederholt dynamische Repräsentationen anfordern.

Anubis erhöhte den Preis, bis Crawler ihn zahlten

Proof of Work verringerte missbräuchlichen Traffic vorübergehend, doch hartnäckige Crawler passten sich an, weil die zugrunde liegenden Daten weiterhin wertvoll blieben.

Kernel.org setzte zunächst auf vertraute Schutzmaßnahmen. Betreiber identifizierten verdächtige User-Agent-Strings, prüften Logs und blockierten Adressen, die mit offensichtlicher automatisierter Datensammlung verbunden waren. Dieser Ansatz funktionierte, solange Crawler sich identifizierten oder aus einer überschaubaren Zahl von Netzwerken stammten.

Der Traffic wurde anschließend schwieriger zu klassifizieren. Ryabitsev beschreibt Clients, die sich als gewöhnliche Browser ausgaben und Anfragen über Cloud-Subnetze verteilten. Das Blockieren eines gesamten Netzwerks konnte Missbrauch stoppen, aber auch legitime automatisierte Prüfungen ausschließen, die beim selben Anbieter gehostet sind.

Die nächste Veränderung schwächte adressbasierte Kontrollen weiter. Anfragen trafen nun von einer großen Zahl privater und mobiler Adressen ein. Jede Adresse erzeugte laut Ryabitsev nur vier oder fünf Anfragen, bevor sie aus den Logs verschwand.

Dieses Muster ähnelt Proxy-Netzwerken, die Traffic über Geräte von Verbraucherinnen und Verbrauchern leiten. Eine Website sieht, was wie eine breite Bevölkerung nicht zusammenhängender Nutzer wirkt, statt eines konzentrierten Scraping-Vorgangs. Bis eine Adresse verdächtig erscheint, kehrt diese konkrete Quelle möglicherweise nie zurück.

Kernel.org reagierte mit Anubis, einer Open-Source-Web-Firewall, die Clients herausfordert, bevor sie einen Upstream-Dienst erreichen dürfen. Ihr zentraler Mechanismus ist Proof of Work, eine kleine mathematische Aufgabe, die für den Client vergleichsweise kostspielig, für den Server jedoch günstig zu prüfen ist.

Das Anubis-Projekt beschreibt die Software als Schutz für kleinere Internetdienste, die anhaltendem KI-Crawler-Traffic ausgesetzt sind. Die Maintainer bezeichnen sie zudem als drastische Maßnahme, weil Challenges kleine Scraper und legitime Archivierungs-Bots blockieren können.

Bei git.kernel.org veränderte die Challenge zunächst die wirtschaftlichen Bedingungen. Automatisierte Clients stellten ihre Zugriffsversuche ein, während menschliche Besucher eine geringe Verzögerung akzeptierten. Diese Phase dauerte mehrere Monate.

Die Bots begannen später, Schwierigkeitsstufe vier zu lösen. Betreiber erhöhten die Challenge auf Stufe fünf, was mehr Rechenleistung auf Client-Seite verlangte. Ryabitsev zufolge kann diese Einstellung auf einem Mobilgerät mehrere Sekunden dauern und das Telefon spürbar erwärmen.

Die höhere Schwierigkeit verschaffte erneut mehrere Monate. Sie verursachte jedoch auch höhere Kosten für jeden legitimen Besucher, der die Challenge erhielt. Die Barrierefreiheit leidet, wenn ältere Hardware, datenschutzorientierte Browser, deaktiviertes JavaScript oder instabile Verbindungen den erwarteten Ablauf nicht abschließen können.

Die Crawler lösten schließlich auch Stufe fünf. Zum Zeitpunkt von Ryabitsevs Bericht bestanden etwa ein Drittel der 6 Millionen täglichen Commit-Anfragen die Herausforderung. Proof of Work war nicht nutzlos geworden, da es weiterhin die anderen zwei Drittel stoppte, stellte aber das frühere Gleichgewicht nicht mehr her.

Dieses Ergebnis legt die zentrale Schwäche ökonomischer Abschreckung offen. Eine Herausforderung funktioniert nur, solange die Kosten den erwarteten Wert für den Scraper übersteigen. Wertvolle, saubere technische Historien geben Sammlern einen Grund, mehr Ressourcen einzusetzen.

Ryabitsev argumentiert, dass die Linux-Commit-Historie besonders attraktiv ist, weil ein Großteil davon vor der Verbreitung generierter Texte entstanden ist. Forschende befürchten, dass wiederholtes Training mit synthetischem Material die Modellqualität beeinträchtigen oder Artefakte verstärken kann. Das macht gut strukturierte, von Menschen erstellte technische Aufzeichnungen zu begehrtem Trainingsmaterial.

Die genauen Identitäten und Zwecke der Clients bleiben unbestätigt. Einige könnten das Modelltraining unterstützen, während andere Suchindizes, Code-Datensätze, Sicherheitsprodukte oder kommerzielle Archive aufbauen. Operativ ist ihr gemeinsames Verhalten wichtiger als ihre Bezeichnung.

Auch Anubis-Entwickler Xe Iaso hat eingeräumt, dass Proof of Work keine vollständige Antwort ist. In einer technischen Diskussion erklärte Iaso, dass der Mechanismus auf die Ökonomie massenhaften Scrapings zielt, äußerte jedoch Zweifel an seinem Nutzen gegen leistungsfähige verteilte Clients.

Ein Client mit Browserautomatisierung kann JavaScript ausführen, Cookies speichern und dieselbe öffentliche Herausforderung wie eine Person lösen. Verteilte Clients können die Arbeit auf viele Geräte aufteilen. Eine höhere Schwierigkeit droht dann legitime Besucher schneller zu bestrafen, als sie gut ausgestattete Sammler abschreckt.

Die Erfahrungen von Kernel.org bestätigen diesen Zielkonflikt anhand von Produktionsdaten. Die Abwehr funktionierte, die gegnerischen Clients passten sich an, und die Betreiber erhöhten die Kosten. Der Wettbewerb endete nicht, weil sowohl Angreifer als auch Verteidiger jeweils noch eine weitere Stellschraube hatten.

Offene Archive Werden Zum Abbau Nützlicher Funktionen Gedrängt

Das schädlichste Ergebnis ist keine höhere Serverrechnung. Es ist der schrittweise Rückzug des anonymen, menschenfreundlichen Zugangs.

Kernel.org plant, die Zahl crawlbarer URLs zu reduzieren und rechenintensive Vorgänge abzusichern. Ryabitsev warnt, dass anonyme Nutzer damit rechnen sollten, dass einige Funktionen verschwinden. Die zugrunde liegenden Daten bleiben zum Download verfügbar, ihr Abruf kann jedoch zusätzliche Schritte erfordern.

Für einen Infrastrukturbetreiber ist diese Reaktion rational. Wenn eine Schnittstelle unverhältnismäßig viel Last erzeugt, schützt ihre Einschränkung den Rest des Dienstes. Git-Clones und Entwickler-Workflows sind wichtiger als unbegrenztes anonymes Rendern beliebiger Vergleiche.

Doch jede Einschränkung verändert, wer das Archiv nutzen kann. Ein Entwickler mit installiertem Git kann ein Repository klonen und lokal untersuchen. Ein Student, der einem Link folgt, ein Journalist, der einen einzelnen Commit prüft, oder jemand mit einem eingeschränkten Gerät kann hingegen auf die Browseroberfläche angewiesen sein.

Auch automatisierte Recherchewerkzeuge können legitime Zwecke erfüllen. Suchindizierung hilft Nutzern, alte Fehlerbehebungen zu finden. Archivsysteme bewahren Beweise. Sicherheitsdienste verknüpfen Commits mit Schwachstellen. Barrierefreiheitswerkzeuge können Seiten auf eine Weise abrufen, die herkömmlichem Browsing nicht ähnelt.

Breite Einschränkungen können diese Clients nicht sauber von missbräuchlichen Sammlern trennen. Authentifizierung schafft Verantwortlichkeit, bringt jedoch Verwaltungsaufwand mit sich. Ratenbegrenzungen verringern Spitzenlasten, können aber scheitern, wenn Anfragen von verteilten Adressen eintreffen.

Das Blockieren privater Netzwerke würde echte Haushalte ausschließen. Das Blockieren von Cloud-Anbietern würde die Entwicklerautomatisierung beeinträchtigen. Die Forderung nach Proof of Work zwingt jeden Besucher, Strom und Zeit aufzuwenden, bevor der Server weiß, ob die Anfrage nützlich ist.

Robots.txt liefert ein Richtliniensignal, ist aber kein Zugangskontrollmechanismus. Der offizielle Robots-Standard stellt fest, dass seine Regeln keine Autorisierung darstellen. Kooperative Crawler befolgen die erklärten Präferenzen, während ein nicht identifizierter Client sie ignorieren oder sich als Browser ausgeben kann.

Das Ergebnis ist eine Asymmetrie. Verantwortungsvolle Organisationen identifizieren ihre Crawler, veröffentlichen Dokumentation, beachten Ausschlüsse und werden dadurch leicht blockierbar. Weniger verantwortungsvolle Sammler verbergen ihre Identität und verteilen ihren Traffic, was sie schwerer stoppbar macht.

Dies kann zu einem paradoxen Ergebnis führen, bei dem regelkonforme Crawler den Zugang verlieren, während ausweichende weiterhin aktiv bleiben. Außerdem wird die Zuordnung von Traffic unzuverlässig. Betreiber können eine Verhaltensklasse berechtigterweise als KI-Scraping beschreiben, ohne Anfragen einem namentlich bekannten Modellentwickler zuordnen zu können.

Diese Unsicherheit ist der zentrale skeptische Punkt dieser Geschichte. Ryabitsevs Traffic-Messungen sind direkte operative Belege, doch der Zweck hinter jeder Anfrage wurde nicht unabhängig festgestellt. Die Schätzung von 98 % betrifft scheinbares Scraping-Verhalten, keine bestätigte Liste von KI-Unternehmen.

Dieser Unterschied sollte sowohl Richtlinien als auch Berichterstattung prägen. Es wäre ungenau, die gesamte Last ohne Netzwerkbelege einem bestimmten Anbieter zuzuschreiben. Ebenso ungenau wäre es, das Problem abzutun, weil jeder Client keine öffentliche Identität besitzt.

Der messbare Schaden besteht auf der Anwendungsebene. Millionen von Anfragen wählen alte Commits, duplizieren Forks und lösen teure Renderings aus. Eine Schutzmaßnahme stoppt viele Anfragen, doch erhebliche Volumina entrichten den Rechenaufwand und machen weiter.

Cloudflare nähert sich dem umfassenderen Problem, indem es Website-Betreibern granularere Kontrollen für Such-, Agenten- und Trainings-Crawler bietet. Seine KI-Traffic-Kontrollen spiegeln einen wichtigen Unterschied wider, denn ein Modelltrainings-Crawler und ein von Nutzern angeforderter Assistent dienen nicht demselben Zweck.

Große Edge-Netzwerke können Adressinformationen, Browsersignale, Traffic-Historie und kundenübergreifende Beobachtungen kombinieren. Kleine Open-Source-Dienste verfügen selten über diese Sichtbarkeit. Sie müssen Entscheidungen anhand lokaler Logs und unvollständiger Kennungen treffen.

Diese Lücke konzentriert den Schaden auf Organisationen, die ihn am wenigsten tragen können. Eine große kommerzielle Plattform kann mehr Kapazität kaufen und spezialisiertes Bot-Management einsetzen. Ein Freiwilligenprojekt, akademisches Archiv oder unabhängiger Publisher kann teure Routen hingegen einfach schließen.

Das offene Web verliert dann mehr als nur einige Oberflächenfunktionen. Es verliert die Annahme, dass die Veröffentlichung nützlicher, verlinkbarer Informationen wirtschaftlich sicher ist. Seiten bleiben technisch öffentlich, doch der Zugang wird bedingt, herausforderungsbasiert oder nur über Workflows für Massendaten verfügbar.

Der Eigentliche Konflikt Lautet Offenheit Gegen Nicht Bepreiste Rechenleistung

Offene Daten erfordern nicht, dass jede mögliche Darstellung kostenlos, anonym und unbegrenzt bleibt.

Die ethische Debatte über Crawling konzentriert sich häufig auf die Erlaubnis, Inhalte zu kopieren. Kernel.org fügt eine zweite Frage hinzu: Wer soll dafür bezahlen, diese Inhalte in das von einem Sammler bevorzugte Format umzuwandeln?

Die Linux-Repositories sind bereits über einen effizienten Übertragungsmechanismus verfügbar. Die Betreiber halten die Historie nicht zurück und verlangen keine exklusive Kontrolle darüber. Sie wenden sich gegen Clients, die den öffentlichen Dienst wiederholt dazu bringen, eine teurere Darstellung zu berechnen.

Dieser Unterschied trennt den Fall von einer einfachen Debatte über die Einschränkung von Wissen. Ein effizienter Clone ermöglicht es einem Sammler, einen Großteil der Verarbeitungskosten nach der Übertragung selbst zu tragen. Commit-für-Commit-HTML-Scraping verlagert wiederholte Arbeit auf die Quelle.

Ein verantwortungsvoller Sammler sollte zuerst nach Bulk-Exporten, Repository-Zugang, Feeds, Sitemaps oder dokumentierten APIs suchen. Er sollte abgerufene Materialien cachen, Forks deduplizieren und beliebige Parameterkombinationen vermeiden. Er sollte sich zudem identifizieren und einen funktionierenden Kontaktkanal anbieten.

Auch die Aushandlung von Raten ist wichtig. Ein Crawler, der ungewöhnlich hohe Volumina benötigt, kann einen Betreiber um einen Mirror oder einen geplanten Export bitten. Kernel.org erklärt, dass es weiterhin Daten für Personen bereitstellen will, die darum bitten, auch wenn anonyme Schnittstellen restriktiver werden.

Diese Praktiken klingen grundlegend, weil reife Suchmaschinen sie über Jahrzehnte entwickelt haben. Die KI-Nachfrage hat die Zahl der Organisationen erhöht, die Web-Datensätze im großen Maßstab sammeln. Nicht jedes Team scheint dieselben operativen Normen übernommen zu haben.

Auch die Anreize unterscheiden sich. Ein Sammler, der um knappes Material aus der Zeit vor KI konkurriert, profitiert davon, schnell zu handeln. Die Kosten ineffizienter Sammlung treffen Tausende unbeteiligter Website-Betreiber. Ohne Verträge, Durchsetzung oder verlässliche Identität trägt der Crawler diese externen Kosten nicht automatisch.

Proof of Work versucht, einen Teil dieser Kosten wieder auf den Anfragenden zu verlagern. Die Ergebnisse von git.kernel.org zeigen sowohl den Reiz als auch die Grenze dieses Modells. Es erhöht die Grenzkosten, kann aber nicht zwischen einer wertvollen menschlichen und einer wertvollen automatisierten Anfrage unterscheiden.

Eine Gebühr pro Crawl eröffnet einen weiteren möglichen Weg, doch Zahlung allein löst kein Systemdesign-Problem. Ein Crawler kann einen dynamischen Endpunkt weiterhin überlasten, wenn Preisgestaltung, Quoten und Kapazitätskontrollen schlecht aufeinander abgestimmt sind. Kleinen Websites fehlen außerdem die Abrechnungssysteme, die zur Aushandlung maschinellen Zugangs erforderlich sind.

Bessere Protokollerkennung würde helfen. Eine maschinenlesbare Seite könnte Sammler auf einen Repository-Clone, ein komprimiertes Archiv oder einen begrenzten Datenexport verweisen. Crawler bräuchten weiterhin Anreize oder Vorgaben, um diese Richtung zu respektieren.

Das Anwendungsdesign kann die Angriffsfläche verringern, bevor Traffic eintrifft. Entwickler können Ergebnisgrößen begrenzen, unangemessene Vergleiche ablehnen, äquivalente URLs kanonisieren und teuren Routen separate Limits zuweisen. Sie können häufige Ansichten vorab berechnen und für ungewöhnliche Abfragen eine Authentifizierung verlangen.

Die Beobachtbarkeit muss Arbeit statt allein Anfragen messen. Eine Million gecachter statischer Antworten kann weniger kosten als einige Tausend ungecachter Datenbankabfragen. Betreiber benötigen CPU-Zeit auf Routenebene, Cache-Wirksamkeit, Abschlussraten von Herausforderungen und über Adressen hinweg gruppiertes Client-Verhalten.

Die tieferliegende politische Frage betrifft durchsetzbare Identität. Ein Crawler, der Betreiber und Zweck angibt, kann maßgeschneiderten Zugang erhalten. Ein verteilter Client, der vorgibt, Millionen von Browsern zu sein, verhindert Verhandlungen und verwandelt jede Anfrage in eine Vertrauensentscheidung.

Solange sich Identität nicht verbessert, werden Schutzsysteme auf Verhaltensinferenz angewiesen sein. Das bedeutet, dass False Positives unvermeidbar bleiben. Die menschlichen Kosten sollten ebenso ernsthaft erfasst werden wie der blockierte Traffic, denn ein Schutz, der reale Nutzer ausschließt, kann den Dienst untergraben, den er bewahren soll.

Creepy Crawlies stehen daher ebenso für ein Governance-Versagen wie für ein Traffic-Problem. Das Web verfügt über Normen für freiwilliges Crawler-Verhalten, aber ihm fehlt ein verlässlicher Rahmen für Clients im Maschinenmaßstab, die diese Normen ignorieren.

Drei Signale Werden Zeigen, Ob Der Druck Nachlässt

Die nächste Phase wird anhand des Traffic-Verhaltens, verlorener Funktionalität und besserer Crawler-Verantwortlichkeit gemessen.

Das erste Signal ist die Bestehensquote der Herausforderung bei git.kernel.org. Etwa 33 % der zufälligen Commit-Anfragen passierten Anubis, als Ryabitsev seine Zahlen veröffentlichte. Ein anhaltender Rückgang würde darauf hindeuten, dass neue Kontrollen den wirtschaftlichen Druck wiederhergestellt oder die Client-Klassifizierung verbessert haben.

Eine stabile oder steigende Bestehensquote würde in die entgegengesetzte Richtung weisen. Sie würde zeigen, dass Sammler die Daten weiterhin hoch genug bewerten, um jede defensive Verschärfung zu absorbieren. Ein weiterer Anstieg der Schwierigkeit würde außerdem zeigen, dass sich der Wettbewerb weiterhin auf Kosten statt auf Identität konzentriert.

Das zweite Signal ist das Ausmaß an anonymer Funktionalität, das kernel.org entfernt. Beschränkungen, die auf ungewöhnlich teure Vergleiche begrenzt sind, würden eine gezielte Reaktion stützen. Umfassendere Verluste bei gewöhnlichen Commit-, Patch- oder Browseransichten würden zeigen, dass Crawler-Druck die öffentliche Nutzungserfahrung verändert.

Betreiber sollten dokumentieren, was verschwindet und warum. Diese Aufzeichnung würde anderen Projekten helfen, gefährliche URL-Muster zu erkennen, bevor sie an denselben Punkt gelangen. Sie würde außerdem zeigen, ob Schutzmaßnahmen die üblichen menschlichen Arbeitsabläufe bewahren, die sie eigentlich schützen sollen.

Das dritte Signal ist, ob große Crawler-Betreiber überprüfbare Identitäten und effiziente Abrufwege einführen. Veröffentlichte Adressbereiche, zweckgebundene User Agents, Kontaktinformationen und durchsetzbare Ratenrichtlinien würden es Websites ermöglichen, kooperative Automatisierung von ausweichendem Scraping zu unterscheiden.

Ohne diese Rechenschaftspflicht wird sich der Markt für Schutzmaßnahmen weiter in Richtung Browser-Fingerprinting, verwalteter Edge-Kontrollen, Authentifizierung und kostenpflichtigem Zugang bewegen. Diese Werkzeuge können Kapazitäten schützen, machen unabhängiges Publizieren jedoch auch komplizierter.

Für Entwickler besteht die unmittelbare Aufgabe darin, zu prüfen, welche öffentlichen Routen die meiste CPU-Leistung verbrauchen und wie viele unterschiedliche URLs denselben zugrunde liegenden Datensatz offenlegen. Testen Sie, ob ein Bulk-Client dieselben Informationen über eine kostengünstigere Schnittstelle abrufen kann.

Veröffentlichen Sie diesen Weg klar und setzen Sie dann strikte Budgets für die dynamische HTML-Generierung. Überwachen Sie Abschlussraten bei Proof-of-Work und Ausfälle legitimer Nutzer getrennt voneinander. Eine Schutzmaßnahme sollte missbräuchliche Rechenlast verringern, ohne jeden Leser zum Kollateralschaden zu machen.

Für KI-Entwickler ist die verantwortungsvolle Entscheidung einfacher. Nutzen Sie die kostengünstigste autorisierte Darstellung, identifizieren Sie den Crawler, respektieren Sie die Website-Richtlinien und kontaktieren Sie Betreiber, bevor Sie skalieren. Offener Zugang ist eine Einladung, gemeinsames Wissen zu nutzen – kein unbegrenzter Anspruch auf die Prozessoren anderer.

Die creepy crawlies bei git.kernel.org haben diese Grenze sichtbar gemacht. Das offene Web kann maschinelle Leser unterstützen, aber nur, wenn diese Maschinen nicht länger jede öffentliche URL als kostenlose Rechenkapazität behandeln.