L’infrastructure FOSS est attaquée par les entreprises d’IA

 (thelibre.news)
1 points par GN⁺ 2025-03-21 | 1 commentaires | Partager sur WhatsApp
  • De nombreuses infrastructures FOSS comme SourceHut, KDE GitLab, GNOME GitLab, LWN, Fedora, Inkscape, Diaspora et Read the Docs subissent des pannes, des blocages et une charge d’exploitation accrue à cause des crawlers d’IA et des rapports de sécurité générés par l’IA
  • Les crawlers ignorent robots.txt ou sollicitent de façon répétée des endpoints coûteux comme git blame, les logs Git ou les pages de commit, et tentent de se fondre dans le trafic normal avec des dizaines de milliers d’IP et des User-Agent usurpés
  • GNOME a introduit la preuve de travail Anubis, mais sur environ 81 000 requêtes en 2 h 30, seules 3 % sont passées, ce qui suggère que la majeure partie du trafic était probablement composée de bots
  • Blocage de versions d’Edge, restrictions pour les utilisateurs non connectés, blocage de sous-réseaux ou de pays, listes d’IP bloquées, robots.txt et .htaccess pour les crawlers d’IA : les contre-mesures se multiplient, et les vrais utilisateurs subissent eux aussi des lenteurs ou des blocages d’accès
  • Les projets open source qui reposent sur la collaboration publique ont une surface d’exposition plus large que les services privés, si bien que le scraping par l’IA et les rapports de sécurité hallucinés par les LLM grignotent directement le temps et les capacités opérationnelles des mainteneurs

Pannes répétées sur plusieurs infrastructures FOSS

  • Drew DeVault, fondateur et CEO de SourceHut, critique les entreprises de LLM qui crawlaient les données sans respecter robots.txt, provoquant de graves perturbations sur SourceHut
  • L’infrastructure KDE GitLab a été surchargée par des crawlers d’IA provenant d’adresses IP de la plage Alibaba, empêchant temporairement les développeurs KDE d’accéder à GitLab
  • Sur GNOME GitLab, un écran de chargement par défaut du challenger de preuve de travail Anubis a commencé à apparaître pour bloquer les scrapers d’IA à l’origine des incidents
  • À mesure que les cas s’accumulent, l’agressivité des scrapers d’IA augmente et la charge d’exploitation des communautés FOSS fondées sur la collaboration publique s’alourdit aussi

Mode de fonctionnement des crawlers et difficulté du blocage

  • Selon Drew DeVault, les crawlers de LLM ne respectent pas les consignes de robots.txt et parcourent l’ensemble des dépôts, y compris les pages les plus coûteuses
    • Parmi les cibles figurent git blame, toutes les pages de logs Git et tous les commits d’un dépôt
    • Les crawlers utilisent des User-Agent aléatoires depuis des dizaines de milliers d’IP, chaque IP n’envoyant qu’une requête HTTP ou moins pour se mêler au trafic utilisateur
  • Cette méthode rend les mesures d’atténuation difficiles à mettre en place, et sur SourceHut, des tâches prioritaires ont été retardées de plusieurs semaines ou mois
  • Comme il est difficile de distinguer les bots des humains, de vrais utilisateurs ont aussi été affectés par intermittence, ce qui a conduit aux pannes de SourceHut
  • Drew ne distingue pas si toutes les entreprises d’IA traitent robots.txt ou la déclaration du User-Agent de la même manière

Réponse de KDE et GNOME

  • Selon Ben, de l’équipe sysadmin de KDE, les IP ayant provoqué un DDoS sur KDE GitLab prétendaient toutes être MS Edge, et le problème venait d’entreprises chinoises d’IA
    • Ben estime que les opérateurs occidentaux de LLM comme OpenAI et Anthropic configurent au moins un User-Agent correct
    • La solution temporaire consistait à bloquer la version d’Edge revendiquée par les bots
    • Comme les bots ont tendance à changer de User-Agent pour se fondre dans le trafic, cette approche est difficile à utiliser comme solution définitive
  • GNOME subissait le problème depuis novembre dernier et a mis en place une limitation de débit empêchant les utilisateurs non connectés de voir les merge requests et les commits
    • Cette mesure a aussi posé problème à de vrais utilisateurs non connectés
  • GNOME est ensuite passé à Anubis
    • Anubis soumet au navigateur un problème de calcul, et l’accès est autorisé une fois la solution renvoyée au serveur après un certain temps de calcul
    • Un développeur a décrit cela comme une « mesure proche de l’option nucléaire », estimant que ce choix avait été imposé par le fait que les scrapers d’IA ne respectent pas des standards comme robots.txt
  • Anubis a aussi eu un impact côté utilisateur
    • Quand beaucoup de personnes ouvrent un lien depuis le même endroit, un défi plus difficile peut être proposé
    • Un utilisateur a subi 1 minute de retard, un autre environ 2 minutes d’attente sur mobile
    • Cela s’est produit quand des liens GitLab étaient collés dans des salons de discussion ou quand la merge request GNOME Triple Buffering a attiré l’attention sur Hacker News
  • Selon les chiffres partagés par le sysadmin GNOME Bart Piotrowski, sur un total de 81 000 requêtes en environ 2 h 30, seuls 3 % ont passé la preuve de travail Anubis
    • Taux de réussite Anubis : {p:3}
    • Cela suggère que 97 % du trafic pourrait être composé de bots

Cas de blocage chez LWN, Fedora et Inkscape

  • Jonathan Corbet, qui gère LWN, a averti les utilisateurs que le site pouvait « parfois être lent » en raison d’un DDoS causé par des bots de scraping d’IA
    • Selon lui, le trafic destiné à de vrais lecteurs humains ne représente qu’une petite partie du total
    • À un moment, les bots accédaient au site simultanément depuis des centaines d’IP, sans se présenter comme bots, et sans même lire robots.txt
  • Kevin Fenzi, sysadmin du projet Fedora, a lui aussi subi le problème des scrapers d’IA
    • Il y a un mois, il a dû intervenir pour maintenir pagure.io en ligne
    • La situation s’est ensuite aggravée, conduisant au blocage de plusieurs sous-réseaux, avec un impact sur de vrais utilisateurs
    • Dans une situation jugée désespérée, le Brésil entier a été bloqué, et ce blocage serait toujours en place
  • Neal Gompa souligne que même le blocage d’un pays entier a ses limites, et que l’infrastructure Fedora est « régulièrement tombée en panne pendant des semaines » à cause des scrapers d’IA
  • Inkscape a connu le même problème la semaine dernière
    • Martin Owens estime qu’il ne s’agissait pas du DDoS chinois habituel de l’an dernier, mais de plusieurs entreprises ignorant les réglages des spiders et usurpant des informations de navigateur
    • Il a créé la liste de blocage Prodigius et indique que si vous travaillez dans une grande entreprise active dans l’IA, vous pourriez ne plus pouvoir accéder au site d’Inkscape

Listes de blocage IP et tentatives de réponse collective

  • BigGrizzly, de Frama software, a lui aussi été inondé par de mauvais crawlers de LLM et a constitué une liste de blocage de 460 000 IP utilisant des User-Agent usurpés
    • Il dit pouvoir partager cette liste
  • Le projet ai.robots.txt est une tentative plus large de créer une liste publique des crawlers web liés aux entreprises d’IA
    • Il fournit un robots.txt implémentant le Robots Exclusion Protocol
    • Il fournit aussi un fichier .htaccess qui renvoie une page d’erreur aux requêtes provenant des crawlers d’IA figurant dans la liste

Chiffres de trafic chez Diaspora et Read the Docs

  • L’analyse de Dennis Schubert sur l’infrastructure Diaspora montre qu’une part importante du trafic web total provient de bots d’entreprises d’IA
    • Les bots avec User-Agent OpenAI représentent un quart du trafic web total
    • Amazon représente 15 %, Anthropic 4,3 %
    • Au total, environ 70 % des requêtes proviennent d’entreprises d’IA
  • Schubert explique que ces bots ne crawlaient pas une fois pour repartir, mais revenaient toutes les 6 heures, sans se soucier de robots.txt
    • Quand on applique une limitation de débit, ils basculent sur d’autres IP
    • Quand on les bloque par chaîne User-Agent, ils passent à des User-Agent non identifiés comme bots
    • Il décrit cela comme un DDoS à l’échelle de tout l’Internet
  • Dans un article intitulé « AI crawlers need to be more respectful », Read the Docs indique qu’après avoir bloqué tous les crawlers d’IA, son trafic a baissé de 75 %
    • Taux de baisse du trafic : {p:75}
    • Le trafic est passé de 800 Go par jour à 200 Go
    • Cela a permis d’économiser environ 1 500 dollars par mois
    • Dans certains cas, les crawlers téléchargeaient plusieurs dizaines de To de données en quelques jours
    • Comme ils utilisent plusieurs IP, il est difficile de les bloquer complètement
  • Selon Schubert, même réunis, les crawlers « légitimes » comme Google et Bing représentent moins de 1 % du trafic

La charge de maintenance créée par les rapports de sécurité générés par l’IA

  • Le problème ne s’arrête pas au scraping et s’étend aussi aux rapports de bugs générés par l’IA
  • Daniel Stenberg, du projet Curl, traite du problème des rapports de bugs générés par l’IA dans son article « The I in LLM stands for Intelligence »
    • Curl exploite un programme de bug bounty
    • Récemment, de nombreux rapports de bugs ont été générés par l’IA et, en apparence, semblaient plausibles, ce qui oblige les développeurs à y consacrer du temps
    • Mais ces rapports contiennent les hallucinations typiques qu’on attend de l’IA
  • Seth Larson, membre des équipes de triage des rapports de sécurité pour CPython, pip, urllib3 et Requests, rencontre un problème similaire
    • Les projets open source reçoivent de plus en plus de rapports de sécurité d’une qualité extrêmement faible, assimilables à du spam et issus d’hallucinations de LLM
    • Comme ces rapports peuvent sembler légitimes au premier regard, il faut du temps pour les réfuter
  • Le traitement des rapports de sécurité est coûteux, et répondre à des rapports de bugs plausibles mais fabriqués impose une lourde charge supplémentaire aux mainteneurs
  • Larson demande de ne pas utiliser l’IA ou des systèmes LLM pour la détection de vulnérabilités
    • Selon lui, les systèmes actuels ne peuvent pas comprendre le code, alors que la détection de vulnérabilités exige une compréhension du code ainsi que de concepts de niveau humain comme l’intention, les usages courants et le contexte

Une charge structurelle plus forte pour le FOSS

  • Les projets FOSS disposent souvent de moins de ressources que les produits commerciaux
  • Dans les projets pilotés par la communauté, une plus grande partie de l’infrastructure est publique et donc exposée aux crawlers
  • Comme ils ont besoin d’infrastructures publiques pour les issues, les rapports de sécurité et la collaboration, les scrapers d’IA et les issues générées par l’IA deviennent une double charge
  • Au final, la réponse aux incidents, les politiques de blocage, l’atténuation des dommages pour les utilisateurs et l’examen des faux rapports de sécurité consomment le temps des mainteneurs open source

À lire aussi

1 commentaires

 
GN⁺ 2025-03-21
Avis sur Hacker News

  • Il y a aussi cet exemple : https://about.readthedocs.com/blog/2024/07/ai-crawlers-abuse... C’est un article également cité dans le texte original, et les personnes que je connais qui exploitent de grandes infrastructures Internet vivent toutes des choses similaires.
    Cet article rassemble bien ces cas au même endroit. Comme je le disais en l’écrivant, ils sont tout simplement en train de brûler entièrement leur capital de confiance.
    L’une des principales startups du secteur a travaillé directement avec nous, nous a remboursé les coûts et a corrigé le bug de son crawler. Facebook, en revanche, n’a pas répondu aux e-mails, et le lien dans le User Agent renvoyait une 404. Un ingénieur de l’entreprise a vu l’article et nous a indiqué la bonne adresse e-mail, mais même après trois messages envoyés là-bas, nous n’avons reçu aucune réponse.

    • Les entreprises d’IA semblent agir comme si le capital de confiance n’avait pas d’importance. Elles font ce qu’elles veulent, comme un gorille de 800 livres doté de 100 milliards de dollars de capital.
      Leur attitude, c’est que, qu’on le veuille ou non, l’IA sera intégrée à tous les produits, et qu’elle absorbera toutes les données, qu’on le veuille ou non.
    • Je me suis arrêté pour relire le passage : « un crawler a téléchargé 73 To de fichiers HTML compressés en mai 2024, entraînant plus de 5 000 dollars de coûts de bande passante ».
      J’exploite une infrastructure qui traite plusieurs centaines de To de trafic par mois, surtout sur des serveurs dédiés, et le coût du trafic est grosso modo de 0,50 à 3 dollars par To. Cela varie selon les régions, mais le coût du trafic sortant AWS est vraiment délirant.
    • S’il n’y a pas de réponse, il suffit d’envoyer la facture à l’équipe comptabilité fournisseurs plutôt que par e-mail.
    • Si vous n’avez pas reçu de réponse après trois e-mails, à partir de là le crawling ne devrait-il pas être considéré non plus comme un bug ou une erreur, mais comme un DDoS ?
    • Et si on leur servait simplement des informations poubelles générées dynamiquement ? Ce serait sans doute plus amusant que de ne rien leur donner du tout.

  • Voir mon projet apparaître comme ça dans l’image d’aperçu, c’est vraiment irréel. Impressionnant ! Si vous voulez l’essayer, c’est ici : https://github.com/TecharoHQ/anubis
    D’après ce que j’ai vu jusqu’ici, ça semble vraiment fonctionner. Je l’ai déployé en production sur xeiaso.net pour voir comment il échoue en conditions réelles sur mon blog.

    • Ce serait bien d’ajouter un peu d’explication pour les humains sur ce qu’ils doivent faire maintenant et sur ce qui se passe sur la page.
      Il y a bien une sorte de widget avec une animation de chargement, mais quand je l’ai vu pour la première fois il y a quelques semaines sur le tracker d’issues de Gnome, la preuve de travail prenait environ 20 secondes et je ne comprenais pas ce qui se passait. Au début, j’ai cru que j’étais bloqué ou que le CAPTCHA ne s’était pas chargé.
      Maintenant je sais ce que c’est, mais prise isolément, la page « vérification que vous n’êtes pas un bot » ne me semble pas claire à 100 %.
    • J’aime beaucoup cette approche. Ça ne me dérange pas qu’Internet fonctionne comme un Far West, mais je n’aime pas l’absence de responsabilité.
      C’est une bonne façon, pour ceux qui veulent continuer à laisser leur site ouvert gratuitement, de transférer la charge économique aux crawlers. S’ils veulent les données, que ce soient eux qui paient.
      L’inconvénient est qu’on peut disparaître des moteurs de recherche, mais rien n’empêche d’inscrire le service dans un indexeur global ou P2P.
    • J’aime bien, comme toujours c’est bien fait.
      Et à propos de https://news.ycombinator.com/item?id=43422781, si on ajoutait un mécanisme qui calcule une infime fraction de la shitcoin de votre choix, cela pourrait donner à la cryptomonnaie un cas d’usage réellement utile de plus.
    • Anubis ne fonctionnera que tant qu’il ne deviendra pas célèbre. Une fois qu’il le sera, les crawlers commenceront à traiter les preuves de travail avec des GPU/ASIC, et ce sera terminé.
    • J’aime bien tomber parfois au hasard sur quelque chose que tu as créé. J’aime aussi le format d’explication façon blog, donc je compte regarder Anubis de plus près.

  • À ce rythme, ce n’est pas seulement un problème propre aux infrastructures libres et open source. Bien sûr, elles sont le canari dans la mine de charbon, donc cela résonne particulièrement, mais au bout du compte, c’est un problème qui concerne tout l’accès anonyme à Internet
    On peut placer un site derrière un mur d’authentification, mais les nouveaux bots, contrairement aux anciens, résolvent les captchas et imitent de vrais utilisateurs. C’est d’autant plus vrai quand ils utilisent des IP résidentielles et de faux User-Agent, voire de vrais User-Agent reliés à des outils comme Playwright, comme dans l’article
    Au final, que restera-t-il, à part voir les sites commencer à exiger une carte bancaire, Worldcoin ou une alternative tout aussi déprimante ?

    • On est déjà à mi-chemin. Je le ressens à chaque fois que je fais de la cartographie OpenStreetMap et que je cherche des commerces locaux qui n’ont pas leur propre site web
      Ils utilisent Facebook, Instagram, X, etc. comme cartes de visite numériques. Je n’utilise pas Facebook ni Instagram au quotidien, j’ai aussi quitté X et je n’ai pas de compte ; quand je suis ces liens, je ne vois qu’une partie des informations avant qu’une boîte de dialogue me demande de créer un compte ou de partir, ou bien qu’une erreur obscure apparaisse
      Rejoindre des communautés privées, pourquoi pas, mais voir ce genre de barrières se dresser devant des informations publiées en pensant qu’elles seraient visibles publiquement, c’est vraiment agaçant
    • Pour dire tout haut la partie silencieuse : l’une des principales raisons pour lesquelles tout cela est déprimant, c’est que ce n’est pas une simple dégradation, mais une dégradation qui rapporte des intérêts composés aux méchants impliqués. Le scraping de contenu n’est que le début
      Un site finit par disparaître pour toujours à cause de la hausse des coûts ? Excellent, les gens devront utiliser l’IA pour toute documentation. On recule devant les captchas et on force les gens à donner une carte bancaire ou un numéro de téléphone ? Excellent, l’anonymat sur Internet recule d’autant
      Les fuites de données augmentent les arnaques ? Excellent, il faudra de l’IA pour les empêcher. Pour les acteurs malveillants, c’est une partie où presque tout le monde gagne
      La balkanisation d’Internet est un sujet discuté depuis longtemps. On pourrait penser que cette menace, ou le fait qu’Internet soit déjà une décharge hors de contrôle, inciterait à une certaine prudence avant d’empirer la situation, mais pousser les limites du harcèlement et des frictions que les gens peuvent supporter n’a de toute façon pas vraiment d’importance. Parce qu’ils n’ont pas de vrai choix
    • Je n’en suis pas sûr. Je gère un petit jeu par navigateur, et même si le serveur se fait régulièrement massacrer par des scrapers de LLM, je n’ai encore vu aucun nouveau compte qui semble avoir été créé par un bot
      Le taux d’inscription n’a pas non plus changé de manière notable. C’est vrai à la fois pour le jeu et pour le wiki, et le trafic de scraping s’est surtout concentré sur le wiki. Si le scraping ne diminue pas, il est très probable que le wiki doive être placé presque entièrement derrière un mur d’authentification
    • Cela pourrait devenir quelque chose du genre : pour effectuer les X prochaines requêtes, il faut traiter autant de tokens. Évidemment, ça sonne assez utopique
    • Il n’est pas forcément nécessaire de mettre cela derrière un mur d’authentification. Utiliser un service de micropaiement anonyme pour chaque requête serait tout à fait possible
      Si un Internet où le fait d’avoir trop de visiteurs devient une menace existentielle pour un site web, alors l’Internet dans lequel nous vivons n’est pas conçu pour survivre longtemps

  • À l’époque où les moteurs de recherche provoquaient ce genre de problème, le secteur s’était mis d’accord pour éviter la mise en place d’une réglementation juridique, et a créé la spécification robots.txt. Résultat, aucun cadre légal n’a été créé
    Aujourd’hui, il existe une nouvelle génération d’indexeurs affamés qui n’a pas pris part à cet accord, qui cherche à aspirer autant de données que possible sous la pression concurrentielle, et qui ignore tout simplement robots.txt
    De toute façon, il aurait fallu légiférer, et ceux qui ignorent robots.txt auraient dû être bloqués, sanctionnés par des amendes, limités en débit, etc.

    • Je ne sais pas si ce plan me plaît. Il ne faut pas que l’IA illégale dispose de plus de connaissances et d’utilité que l’IA légale
      Il existe d’autres options qu’une interdiction totale
    • Je serais surpris qu’il y ait ne serait-ce qu’un seul membre de la Chambre des représentants ou du Congrès américain qui sache ce qu’est robots.txt
    • Comment une loi américaine ou européenne pourrait-elle bloquer le trafic venant de Chine, de Thaïlande ou de Russie ? Au mieux, cela fragmenterait Internet, ce qui n’est pas « le mieux » mais une idée terrible

  • J’ai moi aussi été attaqué récemment [0]. C’est une petite instance Forgejo où j’héberge le code de plusieurs paquets open source, donc elle doit rester publique, mais elle a été complètement mise à mal et le disque s’est rempli d’archives ZIP générées
    Je ne suis pas le seul à avoir vécu la même chose. Dans mon cas, le blocage des plages d’IP d’Alibaba Cloud a, pour l’instant, fait retomber l’attaque
    Si vous exploitez une instance Forgejo, je recommande fortement de définir DISABLE_DOWNLOAD_SOURCE_ARCHIVES sur true. Le crawler continuera à accaparer le CPU, mais au moins le disque ne se remplira pas de fichiers ZIP
    [0] https://blog.nytsoi.net/2025/03/01/obliterated-by-ai

    • « le disque s’est rempli d’archives ZIP générées » signifie qu’il s’agit d’une mauvaise conception logicielle qui crée des fichiers ZIP à la volée
    • Il vaudrait peut-être mieux passer à un logiciel bien conçu, correctement pensé pour être servi sur l’Internet public
      Une conception qui génère un fichier ZIP, l’écrit entièrement sur le disque, puis l’envoie d’un coup au client est totalement horrible et inutilisable. Une bonne conception devrait générer progressivement le contenu et l’envoyer au client en utilisant un minimum de mémoire et sans utiliser le disque du tout
      L’existence d’une conception aussi absurde indique que les développeurs ont largement ignoré l’efficacité, et qu’il y a probablement tout un tas de problèmes critiques similaires
      Par exemple, en jetant un œil rapide au code source de Forgejo, on dirait qu’il lance des processus « git » pour toutes les opérations Git au lieu d’utiliser une bibliothèque dédiée. Je n’ai pas vérifié, mais je ne serais pas surpris que ces opérations soient très loin de la façon la plus efficace d’effectuer ces tâches
      Quand on fait tourner un logiciel aussi extrêmement mal conçu, il n’est pas surprenant que le CPU reste bloqué à 100 % et que le serveur devienne inutilisable

  • La grande conclusion ici, c’est que la domination du Web par Google et la publicité en général est en train de disparaître
    Le seul moyen de bloquer les bots, c’est le CAPTCHA, mais dans ce cas les indexeurs de recherche ne peuvent plus non plus indexer le site. Au final, les moteurs de recherche ne peuvent plus indexer les sites et ne fournissent plus de valeur
    Il y aura sans doute un léger décalage avant que les connaissances présentes dans les LLM actuels ne se tarissent, mais plus personne ne pourra scraper le Web de manière automatisée
    Tout semble destiné à brûler

    • En réalité, je pense que ce sera une forme de stabilité de Liapounov, comme pour des populations de loups et de lapins. Dans ce scénario, nous sommes les lapins
      Quand la population d’IA diminue, le contenu humain augmente, ce qui donne davantage de nourriture à l’IA et la fait remonter. Alors l’expression humaine est noyée, et les humains deviennent plus silencieux. Quand la nourriture de l’IA se raréfie et que l’IA décline, le bruit diminue et les humains regagnent de l’importance. Ce cycle se répète jusqu’à l’écœurement
    • Personnellement, je pense que c’était l’une des véritables motivations de Web Environment Integrity. Permettre à Google d’indexer, mais pas aux autres
      Nous sommes coincés dans une alternative pénible : veut-on des acteurs historiques solidement installés, ou un hébergement bon marché et ouvert ?
    • Google scrape déjà les sites et affiche directement les réponses dans les résultats de recherche. Si le trafic compte pour vous et que vous voulez vendre de l’espace publicitaire, pourquoi voudriez-vous encore que Google indexe votre site ?
      Une bonne partie des sites financés par la publicité vont s’éteindre. Les seuls visiteurs seront des bots
    • Si l’on doit passer à du crawling basé sur l’authentification, cela renforcera encore la position des moteurs de recherche existants. Seuls les crawlers invités pourront y accéder
      Avec un outil simple, la plupart n’autoriseront que Google, Bing, et peut-être un ou deux autres au maximum
    • L’entreprise d’IA qui disposera de la meilleure technologie de contournement des CAPTCHA gagnera, et elle insérera de la publicité dans les sorties des LLM de manière plus sophistiquée

  • Si quelqu’un s’intéresse aux petits actes de sabotage, je pense avoir réussi à « noyer » dans une certaine mesure les vraies informations de mon microblog
    Avec LLaMa, j’ai généré des dizaines de billets contradictoires pour chaque vrai billet, puis je les ai liés de façon invisible pour éviter que les humains ne cliquent dessus. C’est, pour ainsi dire, la méthode Bannon consistant à inonder la zone de déchets

    • J’ai déjà vu cette approche utilisée, mais je ne sais pas quel est son taux de réussite. Logiquement, ça se tient
      On référence explicitement des chemins qu’un humain ne peut pas réellement voir, et le trafic qui les appelle est considéré comme venant de bots. Les bots ne peuvent pas s’en empêcher
    • Oui. Mais il faut absolument les ajouter à robots.txt pour que seuls les mauvais robots en pâtissent
    • Après avoir lu ça hier, j’ai réfléchi à une façon d’atténuer le problème à plus grande échelle. Un site Web pourrait créer des chemins ou endpoints virtuels aléatoires pour diriger les bots vers une Library of Babel[0] servie localement, et contaminer les spiders avec du texte inutile
      Cela ne marchera pas sur des sites bien structurés où le bot connaît l’endpoint exact qu’il veut scraper, mais ça pourrait ralentir les threads de spiders plus exploratoires
      [0] https://libraryofbabel.info/
    • Plutôt que d’inonder de déchets, que penser d’un sabotage direct, comme servir quelque chose du genre ZIP bomb ou leur faire gaspiller des ressources de calcul ?

  • Ici VideoLAN
    Nous aussi, nos forums et notre GitLab se font pilonner par des bots d’entreprises d’IA
    La plupart ne respectent pas robots.txt

    • Avez-vous documenté les mesures prises pour régler ça ?

  • C’est délirant. Je me demande si l’on finira par avoir une version du Web qui ne soit pas indexée par les moteurs de recherche. Un Web plus proche de la navigation des années 90, où les sites devaient se lier les uns aux autres pour être découverts
    J’aime bien l’idée que la solution au scraping par les LLM consiste à demander au navigateur une preuve de travail avant d’autoriser l’accès. Je me demande si de nouveaux sites vont commencer à adopter ça
    Ils ne seraient alors pas indexés par les moteurs de recherche, mais cela aiderait à protéger la propriété intellectuelle

  • Je n’y avais jamais pensé jusqu’ici, mais c’est fou que les entreprises qui proposent à la fois des produits LLM et des services de cloud computing puissent gagner deux fois
    Elles obtiennent un produit LLM vendable, et en même temps encaissent les coûts de trafic sortant et de calcul liés à la charge accrue. Vu comme ça, quel intérêt auraient-elles à se soucier d’un scraping LLM inefficace ? Plus elles laissent le bazar perdurer, plus elles gagnent de l’argent via l’autre empire, celui des frais de trafic sortant du stockage cloud