El navegador es un sandbox

 (simonwillison.net)
1 puntos por GN⁺ 2026-01-28 | 1 comentarios | Compartir por WhatsApp
  • El desarrollador de la plataforma web Paul Kinlan explora el potencial del navegador como un entorno de ejecución seguro para agentes de programación
  • Señala que el navegador ya cuenta con una sólida estructura de sandbox para ejecutar código no confiable
  • Para comprobarlo, creó una demo llamada Co-do, con la que experimenta dentro del navegador el acceso a archivos, la comunicación de red y la ejecución de código
  • Co-do aprovecha File System Access API, encabezados CSP y <iframe sandbox>, y WebAssembly in Web Workers
  • Es un caso que muestra que el navegador puede evolucionar hacia un entorno de ejecución para agentes de IA incluso sin contenedores locales

Ver el navegador como un sandbox

  • Paul Kinlan de Google considera que para ejecutar agentes de programación se necesita un entorno de sandbox robusto
    • Destaca que el navegador es una plataforma que durante los últimos 30 años ha evolucionado para ejecutar de forma segura código malicioso o no confiable
    • Esa característica es la base para aprovechar el navegador como entorno de ejecución de agentes

Tres elementos clave de un sandbox basado en navegador

  • Kinlan presenta tres elementos clave del sandbox: acceso al sistema de archivos, control de acceso a la red y ejecución segura de código
    • File System Access API ofrece funciones para manejar archivos locales desde el navegador, y actualmente se conoce como exclusiva de Chrome
    • El acceso a la red puede controlarse mediante los encabezados CSP (Content Security Policy) y el atributo <iframe sandbox>
    • Con WebAssembly y Web Workers se puede ejecutar código en un entorno aislado

Estructura y funciones de la demo Co-do

  • Para validar la idea de Kinlan se creó una aplicación demo llamada Co-do
    • El usuario selecciona una carpeta y configura el proveedor de LLM y la API key
    • Co-do interactúa con el LLM mediante llamadas a API aprobadas por CSP y ofrece una interfaz de chat para conversar con los archivos
    • Esta estructura es similar a Claude Cowork, pero funciona solo en el navegador sin necesidad de un contenedor local grande

<iframe sandbox> y los límites de las tecnologías de seguridad

  • Se señala como principal problema la falta de documentación sobre <iframe sandbox>
    • Existen grandes diferencias de implementación entre navegadores y hay poca información disponible
    • Kinlan propone un método para aplicar reglas de red al frame interno mediante la técnica de double-iframe

Hallazgos y experimentos adicionales

  • Se confirmó que el atributo <input type="file" webkitdirectory> funciona en Firefox, Safari y Chrome
    • Esto permite que el navegador tenga acceso de solo lectura a un directorio completo
    • Para probarlo se creó una demo de webkitdirectory, que también se planea aprovechar en futuros proyectos

Conclusión

  • El navegador ya ha evolucionado hasta convertirse en una plataforma muy completa para aislamiento de seguridad y ejecución de código
  • El caso de Co-do es una evidencia experimental de que el navegador puede ampliarse como entorno de ejecución para agentes de programación con IA

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-01-28
Comentarios en Hacker News

  • Es un artículo que publiqué en mi link blog. Para entender el contexto completo, hay que leer el original: The Browser is the Sandbox

    • Creo que sería bueno agregar ese aviso en el link blog. Yo también puse el año y una nota de suscripción en mi blog, y desde entonces bajaron muchísimo los correos con la misma pregunta. Gracias a eso sigo disfrutando bloguear
    • Tu constancia de verdad impresiona. No recuerdo una sola semana en HN en la que no haya visto tu nombre. Personalmente, los artículos comparando LLM no son lo mío, pero parece que esa consistencia ya se volvió una marca. Te sigo apoyando

  • Creo que la razón por la que Google creó NaCl llevó justamente a la estandarización del sandbox de WebAssembly. El DOM, JS y CSS también funcionan como un sandbox de renderizado. El navegador debe limitar funciones para ofrecer una experiencia de usuario unificada.
    Esa es también la razón por la que IE y las versiones antiguas de Edge fracasaron. Todos los sandboxes externos como Flash, ActiveX, Java Applet y Silverlight desaparecieron, y con la estabilización de asm.js y WebAssembly la web quedó mucho más limpia. Por cierto, ActionScript de Flash también influyó en el diseño de ECMAScript y TypeScript

    • A mí me encantaba ActionScript 3. Hace tiempo hice un agregador de video llamado chime.tv en AS3 (artículo de TechCrunch) y el proceso de desarrollo fue realmente divertido
    • Java no tiene relación con ActionScript. LiveScript solo pasó a llamarse JavaScript por un acuerdo comercial entre Sun y Netscape
    • Silverlight era bastante bueno; es una lástima que lo hayan descontinuado

  • Cuando vi por primera vez el atributo webkitdirectory, yo también me sorprendí. Llevo años haciendo webapps y se me había pasado por completo. El sandbox del navegador es un modelo de seguridad validado por miles de millones de personas haciendo clic en enlaces sospechosos.
    Es un enfoque mucho más maduro que levantar un contenedor nuevo cada vez. Claro, el navegador tiene la limitación de que no puede hacer llamadas al sistema, ejecutar binarios ni acceder al hardware. Para AI coding es suficiente, pero en algunos trabajos sí tiene límites

    • Yo veo este enfoque como ideal para construir flujos orientados a agentes. En lugar de modificar directamente los archivos originales, puede ampliarse a resúmenes, preguntas y respuestas, generación de documentos nuevos, etc. Incluso usando LLM locales, se puede restringir con seguridad la invocación de herramientas
    • Por la misma razón, creo que los desarrolladores de NPM también harían bien en crear procesadores de código fuente que puedan ejecutarse en el sandbox del navegador en vez de depender de las API inestables de NodeJS

  • Me parece interesante que systemd o el sistema de permisos de usuario de Linux casi no se mencionen en las discusiones sobre sandboxing. En realidad, también son bastante potentes y ofrecen aislamiento de bajo costo

    • El modelo de permisos de Unix originalmente estaba pensado para que el sistema protegiera al usuario. Como los programas se ejecutaban con los permisos del usuario, no existía la idea de que el programa mismo pudiera ser malicioso. Hoy en día hace falta protección entre programas. Yo también intenté en algún momento usar un usuario separado por app, pero era demasiado ineficiente. Al final se necesita un modelo de capabilities. Sobre eso, xkcd 1200 lo explica muy bien
    • La mayoría de la gente sigue en el nivel de escribir un Dockerfile y desplegarlo de inmediato, así que estas discusiones casi no aparecen
    • El kernel de Linux tiene muchas vulnerabilidades de escalamiento de privilegios. Sirve para aislar software confiable, pero es inútil contra malware
    • Hay enfoques como sandvault, que aísla agentes de AI en cuentas de usuario restringidas de MacOS. Parece una idea bastante buena porque es ligera y de propósito general
    • Creo que systemd no puede bloquear solicitudes DNS o HTTP del JavaScript dentro del navegador, así que es difícil incluirlo en este tipo de discusiones

  • La File System Access API es un gran punto de inflexión en la evolución de la web. En co-do.xyz puedes seleccionar un directorio para que la AI manipule con seguridad los archivos internos. Gracias a esta API, las webapps se han consolidado como verdaderas herramientas de productividad

    • Los costos de despliegue bajan, pero manejar el estado en el navegador siempre fue inestable a largo plazo. Yo también intenté hacer una herramienta de publishing y al final volví a LangGraph y Celery. Más importante que ahorrar infraestructura fue asegurar la confiabilidad
    • Mientras la UI nativa siga teniendo ventaja, será difícil que las webapps se conviertan en apps de productividad de primera clase
    • Safari y Firefox todavía no soportan esta funcionalidad de la API

  • La ejecución basada en navegador es interesante, pero la mayoría de las apps de negocio reales se movieron a un enfoque centrado en la nube por razones de mantenibilidad, seguridad y acceso a datos. La ejecución local es buena para la productividad personal, pero tiene límites para las apps principales. Esa es también la razón por la que desaparecieron funciones de automatización de escritorio como AppleScript, COM y DDE

    • COM sigue vivo como el principal mecanismo de paso de API en Windows. Me hace recordar los tiempos de Windows 3.x cuando lidiaba con DDE
    • En apps GenAI bootstrappeadas, descargar la inferencia al navegador es una necesidad económica. El costo de GPU es demasiado alto, así que el hardware del usuario es prácticamente el único recurso gratuito

  • Quiero mencionar dos cosas más que se pueden hacer en el navegador

    1. Con webcontainer se puede ejecutar frontend y backend de NodeJS en el navegador (por ejemplo, el proyecto bolt.diy)
    2. Con jslinux y ejemplos de Linux x86, se puede correr en el navegador un entorno Linux completo basado en WebAssembly
      En teoría, con una sola URL se podría implementar un sistema de agentes bastante completo
    • Estoy trabajando en un experimento con v86. La idea es que el LLM lo trate como si fuera un sistema de archivos y un entorno de ejecución. Pero v86 está muy orientado a una UI interactiva, así que el control programático no es tan fácil
    • Creo que no corresponde mencionar webcontainers.io al mismo nivel que una plataforma open source, porque es una solución comercial cerrada

  • Antes, en Chrome, podías pedir permisos de lectura y escritura sobre directorios con la File System Access API, pero si recargabas la pestaña los permisos desaparecían. Me pregunto si eso ya mejoró

    • Ahora ya es posible tener permisos persistentes. Está explicado en detalle en el blog para desarrolladores de Chrome
    • En Chrome de escritorio (Ubuntu) el permiso se mantiene, pero en Chrome para Android se pierde el acceso al directorio al recargar. Ver la documentación de MDN

  • Este enfoque solo sandboxea el sistema de archivos. Pero la gente quiere conectarlo también a correo, calendario, chat, código fuente, datos financieros, etc. La seguridad del sistema de archivos es solo el comienzo; la seguridad de todo el ecosistema de datos sigue siendo un reto

  • Me pregunto cuáles son los límites de este enfoque. ¿Se podría implementar Gemini CLI en el navegador como una versión con mejor UX? ¿También podría integrarse con herramientas locales?

    • No me atrevería a asegurar que sea totalmente posible, pero como la mayoría de las herramientas están basadas en JS, una buena parte sí puede implementarse en el navegador. Ya casi no quedan API de Node que no puedan correr ahí