Wen hält Anubis eigentlich auf?

 (fzakaria.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Anubis, das vor dem HTTP-Zugriff einen Proof of Work verlangt, verursacht für normale Nutzer, leistungsschwache Geräte und Clients ohne JavaScript-Unterstützung dauerhaft höhere Kosten als für AI-Scraper
  • Das von einem LLM erstellte anubis-fetch löst den Proof of Work direkt, startet bei Bedarf Chromium und imitiert den TLS-/JA3-Fingerprint von Chrome, um sogar manuelle Blockaden von Cloudflare zu umgehen
  • Scraper können ausgegebene Cookies zwischenspeichern und wiederverwenden und die Kosten so über mehrere Anfragen amortisieren; Menschen müssen dagegen bei jedem Besuch mehrere Sekunden Wartezeit und Akkuverbrauch hinnehmen
  • Der Standard-Schwierigkeitsgrad 4 erfordert im Durchschnitt 65.536 Hashes; eine native Go-Implementierung braucht etwa 1,3 ms, Browser-JavaScript etwa 130 ms, die tatsächlich wahrgenommene Wartezeit liegt jedoch bei etwa 1–5 Sekunden
  • Geht man von 2 Sekunden wahrgenommener Zeit und 20 J Energie pro Versuch aus, verbrauchen 1 Million Challenges pro Tag jährlich etwa 23 Personenjahre·2 MWh, 100 Millionen pro Tag etwa 2.300 Personenjahre·200 MWh

Von AI umgangenes Anubis

  • Während ich an einem Patch arbeitete, der im Linux-Kernel über bpf von binfmt_misc Unterstützung für $ORIGIN im Interpreter PT_INTERP hinzufügt, bat ich ein LLM, einen Thread der Linux-Kernel-Mailingliste zu lesen
  • lore.kernel.org hatte den HTTP-Proxy Anubis eingeführt, der vor dem Zugriff auf Ressourcen einen Proof of Work verlangt
  • Das LLM erstellte anubis-fetch, um diese Einschränkung zu handhaben
    • Zunächst löst es den Proof of Work nativ; wenn das fehlschlägt, besucht es die URL mit Chromium
    • Mit req imitiert es den TLS-/JA3-Fingerprint eines echten Chrome und kommt damit auch durch manuelle Blockaden von Cloudflare
    • anubis-fetch <URL> gibt HTML auf die Standardausgabe aus; die Option --text liefert gut lesbaren Klartext
  • Die AI und Bots, auf die Anubis abzielt, können es leicht umgehen, sobald sie einmal Unterstützung für den Proof of Work hinzugefügt haben
    • Scraper lösen die Challenge und cachen bzw. verwenden das erhaltene Cookie wieder, wodurch sie die Kosten über mehrere Anfragen amortisieren
    • Menschen dagegen warten bei jedem Besuch auf den Spinner und verbrauchen Akku; diese Kosten können sie nicht mit anderen Nutzern teilen
    • Je leistungsschwächer das Gerät oder Smartphone, desto größer die Belastung; w3m, lynx, Screenreader und RSS-Reader ohne JavaScript können gar nicht zugreifen
  • Ein Mechanismus, der AI aufhalten soll, wird von AI leicht umgangen, belastet Menschen und das offene Web aber weiterhin mit Kosten – eine regressive Belastung

Die Zeit- und Energiekosten von Proof of Work

  • Der Schwierigkeitsgrad d ist die Zahl der führenden hexadezimalen Nullen, die ein Hash haben muss; der erwartete Arbeitsaufwand pro Lösung beträgt W = 16^d Hashes
    • Der häufige Standardwert Schwierigkeitsgrad 4 erfordert 65.536 Hashes
      • Native Go-Implementierung mit etwa 50 MH/s: ca. 1,3 ms
      • Browser-JavaScript mit etwa 0,5 MH/s: ca. 130 ms
      • Wahrgenommene Zeit inklusive Seitenladen, Worker-Ausführung und Neuladen: ca. 1–5 Sekunden
    • Schwierigkeitsgrad 5 erfordert 1.048.576 Hashes
      • Native Go-Implementierung: ca. 20 ms
      • Browser-JavaScript: ca. 2 Sekunden
      • Wahrgenommene Zeit: ca. 5–15 Sekunden
  • Angenommen werden C tägliche Anubis-Challenge-Lösungen weltweit, eine wahrgenommene Zeit pro Versuch von t = 2 Sekunden und Geräteenergie einschließlich Display und CPU von E = 20 J
    • Die jährliche menschliche Zeit wird als C × t × 365 / 3,15×10⁷ berechnet
    • Die jährliche Energie wird als C × E × 365 / 3,6×10⁶ kWh berechnet
  • Unter diesen Annahmen ergeben sich folgende jährliche Kosten
    • 1 Million pro Tag: etwa 23 Personenjahre, etwa 2 MWh
    • 10 Millionen pro Tag: etwa 230 Personenjahre, etwa 20 MWh
    • 100 Millionen pro Tag: etwa 2.300 Personenjahre, etwa 200 MWh
  • Alle Zahlen sind grobe Schätzungen; da Bot-Farmen und AI-Tools um Größenordnungen mehr Energie verbrauchen, ist dies keine Rechnung, um ein Umweltproblem zu behaupten
  • Für Roboter ist Zeit keine Einschränkung, die Zeit von Menschen ist jedoch endlich; Nutzer verbringen daher kollektiv erhebliche Zeit damit, auf den Zugriff auf Websites zu warten – eine Wartezeit, die es vor der AI-Ära nicht gab

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Kommentare auf Lobste.rs

  • Der Aussage, dass die von Anubis angepeilten Ziele es mühelos aushebeln, kann ich kaum zustimmen. Das Hauptziel von Anubis ist nicht, LLM-Agents oder per Vibe Coding erstellte Programme zu blockieren, sondern wahllose Web-Scraper, wie sie LLM-Unternehmen einsetzen.
    Es gibt Umgehungsmöglichkeiten, und man kann dafür auch Agents oder LLMs nutzen, aber die meisten Scraper sind simpel, und ihre Betreiber werden sich kaum die Mühe machen, ausgerechnet die wenigen Sites zu umgehen, die Anubis einsetzen. Das Ziel ist eher, die Umgehungskosten leicht zu erhöhen, sodass sich das Sammeln nicht mehr lohnt.

    • Anubis dürfte gut funktionieren, um Situationen zu verhindern, in denen Scraper mit Residential Proxies einen Server lahmlegen. Die Anfragen einzelner Agents unterscheiden sich nicht wesentlich davon, dass ein Nutzer die Site selbst durchsieht.
      Für diesen Zweck ist Anubis allerdings überkonstruiert. Man könnte denselben Schutzeffekt erzielen, indem man einmal auf einen Button klicken lässt und danach ein Zugriffscookie ausstellt; als ich das in Apache implementiert habe, funktionierte es auch ohne komplexen Proof of Work ausreichend gut.
    • Das Ziel sind weniger Scraper von LLM-Unternehmen als vielmehr schlecht gemachte und missbräuchliche Web-Scraper allgemein. Es wird lediglich vermutet, dass einige davon von LLM-Unternehmen betrieben werden.
    • Der gestiegene Traffic auf Websites kommt nicht von OpenAI, Anthropic, Meta und ähnlichen Akteuren, sondern von anderen Stellen, weshalb unklar ist, was überhaupt als LLM-Unternehmen definiert wird.
      Moderne Scraping-Tools, wie ich sie auch bei meiner Data-Mining-Arbeit verwende, sind gut genug, um fast alle Hindernisse zu umgehen, und auch Anubis lässt sich problemlos umgehen.
    • Ich möchte auch RAG-Zugriffe auf persönliche Sites und Software verhindern und habe deshalb eine einfache User-Agent-Sperre eingesetzt. Als ich es testweise ausprobierte, indem ich ChatGPT direkt um Zugriff auf die Site bat, wurde es zuverlässig blockiert.
      Sehr spezielle Konfigurationen können durchrutschen, aber das Ziel ist, faule Gegner aufzuhalten, nicht böswillige.
    • Was Anubis hauptsächlich blockiert, sind simple Python-requests-Scraper, die sich schlecht als Chrome tarnen; alles Weitere ist eher ein zusätzlicher Effekt.

  • Anubis filtert keine Bots heraus, sondern begrenzt die Anfragerate des Clients.

  • Anubis ist weniger ein Mittel, um den Zugriff von AI-Agents zu verhindern, sondern eher eine Abwehrmaßnahme gegen Denial-of-Service-Angriffe, und in der Praxis ist es ohnehin schwierig, AI-Agents zuverlässig zu erkennen und zu blockieren.
    Allerdings sperrt es dabei auch Nutzer wie mich aus, die auf Mobilgeräten unbekannte Websites besuchen und JavaScript deaktiviert haben.

  • Angesichts realer Betriebsergebnisse fällt es mir schwer, der Schlussfolgerung des Artikels zuzustimmen. Ich habe die Website meines Homelabs über einen öffentlichen Proxy auf fly.io und Tailscale-Forwarding betrieben, und Scraper, unter anderem von Facebook, verursachten jeden Monat etwa 20 Dollar Bandbreitenkosten.
    Nachdem ich Anubis auf dem Proxy eingesetzt hatte, war ich wieder im kostenlosen Kontingent. Es ist in Ordnung, wenn es sich bei Bedarf umgehen lässt; es reicht, den Großteil des massenhaften Sammeltraffics einiger weniger bösartiger Akteure zu blockieren, die robots.txt ignorieren.

  • Bei Scraping-Operationen, die Botnets aus leistungsschwachen Geräten wie Smart-TVs nutzen, könnte der Proof of Work von Anubis tatsächlich ein Hindernis sein. Auch unter https://lobste.rs/s/kpaxih/update_on_scraper_situation wird dieses Problem ein wenig behandelt.

    • Wenn ich mich nicht irre, werden Smart-TVs lediglich als Proxies verwendet und führen den Proof of Work selbst nicht aus.

  • Was mich an Anubis am meisten stört, ist der Konflikt mit dem offenen Web. Meine Website wird hauptsächlich über RSS-Feeds konsumiert; wenn ich RSS mit Anubis schütze, funktioniert der Feed nicht, und wenn ich ihn nicht schütze, liegt der gesamte Inhalt in maschinenlesbarer Form für Scraper offen.
    Solche Proof-of-Work-Barrieren sind grundsätzlich schwer mit dem offenen Web oder dem IndieWeb vereinbar, das wir anstreben.

    • Im vergangenen Jahr saß ich zwischen solchen unmöglichen Kompromissen fest, und auch ich habe keine gute Antwort gefunden.

  • Hier zeigt sich unverhohlen eine Haltung, die die Entscheidungen anderer Menschen nicht respektiert.

  • Das Unangenehmste daran ist, dass dies offensichtlich gegen Gesetze wie den CFAA zu verstoßen scheint, die Akteure aber trotzdem ihre Identität verbergen wie andere kriminelle DDoS-Dienste.
    Es ist schon absurd zu erwarten, dass ein Unternehmen, dessen gesamtes Geschäftsmodell darauf beruht, die Arbeit anderer zu stehlen und Open-Source-Code zu waschen, sich an das Gesetz hält.

  • Anubis blockiert Dillo normalerweise nicht, kann es aber je nach Site-Konfiguration tun, und das fördert eine Atmosphäre, in der man ohne JavaScript kein Existenzrecht hat, was extrem lästig ist: https://paste.rs/jNgwd.png
    Ich überlege, ob es möglich ist, Listen aller IPs zu sammeln und zu pflegen, die zu Residential Proxies gehören, und sie für einen bestimmten Zeitraum zu blockieren; ipset könnte diese Größenordnung vielleicht bewältigen. In den Logs sind Bots relativ leicht zu erkennen, weil sie keine anderen Ressourcen wie CSS oder Bilder laden, aber jede Datei in jedem Commit des Dillo-Repositorys durchlaufen.
    Auch wenn eine einzelne Site pro IP nur eine Anfrage sieht, ist es wahrscheinlich, dass dieselbe IP mehrere Sites abruft; daher könnte man IPs blockieren, die mehrfach gemeldet wurden. Man sollte die Verbindung nicht einfach kappen, sondern auf eine Hinweisseite auf einem separaten Port weiterleiten, die erklärt, warum blockiert wurde und wie man das Problem lösen kann.
    Dadurch sinkt auch der Anreiz, Browser-Erweiterungen oder Handy-Apps mit Reverse-Proxy-Backdoors zu versehen, weil die Nutzer dann tatsächlich anfangen würden, blockiert zu werden.
    Es ist bedauerlich, sich auf ein IP-Reputationssystem verlassen zu müssen, aber ich sehe kaum andere wirksame Gegenmaßnahmen. Verwundbare Geräte können, selbst wenn der Command-and-Control-Server eines Botnets entfernt wird, vom nächsten Angreifer erneut übernommen und in ein neues Botnet eingegliedert werden.

  • Im Artikel heißt es: „Natürlich erledige ich diese Arbeit mit Hilfe eines LLM.“ Dann frage ich mich, warum kein Vibe-Coding-Tag daran hängt.

    • Weil das Thema dieses Artikels nicht Vibe Coding ist, genauso wenig wie der Autor ein entsprechendes Tag setzen würde, nur weil er einen Compiler oder Editor benutzt hat. Das Tag vibecoding wurde von pushcx entfernt.
    • Beim Posten habe ich das Tag gesetzt, weil im Artikel ausdrücklich stand, dass etwas zum Umgehen der Sperre per Vibe Coding gebaut wurde. Auch Beiträge, die AI-Coding deutlich weniger erwähnen, bekommen manchmal dieses Tag; deshalb überrascht mich die Entfernung, aber ich habe mich damit abgefunden, dass die Anwendung dieses Tags völlig inkonsistent ist.