Qui Anubis bloque-t-il réellement ?

 (fzakaria.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Anubis, qui exige une preuve de travail (Proof-of-Work) avant tout accès HTTP, impose en pratique un coût persistant plus élevé aux utilisateurs ordinaires, aux appareils peu puissants et aux clients sans prise en charge de JavaScript qu’aux scrapers IA
  • anubis-fetch, créé par un LLM, résout directement la preuve de travail et, si nécessaire, lance Chromium, tout en imitant l’empreinte TLS/JA3 de Chrome pour contourner même le blocage manuel de Cloudflare
  • Les scrapers peuvent mettre en cache et réutiliser les cookies obtenus, amortissant ainsi le coût sur plusieurs requêtes, alors que les humains doivent subir à chaque visite plusieurs secondes d’attente et une consommation de batterie
  • La difficulté par défaut de 4 demande en moyenne 65 536 hachages ; une implémentation Go native prend environ 1,3 ms, tandis que le JavaScript du navigateur met environ 130 ms, mais le temps d’attente réellement perçu est d’environ 1 à 5 secondes
  • En supposant un temps perçu de 2 secondes et une énergie de 20 J par tentative, 1 million de défis par jour consomment environ 23 années-homme et 2 MWh par an, et 100 millions par jour environ 2 300 années-homme et 200 MWh

Anubis contourné par l’IA

  • En travaillant sur un patch pour le noyau Linux afin de prendre en charge $ORIGIN dans l’interpréteur PT_INTERP via bpf de binfmt_misc, il a été demandé à un LLM de lire ce fil de discussion de la mailing list du noyau Linux
  • lore.kernel.org avait alors mis en place Anubis, un proxy HTTP qui exige une preuve de travail avant l’accès aux ressources
  • Le LLM a produit anubis-fetch pour gérer cette restriction
    • Il commence par résoudre la preuve de travail nativement et, en cas d’échec, visite l’URL avec Chromium
    • Il imite l’empreinte TLS/JA3 de Chrome réel avec req, ce qui lui permet de passer même le blocage manuel de Cloudflare
    • anubis-fetch <URL> envoie le HTML sur la sortie standard, et l’option --text produit un texte brut plus lisible
  • Les IA et bots visés par Anubis peuvent le contourner facilement une fois la prise en charge de la preuve de travail ajoutée
    • Les scrapers peuvent mettre en cache et réutiliser les cookies reçus après avoir résolu le défi, amortissant ainsi le coût sur plusieurs requêtes
    • À l’inverse, les humains doivent attendre l’animation de chargement à chaque visite et consommer de la batterie, sans pouvoir mutualiser ce coût avec d’autres utilisateurs
    • Plus l’appareil est modeste ou mobile, plus la charge est lourde, et les clients sans JavaScript comme w3m, lynx, les lecteurs d’écran et les lecteurs RSS ne peuvent pas accéder au site
  • Un mécanisme censé bloquer l’IA est facilement contourné par l’IA, tout en continuant d’imposer un coût régressif aux humains et au Web ouvert

Le coût en temps et en énergie créé par la preuve de travail

  • La difficulté d correspond au nombre de caractères hexadécimaux zéro en tête que doit avoir le hachage, et le travail attendu par résolution est de W = 16^d hachages
    • La valeur par défaut fréquente, difficulté 4, demande 65 536 hachages
      • Implémentation Go native à environ 50 MH/s : environ 1,3 ms
      • JavaScript dans le navigateur à environ 0,5 MH/s : environ 130 ms
      • Temps perçu incluant le chargement de la page, l’exécution du worker et le rechargement : environ 1 à 5 secondes
    • La difficulté 5 demande 1 048 576 hachages
      • Implémentation Go native : environ 20 ms
      • JavaScript dans le navigateur : environ 2 secondes
      • Temps perçu : environ 5 à 15 secondes
  • En supposant que le nombre quotidien mondial de résolutions de défis Anubis est C, que le temps perçu par tentative est t = 2 secondes, et que l’énergie consommée par l’appareil, écran et CPU compris, est E = 20 J
    • Le temps humain annuel se calcule par C × t × 365 / 3.15×10⁷
    • L’énergie annuelle se calcule par C × E × 365 / 3.6×10⁶ kWh
  • Avec ces hypothèses, le coût annuel est le suivant
    • 1 million par jour : environ 23 années-homme, environ 2 MWh
    • 10 millions par jour : environ 230 années-homme, environ 20 MWh
    • 100 millions par jour : environ 2 300 années-homme, environ 200 MWh
  • Tous ces chiffres sont des estimations approximatives, et comme les fermes de bots et les outils d’IA consomment plusieurs ordres de grandeur d’énergie en plus, il ne s’agit pas d’un calcul destiné à soutenir un argument environnemental
  • Le temps n’est pas une contrainte pour les robots, mais le temps humain est fini ; les utilisateurs finissent donc par consacrer collectivement un temps considérable à attendre l’accès à des sites web, une attente qui n’existait pas avant l’ère de l’IA

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis sur Lobste.rs

  • Il est difficile d’être d’accord avec l’idée que la cible d’Anubis le neutralise facilement. L’objectif principal d’Anubis n’est pas de bloquer les agents LLM ou les programmes bricolés en vibe coding, mais les scrapers web indiscriminés utilisés par les entreprises de LLM
    Il existe des moyens de contournement, et on peut aussi s’aider d’agents ou de LLM, mais la plupart des scrapers restent simples, et leurs opérateurs ne cherchent généralement pas à contourner les rares sites qui utilisent Anubis. Le but est plutôt d’augmenter légèrement le coût du contournement afin de rendre la collecte peu intéressante

    • Anubis fonctionnera probablement bien pour empêcher des scrapers utilisant des proxys résidentiels de saturer un serveur. Les requêtes d’agents individuels ne sont pas très différentes de celles d’un utilisateur qui navigue réellement sur le site
      Cela dit, pour cet objectif, Anubis est surconçu. On pourrait obtenir le même effet de protection en demandant de cliquer une fois sur un bouton puis en émettant un cookie d’accès, et après l’avoir implémenté dans Apache, cela fonctionne déjà très bien sans preuve de travail complexe
    • La cible n’est pas tant les scrapers d’entreprises de LLM que les scrapers web grossiers et abusifs dans leur ensemble. On suppose seulement qu’une partie d’entre eux est exploitée par des entreprises de LLM
    • Le trafic accru sur les sites web vient non pas d’OpenAI, Anthropic ou Meta, mais d’autres acteurs, si bien qu’on ne sait pas clairement ce qu’il faut entendre par entreprise de LLM
      Même dans mes propres travaux de data mining, les outils modernes de scraping sont suffisamment performants pour contourner presque tous les obstacles, et Anubis se contourne lui aussi facilement
    • Je veux aussi bloquer les approches RAG visant mes sites personnels et mes logiciels, donc j’applique un blocage basique sur le user agent. J’ai testé en demandant directement à ChatGPT d’accéder au site, et cela a bien été bloqué
      Des configurations très particulières peuvent passer entre les mailles, mais l’objectif n’est pas d’arrêter un adversaire malveillant, plutôt un adversaire paresseux
    • Ce qu’Anubis bloque surtout, ce sont les scrapers Python requests rudimentaires qui se déguisent maladroitement en Chrome, le reste de l’effet de blocage étant presque un bonus

  • Anubis ne filtre pas les bots, il limite le débit des requêtes du client

  • Anubis ressemble moins à un moyen d’empêcher l’accès des agents IA qu’à une défense contre les attaques par déni de service, et dans la pratique il est aussi difficile d’identifier puis de bloquer les agents IA
    En revanche, il bloque aussi des utilisateurs comme moi qui visitent un site inconnu sur mobile avec JavaScript désactivé

  • Au vu de l’exploitation réelle, il est difficile d’être d’accord avec la conclusion de l’article. J’hébergeais le site web de mon homelab via le proxy public de fly.io et un transfert Tailscale, et des scrapers, dont ceux de Facebook, me coûtaient environ 20 dollars de bande passante par mois
    Après avoir mis Anubis sur le proxy, je suis revenu au palier gratuit. Peu importe qu’un contournement soit possible si nécessaire : il suffit déjà de bloquer l’essentiel du trafic de collecte massive provenant d’une petite minorité d’acteurs malveillants qui ignorent robots.txt

  • Pour des opérations de scraping reposant sur un botnet d’appareils peu puissants comme des smart TV, la preuve de travail d’Anubis pourrait constituer un obstacle réel. Le sujet est aussi un peu abordé ici : https://lobste.rs/s/kpaxih/update_on_scraper_situation

    • Sauf erreur de ma part, les smart TV sont utilisées seulement comme proxys et n’exécutent pas elles-mêmes la preuve de travail

  • L’aspect d’Anubis qui me gêne le plus, c’est son conflit avec le web ouvert. Mon site est surtout consommé via des flux RSS : si je protège le RSS avec Anubis, le flux ne fonctionne plus, et si je ne le protège pas, tout le contenu est exposé aux scrapers dans un format facile à lire pour une machine
    Ce type de barrière par preuve de travail est fondamentalement difficilement compatible avec le web ouvert ou l’indie web que nous voulions

    • Depuis un an, nous sommes coincés entre ces compromis impossibles, et moi non plus je n’ai pas trouvé de bonne réponse

  • Il y a une attitude qui montre ouvertement un manque de respect pour les choix faits par les autres

  • Le plus déplaisant, c’est que cela ressemble à une violation manifeste de lois comme le CFAA, tout en dissimulant son identité comme d’autres services DDoS à caractère criminel
    Attendre qu’une entreprise dont tout le modèle économique repose sur le vol du travail d’autrui et le blanchiment de code open source respecte la loi est déjà ridicule

  • Anubis ne bloque généralement pas Dillo, mais il peut être bloqué selon la configuration du site, et cela entretient cette ambiance selon laquelle sans JavaScript on ne mérite même pas d’exister, ce qui est extrêmement agaçant : https://paste.rs/jNgwd.png
    Je réfléchis à la possibilité de collecter et gérer la liste de toutes les IP incluses dans les proxys résidentiels pour les bloquer pendant un certain temps, et ipset pourrait peut-être gérer une telle échelle. Les logs montrent que les bots ne chargent pas d’autres ressources comme le CSS ou les images, mais parcourent tous les fichiers de tous les commits du dépôt Dillo, ce qui les rend relativement faciles à identifier
    Même si chaque site ne voit qu’une seule requête par IP, il est probable qu’une même IP récupère plusieurs sites ; on pourrait donc bloquer les IP signalées à plusieurs reprises. Au lieu de simplement couper la connexion, il faudrait rediriger vers une page d’information sur un port séparé afin d’expliquer pourquoi l’accès est bloqué et comment résoudre le problème
    Cela réduirait aussi l’incitation à intégrer des portes dérobées de proxy inverse dans des extensions de navigateur ou des applications mobiles. Les utilisateurs commenceraient alors réellement à être bloqués
    Il est regrettable de devoir s’appuyer sur un système de réputation IP, mais il est difficile de voir d’autres contre-mesures efficaces. Même si le serveur de commande et contrôle d’un botnet disparaît, les appareils vulnérables peuvent être repris par l’attaquant suivant et intégrés à un nouveau botnet

  • L’article dit : « bien sûr, je fais aussi ce travail avec l’aide d’un LLM », alors je me demande pourquoi il n’a pas le tag vibe coding

    • De la même façon qu’on n’ajoute pas ce tag simplement parce que l’auteur a utilisé un compilateur ou un éditeur, le sujet de ce billet n’est pas le vibe coding. Le tag vibecoding a été retiré par pushcx
    • Au moment de la publication, il était explicitement écrit dans le billet qu’une chose servant à contourner le blocage avait été codée en vibe coding, donc ce tag avait été ajouté. Il apparaît parfois sur des billets qui mentionnent encore moins le codage par IA ; je finis donc par considérer que les critères d’application de ce tag sont totalement incohérents