Le web n’a pas besoin de gardiens : la nouvelle proposition de « agents signés » de Cloudflare

• La politique Signed Agents de Cloudflare invoque la sécurité, mais constitue en réalité une tentative fermée de transformer l’accès au web en régime d’autorisation préalable
• Historiquement, le web s’est développé grâce à l’ouverture et aux standards, et des technologies fermées comme Flash ou Silverlight ont fini par disparaître face à des standards ouverts comme HTML5
• À l’avenir, les principaux utilisateurs du web seront les agents IA, ce qui exigera un système d’authentification distribué et vérifiable, ainsi qu’une autorisation à l’échelle des tâches
• Le bon modèle consiste à combiner délégation fondée sur des chaînes + preuve à l’échelle de la requête afin de mettre en œuvre une authentification fiable et un contrôle d’accès granulaire
• Plutôt que de laisser une entreprise particulière détenir les clés, il faut préserver un web où tous peuvent participer et innover grâce à des protocoles et standards ouverts

---

Critique des Signed Agents de Cloudflare

• Cloudflare a proposé un nouveau système d’agents signés (Signed Agents), mais il s’agit en pratique d’un contrôle d’accès fondé sur une liste d’autorisation
• Le fait qu’une entreprise particulière décide si un agent peut être enregistré ou non n’est rien d’autre qu’un régime d’approbation par le fournisseur, et non un protocole Internet
• Cela entre en conflit avec la nature ouverte d’Internet, et « remplir un formulaire pour obtenir une autorisation » ne peut pas devenir un standard

Le web doit rester ouvert

• Dans les années 90, la stratégie « embrace and extend » de Microsoft a échoué, et cela a été possible parce que le web a conservé son ouverture
• Des runtimes fermés comme Flash et Silverlight ont finalement été remplacés par le standard ouvert HTML5
• L’histoire prouve sans cesse que les standards ouverts favorisent l’innovation

L’arrivée de l’ère des agents

• Les agents IA deviendront des utilisateurs centraux du web et effectueront la recherche d’information, l’automatisation, les paiements, la négociation de contrats, etc.
• La frontière entre les actions des humains et celles des agents deviendra floue, ce qui rendra un système d’authentification fondé sur la délégation indispensable

Authentification (Authentication) et autorisation (Authorization)

• Authentification : qui agit ?
• Autorisation : que peut-on faire ?
• Cloudflare confond les deux notions et semble vouloir tout résoudre avec un « passeport », mais c’est fondamentalement impossible
• Une authentification correcte doit être mise en œuvre au moyen d’une chaîne de délégation et de signatures à l’échelle de la requête, en s’appuyant sur des mécanismes de vérification distribués comme l’émission de clés publiques fondée sur le DNS

Gestion des autorisations

• Les logiciels traditionnels fonctionnaient bien avec le modèle de scopes OAuth grâce à un périmètre limité
• Mais les agents étant d’usage général, une autorisation à l’échelle de la tâche (Task-Scoped) est nécessaire
• Exemple : une autorisation de « paiement du dîner » et une autorisation de « consultation de l’historique des dépenses des 3 derniers mois » doivent correspondre à des jetons différents, même pour le même agent
• Pour cela, on peut utiliser des jetons à contraintes comme Macaroons, Biscuits, ainsi que des moteurs de politiques comme OPA/AWS Cedar

Priorité au protocole, pas aux gardiens

• L’authentification, l’autorisation et la monétisation doivent reposer sur des standards ouverts et interopérables, et non sur une entreprise particulière
• Si une poignée d’entreprises décident de la validité des agents, le web risque vite de devenir un jardin clos (Walled Garden)
• Il faut donc proposer en open source la délégation fondée sur des chaînes, la preuve à l’échelle de la requête et l’autorisation à l’échelle de la tâche, afin que chacun puisse les implémenter

Conclusion

• L’avenir du web ne dépend pas de « qui contrôle la porte », mais de protocoles que tous peuvent construire ensemble et faire évoluer par l’innovation

[GN⁺]

Avis Hacker News

• Tout le monde rêve d’un web totalement libre et ouvert, mais il est frustrant de constater qu’en pratique, les personnes qui tiennent un petit blog ou publient du contenu n’ont presque aucun moyen de se protéger des bots d’entraînement de l’IA ; croire qu’on pourra distinguer les agents des bots d’entraînement et qu’ils respecteront réellement robots.txt n’est pas réaliste ; même si robots.txt était respecté, le concept consistant à racheter indirectement les données sous couvert de « licensed data » continuerait ; à moins d’être une entreprise comme Reddit, X, Google ou Meta, avec des ressources juridiques quasi illimitées, un individu n’a aucun pouvoir ; recommande aussi cette vidéo

  • Le web libre et ouvert que tout le monde souhaite semble en contradiction avec l’envie de bloquer les bots d’entraînement de l’IA ; si le web est ouvert à tous, alors les bots d’entraînement de l’IA devraient eux aussi pouvoir y accéder sans exception

  • (À propos du rêve du web ouvert) Le rêve de contenus ouverts sur Internet est bien réel ; mon blog est accessible librement à tous — humains comme machines — et comme j’héberge moi-même mon serveur chez moi, je ne ressens pas vraiment le besoin de distinguer humains et IA ; si l’on craint qu’un site reçoive trop de visiteurs, le vrai problème est en fait l’excès de trafic lui-même, qu’il vienne d’humains ou d’IA ; je ne garde dans robots.txt qu’un minimum d’indications pour éviter que les bots ne tournent en boucle, et je laisse le crawl ouvertement ; Amazonbot visite souvent mon site et il est toujours le bienvenu

  • Il faut développer du logiciel libre pour lutter contre les logiciels hostiles ; les grandes entreprises développent des agents IA hostiles, et en face, les hackers compétents devraient développer des anti-AI-agent ; je ne suis pas d’accord avec le défaitisme du « nous n’avons aucun pouvoir »

  • Souligne la réalité selon laquelle, sur Hacker News, malgré le grand nombre d’ingénieurs de grandes entreprises IT, ils crient toujours sur d’autres sujets sans jamais aborder la confidentialité et la gouvernance des données dans leur propre travail ; s’il faut un miroir pour faire un peu d’introspection, je suis prêt à l’acheter

  • Ne comprend pas pourquoi on pose même la question de protéger de petits blogs ou contenus contre les bots d’entraînement de l’IA ; si produire du HTML basique est déjà trop difficile au point d’exiger des frameworks lourds et complexes, au prix d’une consommation excessive de CPU, alors c’est là le vrai problème ; ou alors, si l’on considère ses écrits en ligne comme un chemin vers la richesse et la célébrité en tant que créateur de contenu, il y a de quoi s’inquiéter ; sinon, il n’y a pas vraiment de problème

• En pratique, le « web » n’est déjà plus ouvert depuis longtemps ; la majorité des interactions, des publications et de la circulation de l’information se font derrière une authentification (connexion) ; la plupart des grands réseaux sociaux, journaux et autres limitent ou bloquent l’accès non authentifié ; les blogs ne représentent qu’une part infime de l’ensemble des informations consommées par le grand public

  • N’est pas d’accord avec l’idée que « le web n’est plus ouvert » ; le web n’a pas besoin de plus de gatekeepers, et s’il y en a déjà beaucoup, il faudrait au contraire les réduire

• Les AI Agents en eux-mêmes ne me dérangent pas, tant qu’il y a un véritable utilisateur derrière ; en revanche, je suis très mécontent de voir Meta, Perplexity, OpenAI et d’autres crawler mon site de façon agressive ; le crawl IA consomme plus de ressources que de vrais utilisateurs ou même que la recherche Google ; voir des cœurs CPU monopolisés par le crawl IA est vraiment agaçant

  • J’ai moi aussi plusieurs applications personnelles en ligne, et le mois dernier un bot IA a aspiré 1,6 To de données, au point que j’ai dû activer la protection Cloudflare contre les bots IA ; il y avait plus de 1,3 million de requêtes par jour, en continu, c’était ingérable

  • Sur certains de mes sites marketing, je reçois 200 à 300 requêtes par seconde ; le bot invente même des URL inexistantes et les appelle au hasard, à un niveau totalement hors de contrôle

  • Je me demande combien de cycles CPU les entreprises d’IA font brûler à cause du web crawling ; en général, quand on parle de l’impact environnemental de l’IA, on ne compte que l’entraînement ou l’inférence en production, mais il faut aussi prendre en compte la charge supplémentaire imposée par le crawl du web ; pour une comparaison correcte, il faudrait mesurer cela face à ce qu’un humain ferait directement ; si un bot est conçu pour générer le trafic de manière plus efficace, en ne récupérant que le strict nécessaire pour répondre à une requête tout en minimisant trackers, images et éléments annexes, alors la charge CPU totale pourrait même être inférieure à celle d’une humanité entière visitant directement les pages via un navigateur

  • Même chose pour moi : utiliser un agent IA ne me dérange pas trop s’il y a un utilisateur réel derrière et qu’il n’accède pas au site de façon anormalement excessive ; (je n’ai pas spécialement cherché à encourager l’usage d’agents IA, mais peu importe qui les utilise et comment), en revanche je déteste le crawl excessif ; plus important encore, quelqu’un peut aussi simplement télécharger un fichier avec curl ou utiliser un navigateur texte comme Lynx ; je pense que ces scénarios doivent continuer d’être pris en charge

  • Cloudflare distingue certains « agents tentés par un utilisateur » des autres agents afin de séparer le crawl indiscriminé destiné à collecter des données d’entraînement de l’usage par de vrais utilisateurs ; la plupart des requêtes envoyées par Meta, Perplexity et OpenAI relèvent en fait de fonctions de recherche web déclenchées par de vrais prompts utilisateur, et ne servent pas à l’entraînement du prochain modèle LLM ; Cloudflare entretient volontairement le flou entre les deux, affiche officiellement une volonté de « protéger les créateurs », mais construit en réalité un système destiné à prélever un « péage » sur les fournisseurs de LLM pour son propre bénéfice ; au fond, la motivation n’est pas l’équité mais l’argent

• J’utilise un navigateur rare qui expose peu de données personnelles, et du point de vue de Cloudflare je ressemble moi aussi à un bot ; dans un environnement où l’hôte (le propriétaire du site) décide qui a le droit d’accéder, il ne peut pas y avoir de véritable vie privée ; je suis d’accord pour limiter le débit afin de protéger les serveurs, mais bloquer l’accès automatisé est en pratique impossible, et à force de vouloir le faire on finit aussi par compliquer l’accès des vrais utilisateurs

  • Demande si, actuellement, on se retrouve souvent bloqué à cause de Cloudflare ou de turnstile ; c’était déjà sous-entendu plus haut, mais il veut une confirmation explicite

  • Du point de vue des gens qui vivent dans des États autoritaires, si un VPN est nécessaire pour préserver la vie privée et la liberté, alors Internet devient un enfer de captchas tenu par deux ou trois entreprises ; quand je fais moi-même accéder un bot à un site protégé par Cloudflare, j’ai moins de problèmes que lorsque je navigue normalement sur Internet avec un VPN et un navigateur respectueux de la vie privée ; et, au passage, si Microsoft avait assuré le gatekeeping du web, ce serait encore pire ; surtout avec un VPN, passer les captchas de Microsoft demande parfois plus de 5 minutes de concentration, comme s’il fallait rédiger un mémoire

  • Les propriétaires de sites ont bien sûr aussi des droits ; leur dire de ne pas choisir le gatekeeping pour assurer la viabilité financière de leur activité est une exigence déraisonnable

  • Moi aussi, avec un navigateur rare, je me fais souvent attraper par les bloqueurs de bots ; cela dit, je pense aussi que l’hôte a le droit de traiter librement mes requêtes ; en particulier pour les sites gouvernementaux, je pense que la responsabilité de servir tout le monde équitablement est bien plus forte

• S’il existe une meilleure alternative plus ouverte, je veux bien l’entendre ; mais pour l’instant, ce que fait Cloudflare résout assez bien le problème concret des bots IA ; on a déjà essayé de bloquer par IP ou par user agent, mais cela a ses limites ; et, en pratique, d’autres problèmes de sécurité ont eux aussi été résolus par des approches assez centralisées ; les autorités de certification (certificate authority) ne forment pas un système ouvert, pas plus que les fournisseurs d’attestations, et pourtant cela fonctionne bien

  • Si l’on veut une solution plus ouverte, la réponse peut être la régulation ; il suffirait d’interdire légalement les requêtes des crawlers que l’exploitant d’un site n’a pas explicitement autorisés dans robots.txt, avec un contrôle assuré directement par les autorités ; si l’exploitant peut prouver le trafic bot, il pourrait le signaler au gouvernement et déclencher de lourdes amendes ; on pourrait aussi obliger les fournisseurs cloud à conserver des traces de qui utilisait quelle IP ; ce ne serait pas une solution à 100 %, mais si c’est bien appliqué, l’effet dissuasif pourrait être très fort

  • Ce n’est peut-être pas la meilleure solution possible, mais c’est une solution pragmatique qui peut fonctionner dans une certaine mesure ; on pointe beaucoup les problèmes de centralisation, mais si Cloudflare réussit à faire participer à la fois les grands acteurs de l’IA et les CDN, cela pourrait de fait devenir un standard

  • Les certificats ne bloquent pas des humains au motif qu’ils auraient été pris pour des bots

  • À l’inverse, je pense que l’AI poisoning — injecter volontairement de mauvaises informations dans les données pour perturber l’IA — est une protection plus efficace ; Cloudflare pourrait même proposer un service consistant à fournir délibérément de fausses données aux bots IA

  • En réalité, avant Let’s Encrypt, les autorités de certification n’étaient souvent utilisées que par des sites d’entreprise ordinaires, et encore seulement sur certaines pages de connexion ; sans la politique ouverte de Let’s Encrypt, nos données personnelles seraient probablement encore exposées aux FAI ou à des intermédiaires ; quant aux fournisseurs d’attestation, ils sont eux aussi impuissants, par exemple lorsqu’ils refusent de révoquer une certification malgré la publication large de vulnérabilités, pour de simples raisons business ; au final, dans la plupart des discussions, on ne trouve pas vraiment de bonne alternative ; faire de Cloudflare le gatekeeper d’Internet est une mauvaise solution, mais le problème lui-même est bien plus grave ; il existe déjà des solutions entièrement décentralisées (par ex. remote attestation, modèles de visite payante / abonnement, firewall auto-hébergé), et le fait d’ignorer les effets secondaires de l’IA en se contentant de dire « payez le coût » a encore renforcé Cloudflare ; si les FAI et d’autres n’avaient pas fermé les yeux sur des problèmes comme le spoofing, les DDoS ou les botnets, Cloudflare serait sans doute resté un simple concurrent d’Akamai

• Nous vivons déjà dans un monde avec bien trop de gatekeepers ; toute tentative d’en ajouter un de plus doit être vue comme une agression ; Cloudflare et Google renforcent tous deux de plus en plus leur position de gatekeeper, et si cette tendance continue, j’aimerais voir les deux s’effondrer complètement

  • Plusieurs entreprises essaient d’apporter des solutions au problème des bots IA, et si Cloudflare est choisi, il en tirera des revenus énormes ; mais même si Cloudflare reculait, le problème ne disparaîtrait pas pour autant : une autre mauvaise alternative serait simplement adoptée ; le gatekeeping est en fait une option choisie par le propriétaire du site (paywall, détection de bots maison, vérification d’identité, etc.) ; Cloudflare fournit déjà ce type de service, et si cela se standardise, cela augmentera même le choix possible et ouvrira davantage le marché — avec ses effets secondaires ; la vraie liberté du web ouvert ne concerne pas seulement les visiteurs, mais aussi les propriétaires de sites

  • L’« ambition » de Google de devenir le gatekeeper du futur est excessive ; en réalité, Google joue déjà ce rôle depuis des années via la domination de Chrome ; Firefox est devenu marginal ; l’idée est que Google oriente déjà l’ensemble du www dans le sens qu’il souhaite (uBlock interdit, format .webp imposé, etc.)

• Avant de pointer du doigt l’allowlist opérée par une seule entreprise, il faut rappeler que c’est le propriétaire du site qui a choisi ce service ; ce qui est amusant, c’est la contradiction entre un discours idéologique sur « l’équité » et le fait de publier sur son blog des bandes dessinées générées par des outils IA, signe qu’au quotidien l’IA est déjà profondément installée

  • Cloudflare est en train d’implémenter le standard émergent Web Bot Auth, et chez Stytch nous appliquons le même standard sur IsAgent.dev ; le débat actuel est un peu surchauffé, donc j’avance cela avec prudence, mais au final l’allowlist n’est qu’une option proposée aux clients de Cloudflare, et le cœur du système, comme HTTP Message Signature, est conçu de façon ouverte et distribuée, de sorte que tout le monde peut l’utiliser

  • Utiliser l’allowlist d’une entreprise par choix personnel n’est pas en soi un gros problème, mais cela n’en fait pas un protocole pour autant ; et le débat sur l’équité n’a pas vraiment de lien logique avec l’usage de BD générées par IA

  • On risque de se retrouver dans une situation du type frying pan/fire, où la solution d’une entreprise particulière devient de fait un standard public ; cette occasion aurait pu permettre de créer une vraie solution fondée sur un protocole ou un standard, mais Cloudflare cherche surtout à se créer un océan bleu ; et le fait de revendiquer « l’équité » tout en utilisant concrètement l’IA dans la vie quotidienne est relevé avec une certaine ironie

• Cela ressemble à la structure de l’e-mail ; l’e-mail repose sur des standards Internet, mais dans les faits la majorité des utilisateurs dépend d’un tout petit nombre de fournisseurs comme Gmail ; Cloudflare pousse lui aussi des standards ouverts, mais son véritable pouvoir vient du nombre de clients à grande échelle ; (et on pose aussi la question de savoir quelle alternative crédible il existe) ; comme pour l’e-mail, où le filtrage anti-spam rend la délivrabilité peu fiable et l’implémentation difficile, le web pourrait suivre une trajectoire similaire

  • En pratique, il n’existe pas de véritable alternative à Cloudflare en tant que CDN gratuit ; l’entreprise déploie des serveurs dans le monde entier, distribue gratuitement ce service, et se rémunère avec des offres serverless premium ; de leur côté, les grands fournisseurs cloud facturent des frais d’egress anormalement élevés

• Le web ne veut ni attestation, ni signed agent, ni Cloudflare décidant qui est un agent « légitime » ; tout le monde devrait se rappeler ce que signifie vraiment « public », et si le traitement du trafic devient difficile, alors un simple rate limiting de base reste la meilleure option ; le web n’a pas à distinguer humains, bots ou chiens : il doit simplement servir des octets à tous les requérants dans les limites de ressources disponibles ; si cette essence du « web ouvert » disparaît, tout le monde le regrettera

  • Même un rate limiting basique reste vulnérable aux attaques ; on ne peut pas ignorer les botnets, et avec l’arrivée d’IPv6, un rate limiting utile devient pratiquement impossible ; si l’on choisit mal les buckets de bande passante, certains opérateurs allouent des blocs /48 si facilement que les limites deviennent inopérantes, tandis que sur mobile des centaines de milliers de personnes peuvent se retrouver coincées sous une même limite

  • Cette approche revient en pratique à dire à quantité de petits sites web qu’ils n’ont qu’à fermer s’ils n’arrivent pas à absorber le trafic, ce qui contredit le slogan de l’« Internet ouvert »

  • Les crawlers IA récents sont désormais impossibles à distinguer de botnets malveillants ; un rate limiting normal n’a plus vraiment de sens, et c’est précisément à ce moment-là que Cloudflare a essayé de résoudre le problème

  • L’idée que « public veut dire PUBLIC » serait souhaitable si un simple rate limiting suffisait ; mais en pratique, il faudrait alors publier clairement les vitesses d’accès acceptables ; or on voit souvent des cas où il suffit qu’un user-agent soit différent pour être bloqué dès la première requête ; au final, les exploitants ont tendance à bloquer n’importe quelle requête non pas sur la base d’un comportement bot, mais simplement sur l’identité (identity) ; le critère est grossier, produit beaucoup de faux positifs, et même dans ce cas, aucune tentative ni aucun contexte n’est examiné : la décision de blocage est prise uniquement sur l’identité

  • Même un rate limiting basique n’est souvent pas simple à mettre en œuvre ; sauf dans les cas où une authentification ou une délégation précise est nécessaire, je pense qu’un accès public à des fichiers ne devrait pas exiger d’authentification ni de délégation supplémentaires ; et même s’il y a des questions de délégation, il n’y a pas lieu qu’un tiers comme Cloudflare intervienne au-delà du rôle du véritable délégant

• Je suis d’accord avec la majeure partie de l’avis de l’auteur ; dans les environnements d’entreprise, la vraie difficulté est de savoir comment contrôler le comportement des agents dans des réseaux privés complexes ; j’ai récemment créé moi-même un système d’identity token basé sur biscuit ; grâce à ce token, on s’authentifie, puis on peut créer un token de délégation à remettre à un agent subordonné ; dans mon système, sans authorization token, on ne peut rien faire (logique de périmètre unique et d’usage unique) ; sur Internet, j’imagine qu’on pourrait échanger un identity token contre un authorization token via un micropaiement (par ex. une très petite transaction crypto) ; ainsi, pour un utilisateur humain, le coût resterait presque nul, tandis que seuls les crawlers IA paieraient réellement beaucoup