Show HN: Firefox in WebAssembly

Original Article ↗ Hacker News Discussion ↗

Running Firefox itself inside WebAssembly – effectively a browser inside a browser – impresses many with how usable and performant it already is, even handling complex sites like YouTube. Commenters dig into the technical choices (single‑process Gecko, JSPI requirements, a custom WASM→JS JIT, TCP-over-WebSocket networking) and debate security implications, noting both stronger isolation layers and new attack surfaces or sandbox regressions. Others question real‑world use cases, costs (including claims of $25k in AI tokens to aid the port), and the reliance on remote relays, while imagining scenarios from ad‑blocking on locked‑down TVs to future “inner browser” tricks that could bypass user extensions.

Overall reaction

  • Many find the demo “rad”/“amazing” and surprisingly performant, especially given it runs a full Firefox engine in the browser.
  • Others question practical use cases and see it primarily as a striking proof-of-concept for WebAssembly.

Technical implementation

  • Uses a Firefox single‑process build with GPU/WebRender passthrough to canvas and optional software fallback.
  • Relies on WebAssembly JSPI (wasm_js_promise_integration) to yield the event loop and sync OffscreenCanvas; Firefox users must enable a hidden flag, with full support expected in future Firefox/Safari versions.
  • Includes an experimental WASM→JS JIT and some WebAssembly interpreter backend work, with substantial effort spent on performance and stability.
  • Prior art referenced: WebKit-in-Wasm ports and earlier WebKit.js.

Performance & compatibility

  • Works well for many desktop users (including ARM Macs and Steam Deck), even running YouTube.
  • Fails or partially works on mobile (Firefox and Chrome/Android) due to memory limits, missing features, or freezing after the first frame.
  • Nested “Firefox-in-Wasm inside Firefox-in-Wasm” sometimes works but is unstable.
  • Some users report 10× slower network speeds inside the wasm browser and various bugs (GPU driver issues, unsupported syscalls).

Security and networking

  • Some argue this strongly hardens sandboxing (browser inside browser, plus wasm runtime), while others note it disables Firefox’s usual multiprocess isolation and relies on a heavily modified, AI-edited build.
  • All TCP traffic is proxied via a WebSocket-based relay (WISP protocol) running on Cloudflare; TLS is handled in-browser by OpenSSL compiled to Wasm.
  • IP inside the wasm browser is that of the proxy, raising trust and abuse concerns (cloaking, potential mischief).
  • “End-to-end encryption” claims are criticized because the site serves the wasm code and controls what runs.

Use cases and implications

  • Proposed uses include adding ad blocking and extensions to locked‑down smart TVs and as a general-purpose browser sandbox.
  • Others foresee publishers shipping obfuscated “inner browsers” to bypass user ad blockers, possibly at a heavy RAM and complexity cost.

Cost and AI involvement

  • Port reportedly consumed around $25k worth of AI tokens for debugging and JIT research, sparking discussion on cost, feasibility vs. human work, and whether this is “fun experiment” or serious research.