Anubis funktioniert tatsächlich

 (xeiaso.net)
3 Punkte von GN⁺ 2025-04-14 | 1 Kommentare | Auf WhatsApp teilen
  • Anubis wurde auf policytoolbox.iiep.unesco.org der UNESCO ausgerollt und erhält damit mehr Aufmerksamkeit als Beispiel für ein Bot-Abwehr-Tool, das von großen Organisationen eingesetzt wird
  • Nach der Bestätigung, dass unesco.org die offizielle Domain der UNESCO ist, gilt dieses Deployment als realer Einsatzfall einer Organisation im Umfeld der Vereinten Nationen
  • Zusammen mit bereits bekannten Deployments wie den Linux Kernel Mailing List Archives, FreeBSD SVN, SourceHut, FFmpeg, Wine und GNOME GitLab weitet sich der Einsatzbereich aus
  • Dass solche Organisationen Anubis einführen, zeigt, dass das Problem des Bot-Traffics im Internet ernster sein könnte als erwartet
  • Anubis und der zugehörige Stack brauchen mehr Zeit; mit ausreichender Förderung wären Vollzeitentwicklung und sogar Einstellungen möglich

UNESCO-Deployment bestätigt

  • Anubis wurde auf policytoolbox.iiep.unesco.org der UNESCO, einer Unterorganisation der Vereinten Nationen, ausgerollt
  • unesco.org ist laut Wikipedia als offizielle Domain der United Nations Educational, Scientific and Cultural Organization eingetragen
  • Es soll Kontakt mit dem Systemadministrator-Team der UNESCO aufgenommen werden, um zu klären, ob es bei der Installation Probleme gab, und den Installationsprozess einfacher zu machen

Bekannte Deployments und nächste Arbeiten

  • Zu den bestätigten großen Deployments gehören unter anderem:
    • Linux Kernel Mailing List Archives
    • SVN von FreeBSD, bald git
    • SourceHut
    • FFmpeg
    • Wine
    • UNESCO
    • The Science Olympiad Student Center
    • Enlightenment Desktop Environment
    • GitLab von GNOME
  • Wenn Organisationen dieser Größenordnung Anubis einsetzen, könnte das Bot-Traffic-Problem deutlich gravierender sein als bisher angenommen
  • Wie bei YouTube, das zeitweise nahe an „the inversion“ war, also dem Punkt, an dem es mehr Bot-Traffic als menschlichen Traffic gibt, bleibt die Frage, wie weit ein ähnliches Phänomen im gesamten Internet verbreitet ist
  • In Anubis und den zugehörigen Stack muss ernsthaft Zeit investiert werden; mit ausreichender Förderung wäre es möglich, in Vollzeit daran zu arbeiten und sogar Personal einzustellen
  • Wenn Anubis hilfreich ist, wird um Unterstützung über Patreon gebeten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-04-14
Hacker-News-Kommentare

  • Verwandter Beitrag: Anubis: Ein Proof-of-Work-Proxy, um AI-Crawler abzuwehren (100 Punkte, vor 23 Tagen, 58 Kommentare) https://news.ycombinator.com/item?id=43427679

  • Ich finde es interessant, dass Xe etwas, das früher fast wie ein Witz/Blödsinn wirkte, zu einem tatsächlich nützlichen Produkt gemacht hat. Es hieß ja schon immer: Timing ist alles
    Dass so viele Websites das wollen oder brauchen, überrascht mich etwas. Das Problem langsamer Git-Seiten bei manchen Git-Servern, die sehr tief verschachtelt sind, keinen Cache haben und von langsamen Platten ausgeliefert werden, verstehe ich
    UNESCO war etwas unerwartet. Die betreffende Unterseite ist mit Tausenden Dokumenten zwar ziemlich groß, aber statischer Content sollte leicht auszuliefern sein. Beim Nachsehen stellte sich heraus: schlampig deploytes WordPress auf Apache, ohne Cache, ohne Content-Kompression und ohne HTTP/2 oder HTTP/3
    Es wäre wahrscheinlich einfach, das so zu reparieren, dass es selbst auf einer sehr kleinen Maschine extrem günstig ausgeliefert werden kann, aber natürlich braucht man dafür Expertise, und Expertise ist weiterhin nicht billig
    Man könnte zwar ein LLM fragen, aber wenn man nicht einmal weiß, was man fragen soll, hilft das noch nicht besonders. Wenn man nicht einmal weiß, dass die Website überhaupt langsam ist, warum sollte man fragen? Vermutlich hört man nur, dass sie vom Traffic überrollt wird, und sucht sich dann einen furry Verteidiger

    • „Man braucht Expertise, und Expertise ist weiterhin nicht billig“ stimmt, aber gleichzeitig würde ich vermuten, dass es viel weniger Leute gibt, die Anubis konfigurieren können, als Leute mit WordPress-Admin-Erfahrung; deshalb überrascht es mich trotzdem
      Ich meine nicht, dass es schwierig ist, sondern dass schon nur wenige überhaupt wissen, dass es existiert
      Meine Vermutung: Der Grund, WordPress nicht anzufassen, ist kein technisches Problem, sondern eher, dass niemand eine fragile Instanz berühren will, dass es organisatorische Berechtigungsprobleme gibt oder dass der Admin bereits davon ausgeht, WP sei gut eingerichtet
    • Die Website, auf der ich das gern einsetzen würde, hat viele Artikel, und durch facettierte Suche auf Tag-Basis entstehen praktisch unendlich viele mögliche Kombinationen und Seiten
      Das lässt sich nicht cachen, und Bots halten sich nicht an die robots-Datei; sie fordern immer weiter URLs an und holen Artikel wiederholt mit verschiedenen Zahlen und Kombinationen ab. Das ist wirklich ein Ärgernis
    • AI-Scraper sind nicht nur schlecht implementiert, sie betreiben sogar absichtlich Cache-Invalidierung
      Die einzigen Lösungen, die ich bisher gesehen habe, waren Cloudflare, Login-Pflicht, Anubis oder Infrastruktur in völlig absurdem Maßstab
      Eine Website sagte, 60 % ihres Traffics kämen von Bots; bei kleineren Websites dürfte der Anteil wahrscheinlich noch viel höher sein
    • Proof-of-Work-basierte Bot-/Scraping-/DDoS-Abwehr gab es schon vor 10 Jahren; ich weiß nicht, warum sie sich erst jetzt verbreitet
      Ich erinnere mich auch an Projekte, die Proof of Work in nützliche Berechnungen verwandeln wollten

  • Falls unklar ist, was das ist: Es ist dafür gedacht, AI-Scraping zu verhindern
    „Anubis verwendet Proof-of-Work-Aufgaben, um sicherzustellen, dass der Client einen modernen Browser nutzt und SHA-256-Prüfsummen berechnen kann“
    https://anubis.techaro.lol/docs/design/how-anubis-works
    Ziemlich cool, und es könnte auch ein oder zwei meiner Projekte unterstützen

    • Seit einigen Jahren frage ich mich, ob das Web für Menschen oder für Maschinen gedacht ist. Mir fällt kein besonders guter Grund ein, Bots beim Ausliefern von Content gezielt zu blockieren
      Content zu veröffentlichen oder Aktionen auszuführen kann natürlich in vielen Situationen problematisch sein
      Aber beim bloßen Ausliefern von Content ist normalerweise nicht entscheidend, ob es ein Mensch oder ein Bot ist, wenn man filtern oder blockieren will. Solange ein bestimmter Client das System nicht missbraucht, warum sollte es mich kümmern, ob dieser Client ein Mensch ist?

  • „Außerdem wird auch die Zeit als Eingabewert verwendet. Aufgrund der Natur einer linearen Zeitachse wissen sowohl der Server als auch der Anfragende, was Zeit ist“
    Ein lustiger Satz aus der Dokumentation

    • Oh Mann, ich hatte vergessen, dass ich das drin gelassen habe. Witzig. Ich werde es einfach beibehalten
    • Leider ist die Aussage ohne Kontext falsch. Anubis rundet die Zeit auf die nächste Woche, und wenn auch die benachbarte Woche gültig ist, dürfte das wahrscheinlich ausreichen
      Aus verschiedenen Gründen sind Abweichungen bei der Uhrzeitsynchronisierung häufig. Man kann nicht erwarten, dass die unteren 10 % der Nutzer auch nur auf Tagesebene korrekt liegen, und selbst die unteren 25 % können um etwa fünf Minuten danebenliegen

  • Die Zwischenseiten-Bilder, die angezeigt werden, bis die Anubis-Prüfung abgeschlossen ist, sind wirklich niedlich. Die Illustrationen und Figuren in Xes Blog fand ich schon immer schön
    Nebenbei habe ich mich gefragt, welche Auswirkungen das auf normale Suchmaschinen hat und wie es sich von Cloudflares Lösung gegen AI-Crawler unterscheidet; das wird auf der GitHub-Seite erklärt [1]
    „Wenn man das installiert und verwendet, ist es sehr wahrscheinlich, dass manche Suchmaschinen die Website nicht indexieren können. Das gilt nicht als Bug von Anubis, sondern als Feature“
    „Das ist zwar eine Art nukleare Antwort, aber die AI-Scraper-Bots haben so aggressiv gescrapet, dass keine andere Wahl blieb“
    „In den meisten Fällen muss man das nicht verwenden; wahrscheinlich reicht es, einen bestimmten Origin-Server mit Cloudflare zu schützen. Falls man Cloudflare jedoch nicht nutzen kann oder nicht nutzen will, gibt es Anubis“
    [1]: https://github.com/TecharoHQ/anubis/

    • Stimmt. Im Moment verhindert es leider Suchindexierung. Vielleicht kann man später Suchmaschinen-IPs auf eine Allowlist setzen
      Allerdings verwenden Anbieter wie Google teils dieselben IPs für AI und Suchindexierung
      Trotzdem wird daran gearbeitet, etwa Open-Graph-Tags durchzulassen, damit zumindest Rich Previews funktionieren
    • Ich stimme zu, dass die Zwischenseiten-Bilder niedlich sind. Aber es ist schrecklich, daran zu denken, dass irgendwann irgendjemand sie auf irgendeine Weise als „problematisch“ einstufen und sie am Ende entfernt werden könnten

  • Ich habe über Anubis gelesen, ein cooles Projekt. Leider müssen Website-Besucher, wie in den Kommentaren erwähnt, JavaScript™ aktivieren.
    Wenn eine Website ohnehin JavaScript™ braucht, um die User Experience zu verbessern, ist das völlig in Ordnung, aber für statische Sites oder Ähnliches, die überhaupt kein JS benötigen, ist es eher ungeeignet.
    Ich habe mir eine eigene Lösung gebaut, die solche „bösen Bots“ effektiv auf Netzwerkebene blockiert. Mit der MaxMind-Datenbank sowie einem selbstgebauten WAF und Reverse Proxy blockiere ich mehrere große „Big Tech / Big LLM“-Netze komplett auf ASN-(BGP-)Ebene.

    • Ein erheblicher Teil des Bot-Traffics, um den es in diesem Beitrag geht, kommt aus normalen privaten IP-Bereichen.
      Natürlich gibt es auch ASN-Spielchen und Reputationsbetrug, aber das ist sehr schwer zu bekämpfen. Eine grobe Untersuchung der Logs zeigte, dass diese Bots von bestimmten privaten IPs ungefähr einmal anfragen, und diese Bereiche werden wahrscheinlich auch von echten menschlichen Nutzern verwendet.
      Kurz gesagt: Es besteht das Risiko, legitimen Traffic zu blockieren. Auch diese Lösung birgt Risiken, aber für die meisten Menschen ist das tatsächliche Risiko deutlich geringer.
      Es wäre schön, wenn man ohne JavaScript auskäme und auch Nutzer unterstützen könnte, die es deaktiviert haben, aber Kunden oder Endnutzer haben sich noch nie darüber beschwert, dass JavaScript aktiviert sein muss.
      Die Ablehnung der JavaScript-Anforderung kommt von einer lauten Minderheit, und die meisten davon schalten es einfach ein, wenn sie auf eine Site stoßen, die JavaScript braucht. Selbst dann dürften nur sehr wenige dabei einen ergebenen Seufzer ausstoßen.
    • Für alle, die es interessiert: Die Marke „JavaScript“ gehört Oracle: https://javascript.tm/
    • Woher weiß man, ob es ein LLM oder ein VPN ist? Wie trennt man LLM-Traffic mit der MaxMind-Datenbank heraus?
    • Gibt es einen Link zu deiner selbstgebauten Lösung?

  • Mir gefällt die Idee, aber sobald die Art der Challenge klarer umrissen ist, muss sie wahrscheinlich auf die Protokollebene hinunter.
    Für die Barrierefreiheit wäre es am Ende besser, wenn eine Proof-of-Work-Challenge eher Teil von etwas TCP-Nahem würde, statt von jeder Website separat in JavaScript implementiert zu werden.

    • Es gibt Cloudflares PrivacyPass, das ein IETF-Standard geworden ist [0], aber es ist ziemlich seltsam und die Referenzimplementierung ist ein Bug-Haufen.
      [0] https://datatracker.ietf.org/wg/privacypass/about/
    • Man könnte beliebige Challenges als SPIR-V- oder MLIR-Blackbox ausliefern. Wenn man den Challenge-Response-Austausch in HTTP integriert, wären breite Unterstützung und flexible Hardwarebeschleunigung möglich.
      Die „gut genug“-Lösung, die es bereits breit im Einsatz gibt, ist SHA(seed, nonce). Wenn die großen Tech-Konzerne gewollt hätten, hätte sich das leicht in eine niedrigere Ebene des Stacks integrieren lassen.

  • Auf meinem Handy dauert das Lösen der Bot-Erkennung ganze 5 Sekunden.

    • Ich nutze Fennec, den Firefox-Fork aus F-Droid, und ein Pixel 9 Pro XL; bei Schwierigkeitsgrad 4 dauert es etwa 8 Sekunden.
      Persönlich finde ich die User Experience nicht so schlecht, weil ich nichts tun muss. Ich ziehe das CAPTCHA definitiv vor.
    • Viel besser als eine endlose Cloudflare-CAPTCHA-Schleife.
    • Glück gehabt. Bei mir hat es 30 Sekunden gedauert.
    • Bei mir sind es etwa 0,5 Sekunden, interessant.

  • Ich baue gerade einen Prototyp, den ich derzeit „Enigma Webfont“ nenne. Für ausgelieferte und gecachte Webfonts möchte ich pro Nutzersitzung einen Custom Seed und Rotationswerte anwenden.
    Ziel ist es, Web Scraping wegen der OCR-Rechenkosten unpraktikabel zu machen. Im Moment ist es ein Katz-und-Maus-Spiel, und ich möchte das Kräfteverhältnis etwas verschieben.
    Ohne Nutzersitzung wäre der HTML-Quelltext praktisch bedeutungslos, und wenn der Asset-Cache durch ein OTP-ähnliches Verhalten wegfällt, ließe sich auch die Webseite nicht mehr lesen.
    Damit könnte man effektiv ein CAPTCHA bauen, bei dem der Nutzer ein lokales Seed-Fenster anpasst, bis er ein bestimmtes Wort lesen kann. Zum Beispiel: „Bewegen Sie den Schieberegler, bis das Wort Foxtrott lesbar ist.“
    Ich würde sehr gern Xes Meinung dazu hören. Können wir unsere Kräfte bündeln?
    Der Tech-Stack ist Go, weil es die einzige Sprache war, mit der sich Webfont-Dateien problemlos direkt verändern ließen.

    • Selbst abgesehen von den offensichtlichen Barrierefreiheitsproblemen: Ist das nicht höchstens eine Substitutionschiffre? Mit einem ausreichend großen Korpus dürfte die Kryptoanalyse deutlich einfacher werden.
    • Das Problem ist nicht, dass Websites gescrapet werden, sondern das Anfragevolumen, das die Infrastruktur lahmlegt oder die Kosten hochtreibt. Suchmaschinen machen so etwas seit über 30 Jahren.
      Text kaputtzumachen wird nicht helfen. Sie werden trotzdem weiter darauf einhämmern. Wenn man sich die Traffic-Muster ansieht, ist die Person, die diese Bots gebaut hat, einfach ... <https://www.youtube.com/watch?v=ulIOrQasR18>
      Zu „Ich würde gern Xes Meinung hören. Können wir unsere Kräfte bündeln?“: Soweit ich das sehe, braucht dieses Projekt eher Hilfe dabei, kurz- und langfristig nachhaltiger zu werden, als noch mehr Features. Anubis scheint bereits sehr gut zu funktionieren.

  • Es funktioniert definitiv gut darin, Nutzer zu blockieren, die JavaScript deaktiviert haben.

    • Stimmt. Als Versuch, es für mehr Menschen attraktiv erscheinen zu lassen, ist das wirklich schwach. Solange es keine nojs-Version gibt, unterscheidet es sich in dem Punkt, dass es das Web kaputtmacht, nicht von „KI“-Scrapern.