Le navigateur est un sandbox

 (simonwillison.net)
1 points par GN⁺ 2026-01-28 | 1 commentaires | Partager sur WhatsApp
  • Le développeur de la plateforme web Paul Kinlan explore le potentiel du navigateur comme environnement d’exécution sûr pour des agents de code
  • Il souligne que le navigateur dispose déjà d’une puissante architecture de sandbox pour exécuter du code non fiable
  • Pour le vérifier, il a créé une démo appelée Co-do, afin d’expérimenter dans le navigateur l’accès aux fichiers, les communications réseau et l’exécution de code
  • Co-do s’appuie sur la File System Access API, les en-têtes CSP et <iframe sandbox>, ainsi que sur WebAssembly dans des Web Workers
  • C’est un exemple qui montre que le navigateur peut évoluer en environnement d’exécution pour agents IA sans conteneur local

Une vision du navigateur comme sandbox

  • Paul Kinlan de Google estime qu’un environnement de sandbox robuste est nécessaire pour exécuter des agents de code
    • Il insiste sur le fait que le navigateur est une plateforme qui s’est développée pendant les 30 dernières années pour exécuter en toute sécurité du code malveillant ou non fiable
    • Cette caractéristique justifie l’usage du navigateur comme environnement d’exécution pour agents

Les trois éléments clés d’un sandbox basé sur le navigateur

  • Kinlan présente trois éléments essentiels d’un sandbox : l’accès au système de fichiers, le contrôle de l’accès réseau et l’exécution sécurisée du code
    • La File System Access API fournit des fonctions pour manipuler des fichiers locaux dans le navigateur et est actuellement connue comme étant réservée à Chrome
    • Les en-têtes CSP (Content Security Policy) et l’attribut <iframe sandbox> permettent de contrôler l’accès réseau
    • WebAssembly et les Web Workers permettent d’exécuter du code dans un environnement isolé

Structure et fonctions de la démo Co-do

  • Une application de démonstration nommée Co-do a été créée pour valider l’idée de Kinlan
    • L’utilisateur sélectionne un dossier puis configure un fournisseur de LLM et une clé API
    • Co-do interagit avec le LLM via des appels d’API autorisés par la CSP et fournit une interface de chat capable d’interagir avec les fichiers
    • Cette architecture ressemble à Claude Cowork, mais fonctionne uniquement dans le navigateur, sans gros conteneur local

Les limites de <iframe sandbox> et des technologies de sécurité

  • Le manque de documentation autour de <iframe sandbox> est pointé comme un problème majeur
    • Les différences d’implémentation selon les navigateurs sont importantes, et la documentation disponible est limitée
    • Kinlan propose une méthode de double iframe (double-iframe) pour appliquer des règles réseau au frame interne

Découvertes et expérimentations supplémentaires

  • Il a été confirmé que l’attribut <input type="file" webkitdirectory> fonctionne sur Firefox, Safari et Chrome
    • Cela permet au navigateur d’effectuer un accès en lecture seule à un répertoire entier
    • Une démo webkitdirectory a été créée pour le tester et devrait être réutilisée dans de futurs projets

Conclusion

  • Le navigateur a déjà évolué en une plateforme très aboutie pour l’isolation de sécurité et l’exécution de code
  • Le cas de Co-do constitue une preuve expérimentale que le navigateur peut s’étendre en environnement d’exécution pour agents de codage IA

À lire aussi

1 commentaires

 
GN⁺ 2026-01-28
Avis sur Hacker News

  • C’est un billet que j’ai publié sur mon link blog. Pour bien comprendre le contexte général, il faut absolument lire l’original, The Browser is the Sandbox

    • Ce serait sans doute une bonne idée d’ajouter ce genre de mention d’avertissement sur le link blog. J’ai moi-même ajouté l’année de publication et une indication d’abonnement sur mon blog, et depuis, j’ai reçu bien moins d’e-mails posant les mêmes questions. Grâce à ça, je continue à prendre plaisir à bloguer
    • Ta constance est vraiment impressionnante. Il ne se passe presque pas une semaine sans que je voie ton nom sur HN. Personnellement, les billets de comparaison de LLM ne sont pas trop mon style, mais cette régularité est finalement devenue une marque en soi. Bon courage pour la suite

  • Je pense que la raison pour laquelle Google a créé NaCl a justement conduit à la standardisation du sandboxing de WebAssembly. Le DOM, JS et CSS fonctionnent eux aussi comme des sandboxes de rendu. Le navigateur doit limiter les fonctionnalités afin d’offrir une expérience utilisateur unifiée.
    C’est aussi pour cela qu’IE et l’ancien Edge ont échoué. Les sandboxes externes comme Flash, ActiveX, Java Applet et Silverlight ont toutes disparu, et avec la stabilisation de asm.js et de WebAssembly, le web est devenu bien plus propre. À noter que l’ActionScript de Flash a aussi influencé la conception d’ECMAScript et de TypeScript

    • J’adorais vraiment ActionScript 3. À l’époque, j’avais créé un agrégateur vidéo appelé chime.tv avec AS3 (article de TechCrunch), et le développement avait été un vrai plaisir
    • Java n’a aucun rapport avec ActionScript. LiveScript a simplement été renommé JavaScript à cause d’un accord commercial entre Sun et Netscape
    • Silverlight était plutôt pas mal, c’est dommage qu’il ait été abandonné

  • Moi aussi, j’ai été surpris la première fois que j’ai vu l’attribut webkitdirectory. Je développe des applications web depuis des années, et j’étais passé à côté. Le sandbox du navigateur est un modèle de sécurité validé par des milliards de clics sur des liens suspects.
    C’est une approche bien plus mature que de relancer un conteneur à neuf à chaque fois. En revanche, le navigateur a des limites : il ne permet pas les appels système, l’exécution de binaires ni l’accès au matériel. C’est suffisant pour le code assisté par IA, mais il y a des cas où ça bloque

    • Je pense que cette approche convient bien à la mise en place de flux de type agentique. On peut l’étendre à des usages comme le résumé, les questions-réponses ou la génération de nouveaux documents sans modifier directement les fichiers originaux. On peut aussi limiter en toute sécurité les appels d’outils, même avec un LLM local
    • Pour la même raison, je pense aussi que les développeurs NPM devraient créer des processeurs de code source exécutables dans le sandbox du navigateur plutôt que de s’appuyer sur les API instables de NodeJS

  • Je trouve intéressant que systemd ou le système de permissions utilisateur de Linux soient presque absents des discussions sur le sandboxing. En réalité, eux aussi sont assez puissants et offrent une isolation peu coûteuse

    • Le modèle de permissions Unix a été conçu à l’origine pour que le système protège les utilisateurs. Comme les programmes s’exécutaient avec les droits de l’utilisateur, on n’imaginait pas vraiment qu’un programme puisse être malveillant en lui-même. Aujourd’hui, il faut une protection entre programmes. J’ai moi-même essayé à un moment d’attribuer un utilisateur distinct à chaque application, mais c’était beaucoup trop inefficace. Au final, il faut un modèle par capabilities. xkcd 1200 l’explique bien
    • La plupart des gens en sont encore au stade où ils écrivent juste un Dockerfile avant de déployer, donc ces discussions restent rares
    • Le noyau Linux comporte beaucoup de failles d’élévation de privilèges. C’est acceptable pour isoler des logiciels de confiance, mais inutile face à du code malveillant
    • Il existe des approches comme sandvault, qui isole les agents IA dans un compte utilisateur MacOS restreint. C’est léger et assez générique, donc l’idée me paraît plutôt bonne
    • Avec systemd, on ne peut pas bloquer les requêtes DNS ou HTTP du JavaScript exécuté dans le navigateur, donc je pense qu’il est difficile de l’inclure dans ce type de discussion

  • La File System Access API représente un grand tournant dans l’évolution du web. Sur co-do.xyz, on peut sélectionner un répertoire et laisser l’IA manipuler en toute sécurité les fichiers qu’il contient. Grâce à cette API, les applications web sont devenues de vrais outils de productivité

    • Les coûts de déploiement baissent, mais gérer l’état dans le navigateur a toujours été instable sur le long terme. J’ai moi aussi créé un outil de publication, avant de revenir finalement à LangGraph et Celery. Obtenir de la fiabilité était plus important que de réduire l’infrastructure
    • Tant que les interfaces natives garderont l’avantage, il sera difficile pour les applications web de devenir de véritables applications de productivité de premier plan
    • Cette fonctionnalité de l’API n’est toujours pas prise en charge dans Safari et Firefox

  • L’exécution dans le navigateur est intéressante, mais la plupart des applications métier réelles ont évolué vers un modèle centré sur le cloud, pour des raisons de maintenabilité, de sécurité et d’accès aux données. L’exécution locale est utile pour la productivité personnelle, mais elle a des limites pour les applications grand public. C’est aussi pour cela que des fonctions de desktop automation comme AppleScript, COM ou DDE ont disparu

    • COM est toujours bien vivant comme principal mécanisme d’exposition d’API sous Windows. Ça me rappelle l’époque de Windows 3.x, quand on manipulait DDE
    • Pour les applications GenAI bootstrappées, déporter l’inférence vers le navigateur est une nécessité économique. Le coût des GPU est trop élevé, et le matériel de l’utilisateur est en pratique la seule ressource gratuite

  • Je voudrais aussi présenter deux autres choses possibles dans le navigateur

    1. Avec webcontainer, on peut exécuter un frontend et un backend NodeJS dans le navigateur (par exemple le projet bolt.diy)
    2. Avec jslinux et des exemples de Linux x86, on peut faire tourner dans le navigateur un environnement Linux complet basé sur WebAssembly
      En théorie, on peut donc implémenter un système agentique assez complet derrière une simple URL
    • Je mène actuellement une expérience v86. L’objectif est que le LLM puisse l’utiliser comme système de fichiers et environnement d’exécution. En revanche, v86 est centré sur une UI interactive, donc le contrôle programmatique n’est pas simple
    • webcontainers.io est une solution commerciale propriétaire, donc je pense qu’il est inapproprié de la mentionner au même niveau qu’une plateforme open source

  • Avant, dans Chrome, on pouvait demander des droits de lecture/écriture sur un répertoire avec la File System Access API, mais les permissions disparaissaient après un rechargement de l’onglet. Je me demande si cela a été amélioré depuis

    • On peut désormais accorder des permissions persistantes. C’est expliqué en détail sur le blog développeur de Chrome
    • Sur Chrome desktop (Ubuntu), les permissions sont conservées, mais sur Chrome Android, l’accès au répertoire disparaît après un rechargement. Voir la documentation MDN

  • Cette approche ne sandboxe que le système de fichiers. Mais les gens veulent aussi se connecter à leurs e-mails, calendriers, chats, code source, données financières, etc. La sécurité du système de fichiers n’est qu’un point de départ ; la sécurité de tout l’écosystème de données reste un défi

  • Je me demande quelles sont les limites de cette approche. Peut-on implémenter Gemini CLI dans le navigateur sous la forme d’une version à l’UX améliorée ? Peut-elle aussi s’intégrer à des outils locaux ?

    • Je ne dirais pas que c’est totalement certain, mais comme la plupart des outils sont basés sur JS, on peut déjà en implémenter une grande partie dans le navigateur. Désormais, il ne reste presque plus d’API Node impossibles à faire tourner dans un navigateur