Creepy Crawlies z Kernel.org zamieniają otwarty dostęp w podatek od CPU

Konstantin Ryabitsev twierdzi, że creepy crawlies utrzymują obecnie w ciągłym użyciu od 14 do 16 rdzeni CPU w git.kernel.org, mimo zabezpieczeń zaprojektowanych tak, by automatyczne skrobanie danych było kosztowne. Crawlery żądają milionów pojedynczych stron commitów zamiast klonować bazowe repozytoria Git. Ten wybór zamienia wydajne publiczne archiwum w stałą usługę renderowania HTML dla niezidentyfikowanych maszyn.

Ryabitsev, administrator systemów Linux Foundation zaangażowany w infrastrukturę kernel.org, opublikował te dane 29 sierpnia 2026 roku. Simon Willison zwrócił na nie uwagę 7 września, ponieważ Datasette wiąże się z podobnym profilem ryzyka. Może udostępniać bazę danych za pośrednictwem ogromnej kolekcji użytecznych stron dostępnych dla crawlerów.

Bezpośrednio sprawa dotyczy infrastruktury Linuksa, lecz konflikt sięga znacznie dalej. Otwarte archiwa techniczne zaprojektowano tak, by pomagały ludziom sprawdzać, cytować i zachowywać informacje. Klienci działający na skalę maszynową mogą przekształcić tę otwartość w niewyceniony obowiązek obliczeniowy.

Odwrócenie ról jest szczególnie wyraźne w git.kernel.org. Jego opiekunowie już udostępniają pełną historię repozytoriów przez Git — protokół stworzony do efektywnego przesyłania tej historii. Według doniesień scrapery i tak wybierają drogę kosztowną obliczeniowo, żądając osobno renderowanych stron commitów, patchy i diffów.

Takie zachowanie wywiera presję na opiekunów, by ograniczali interfejsy używane przez prawowitych deweloperów. Usługa pozostaje responsywna, według Ryabitseva, lecz już wyłącza funkcje i umieszcza więcej działań za kontrolą dostępu. Koszt wzrostu ruchu crawlerów mierzy się więc zarówno utraconą otwartością, jak i czasem CPU.

Creepy Crawlies generują sześć milionów żądań dziennie

Skala jest wystarczająco duża, by stale obciążać infrastrukturę, nawet gdy dla odwiedzających ludzi witryna wydaje się działać prawidłowo.

Crawler measurements Ryabitseva opisują około 6 milionów dziennych żądań dotyczących pozornie losowych commitów. Anubis, mechanizm wyzwania przeglądarkowego umieszczony przed główną witryną, natychmiast odrzuca około 66% tych żądań. Kolejne 33% rozwiązuje wyzwanie i przechodzi dalej do git.kernel.org.

Liczby nie dowodzą, że każde żądanie objęte wyzwaniem pochodzi od firmy AI. Ryabitsev wyraźnie zaznacza, że operatorzy nie potrafią z pewnością zidentyfikować każdego klienta. Człowiek może otworzyć stary commit, a bot może naśladować aktualną przeglądarkę.

Najmocniejsze dowody dostarczają wzorce żądań. Klient przemieszczający się między niepowiązanymi commitami w starych, nieaktywnych forkach nie przypomina dewelopera śledzącego serię patchy. Ryabitsev szacuje, że prawowita aktywność stanowi około 2% całego ruchu, nawet przy zastosowaniu założeń korzystnych dla użytkowników.

Wynikające z tego obciążenie zajmuje od 14 do 16 z 90 rdzeni CPU w pięciu geograficznie rozproszonych węzłach. Odpowiada to średnio około 20% całkowitej mocy obliczeniowej usługi. Rzeczywisty popyt przychodzi falami, więc obciążenie jest mniej uporządkowane niż stały przydział 20%.

Rdzenie wykonują wąskie zadanie. Zamieniają obiekty Git w strony HTML dla klientów, którzy następnie analizują wyrenderowany wynik. Ryabitsev twierdzi, że ta aktywność zużywa więcej czasu CPU niż wszystkie formy prawowitego dostępu łącznie, w tym klonowanie Git.

To rozróżnienie ma znaczenie, ponieważ klonowanie przesyła repozytorium przez natywny model obiektów Git. Klient otrzymuje historię i może lokalnie przechodzić między commitami. Serwer nie musi ponownie budować strony prezentacyjnej dla każdego obiektu, który klient chce sprawdzić.

Żądania HTML odwracają tę efektywność. Każde żądanie wymaga od serwera odnalezienia danych repozytorium, uruchomienia cgit i skonstruowania czytelnej dla człowieka odpowiedzi. Klient odrzuca znaczną część otaczającego interfejsu po wyodrębnieniu tekstu, którego potrzebuje.

Powielona miliony razy, indywidualnie rozsądna strona staje się kosztownym punktem końcowym dla maszyn. Tradycyjne planowanie pojemności często traktuje odsłony stron jako jednostki pracy o porównywalnym koszcie. Przypadek git.kernel.org pokazuje, dlaczego ten model zawodzi, gdy jeden URL może wywołać znacznie więcej obliczeń niż inny.

Usługa nie zawaliła się pod obecnym obciążeniem działającym w tle. Ryabitsev twierdzi, że źle zaprojektowane systemy ciągłej integracji nadal mogą powodować bardziej dotkliwe awarie, zwłaszcza gdy wiele węzłów jednocześnie wykonuje płytkie klonowania. Ruch crawlerów tworzy inny problem, ponieważ trwale odbiera zapas mocy operacyjnej.

Utrata tego zapasu zmniejsza tolerancję na skoki ruchu, zdarzenia konserwacyjne i prawowitą automatyzację. Zmusza też operatorów do poświęcania czasu na badanie zachowań o charakterze antagonisty zamiast na ulepszanie usług dla deweloperów jądra. Pozornie stabilna witryna może więc ponosić znaczny ukryty koszt.

Kluczowa zmiana nie polega na tym, że publiczny kod źródłowy można pobrać. Kernel.org celowo wspiera takie użycie. Zmiana polega na tym, że niezidentyfikowani klienci wybierają kosztowną reprezentację i żądają jej na skalę przemysłową.

Git sprawia, że dane są tanie, ale HTML czyni je kosztownymi

Sednem konfliktu nie jest dostęp kontra tajność. Chodzi o wydajny dostęp zbiorczy kontra marnotrawne wydobywanie danych strona po stronie.

Rozwój Linuksa zawsze korzystał na replikacji. Repozytoria Git można klonować, archiwa list mailingowych kopiować, a mirrory mogą zachowywać materiały dłużej niż działa pojedynczy serwer. Kernel.org zachęca do takiej redundancji, zamiast traktować każde pobranie jako zagrożenie.

Git czyni ten model ekonomicznym, przesyłając obiekty zgodnie z ich relacjami. Repozytorium przechowuje commity, drzewa i zawartość plików jako adresowalne obiekty. Klient i serwer uzgadniają, których obiektów klientowi brakuje, a następnie przesyłają niezbędne dane bez odtwarzania strony internetowej wokół każdego commitu.

Interfejs webowy służy innemu celowi. Pomaga deweloperowi sprawdzić pojedynczą zmianę, udostępnić stabilny link, porównać rewizje lub pobrać patch bez klonowania dużego repozytorium. cgit, interfejs używany przez git.kernel.org, oferuje kilka widoków, ponieważ każdy wspiera prawowity przepływ pracy człowieka.

Te opcje zwielokrotniają również powierzchnię dostępną dla crawlerów. Główne repozytorium Linuksa zawiera około 1,48 miliona commitów, według relacji Ryabitseva. Git.kernel.org hostuje około 922 forków, które w dużej mierze współdzielą te same bazowe obiekty.

Crawler może więc odkryć wiele URL-i prowadzących do zduplikowanej treści commitów. Może też żądać widoków patchy, renderowań zwykłego tekstu, drzew repozytoriów i dowolnych porównań. Treść jest skończona, ale możliwa przestrzeń URL-i staje się znacznie większa.

To znany tryb awarii witryn opartych na bazach danych. Baza danych może zawierać łatwą do opanowania liczbę rekordów, podczas gdy jej interfejs pozwala na niezliczone kombinacje filtrowania, sortowania, paginacji i porównań. Każda wygenerowana ścieżka wygląda dla bezkrytycznego crawlera jak kolejny dokument.

Willison powiązał ten wzorzec z Datasette, swoim narzędziem open source do publikowania przeszukiwalnych baz danych w sieci. Instancja Datasette może przekształcać ustrukturyzowane informacje w przeglądalne strony i wyniki zapytań. Ta dostępność jest cenna dla ludzi, wyszukiwarek, badaczy i narzędzi wspomagających.

Może jednak również udostępniać kosztowne kombinacje parametrów. Bot nie potrzebuje złośliwego kodu, by stworzyć szkodliwe obciążenie. Wystarczy, że wylicza linki lub konstruuje prawidłowe URL-e szybciej, niż aplikacja może tanio je obsłużyć.

To samo ryzyko dotyczy systemów dokumentacji, trackerów zgłoszeń, przeglądarek kodu, portali rejestrów publicznych i osobistych archiwów. Witryny, które na żądanie przekształcają ustrukturyzowane dane, są bardziej podatne niż strony statyczne, ponieważ każde pobranie może uruchomić pracę bazy danych lub renderowanie po stronie serwera.

Cache pomaga, gdy wielu klientów żąda tego samego zasobu. Pomaga mniej, gdy crawlery celowo lub przypadkowo rozpraszają żądania po unikalnych URL-ach. Parametry zapytań, dowolne diffy i stare forki mogą udaremnić ponowne wykorzystanie, które nadaje cache’owi wartość.

Operatorzy mogą wstępnie renderować popularne strony, ale wstępne renderowanie każdego możliwego porównania jest niemożliwe. Mogą też udostępniać eksporty zbiorcze, lecz crawler zaprojektowany wokół linków webowych może nigdy nie odkryć ani nie wybrać wydajnej ścieżki. Techniczna dostępność nie gwarantuje rozsądnego zachowania klienta.

Dla deweloperów budujących przeszukiwalne archiwa jest to ostrzeżenie architektoniczne. Dostęp maszynowy powinien, tam gdzie to możliwe, korzystać z ograniczonych API, feedów, eksportów lub protokołów repozytoriów. Interfejsy dla ludzi potrzebują limitów odzwierciedlających koszt wygenerowania każdej odpowiedzi.

Zespoły dokumentujące te wybory powinny również zachowywać decyzje operacyjne obok kodu. Przeszukiwalna baza wiedzy inżynieryjnej może połączyć polityki dotyczące crawlerów, kosztowne ścieżki i dowody z incydentów, zanim nadejdzie kolejna fala ruchu.

Incydent kernel.org pokazuje, że przepustowość to tylko część rachunku. Czas CPU, rotacja cache’a, koszty obserwowalności i uwaga operatorów mogą dominować, gdy zautomatyzowani klienci wielokrotnie żądają dynamicznych reprezentacji.

Anubis podniósł cenę, aż crawlery zaczęły ją płacić

Proof of work tymczasowo ograniczył nadużycia w ruchu, lecz wytrwałe crawlery się dostosowały, ponieważ bazowe dane pozostały wartościowe.

Kernel.org najpierw zastosował znane zabezpieczenia. Operatorzy identyfikowali podejrzane ciągi user-agent, analizowali logi i blokowali adresy związane z oczywistym automatycznym gromadzeniem danych. To podejście działało, gdy crawlery identyfikowały się lub pochodziły z możliwej do opanowania puli sieci.

Ruch stał się następnie trudniejszy do sklasyfikowania. Ryabitsev opisuje klientów podających się za zwykłe przeglądarki i rozpraszających żądania po podsieciach chmurowych. Zablokowanie całej sieci mogło zatrzymać nadużycie, lecz mogło również odciąć prawowite automatyczne kontrole hostowane u tego samego dostawcy.

Kolejna zmiana jeszcze bardziej osłabiła kontrole oparte na adresach. Żądania zaczęły napływać z dużej liczby adresów mieszkaniowych i mobilnych. Według Ryabitseva każdy adres generował tylko cztery lub pięć żądań, zanim znikał z logów.

Ten wzorzec przypomina sieci proxy kierujące ruch przez urządzenia konsumenckie. Witryna widzi coś, co wygląda na szeroką populację niepowiązanych użytkowników, zamiast skoncentrowanej operacji scrapowania. Zanim adres zacznie wyglądać podejrzanie, to konkretne źródło może już nigdy nie wrócić.

Kernel.org odpowiedział za pomocą Anubis, firewalla webowego open source, który rzuca klientom wyzwanie, zanim pozwoli im dotrzeć do usługi upstream. Jego centralnym mechanizmem jest proof of work — niewielkie zadanie matematyczne, które jest stosunkowo kosztowne dla klienta, lecz tanie do zweryfikowania przez serwer.

Projekt Anubis opisuje to oprogramowanie jako ochronę dla mniejszych usług internetowych zmagających się z ciągłym ruchem crawlerów AI. Jego opiekunowie nazywają je również radykalną odpowiedzią, ponieważ wyzwania mogą blokować małe scrapery i prawowite boty archiwizujące.

W git.kernel.org wyzwanie początkowo zmieniło ekonomię sytuacji. Zautomatyzowani klienci przestali próbować uzyskać dostęp, a odwiedzający ludzie akceptowali niewielkie opóźnienie. Ten okres trwał kilka miesięcy.

Boty później zaczęły rozwiązywać poziom trudności cztery. Operatorzy podnieśli wyzwanie do poziomu pięć, co wymagało większych obliczeń po stronie klienta. Ryabitsev twierdzi, że przy tym ustawieniu rozwiązanie może zająć kilka sekund na urządzeniu mobilnym i zauważalnie rozgrzać telefon.

Wyższy poziom trudności ponownie zapewnił kilka miesięcy spokoju. Narzucił też większy koszt każdemu prawowitemu odwiedzającemu, który otrzymał wyzwanie. Dostępność cierpi, gdy starszy sprzęt, przeglądarki nastawione na prywatność, wyłączony JavaScript lub niestabilne połączenia nie mogą ukończyć oczekiwanego procesu.

Roboty indeksujące ostatecznie rozwiązały również poziom piąty. W chwili raportu Ryabitseva około jedna trzecia z 6 milionów codziennych żądań commitów przechodziła wyzwanie. Dowód pracy nie stał się bezużyteczny, ponieważ nadal zatrzymywał pozostałe dwie trzecie, ale nie przywracał już wcześniejszej równowagi.

Ten rezultat ujawnia kluczową słabość odstraszania ekonomicznego. Wyzwanie działa tylko wtedy, gdy koszt przewyższa oczekiwaną wartość dla scrapera. Wartościowa, uporządkowana historia techniczna daje zbieraczom danych powód, by wydawać więcej zasobów.

Ryabitsev twierdzi, że historia commitów Linux jest szczególnie atrakcyjna, ponieważ znaczna jej część powstała przed upowszechnieniem generowanego tekstu. Badacze obawiają się, że powtarzalne trenowanie na syntetycznych materiałach może obniżać jakość modeli lub wzmacniać artefakty. To sprawia, że dobrze uporządkowane, tworzone przez ludzi zapisy techniczne są pożądanym materiałem treningowym.

Dokładna tożsamość i cele tych klientów pozostają niezweryfikowane. Część może wspierać trenowanie modeli, podczas gdy inne mogą tworzyć indeksy wyszukiwania, zbiory danych kodu, produkty bezpieczeństwa lub komercyjne archiwa. Z operacyjnego punktu widzenia ich wspólne zachowanie ma większe znaczenie niż etykieta.

Twórca Anubis, Xe Iaso, również przyznał, że dowód pracy nie jest pełną odpowiedzią. W dyskusji technicznej Iaso wyjaśnił, że mechanizm wymierzony jest w ekonomię masowego scrapingu, lecz wyraził sceptycyzm co do jego skuteczności wobec zdolnych klientów rozproszonych.

Klient z automatyzacją przeglądarki może wykonywać JavaScript, przechowywać pliki cookie i rozwiązywać to samo publiczne wyzwanie co człowiek. Klienci rozproszeni mogą podzielić pracę między wiele urządzeń. Podnoszenie poziomu trudności grozi wtedy szybszym karaniem legalnych odwiedzających niż odstraszaniem dobrze finansowanych zbieraczy.

Doświadczenie Kernel.org potwierdza ten kompromis danymi produkcyjnymi. Obrona zadziałała, przeciwnicy się dostosowali, a operatorzy podnieśli koszt. Rywalizacja nie zakończyła się, ponieważ zarówno atakujący, jak i obrońca mieli jeszcze jedno ustawienie do zmiany.

Otwarte archiwa są zmuszane do usuwania przydatnych funkcji

Najbardziej szkodliwym skutkiem nie jest wyższy rachunek za serwery. To stopniowe wycofywanie anonimowego, przyjaznego ludziom dostępu.

Kernel.org planuje ograniczyć liczbę URL-i dostępnych do crawlowania i objąć kontrolą operacje kosztowne w wykonaniu. Ryabitsev ostrzega, że anonimowi użytkownicy powinni spodziewać się zniknięcia części funkcjonalności. Bazowe dane pozostaną dostępne do pobrania, lecz ich uzyskanie może wymagać dodatkowych kroków.

Taka odpowiedź jest racjonalna dla operatora infrastruktury. Jeśli jeden interfejs generuje nieproporcjonalne obciążenie, jego ograniczenie chroni resztę usługi. Klony Git i przepływy pracy deweloperów są ważniejsze niż nieograniczone anonimowe renderowanie dowolnych porównań.

Jednak każde ograniczenie zmienia to, kto może korzystać z archiwum. Deweloper z zainstalowanym Git może sklonować repozytorium i zbadać je lokalnie. Student podążający za linkiem, dziennikarz sprawdzający jeden commit lub osoba korzystająca z ograniczonego urządzenia może zależeć od interfejsu przeglądarkowego.

Zautomatyzowane narzędzia badawcze również mogą mieć uzasadnione cele. Indeksowanie wyszukiwarek pomaga użytkownikom odnajdywać stare poprawki. Systemy archiwizacji zachowują dowody. Usługi bezpieczeństwa korelują commity z podatnościami. Narzędzia dostępności mogą pobierać strony w sposób nieprzypominający konwencjonalnego przeglądania.

Szerokie ograniczenia nie potrafią czysto oddzielić tych klientów od nadużywających zbieraczy. Uwierzytelnianie tworzy rozliczalność, ale dodaje pracy administracyjnej. Limity szybkości ograniczają skoki ruchu, lecz mogą zawodzić, gdy żądania napływają z rozproszonych adresów.

Blokowanie sieci mieszkaniowych wykluczałoby prawdziwe gospodarstwa domowe. Blokowanie dostawców chmurowych zakłócałoby automatyzację deweloperską. Wymaganie dowodu pracy sprawia, że każdy odwiedzający zużywa energię elektryczną i czas, zanim serwer wie, czy żądanie jest użyteczne.

Robots.txt przekazuje sygnał dotyczący zasad, ale nie jest mechanizmem kontroli dostępu. Oficjalny standard robots stwierdza, że jego reguły nie są formą autoryzacji. Współpracujące crawlery stosują się do zadeklarowanych preferencji, podczas gdy niezidentyfikowany klient może je zignorować lub podszywać się pod przeglądarkę.

Rezultatem jest asymetria. Odpowiedzialne organizacje identyfikują swoje crawlery, publikują dokumentację, przestrzegają wykluczeń i łatwo je zablokować. Mniej odpowiedzialni zbieracze ukrywają tożsamość i rozpraszają ruch, przez co trudniej ich powstrzymać.

Może to prowadzić do paradoksalnego rezultatu, w którym zgodne z zasadami crawlery tracą dostęp, podczas gdy unikające wykrycia nadal działają. Utrudnia to również wiarygodne przypisywanie ruchu. Operatorzy mogą zasadnie opisywać klasę zachowań jako scraping AI, nie będąc w stanie powiązać żądań z konkretnym twórcą modelu.

Ta niepewność jest główną sceptyczną kwestią w tej historii. Pomiary ruchu Ryabitseva stanowią bezpośredni dowód operacyjny, lecz cel każdego żądania nie został niezależnie ustalony. Szacunek 98% dotyczy pozornego zachowania scrapingowego, a nie zweryfikowanej listy firm AI.

To rozróżnienie powinno kształtować zarówno politykę, jak i relacjonowanie. Przypisywanie całego obciążenia konkretnemu dostawcy bez dowodów sieciowych byłoby nieprecyzyjne. Równie nieprecyzyjne byłoby bagatelizowanie problemu dlatego, że każdy klient nie ma publicznej tożsamości.

Mierzalna szkoda występuje na warstwie aplikacji. Miliony żądań wybierają stare commity, zduplikowane forki i kosztowne renderowania. Wyzwanie obronne zatrzymuje wiele żądań, lecz znaczne wolumeny płacą koszt obliczeniowy i kontynuują działanie.

Cloudflare podeszło do szerszego problemu, dając właścicielom witryn bardziej szczegółową kontrolę nad crawlerami wyszukiwarek, agentów i treningowymi. Jego kontrole ruchu AI odzwierciedlają istotne rozróżnienie, ponieważ crawler trenujący model i asystent wywołany przez użytkownika nie służą temu samemu celowi.

Duże sieci edge mogą łączyć dane o adresach, sygnały przeglądarkowe, historię ruchu i obserwacje z całej bazy klientów. Małe usługi open source rzadko mają taką widoczność. Muszą podejmować decyzje na podstawie lokalnych logów i niedoskonałych identyfikatorów.

Ta luka koncentruje szkody na organizacjach najmniej zdolnych do ich poniesienia. Duża platforma komercyjna może kupić większą przepustowość i wdrożyć wyspecjalizowane zarządzanie botami. Projekt wolontariacki, archiwum akademickie lub niezależny wydawca może po prostu zamknąć kosztowne ścieżki.

Otwarty internet traci wtedy więcej niż kilka funkcji interfejsu. Traci założenie, że publikowanie użytecznych informacji, do których można linkować, jest ekonomicznie bezpieczne. Strony pozostają technicznie publiczne, lecz dostęp staje się warunkowy, objęty wyzwaniami lub dostępny wyłącznie przez procesy pracy z danymi zbiorczymi.

Rzeczywisty konflikt to otwartość kontra niewycenione obliczenia

Otwarte dane nie wymagają, by każda możliwa forma reprezentacji pozostawała bezpłatna, anonimowa i nieograniczona.

Etyczny argument wokół crawlowania często koncentruje się na zgodzie na kopiowanie treści. Kernel.org dodaje drugie pytanie: kto powinien płacić za przekształcenie tych treści do formatu preferowanego przez zbieracza?

Repozytoria Linux są już dostępne przez wydajny mechanizm transferu. Operatorzy nie ukrywają historii ani nie żądają nad nią wyłącznej kontroli. Sprzeciwiają się klientom, którzy zmuszają usługę publiczną do wielokrotnego obliczania droższej reprezentacji.

Ta różnica oddziela ten przypadek od prostej debaty o ograniczaniu wiedzy. Wydajny klon pozwala zbieraczowi ponieść dużą część kosztów przetwarzania po transferze. Scraping HTML commit po commicie przenosi powtarzalną pracę na źródło.

Odpowiedzialny zbieracz powinien najpierw szukać eksportów zbiorczych, dostępu do repozytorium, kanałów, map witryny lub udokumentowanych API. Powinien buforować pobrane materiały, usuwać duplikaty forków i unikać dowolnych kombinacji parametrów. Powinien także się identyfikować i udostępniać działający kanał kontaktowy.

Znaczenie ma również negocjowanie tempa. Crawler potrzebujący nietypowego wolumenu może poprosić operatora o mirror lub zaplanowany eksport. Kernel.org twierdzi, że zamierza nadal udostępniać dane osobom, które o nie poproszą, nawet gdy anonimowe interfejsy staną się bardziej restrykcyjne.

Te praktyki brzmią elementarnie, ponieważ dojrzałe wyszukiwarki rozwijały je przez dekady. Popyt AI zwiększył liczbę organizacji zbierających zbiory danych na skalę internetu. Nie każdy zespół wydaje się dziedziczyć te same normy operacyjne.

Różnią się również zachęty. Zbieracz ścigający się, by zdobyć rzadkie materiały sprzed ery AI, zyskuje na szybkim działaniu. Koszt nieefektywnego zbierania spada na tysiące niepowiązanych operatorów witryn. Bez umów, egzekwowania zasad lub wiarygodnej tożsamości crawler nie ponosi automatycznie tego zewnętrznego kosztu.

Dowód pracy próbuje przenieść część wydatków z powrotem na żądającego. Wyniki git.kernel.org pokazują zarówno atrakcyjność, jak i ograniczenie tego modelu. Podnosi koszt krańcowy, lecz nie potrafi odróżnić wartościowego żądania człowieka od wartościowego żądania automatycznego.

Opłata za crawl tworzy inną możliwą ścieżkę, lecz sama płatność nie rozwiązuje problemu projektowania systemu. Crawler nadal może przeciążyć dynamiczny endpoint, jeśli ceny, limity i kontrola przepustowości są źle dopasowane. Małym witrynom brakuje też systemów rozliczeniowych potrzebnych do negocjowania dostępu maszynowego.

Pomogłoby lepsze wykrywanie protokołów. Strona czytelna dla maszyn mogłaby kierować zbieraczy do klona repozytorium, skompresowanego archiwum lub ograniczonego eksportu danych. Crawlery nadal potrzebowałyby zachęt lub wymagań, by respektować taki kierunek.

Projekt aplikacji może ograniczyć ekspozycję, zanim pojawi się ruch. Deweloperzy mogą ograniczać rozmiary wyników, odrzucać nierozsądne porównania, kanonizować równoważne URL-e i przypisywać oddzielne limity kosztownym ścieżkom. Mogą wstępnie obliczać częste widoki i wymagać uwierzytelniania dla nietypowych zapytań.

Obserwowalność musi mierzyć pracę, a nie tylko liczbę żądań. Milion buforowanych odpowiedzi statycznych może kosztować mniej niż kilka tysięcy niebuforowanych zapytań do bazy danych. Operatorzy potrzebują czasu CPU na poziomie ścieżek, skuteczności cache, wskaźników ukończenia wyzwań oraz zachowania klientów grupowanego między adresami.

Głębsze pytanie polityczne dotyczy egzekwowalnej tożsamości. Crawler deklarujący operatora i cel może otrzymać dostosowany dostęp. Rozproszony klient udający miliony przeglądarek uniemożliwia negocjacje i zmienia każde żądanie w decyzję opartą na zaufaniu.

Dopóki identyfikacja się nie poprawi, systemy obronne będą polegać na wnioskowaniu z zachowań. Oznacza to, że fałszywe pozytywy pozostaną nieuniknione. Koszt dla ludzi należy śledzić równie poważnie jak zablokowany ruch, ponieważ ochrona wykluczająca prawdziwych użytkowników może podważyć usługę, którą zachowuje.

Creepy crawlies stanowią więc porażkę zarządzania w takim samym stopniu jak problem ruchu. Internet ma normy dotyczące dobrowolnego zachowania crawlerów, ale brakuje mu wiarygodnych ram dla klientów działających na skalę maszynową, którzy ignorują te normy.

Trzy sygnały pokażą, czy presja słabnie

Kolejna faza będzie mierzona zachowaniem ruchu, utraconą funkcjonalnością i lepszą rozliczalnością crawlerów.

Pierwszym sygnałem jest wskaźnik przejścia wyzwań w git.kernel.org. Gdy Ryabitsev opublikował swoje dane, około 33% losowych żądań commitów przechodziło Anubis. Trwały spadek sugerowałby, że nowe kontrole przywróciły presję ekonomiczną lub poprawiły klasyfikację klientów.

Stabilny lub rosnący wskaźnik przejść wskazywałby na sytuację odwrotną. Pokazałby, że zbieracze nadal cenią dane na tyle, by ponosić koszt każdego wzrostu poziomu obrony. Kolejny wzrost trudności wyzwania również ujawniłby, że rywalizacja nadal koncentruje się na koszcie, a nie tożsamości.

Drugim sygnałem jest zakres anonimowej funkcjonalności usuwanej przez kernel.org. Ograniczenia dotyczące wyłącznie wyjątkowo kosztownych porównań wskazywałyby na ukierunkowaną odpowiedź. Szersze straty obejmujące zwykłe widoki commitów, patchy lub przeglądania pokazałyby, że presja crawlerów zmienia doświadczenie publiczne.

Operatorzy powinni dokumentować, co znika i dlaczego. Taki rejestr pomógłby innym projektom identyfikować niebezpieczne wzorce URL, zanim dotrą do tego samego punktu. Ujawniłby też, czy mechanizmy obronne zachowują typowe ludzkie procesy pracy, które miały chronić.

Trzecim sygnałem jest to, czy główni operatorzy crawlerów przyjmują weryfikowalne tożsamości i efektywne ścieżki pozyskiwania danych. Opublikowane zakresy adresów, agenty użytkownika przeznaczone do konkretnych celów, dane kontaktowe oraz egzekwowalne zasady dotyczące limitów zapytań pozwoliłyby stronom odróżniać współpracującą automatyzację od unikającego wykrycia scrapingu.

Bez takiej rozliczalności rynek narzędzi obronnych będzie nadal zmierzał w stronę fingerprintingu przeglądarek, zarządzanych kontroli na brzegu sieci, uwierzytelniania i płatnego dostępu. Narzędzia te mogą chronić wydajność, ale jednocześnie komplikują niezależne publikowanie.

Dla deweloperów najpilniejszym działaniem jest sprawdzenie, które publiczne ścieżki zużywają najwięcej CPU i ile różnych URL-i udostępnia ten sam bazowy rekord. Należy przetestować, czy klient masowy może pobrać te same informacje za pośrednictwem tańszego interfejsu.

Należy jasno opublikować taką ścieżkę, a następnie wprowadzić ścisłe limity dla dynamicznego generowania HTML. Osobno monitoruj wskaźniki ukończenia proof-of-work oraz błędy napotykane przez legalnych użytkowników. Mechanizm obronny powinien ograniczać nadużycia obliczeniowe, nie zamieniając każdego czytelnika w przypadkową ofiarę.

Dla twórców AI odpowiedzialny wybór jest prostszy. Korzystajcie z najtańszej autoryzowanej reprezentacji, identyfikujcie crawlera, przestrzegajcie polityki strony i kontaktujcie się z operatorami przed skalowaniem. Otwarty dostęp jest zaproszeniem do korzystania ze wspólnej wiedzy, a nie nieograniczonym prawem do cudzych procesorów.

Pełzające stwory na git.kernel.org uwidoczniły tę granicę. Otwarty web może wspierać maszynowych czytelników, ale tylko wtedy, gdy maszyny przestaną traktować każdy publiczny URL jako darmową moc obliczeniową.