Des scrapers IA agressifs compliquent sérieusement l’exploitation des wikis

 (weirdgloop.org)
3 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le trafic des scrapers IA fragilise les coûts et la stabilité des wikis publics et, sans mesures d’atténuation, peut consommer environ 10 fois plus de ressources de calcul que l’ensemble de l’activité humaine
  • Les bots vont au-delà des User Agents identifiables comme GPTBot et déguisent leurs en-têtes pour ressembler à la dernière version de Chrome, tout en contournant les blocages via des proxys résidentiels faisant tourner 1 million d’IP par jour
  • Les wikis exposent bien plus d’URL que leurs simples articles, avec des anciennes révisions, écrans d’édition et pages spéciales, si bien qu’un crawl naïf contourne les caches et peut coûter 50 à 100 fois plus qu’une requête normale
  • Les Cloudflare Challenge, Anubis, les règles de pare-feu manuelles et la détection basée sur des requêtes de comportement humain sont efficaces, mais génèrent aussi des faux positifs, une charge de maintenance et des frictions pour les lecteurs
  • Des blocages extrêmes comme l’obligation de connexion ou les challenges généralisés peuvent réduire les nouvelles contributions, d’où le besoin de discussions publiques entre opérateurs et d’approches API qui changent les incitations à collecter via des bots

La charge imposée aux wikis par les scrapers IA

  • Le scraping automatisé pour alimenter les données d’entraînement des LLM augmente à une échelle sans précédent et déstabilise les coûts comme la fiabilité des sites web publics : le sujet est aussi abordé dans FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline? et Smart TV web crawler AI
  • Weird Gloop héberge de grands wikis de jeux comme Minecraft Wiki, OSRS Wiki et League Wiki, et consacre de plus en plus de temps à la gestion du trafic de bots depuis trois ans
  • Sans atténuation continue, les bots peuvent consommer environ 10 fois plus de ressources de calcul que tout le reste du trafic réuni, y compris des dizaines de millions de pages vues humaines et des dizaines de milliers d’éditions par jour
  • La Wikimedia Foundation a également publié un article sur l’impact des crawlers sur ses opérations ; plusieurs grandes fermes de wikis ont subi divers niveaux d’incidents et certains petits wikis indépendants sont même passés complètement hors ligne
  • Cette année, environ 95 % des problèmes serveurs dans l’écosystème wiki seraient dus à de mauvais scrapers

Des scrapers qui veulent ressembler à des humains

  • Les bots « officiels » des grandes entreprises d’IA, comme GPTBot, ClaudeBot ou PerplexityBot, ont parfois ignoré robots.txt, mais ils restent généralement identifiables via leur chaîne User Agent, ce qui permet de les bloquer facilement avec le blocage des bots IA de Cloudflare ou via nginx
  • À mesure que les webmasters ont commencé à bloquer les scrapers IA sur la base du User Agent, les bots ont eu une forte incitation à se faire passer pour du trafic humain
  • Aujourd’hui, la majorité du trafic de scrapers IA qui atteint les wikis envoie des en-têtes travaillés pour ressembler à la dernière version de Google Chrome
  • Les signaux évidents qui permettaient autrefois de distinguer « bot ou vraie personne » ont disparu, rendant le blocage plus difficile

Des dizaines de millions d’IP et le contournement par proxy

  • Avant 2023, 95 % du scraping problématique provenait d’une seule adresse IP ou d’un petit sous-réseau de datacenter, ce qui rendait les blocages par IP ou caractéristiques d’ISP globalement efficaces
  • Avec des proxys résidentiels, il suffit d’une carte bancaire pour blanchir des requêtes de scraping à travers un réseau de millions d’adresses IP
  • Les wikis se retrouvent parfois face à des scrapers faisant tourner 1 million d’IP par jour, qui ressemblent à des requêtes légitimes venant d’ISP résidentiels comme Comcast, AT&T ou Charter
  • Les clients concernés ignorent probablement que leur IP sert de nœud de sortie à un proxy résidentiel
  • Certains acteurs malveillants utilisent aussi les aperçus de liens facebookexternalhit ou Google Translate pour faire croire que les requêtes proviennent des serveurs de Google ou Facebook, masquant ainsi leur origine réelle
  • Dans certains cas, 99,99 % des requêtes arrivant via l’outil d’URL de Google Translate étaient abusives, au point qu’il a fallu casser cet outil sur tous les wikis pendant un temps

Des « URL stupides » particulièrement coûteuses à crawler sur les wikis

  • Beaucoup de scrapers IA choisissent leurs URL en visitant la page d’accueil d’un wiki, puis tous les liens de cette page, puis tous les liens des pages suivantes, et ainsi de suite
  • Ils semblent ignorer que robots.txt et les sitemaps indiquent déjà quelles URL valent la peine d’être scrapées
  • OSRS Wiki contient environ 40 000 articles, et ces URL représentent l’essentiel des informations utiles du site
  • Mais si l’on inclut les anciennes révisions, les écrans d’édition et les pages spéciales, le nombre d’URL explorables atteint au moins 1 milliard
  • Ce crawl naïf ne se termine jamais et semble gaspiller beaucoup de ressources sur des URL peu utiles pour l’entraînement des LLM
  • Ces requêtes étranges contournent aussi des couches de cache comme le cache du parseur MediaWiki, qui est normalement utilisé par les vraies requêtes utilisateurs, ce qui augmente le coût du service
  • Une requête servie depuis le cache se traite généralement en moins de 20 millisecondes, alors qu’une requête vers un vieux diff prend souvent 1 à 2 secondes
  • Des métriques globales comme « 8 millions de requêtes bots par jour » ou « les bots utilisent 65 % de la bande passante » sous-estiment le problème
  • Le vrai goulot d’étranglement est généralement le CPU, et une requête de bot avec des paramètres de requête bizarres coûte souvent 50 à 100 fois plus à traiter qu’une requête normale

Des pics de trafic invisibles dans les moyennes

  • Les requêtes mensuelles de bots tournent autour de 250 millions, soit environ 100 requêtes par seconde en moyenne, mais il ne s’agit que d’une moyenne de long terme
  • Les scrapers envoient fréquemment plus de 1 000 requêtes par seconde sur de courtes périodes, ce qui les rend presque impossibles à distinguer d’une attaque DDoS classique
  • Même si, sur le long terme, les bots ne représentent qu’environ 50 % de l’usage CPU total, les pics de trafic malveillant provoquent environ 95 % des ralentissements et incidents des wikis

Une structure qui rend l’attribution difficile

  • On parle de « scrapers IA », mais comme tout le trafic se déguise en Google Chrome, il est difficile de savoir qui en est réellement responsable et à quoi servent les données de wiki collectées
  • Les acteurs possibles vont des courtiers en données à des collectes redondantes de frontier labs, en passant par des projets indépendants ayant accès à des proxys résidentiels
  • Le niveau réel de baisse de la barrière à l’entrée reste lui aussi incertain
  • S’il existait une meilleure manière de faire, l’objectif serait de contacter directement les vrais collecteurs pour trouver des méthodes moins inefficaces

Ce qui a fonctionné jusqu’ici

  • Cloudflare Challenge et Anubis

    • Placer un site derrière un Cloudflare challenge ou un outil comme Anubis est devenu courant sur Internet au cours de la dernière année
    • C’est efficace dans une certaine mesure, mais il y a des périodes où certains bots passent régulièrement les challenges
    • Il semble exister une course aux armements invisible entre Cloudflare et les développeurs de bots : Cloudflare gagne environ 90 % du temps, mais les 10 % restants suffisent à créer une vraie difficulté opérationnelle
    • Les vrais lecteurs n’aiment pas voir un challenge avant d’accéder à un wiki
    • Pour éviter d’affecter la majorité des gens, il faut de bonnes règles heuristiques permettant de décider quel trafic doit être challengé, mais détecter de façon fiable le trafic automatisé est déjà en soi difficile

  • Règles de pare-feu manuelles

    • La plupart des opérateurs disposent de règles de pare-feu manuelles adaptées à leur infrastructure et à leurs attaques passées
    • Ces filtres reposent généralement sur des chaînes User Agent spécifiques, des groupes d’IP ou des ASN
    • Weird Gloop traite la plupart de cela au niveau Cloudflare/CDN, mais d’autres wikis le font côté nginx ou serveur web
    • Aujourd’hui, User Agent et IP ne suffisent souvent plus ; il faut examiner des attributs de requête plus complexes comme la version HTTP, les en-têtes, les suites TLS, ou des hachages liés à ja4

  • Chercher « ce que les humains font et que les bots ne font pas »

    • Une approche utile consiste à chercher des comportements collectifs humains que les bots n’imitent pas
    • Sur les wikis basés sur MediaWiki, les vrais utilisateurs de navigateur génèrent fréquemment plusieurs types de requêtes HTTP que les bots ne produisent généralement pas
    • Si un ensemble de trafic, identifiable via les en-têtes, des hachages ja4, etc., visite de nombreux articles sans jamais produire les requêtes typiques d’un « humain », c’est un signal fort pour lui appliquer un challenge
    • Observer l’absence de requêtes de comportement humain dans le trafic de bots est particulièrement puissant
    • Un système a commencé à être développé pour analyser ce trafic « manquant » et proposer automatiquement des heuristiques basées sur des arbres de décision pour décider quel trafic challenger
    • En test, cela semblait bien détecter presque tous les scrapers, mais on ne sait pas encore clairement quels faux positifs cela peut générer pour des utilisateurs aux habitudes inhabituelles, comme ceux de NoScript, de lecteurs d’écran ou d’appareils inattendus
    • La création puis la maintenance permanente d’une infrastructure interne de ML et d’analyse de données restent aussi une charge

  • Techniques de détection plus exotiques

Des options extrêmes mauvaises pour les lecteurs

  • Les « options nucléaires » pour bloquer les scrapers IA sont bien plus destructrices pour les vrais utilisateurs
  • Une méthode courante consiste à exiger une connexion pour voir des pages dont le coût de génération peut être élevé
  • Fandom a appliqué ce type de mesure à tous ses wikis il y a quelques mois
  • Une autre approche consiste à servir un Cloudflare challenge à tout le trafic
  • Du point de vue d’un webmaster, cela se comprend, mais c’est mauvais pour la santé à long terme d’un wiki et de sa communauté
  • En 16 ans de construction de communautés wiki, la leçon essentielle a été que la meilleure façon d’attirer de nouveaux contributeurs est de supprimer les frictions
  • Il faut faciliter l’édition, rendre la structure interne du wiki plus simple à explorer, et abaisser la barrière d’entrée entre lecteurs et éditeurs
  • Les techniques antibot extrêmes recréent de la friction et produisent des résultats prévisibles
  • Après que Fandom a caché les « pages internes » à plus de 95 % des lecteurs non connectés, les nouvelles contributions d’utilisateurs à l’échelle de Fandom auraient chuté d’environ 40 %
  • Il est difficile de considérer ce compromis comme valable

La suite

  • Weird Gloop continue d’héberger des wikis et poursuit aussi son travail pour aider des wikis à quitter Fandom
  • À long terme, les « AI Overviews » pourraient tuer le pipeline qui transforme les lecteurs de wiki en contributeurs, mais c’est un problème distinct
  • Certains proches pensent que cette vague de bots pourrait en réalité avantager Weird Gloop, mais si les gens ne peuvent plus héberger facilement des wikis, Internet s’en portera plus mal
  • Un scénario où l’hébergement fiable d’un wiki exigerait des astreintes, des ingénieurs ML et des produits d’entreprise serait une très mauvaise nouvelle pour les communautés wiki indépendantes
  • La course aux armements entre propriétaires de bots et webmasters devrait se poursuivre tant qu’aucune méthode intelligente ne viendra modifier les incitations structurelles au scraping
  • La nouvelle crawling API de Cloudflare pourrait changer la donne s’il devient plus simple pour les bots d’utiliser une API que de construire leurs propres systèmes ignorant robots.txt et causant des problèmes
  • Il vaudrait mieux que le scraping n’ait pas lieu du tout, mais il est difficile de revenir en arrière maintenant que c’est déjà en cours

La nécessité d’une discussion publique et de coopération

  • Des milliers d’opérateurs gèrent chacun leur site web et cherchent des techniques plus intelligentes pour répondre aux bots
  • Dans des conversations privées avec d’autres administrateurs systèmes, des idées concrètes et intéressantes ont émergé, et il est probable que beaucoup de discussions aient aussi lieu sur Slack, Discord ou dans de petits groupes
  • Il faut davantage de discussions publiques sur les détails concrets de l’exploitation au quotidien
  • Beaucoup d’administrateurs systèmes ne réalisent pas assez que les problèmes qu’ils rencontrent sont presque identiques à ceux d’autres opérateurs
  • Tout le monde n’a pas envie de rendre publiques ses méthodes de défense, par crainte de perdre un avantage en le faisant
  • Malgré cela, si cela aide les gens à réfléchir ensemble, le risque de réduire l’efficacité de certaines tactiques mérite d’être pris
  • Les administrateurs systèmes confrontés aux scrapers IA ont intérêt à partager, dans les espaces adaptés, les méthodes qui ont fonctionné pour eux
  • Les entreprises qui vendent des produits de résolution du problème des bots devraient publier davantage d’études de cas contenant des données concrètes sur les ratios de precision and recall dans des situations non artificielles
  • Les personnes qui prennent les décisions d’achat se soucient des résultats réels, pas de cocher des cases
  • Si vous exploitez un wiki ou un site web indépendant et souhaitez discuter de la détection de bots, vous pouvez prendre contact par e-mail ou via un message Discord

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Avis sur Lobste.rs

  • J’ai essayé d’utiliser un défi de preuve d’attente (proof-of-wait) pour compenser les défauts d’Anubis, et cela a plutôt bien marché
    En gros, si le taux global de requêtes reste sous un certain seuil, le filtre est désactivé, et s’il le dépasse, l’utilisateur doit attendre N secondes avant de pouvoir continuer
    Ensuite, un jeton lié à cette IP est émis, n’autorisant qu’un petit nombre de requêtes pendant sa durée de validité, et le jeton lui-même est aussi soumis à une limitation de débit
    Si les requêtes réussies continuent d’arriver, le temps d’attente augmente progressivement
    Cela a assez bien fonctionné, avec une dégradation progressive qui ne pénalise pas excessivement les appareils mobiles, et ça marche sans JavaScript

    • J’ai vu cette approche fonctionner sur marginalia.nu, et j’aime bien le fait qu’elle ne gaspille pas la batterie du téléphone en preuve de travail
    • Si cela fait partie du code publié, je me demande s’il serait possible d’avoir un lien vers le code source qui l’implémente
    • Très chouette. Je me demande s’il existe des efforts pour intégrer ce genre d’approche à TLS. Cela ressemble un peu à ce que draft-venhoek-tls-client-puzzles-00 essaie de faire pour les défis de preuve de travail
      Ce genre de chose devrait probablement se situer beaucoup plus bas dans la pile, comme TLS, voire la pile IP du système d’exploitation
      Je n’ai pas beaucoup réfléchi à la preuve d’attente, mais n’est-ce pas bien pire pour les utilisateurs légitimes que pour les scrapers automatiques ? Les humains s’énervent d’attendre, alors que le scraper peut stocker le jeton et revenir N secondes plus tard
      J’ai aussi des sentiments mitigés sur la preuve de travail, mais au moins elle impose aux scrapers un coût réel proportionnel à l’échelle
    • Je me demande si c’est simple à configurer. Cela m’intéresse aussi pour mon wiki
    • Cela semble être une approche utile. Je me demande si vous prévoyez de publier plus de détails
      La preuve d’attente pourrait rassurer les personnes préoccupées par la preuve de travail

  • Pour certaines pages spéciales, le fait d’exiger une connexion préalable et de n’autoriser l’accès qu’aux clients ayant ce cookie fonctionne aussi plutôt bien, sinon l’accès est refusé
    Comme la plupart des crawlers visent les pages spéciales pour parcourir le wiki, on peut les réserver aux utilisateurs connectés
    Dans cette configuration, le wiki n’autorise pas la création de comptes
    <If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
    ErrorDocument 403 "Access denied, please login."
    Require all denied
    </If>
    Cela a considérablement réduit la charge sur notre système. Avant, il y avait souvent des pics où les pages spéciales étaient tellement crawlées que le wiki devenait inutilisable
    À part ça, on bloque immédiatement avec un 403 les user agents connus de crawlers IA, et on bloque aussi certaines plages d’IP comme Alibaba ou Amazon Cloud
    Fait amusant, ils s’en sont rendu compte. Ils parcouraient les pages via la vue Diff, puis quand on a limité cela, ils ont essayé la même chose via la vue MobileDiff
    Il y a eu quelques allers-retours, mais depuis quelques mois, cette méthode fonctionne bien

    • Le blocage basé sur le user agent est en pratique presque la pire chose à faire
      Si vous bloquez par user agent, le crawler réessaie avec un user agent ayant l’air humain pour explorer le site
      S’il déduit que le déclencheur du blocage est le user agent, il passe en mode enfer, ce qui le rend bien plus difficile à identifier, et il martèle le site jusqu’à le mettre à terre
      Le blocage par plage d’IP aide aussi, mais ce n’est pas suffisant et il est impossible de tout attraper, car ils crawlent via des proxys de malwares mobiles
      Si on ne les bloque pas du tout au départ, ils ont généralement tendance à rester relativement sages
      L’astuce consiste donc, au lieu de bloquer, à leur servir des données poubelles générées à bas coût, sans déclencher le mode enfer, et moi j’utilise https://iocaine.madhouse-project.org/
    • À noter qu’on peut aussi faire cela avec les permissions MediaWiki. En mettant par défaut toutes les permissions à refusé, puis en ne redonnant aux utilisateurs anonymes que la lecture des pages de l’espace de noms principal, on évite le jeu du chat et de la souris
      En revanche, cela oblige MediaWiki à servir lui-même les réponses, alors qu’il y a aussi un avantage à laisser Apache s’en charger
    • Je me demande s’ils s’en sont réellement rendu compte immédiatement. À mon avis, les auteurs de scrapers avaient déjà plusieurs techniques de repli prêtes, et quand ils ont commencé à recevoir des 403, le bot a sans doute simplement essayé les astuces suivantes dans l’ordre

  • À part ça, Weird Gloop est un excellent service. La qualité des wikis qu’ils exploitent est très élevée, et déplacer du contenu créé par les fans hors de l’horrible plateforme de Fandom rend service au monde

  • Gergely Nagy, alias algernon, ainsi que le développeur de iocaine, s’occupe de ce problème depuis un moment et a probablement des retours utiles pour Weird Gloop

  • Je déteste dire ça, mais les propositions du type réglons ça sur le comportement humain risquent de se retourner contre nous plus tard
    Les bots vont se mettre à demander aussi toutes les ressources statiques de la page, en partant du principe que cela fait partie des comportements qui identifient un humain
    Jeu intéressant, professeur Falken

  • Si le scraper atteint ce genre de pages en suivant récursivement des liens <a href=...> ordinaires, je me demande si on ne pourrait pas le rediriger en douceur ailleurs en rendant des pages coûteuses et non mises en cache, comme les différences d’historique, accessibles uniquement via soumission de <form method="POST" action=...>
    On ne bloque rien, et en fait c’est presque aussi avantageux pour le scraper, puisqu’on l’empêche d’ingérer récursivement une quantité presque infinie d’informations redondantes
    Les utilisateurs ordinaires verraient à peine la différence, et le rapport effort/efficacité semble correct. Pour les utilisateurs anonymes, cela pourrait être mieux qu’Anubis
    Cela repose sur l’hypothèse que les scrapers ne soumettent pas les formulaires HTTP avec method="POST"
    Si ce n’était généralement pas vrai, on aurait déjà vu des gros titres disant que des scrapers IA ont soumis en masse des modifications anonymes et transformé le contenu de Wikipedia en déchets aléatoires

    • Cela rendrait aussi la réponse non cacheable, ce qui pourrait poser problème si vous dépendez d’un CDN
      Je me demande si les bots suivent aussi les <form method="GET">. Cela serait plus compatible avec le cache, tout en imposant une logique supplémentaire aux crawlers

  • 95 % du trafic de mon petit blog vient de scrapers LLM de Singapour et de Chine

  • Cela fait des années, et personne n’a réussi à remonter à une IP appartenant à un petit FAI qu’on pourrait contacter et aller voir directement ? À demander poliment à cet utilisateur si on peut examiner sa machine ? Personne n’a réussi à découvrir concrètement quel logiciel fait ce crawling ?
    Si les administrateurs de sites n’en sont même pas capables, alors je n’ai plus envie de m’en soucier. En réalité, c’est parce qu’ils font tout pour éviter le contact humain sale et direct qu’ils récoltent des bots
    Et les bots qui tournent sur des botnets résidentiels ont bien sûr parfois assez de ressources de calcul pour passer un CAPTCHA ou Anubis
    Il est impossible de gagner durablement côté serveur. L’utilisateur de cette machine produit aussi du trafic légitime
    Donc, à moins de vouloir une attestation à distance, il faut aller voir ces IP

    • Vous semblez sous-estimer l’ampleur des botnets résidentiels
    • Le problème, c’est que le trafic vient de dizaines de milliers d’IP différentes
      Même en laissant de côté des questions pratiques comme le coût de l’essence pour parcourir le monde, cela devient un énorme problème du voyageur de commerce
    • C’est une opinion vraiment stupéfiante de médiocrité
      L’idée que quelques bots justifieraient que des administrateurs système passent tout un week-end à conduire n’importe où pour leur demander d’être un peu plus polis, surtout quand la plupart viennent de gros FAI ou de FAI étrangers, est simplement risible
      On se demande ce que vous avez fumé
      Quant à savoir quel logiciel fait le crawling aujourd’hui, il suffit que quelqu’un demande à un chatbot « fabrique-moi un truc qui scrape ceci », et chaque scraper est ensuite généré individuellement
    • La question du « personne » n’est raisonnable que si vous pouvez dire qui aurait les moyens, la motivation ou la responsabilité de faire ce travail
      Sinon, cela revient juste à blâmer l’univers de façon abstraite
    • Contacter un petit FAI puis aller sur place n’est pas réaliste
      Je peux garantir que la plupart des fournisseurs se moquent complètement que leurs IP servent à scraper un site web
      Et je peux aussi garantir qu’ils ne vous donneront jamais l’adresse liée à cette IP
      Ce qui marche bien mieux, c’est de jeter en bloc le trafic ASN associé à plusieurs fournisseurs comme Alibaba ou AWS
      Ce n’est pas toujours une option possible. Par exemple, pour un blog avec un flux Atom, cela peut aussi bloquer les lecteurs de flux
      Mais dans beaucoup de cas, cela permet d’éliminer 80 % du trafic poubelle

  • Est-ce que quelqu’un sait pourquoi ce comportement se produit ? Je me demande surtout d’où viennent les pics

    • Une hypothèse que j’ai entendue est que le botnet est peu fiable, et que les gens qui vendent l’accès au botnet via des proxys résidentiels compensent cette instabilité par des requêtes dupliquées
      Je ne sais pas si c’est vrai, mais au moins c’est plausible
      Sans mieux comprendre l’infrastructure, c’est difficile à dire. Cela pourrait aussi être une limite du command-and-control
      Si le botnet a été conçu pour le DDoS, il est possible que son architecture manque par nature de contrôle fin de ce type