O navegador é a sandbox

 (simonwillison.net)
1 pontos por GN⁺ 2026-01-28 | 1 comentários | Compartilhar no WhatsApp
  • O desenvolvedor da plataforma web Paul Kinlan explora o potencial do navegador como um ambiente de execução seguro para agentes de programação
  • Ele destaca que o navegador já possui uma poderosa estrutura de sandbox para executar código não confiável
  • Para verificar isso, ele criou uma demonstração chamada Co-do, na qual testa acesso a arquivos, comunicação em rede e execução de código, tudo dentro do navegador
  • O Co-do utiliza File System Access API, cabeçalhos CSP e <iframe sandbox>, e WebAssembly in Web Workers
  • É um caso que mostra que o navegador pode evoluir para um ambiente de execução de agentes de IA mesmo sem contêineres locais

A perspectiva de ver o navegador como sandbox

  • Paul Kinlan, do Google, considera que é necessário um ambiente de sandbox robusto para executar agentes de programação
    • Ele enfatiza que o navegador é uma plataforma que evoluiu ao longo dos últimos 30 anos para executar com segurança código malicioso ou não confiável
    • Essa característica serve de base para usar o navegador como ambiente de execução de agentes

Três elementos centrais da sandbox baseada em navegador

  • Kinlan apresenta três elementos centrais da sandbox: acesso ao sistema de arquivos, controle de acesso à rede e execução segura de código
    • A File System Access API fornece recursos para lidar com arquivos locais no navegador e atualmente é conhecida como exclusiva do Chrome
    • O acesso à rede pode ser controlado por meio de cabeçalhos CSP (Content Security Policy) e do atributo <iframe sandbox>
    • Com WebAssembly e Web Workers, é possível executar código em um ambiente isolado

Estrutura e funcionalidades da demo Co-do

  • Para validar a ideia de Kinlan, foi criada uma aplicação de demonstração chamada Co-do
    • O usuário seleciona uma pasta e configura o provedor de LLM e a chave de API
    • O Co-do interage com o LLM por meio de chamadas de API aprovadas por CSP e oferece uma interface de chat capaz de conversar com os arquivos
    • Essa estrutura é semelhante ao Claude Cowork, mas roda apenas no navegador, sem contêineres locais pesados

<iframe sandbox> e os limites das tecnologias de segurança

  • A falta de documentação de <iframe sandbox> é apontada como um problema importante
    • Há grandes diferenças de implementação entre os navegadores, e o material relacionado é escasso
    • Kinlan apresenta uma forma de aplicar regras de rede ao frame interno por meio da técnica de double-iframe

Descobertas e experimentos adicionais

  • Foi confirmado que o atributo <input type="file" webkitdirectory> funciona em Firefox, Safari e Chrome
    • Com isso, o navegador pode realizar acesso somente leitura a um diretório inteiro
    • Para testar isso, foi criada uma demo do webkitdirectory, que deverá ser aproveitada em projetos futuros

Conclusão

  • O navegador já evoluiu para uma plataforma madura para isolamento de segurança e execução de código
  • O caso do Co-do é uma evidência experimental de que o navegador pode se expandir para se tornar um ambiente de execução para agentes de programação com IA

Leituras relacionadas

1 comentários

 
GN⁺ 2026-01-28
Comentários do Hacker News

  • É um texto que publiquei no meu blog de links. Para entender o contexto completo, é indispensável ler o original, The Browser is the Sandbox

    • Acho que seria bom adicionar esse aviso no blog de links. Eu também coloquei indicação do ano e instruções de assinatura no meu blog, e depois disso o volume de e-mails com as mesmas perguntas caiu bastante. Graças a isso, continuo gostando de blogar
    • Sua consistência é realmente impressionante. Não teve uma semana em que eu não tenha visto seu nome no HN. Pessoalmente, comparação de LLM não faz muito meu estilo, mas acho que a constância acabou virando sua marca. Continuo torcendo por você

  • Acho que o motivo de o Google ter criado o NaCl levou diretamente à padronização do sandbox do WebAssembly. DOM, JS e CSS também funcionam como um sandbox de renderização. O navegador precisa limitar funcionalidades para oferecer uma experiência de usuário unificada.
    É por isso também que o IE e o Edge antigo fracassaram. Sandboxes externos como Flash, ActiveX, Java Applet e Silverlight desapareceram, e com a estabilização de asm.js e WebAssembly a web ficou muito mais limpa. Aliás, o ActionScript do Flash também influenciou o design do ECMAScript e do TypeScript

    • Eu gostava muito de ActionScript 3. Antigamente fiz um agregador de vídeos chamado chime.tv em AS3 (artigo do TechCrunch) e o processo de desenvolvimento foi realmente divertido
    • Java não tem relação com ActionScript. O LiveScript só passou a se chamar JavaScript por causa de um acordo comercial entre Sun e Netscape
    • Silverlight era bem interessante, uma pena que tenha sido descontinuado

  • Quando vi o atributo webkitdirectory pela primeira vez, eu também me surpreendi. Faço webapps há anos e isso tinha passado batido. O sandbox do navegador é um modelo de segurança validado por bilhões de pessoas clicando em links suspeitos.
    É uma abordagem muito mais madura do que subir um container novo toda vez. Ainda assim, o navegador tem limitações: não pode fazer chamadas de sistema, executar binários nem acessar hardware. Para coding com IA é suficiente, mas em alguns trabalhos há limites

    • Acho esse método adequado para construir fluxos com agentes. Dá para expandir para resumo, perguntas e respostas, criação de novos documentos etc., sem modificar diretamente os arquivos originais. Também permite limitar com segurança as chamadas de ferramentas mesmo usando LLM local
    • Pelo mesmo motivo, acho que desenvolvedores NPM também deveriam criar processadores de código-fonte que possam rodar no sandbox do navegador, em vez de depender da API instável do NodeJS

  • É interessante como systemd e o sistema de permissões de usuário do Linux quase não aparecem nessas discussões sobre sandbox. Na prática, eles também são bem poderosos e oferecem isolamento de baixo custo

    • O modelo de permissões do Unix foi originalmente estruturado para o sistema proteger o usuário. Como os programas eram executados com as permissões do usuário, não existia a ideia de que o próprio programa pudesse ser malicioso. Hoje precisamos de proteção entre programas. Eu mesmo já tentei usar um usuário separado para cada app, mas era muito ineficiente. No fim, precisamos de um modelo de capabilities. O xkcd 1200 explica isso bem
    • A maioria das pessoas ainda está no nível de escrever um Dockerfile e publicar direto, então essas discussões são raras
    • O kernel do Linux tem muitas vulnerabilidades de elevação de privilégio. Para isolar software confiável funciona, mas contra malware é fraco
    • Existe uma abordagem como o sandvault, que isola agentes de IA em uma conta de usuário restrita no MacOS. Parece uma ideia bem boa por ser leve e genérica
    • Acho difícil incluir systemd nesse tipo de discussão, porque ele não consegue bloquear requisições DNS ou HTTP de JavaScript dentro do navegador

  • A File System Access API é um grande ponto de virada na evolução da web. No co-do.xyz, você pode selecionar um diretório e deixar a IA lidar com os arquivos internos com segurança. Graças a essa API, webapps passaram a se firmar como verdadeiras ferramentas de produtividade

    • O custo de implantação cai, mas gerenciar estado no navegador sempre me pareceu instável no longo prazo. Eu também cheguei a fazer uma ferramenta de publicação, mas no fim voltei para LangGraph e Celery. Mais importante do que reduzir infraestrutura era garantir confiabilidade
    • Enquanto a UI nativa continuar superior, será difícil para webapps virarem apps de produtividade de primeira classe
    • Safari e Firefox ainda não oferecem suporte a essa funcionalidade da API

  • A execução no navegador é interessante, mas a maioria dos apps de negócio reais migrou para um modelo centrado na nuvem por motivos de manutenção, segurança e acesso a dados. Execução local é boa para produtividade pessoal, mas tem limites para apps do mainstream. É por isso também que recursos antigos de automação de desktop como AppleScript, COM e DDE desapareceram

    • O COM ainda vive como principal mecanismo de passagem de APIs no Windows. Isso me faz lembrar da época em que eu lidava com DDE no Windows 3.x
    • Em apps GenAI bootstrapped, descarregar a inferência para o navegador é uma necessidade econômica. O custo de GPU é alto demais, então o hardware do usuário é praticamente o único recurso gratuito

  • Quero apresentar mais duas coisas possíveis no navegador

    1. com webcontainer, dá para executar frontend e backend em NodeJS no navegador (ex.: projeto bolt.diy)
    2. com jslinux e exemplos de Linux x86, dá para rodar no navegador um ambiente Linux completo baseado em WebAssembly
      Em teoria, seria possível implementar um sistema de agentes bem completo com apenas uma URL
    • Estou fazendo um experimento com v86. A ideia é fazer o LLM tratá-lo como sistema de arquivos e ambiente de execução. Mas o v86 é voltado para UI interativa, então o controle programático não é fácil
    • O webcontainers.io é uma solução comercial proprietária, então acho inadequado mencioná-lo no mesmo nível de plataformas open source

  • Antigamente, no Chrome, dava para pedir permissão de leitura e escrita em diretórios com a File System Access API, mas ao recarregar a aba a permissão sumia. Fiquei curioso se isso melhorou hoje

  • Essa abordagem faz sandbox apenas do sistema de arquivos. Mas as pessoas querem conectar também e-mail, calendário, chat, código-fonte, dados financeiros etc. A segurança do sistema de arquivos é só o começo; a segurança de todo o ecossistema de dados ainda continua sendo um desafio

  • Fico curioso sobre os limites dessa abordagem. Seria possível implementar o Gemini CLI no navegador, como uma versão com UX melhorada? Também daria para integrar com ferramentas locais?

    • Não dá para afirmar que é totalmente possível, mas como a maioria das ferramentas é baseada em JS, boa parte já pode ser implementada no navegador. Hoje quase não existe API do Node que não possa rodar no navegador