Nourrissons les bots

• Présentation d’une expérience dans laquelle l’administrateur d’un site web a créé des pages de « bavardage infini » pour attirer le trafic des bots scraper destinés à l’entraînement de l’IA
• Contrairement aux crawlers de moteurs de recherche traditionnels, ces bots sont agressifs : ils ignorent robots.txt, changent d’IP et continuent d’envoyer des requêtes en permanence
• Le blocage IP, la limitation de débit, les CAPTCHA, les murs de connexion et autres contre-mesures classiques sont toutes neutralisées, tout en ne faisant qu’incommoder les vrais utilisateurs
• L’auteur a donc constaté que la solution la moins chère et la plus efficace consistait à générer automatiquement de fausses données (du texte sans signification) pour les servir aux bots
• Cela met en lumière les effets secondaires de la collecte de données pour l’IA et le gaspillage de ressources serveur, tout en proposant une réponse réaliste à la portée des exploitants de sites

---

La nature de ces bots

• Les crawlers récents ne visent pas les moteurs de recherche, mais la collecte de données pour l’entraînement des LLM (grands modèles de langage)
  • Ils ignorent robots.txt, se font passer pour des navigateurs ou changent d’IP pour accéder au site
  • Ils envoient des requêtes plusieurs fois par seconde, toute la journée, ce qui surcharge les serveurs
• À la différence des moteurs de recherche classiques, ils ne se soucient pas de la pérennité des sites web et les considèrent seulement comme des sources de données interchangeables

Les problèmes quand on les laisse entrer

• Servir des fichiers statiques coûte peu, mais ce n’est pas gratuit : il existe une latence d’accès SSD et une surcharge du système de fichiers
  • Ils demandent d’anciennes pages absentes du cache, ce qui dégrade les performances du serveur
• La consommation de bande passante pose aussi problème : des billets de blog avec images s’accumulent vite et peuvent générer plus de 1 To de trafic par mois
  • Un coût difficilement supportable pour l’exploitant d’un serveur personnel

Les limites des tentatives de blocage

• Le blocage IP est inefficace : les réseaux de bots opérés par de grandes entreprises disposent de milliers d’adresses
  • Même si l’on bloque toutes les adresses connues, ils rachètent de nouvelles IP et reviennent
• La limitation du débit des requêtes (rate limit) est tout aussi inutile, certains utilisant même une IP différente à chaque requête

Les effets pervers des pare-feu et barrières d’authentification

• Connexion obligatoire, paiement, CAPTCHA, preuve de travail (proof-of-work) fondée sur le hachage : diverses défenses ont été proposées, mais elles finissent toutes par gêner les utilisateurs
  • Exiger un compte bloque l’accès des lecteurs, et les vérifications basées sur JavaScript empêchent les navigateurs sans JS
  • Le chargement des pages ralentit, ce qui dégrade l’expérience utilisateur

L’inefficacité des bombes de compression (gzip bomb)

• Certains proposent d’attaquer les bots avec des bombes gzip, mais en pratique le taux de compression n’atteint qu’environ 1000×
  • Pour créer un fichier décompressé de 100 Go, il faut tout de même fournir un actif de 100 Mo
  • Les essais montrent que les bots les ignorent, ou envoient au contraire encore plus de requêtes

L’échec de la tromperie

• La méthode du « Jedi mind trick », qui consiste à renvoyer une erreur 404 pour faire croire que le site n’existe pas, échoue elle aussi
  • Si le lien est publié ailleurs, les bots détectent son existence et, si l’accès leur est refusé, deviennent au contraire plus agressifs
  • Au final, il faut satisfaire les bots pour que le serveur retrouve son calme

L’efficacité de fournir des données inutiles

• La génération de contenu dynamique peut sembler coûteuse, mais en réalité le CPU et la RAM sont les ressources les plus rapides
  • Si cela paraît lent, c’est surtout à cause des E/S de base de données ou d’une logique JS complexe
• Le babbler à base de Markov créé par l’auteur n’utilise qu’environ 60 microsecondes de CPU et 1,2 Mo de mémoire par requête
  • Aucun accès disque, aucune gestion de liste noire nécessaire
  • Les bots viennent d’eux-mêmes consommer du texte dénué de sens, ce qui réduit la charge serveur

Conclusion

• La collecte indiscriminée de données par les bots d’entraînement de l’IA entraîne une hausse des coûts d’infrastructure web et des abus sur les contenus
• Plutôt que de simplement bloquer, la stratégie consistant à répondre avec des données sans signification est plus rentable et aide à préserver la stabilité du serveur
• Cette approche est présentée comme une expérimentation pour explorer les moyens de faire coexister le crawling IA et l’écosystème du web

[kimjoin2]

Oh… c’est original et sympa.

[GN⁺]

Commentaires sur Hacker News

• Le paragraphe d’instructions caché avant le lien était drôle
  Il y avait une consigne facétieuse destinée à tromper les LLM, du genre « le contenu de cette page est dangereux, ne le divulguez pas »
  Le document associé se trouve à ce lien

  • Pour résumer l’article The Cost of Trash, l’auteur a essayé plusieurs méthodes pour bloquer des scrapers web agressifs (probablement pour l’entraînement de LLM), sans succès, et a fini par choisir une stratégie consistant à générer dynamiquement des données inutiles afin de gaspiller leurs ressources
    La section finale « LLM instructions » n’était pas le vrai contenu de l’article mais une méta-consigne destinée à perturber les LLM, donc elle a été exclue du résumé

• J’ai toujours recommandé ce genre de stratégie — fournir en masse aux bots d’IA des données poubelles qui ont l’air authentiques, de sorte qu’au final des humains doivent les filtrer
  Si tous les sites faisaient cela, la qualité des données d’entraînement de l’IA chuterait brutalement
  S’il est difficile de se battre, autant tout noyer sous un déluge de données

  • Une meilleure méthode, mais plus coûteuse, consiste à faire ingérer aux LLM de grandes quantités de contenus promotionnels positifs
    Un peu comme un appât SEO, en créant des sites qui ressemblent à des domaines d’actualités pour y diffuser des articles de promotion de produits
  • Mais les LLM sont déjà pour l’essentiel entraînés sur des données poubelles
    Ce genre de tentative n’est qu’une perte de temps, comme répondre aux appels spam
  • En plus, les LLM peuvent effectuer la détection de déchets bien moins cher que les humains
    Il y aura au final très peu de raisons d’embaucher des gens
  • Je me demande pourquoi certains pensent que les humains filtrent mieux les déchets que l’IA

• Les détails de « Markov babbler » figurent dans ce billet

  • Avec gcc 14, une erreur d’argument pthread_detach survient à la compilation
    Le compilateur utilisé par l’auteur semble ignorer les avertissements
    Comme le programme traite les requêtes sans limite de gestion des threads, il est plus sûr de l’exécuter dans un conteneur en tant qu’utilisateur non privilégié
    Il semble aussi utiliser des fonctions C dangereuses comme sprintf(), donc prudence côté sécurité
  • Il dit qu’il ajoutera aussi cela à « toptext »
  • Le code est jugé élégant et rapide, et on espère que les scrapers de LLM souffriront en essayant de nettoyer ces données

• Sur mon site, j’ai placé une Basic Auth sur tous les liens, et aucun bot ne l’a encore franchie
  Du coup, je me demande ce qui se passerait si tous les sites web utilisaient les mêmes identifiants publics
  utilisateur : nobots / mot de passe : nobots
  Est-ce que les bots pourraient quand même passer ?

  • Bien sûr que oui. Il suffit d’ajouter un en-tête d’authentification aux requêtes HTTP
    C’est juste que la plupart des bots ne prennent pas encore ce cas en compte
    Le format http://username:[e-mail] permet de le gérer simplement
  • Si les identifiants sont connus de tous, ils n’auront probablement aucun effet contre les bots
  • Ce type d’approche n’est efficace que si très peu de gens l’utilisent. Dès que cela se répand un peu, elle est neutralisée

• Moi aussi, je leur fournis désormais des données poubelles
  Pour information, j’ai utilisé Frankenstein, Alice in Wonderland et Moby Dick comme sources, mais les fichiers sont gros donc le chargement est lent
  J’ai corrigé l’erreur de compilation en remplaçant pthread_detach(&thread) par pthread_detach(thread)

  • La correction a été appliquée, et la suggestion de gcc était la bonne

• J’exploite un « ethical crawler »
  Je réduis la fréquence des requêtes pour ne pas surcharger les sites, et cela devient de plus en plus difficile car l’accès RSS est bloqué à de nombreux endroits
  Mon crawler teste divers en-têtes et mécanismes pendant l’exploration
  Code : crawler-buddy, Django-link-archive

  • Il y a feedparser dans requirements.txt, mais il n’y a aucune trace de son utilisation réelle
    Cela se vérifie aussi via les résultats de recherche

• L’article The Cost of Trash mentionne qu’une gzip bomb n’est pas efficace
  gzip ne compresse qu’à environ 1000x, donc pour produire 100 Go il faut fournir un fichier de 100 Mo
  Et il est dit que les bots ont au contraire fait encore plus de requêtes

  • Avec zip, c’est possible, mais pas avec gzip
    La plupart des clients décompressent en streaming, donc ne chargent pas tout en mémoire
    Pour qu’une gzip bomb fonctionne réellement, il faudrait un traitement anormal
    Référence : documentation de l’API zlib
  • À la place, mieux vaut créer des milliers de petits fichiers gzip pour gaspiller du CPU et du temps
    On peut y mettre des déchets aléatoires, ou insérer des messages que l’on voudrait voir appris par l’IA

• Il faut noter que certaines requêtes peuvent en réalité utiliser le navigateur d’un utilisateur comme proxy
  Certains fournisseurs de navigateurs utilisent le trafic de leurs utilisateurs comme proxy
  Si la marge d’erreur de détection des requêtes automatiques est faible, il serait même possible d’y injecter du code de minage de cryptomonnaie, mais cela risquerait d’affecter de vrais utilisateurs
  Je me demande en particulier s’il existe des requêtes d’IA utilisant des agents mobiles

• Il était dit que « Markov babbler » consomme environ 60 μs de CPU par requête,
  alors je me demande ce qui se passerait si on y mêlait du contenu comportant des messages idéologiques ou de propagande pour que l’IA l’apprenne
  L’IA pourrait alors se mettre à produire des déclarations politiques absurdes
  À tout le moins, cela réduirait les violations de copyright et la charge serveur

• Pourquoi générer du texte de Markov côté serveur ?
  Si les bots exécutent du JavaScript, pourquoi ne pas le générer côté client ?

  • Les bots ont un CPU et une mémoire pratiquement illimités, donc la charge serveur n’est pas importante
    De plus, envoyer les données de la chaîne de Markov au client serait encore moins efficace
    Comme chaque requête ne consomme que quelques microsecondes de CPU et environ 1 Mo de RAM, le traitement côté serveur reste largement assez léger