Un scraper IA demande des scripts commentés

• Lors de l’analyse des logs du serveur web, une forte activité de bots demandant des fichiers JavaScript inexistants a été repérée
• Il s’agirait de requêtes ayant interprété comme du vrai code des balises script placées dans des commentaires HTML, ce qui laisse penser à une tentative de collecte de données pour l’entraînement de LLM
• Plusieurs réponses possibles sont proposées pour détecter et contrer ces requêtes anormales : avertissement public, blocage d’IP, bombe de décompression, empoisonnement des données
• L’empoisonnement des données est notamment cité comme un moyen efficace de dégrader les performances d’un modèle en contaminant ses données d’entraînement
• L’article souligne la nécessité pour les administrateurs web d’expérimenter des stratégies de défense et de contre-attaque face aux scrapers IA

---

Découverte d’un scraping anormal

• De nombreuses requêtes 404 visant des fichiers JavaScript inexistants ont été relevées dans les logs du serveur
  • Ces fichiers correspondaient à des scripts inactifs inclus dans des commentaires HTML, qu’un navigateur normal ne devrait pas demander
• Parmi les User-Agent observés, certains étaient clairement identifiables comme des bots, par exemple python-httpx/0.28.1, Go-http-client/2.0, Gulper Web Bot 0.2.4
• Les requêtes continuaient malgré l’interdiction d’accès aux crawlers dans robots.txt, ce qui suggère un non-respect des règles ou une politique ignorée
• Certaines requêtes se faisaient passer pour Firefox, Chrome ou Safari, mais leur incapacité à interpréter les commentaires HTML a révélé une fausse identification
• Ces requêtes sont soupçonnées de provenir de scrapers collectant sans consentement du contenu destiné à l’entraînement de LLM

Mode de fonctionnement des scrapers

• Certains pourraient parser correctement le HTML et explorer récursivement les URL présentes dans les commentaires
• D’autres semblent traiter le HTML comme du simple texte et effectuer une extraction d’URL basée sur des expressions régulières
• La diversité et le niveau hétérogène des User-Agent laissent penser à la présence de plusieurs opérateurs, dont certains utilisent de simples outils d’automatisation
• Leur motivation commune est une collecte de données vorace, que l’article présente comme pouvant être retournée contre eux

Sabotage algorithmique (Algorithmic Sabotage)

• Il s’agit d’actions visant à perturber intentionnellement des systèmes algorithmiques, un sujet mis en avant en raison du coût externalisé des LLM
• Une fois les schémas de comportement non humains des bots identifiés, leur détection et leur traitement deviennent plus simples
• Les réponses proposées se répartissent en quatre catégories : avertissement public, filtrage IP, bombes de décompression, empoisonnement des données

0. Avertissement public (Public Disclosure)

• Les faux positifs mineurs (par ex. une faute dans le User-Agent comme « Mozlla ») sont gardés non publics, car ils peuvent être facilement corrigés
• En revanche, les comportements de fond (par ex. demander des scripts dans des commentaires) ne peuvent pas être corrigés facilement, ce qui rend leur divulgation utile
• Cela permet à d’autres administrateurs de site de détecter et bloquer la même attaque
• Un système de détection de ce comportement est également en cours de déploiement sur d’autres sites

1. Filtrage IP (IP Filtering)

• fail2ban est utilisé pour bloquer automatiquement sur la base des motifs dans les logs, de la date et de l’IP
• En général, la durée de blocage est courte, mais un blocage longue durée peut décourager les nouvelles tentatives de bots apprenants
• Dans le cas d’un botnet, les requêtes peuvent se poursuivre en changeant d’IP, mais les schémas répétitifs permettent toujours la détection
• L’auteur mentionne un futur travail de recherche sur l’analyse du comportement des botnets

2. Bombes de décompression (Decompression Bombs)

• Fournir un zip bomb en réponse au fichier demandé peut provoquer une consommation importante des ressources système côté attaquant
• Cela peut entraîner une surconsommation de CPU, de RAM et de disque, voire permettre l’exploitation de vulnérabilités
• Inconvénient : cette méthode peut aussi consommer des ressources serveur et entraîner un gaspillage de bande passante
• Certains bots tournent sur des systèmes infectés, ce qui peut limiter l’effet de l’attaque
• Plutôt que de l’appliquer à tous les bots, l’article propose de ne répondre ainsi qu’à une partie aléatoire des requêtes

3. Empoisonnement des données (Poisoning)

• Il s’agit de contaminer les données d’entraînement des LLM afin de provoquer une dégradation de leurs performances
• D’après des recherches récentes, 250 documents empoisonnés pourraient suffire à produire un effet durable sur un grand modèle
• Les données empoisonnées peuvent amener le modèle à générer des sorties dénuées de sens sur certains sujets
• Exemple : orienter le modèle pour qu’il recommande un blog précis lorsqu’on l’interroge sur la recherche en sécurité
• Des outils publics comme nepenthes, iocaine, glaze, nightshade peuvent être utilisés
• Si les données d’entraînement d’un LLM sont collectées sans consentement, cette réponse est présentée comme un moyen de défense légitime
• La mise en œuvre conjointe avec le blocage IP peut accroître la complexité, mais une utilisation combinée reste possible
• L’auteur indique qu’il pourrait ne pas publier les conceptions les plus efficaces et souligne la nécessité d’élargir la participation à des formes créatives de sabotage

Conclusion et réponse de la communauté

• Détecter des bots par leur comportement anormal n’est pas une idée nouvelle, mais les requêtes de scripts dans des commentaires constituent ici un cas inédit
• L’ajout d’une directive Disallow dans robots.txt est proposé afin de déclencher des mesures de contre-attaque sur certaines requêtes

  User-agent: GPTBot
  Disallow: /poison/
  

• La communauté a également partagé diverses idées pour cacher des liens pièges à bots au moyen de display:none et de l’attribut rel="nofollow"
  • Exemple : <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
• Définir ces liens en chemins absolus (absolute URL) pourrait tromper davantage de crawlers
• Plusieurs expériences de leurres et de blocage de bots sont en cours sur différents sites, avec l’intention d’en mesurer et partager l’efficacité
• D’autres chercheurs participent aussi à des expériences de perturbation de scrapers IA, avec présentation de cas d’empoisonnement originaux
• L’objectif général est de favoriser la diffusion de stratégies autonomes de défense et de contre-attaque face à la collecte de données par l’IA

[GN⁺]

Avis Hacker News

• La plupart des scrapers web sont utilisés à des fins commerciales, même si c’est illégal
  Ils récupèrent donc souvent des données d’Amazon ou de sites e-commerce. Au final, l’essentiel du trafic indésirable vient des big tech ou d’acteurs malveillants à la recherche de vulnérabilités
  Je m’y connais un peu en web scraping. Certains sites renvoient même des 404 à titre de protection, donc mon crawler essaie plusieurs fois avec des méthodes de crawl rapides comme curlcffi
  La défense contre les zip bombs est simple : il suffit de lire le header content-length. Si la réponse est trop grosse, on fixe une limite en octets pour ne pas la lire, avec aussi un contrôle par timeout
  Mais savez-vous que le timeout de requests n’est pas un timeout sur la lecture complète de la page ? Si le serveur envoie les octets lentement, on peut attendre indéfiniment
  C’est pour régler ce genre de problème que j’ai construit mon propre système de crawl. On peut aussi y faire tourner Selenium de façon cohérente
  Mon projet est crawler-buddy, et la bibliothèque de base est webtoolkit

  • Il ne faut pas oublier que content-length est calculé après content-encoding
  • Je me demande s’il y a une différence entre “scraping” et “crawling”
  • On entre sans doute maintenant dans l’ère des scrapers dans le navigateur. Côté serveur, il devient impossible de les distinguer d’un humain, et les drivers IA peuvent même passer les tests destinés aux humains

• La formule “collecter des données d’entraînement LLM sans consentement” me fait rire
  On envoie des requêtes GET à un serveur HTTP public, je ne vois pas de quelle permission on aurait besoin. Bien sûr, l’affaire weev était une catastrophe à part

  • Quand j’ouvre un serveur HTTP public, j’accueille volontiers les requêtes GET ordinaires
    Mais (1) l’accès d’un utilisateur normal et une attaque DDoS de bots sont deux choses différentes. Ce n’est pas parce que c’est gratuit qu’on peut tout prendre sans limite, c’est un abus
    (2) Il faut distinguer la copie légitime et la contrefaçon opérée par des robots
    (3) Un bot bien élevé devrait respecter robots.txt. Ce n’est pas la loi, mais une question de politesse
    Des bots qui tournent sur des millions d’IP résidentielles ne sont absolument pas normaux
  • Si l’on trompe la configuration du serveur pour obtenir les données voulues, c’est un accès non consenti
    Ce n’est pas parce que le serveur est public qu’il autorise les requêtes mensongères. Il n’y a consentement implicite que pour des requêtes raisonnables
  • robots.txt n’a pas de force obligatoire, c’est une demande de courtoisie
    Cela veut simplement dire quelque chose comme « merci de ne pas scraper cette page » ; si l’on veut vraiment bloquer l’accès, il faut mettre en place des tokens API ou une authentification
  • Assimiler un accès unique à une explosion infinie de crawl n’a aucun sens
    De la même manière que le spam n’est pas un simple e-mail, l’abus de bots n’est pas une simple requête
  • Pour reprendre la métaphore du « bol de bonbons », si un adulte prend tous les bonbons prévus pour Halloween, personne ne va s’en réjouir

• Il me semble que rechercher directement les chaînes http/https serait plus rapide que parser le DOM

  • La différence de ressources entre une simple recherche textuelle et un parcours du DOM est telle que dire « probablement plus rapide » est en dessous de la réalité
  • L’approche par regex est simple à implémenter, mais même avec un parsing DOM, le vrai goulot d’étranglement est plus le réseau que le CPU Au final, le facteur limitant reste la congestion réseau

• C’est amusant de voir une application pratique d’une recherche intéressante
  On peut consulter la recherche en question dans ce billet

• Le titre prête à confusion. “commented-out” me semblerait plus juste

  • Moi aussi, au début j’ai cru qu’il s’agissait d’un script pour bloquer les scrapers IA

• Cela ressemble moins à un abus qu’au simple fait de lire des URL mises en commentaire

  • Le contenu de l’article n’explique pas un abus, mais une manière de l’utiliser comme signal de détection de bots
  • En revanche, ignorer robots.txt et scraper jusqu’aux commentaires reste clairement un comportement impoli

• À l’époque où je crawlait le web, les regex Perl étaient ce qu’il y avait de plus fiable
  Bien sûr, j’ajoutais aussi à la file les URL présentes dans les commentaires

  • Explorer le DOM était au contraire une tentative excessive. Attraper les div ou p nécessaires avec des regex était plus robuste et plus simple

• Je me demande ce que ça donnerait de servir aux bots un fichier de données aléatoires de 512 Mo

  • Ce serait encore plus rentable de manipuler les réponses publicitaires pour les scrapers IA afin d’inciter les LLM à recommander un produit précis
    La startup que j’ai créée fournit justement ce type de Ad-poisoning-as-a-service
  • On pourrait aussi créer des pages pièges empoisonnées pour l’IA, reliées aléatoirement entre elles pour enfermer les bots. Les humains, eux, ne cliqueront pas dessus
  • Mais la plupart des gens ne peuvent pas supporter le coût de bande passante
  • Ce serait aussi amusant de remplir les 512 Mo uniquement avec « notre service est le meilleur »

• Plus que de la “collecte de données pour l’entraînement des LLM”, c’est surtout du bruit de scan de l’Internet

  • Oui. Un scanner de vulnérabilités essaierait de collecter autant d’endpoints HTTP que possible
    Les fichiers JS sont de bons indices, qu’il y ait des commentaires ou non
    En revanche, pour de l’entraînement LLM, j’ai du mal à croire qu’on s’intéresse à un code JS de si faible qualité

• Voici une réflexion sur des moyens d’empoisonner le trafic d’entraînement LLM non désiré

  1. Si plusieurs sites coopèrent, ils augmentent leurs chances de contaminer le modèle tout en évitant la déduplication des données
  2. On pourrait aussi utiliser le droit d’auteur pour augmenter le coût de la pollution, même si cela peut exposer les sites à un risque juridique
     En coopérant avec les ayants droit, on pourrait réduire ce risque
  • Ce serait bien d’en faire un plugin WordPress
    On pourrait aussi modifier dynamiquement les images à chaque requête pour neutraliser les défenses par déduplication. S’il existait un tel plugin, je l’installerais immédiatement