Show HN: Firefox en WebAssembly

Artículo original ↗ Discusión en Hacker News ↗

Ejecutar Firefox dentro de WebAssembly —efectivamente, un navegador dentro de un navegador— impresiona a muchos por lo utilizable y eficiente que ya es, incluso manejando sitios complejos como YouTube. Los comentaristas profundizan en las decisiones técnicas (Gecko de proceso único, requisitos de JSPI, un JIT WASM→JS personalizado, red TCP sobre WebSocket) y debaten las implicaciones de seguridad, señalando tanto capas de aislamiento más fuertes como nuevas superficies de ataque o regresiones del sandbox. Otros cuestionan los casos de uso reales, los costes (incluidas afirmaciones de 25k dólares en tokens de IA para ayudar al port) y la dependencia de relays remotos, mientras imaginan escenarios que van desde el bloqueo de anuncios en televisores cerrados hasta futuros trucos de “navegador interno” que podrían eludir las extensiones del usuario.

Reacción general

  • Muchos consideran la demo “radical”/“increíble” y sorprendentemente eficiente, especialmente dado que ejecuta un motor completo de Firefox dentro del navegador.
  • Otros cuestionan los casos de uso prácticos y lo ven principalmente como una llamativa prueba de concepto para WebAssembly.

Implementación técnica

  • Usa una compilación de Firefox de proceso único con paso directo de GPU/WebRender a canvas y un fallback opcional por software.
  • Se apoya en WebAssembly JSPI (wasm_js_promise_integration) para ceder el bucle de eventos y sincronizar OffscreenCanvas; los usuarios de Firefox deben activar una bandera oculta, y se espera compatibilidad completa en futuras versiones de Firefox/Safari.
  • Incluye un JIT experimental de WASM→JS y parte del trabajo de backend intérprete de WebAssembly, con un esfuerzo sustancial dedicado al rendimiento y la estabilidad.
  • Se cita trabajo previo: ports de WebKit en Wasm y el anterior WebKit.js.

Rendimiento y compatibilidad

  • Funciona bien para muchos usuarios de escritorio (incluidos Macs ARM y Steam Deck), incluso ejecutando YouTube.
  • Falla o funciona solo parcialmente en móviles (Firefox y Chrome/Android) debido a límites de memoria, funciones ausentes o bloqueo tras el primer frame.
  • A veces funciona la anidación “Firefox-in-Wasm dentro de Firefox-in-Wasm”, pero es inestable.
  • Algunos usuarios informan de velocidades de red 10× más lentas dentro del navegador wasm y varios errores (problemas de drivers GPU, syscalls no compatibles).

Seguridad y red

  • Algunos sostienen que esto refuerza mucho el sandboxing (navegador dentro de navegador, más runtime wasm), mientras que otros señalan que desactiva el aislamiento multiproceso habitual de Firefox y depende de una compilación muy modificada, editada por IA.
  • Todo el tráfico TCP se proxifica mediante un relay basado en WebSocket que corre en Cloudflare; TLS se maneja dentro del navegador mediante OpenSSL compilado a Wasm.
  • La IP dentro del navegador wasm es la del proxy, lo que plantea preocupaciones de confianza y abuso (ocultación, posibles malas prácticas).
  • Las afirmaciones de “cifrado de extremo a extremo” son criticadas porque el sitio sirve el código wasm y controla lo que se ejecuta.

Casos de uso e implicaciones

  • Entre los usos propuestos están añadir bloqueo de anuncios y extensiones a smart TVs cerradas, y servir como sandbox de navegador de propósito general.
  • Otros prevén que los editores desplieguen “navegadores internos” ofuscados para eludir los bloqueadores de anuncios del usuario, posiblemente con un alto coste en RAM y complejidad.

Coste e implicación de IA

  • Se informa que el port consumió alrededor de 25k dólares en tokens de IA para depuración e investigación del JIT, lo que ha generado debate sobre el coste, la viabilidad frente al trabajo humano y si esto es un “experimento divertido” o investigación seria.