Show HN: Firefox em WebAssembly

Artigo original ↗ Discussão no Hacker News ↗

Executar o próprio Firefox em WebAssembly – efetivamente um navegador dentro de um navegador – impressiona muitos pela usabilidade e desempenho já alcançados, inclusive ao lidar com sites complexos como o YouTube. Os comentaristas detalham as escolhas técnicas (Gecko single-process, exigências de JSPI, um JIT WASM→JS personalizado, rede TCP sobre WebSocket) e debatem as implicações de segurança, observando tanto camadas de isolamento mais fortes quanto novas superfícies de ataque ou regressões de sandbox. Outros questionam casos de uso reais, custos (incluindo alegações de US$25 mil em tokens de IA para ajudar o port) e a dependência de relays remotos, enquanto imaginam cenários que vão de bloqueio de anúncios em TVs travadas a futuros truques de “navegador interno” que poderiam contornar extensões do usuário.

Reação geral

  • Muitos consideram a demo “rad”/“incrível” e surpreendentemente performática, especialmente por executar um engine completo do Firefox dentro do navegador.
  • Outros questionam casos de uso práticos e veem isso principalmente como uma prova de conceito marcante para WebAssembly.

Implementação técnica

  • Usa uma build single-process do Firefox com passthrough de GPU/WebRender para canvas e fallback opcional por software.
  • Depende do WebAssembly JSPI (wasm_js_promise_integration) para ceder o loop de eventos e sincronizar OffscreenCanvas; usuários do Firefox precisam habilitar uma flag oculta, com suporte completo esperado em futuras versões do Firefox/Safari.
  • Inclui um JIT experimental de WASM→JS e algum trabalho de backend interpretador de WebAssembly, com esforço substancial dedicado a desempenho e estabilidade.
  • Arte anterior citada: ports de WebKit-in-Wasm e o WebKit.js anterior.

Desempenho e compatibilidade

  • Funciona bem para muitos usuários de desktop (incluindo Macs ARM e Steam Deck), inclusive executando YouTube.
  • Falha ou funciona parcialmente em mobile (Firefox e Chrome/Android) devido a limites de memória, recursos ausentes ou travamento após o primeiro frame.
  • “Firefox-in-Wasm dentro de Firefox-in-Wasm” aninhado às vezes funciona, mas é instável.
  • Alguns usuários relatam velocidades de rede 10× mais lentas dentro do navegador wasm e vários bugs (problemas de driver GPU, syscalls sem suporte).

Segurança e rede

  • Alguns argumentam que isso fortalece fortemente o sandboxing (navegador dentro de navegador, mais runtime wasm), enquanto outros observam que isso desativa o isolamento multiprocessual usual do Firefox e depende de uma build fortemente modificada, editada por IA.
  • Todo o tráfego TCP é proxyado por meio de um relay baseado em WebSocket (protocolo WISP) executado na Cloudflare; o TLS é tratado no navegador por OpenSSL compilado para Wasm.
  • O IP dentro do navegador wasm é o do proxy, o que levanta preocupações de confiança e abuso (camuflagem, potencial para travessuras).
  • Alegações de “criptografia de ponta a ponta” são criticadas porque o site serve o código wasm e controla o que é executado.

Casos de uso e implicações

  • Usos propostos incluem adicionar bloqueio de anúncios e extensões a smart TVs travadas e servir como um sandbox de navegador de uso geral.
  • Outros preveem publishers distribuindo “navegadores internos” ofuscados para contornar bloqueadores de anúncios dos usuários, possivelmente com alto custo de RAM e complexidade.

Custo e envolvimento de IA

  • O port teria consumido cerca de US$25 mil em tokens de IA para depuração e pesquisa de JIT, gerando चर्चा sobre custo, viabilidade versus trabalho humano e se isso é um “experimento divertido” ou pesquisa séria.