Puter Ported Firefox to WebAssembly — and Routed Every Byte Through Its Own Server

Puter, the company behind an in-browser "cloud OS", published a demo that compiles the Firefox/Gecko engine to WebAssembly using Emscripten — so a full instance of Firefox runs inside a tab of your regular browser. Simon Willison called it "absurdly cool", and it is a legitimately impressive engineering feat. It's also a tidy, low-stakes illustration of a question every security team should be asking about remote-browser and browser-isolation products: who actually sits on the wire, and what do they see?

How the port works

The source is MPL-2.0 licensed and, per its README, is "made possible by emscripten and the WISP protocol for networking support." Puter's team chose Firefox/Gecko over Chromium specifically because Gecko has strong single-process support, which matters when you're squeezing an entire browser engine into a single WebAssembly module rather than Chromium's multi-process architecture.

The harder problem is networking. Code running inside a browser sandbox cannot open arbitrary TCP connections, so the guest Firefox can't just make HTTP requests the normal way. Puter's answer is to funnel all of the guest browser's traffic over a WebSocket using the Wisp protocol, tunnelled through Puter's own server, which then makes the real outbound connections on the guest's behalf.

The trust boundary hiding in the demo

That architecture means Puter's server is not a passive pipe — it is a genuine man-in-the-middle by design, terminating and re-originating every connection the guest browser makes. Willison tested this directly: traffic to his own HTTPS site stayed encrypted end-to-end (Puter's relay could see only opaque TLS bytes), but plain-HTTP requests to a test site showed up in cleartext on the WebSocket channel. In other words, the relay behaves exactly as any TLS-terminating proxy would — HTTPS destinations keep their confidentiality guarantees, but anything served over plain HTTP is visible to the operator of the relay.

For a research demo this is a reasonable, disclosed trade-off. But the architecture is structurally identical to commercial remote-browser-isolation (RBI) and "secure browser" products that enterprises adopt precisely to reduce endpoint risk. The lesson generalises past this one demo: any product that proxies your browsing through a third party's infrastructure is, by construction, asking you to extend your trust boundary to that operator for at least the plaintext traffic that crosses it. Evaluating those products means asking the same questions Willison's quick test answered informally — what's actually encrypted end-to-end, what terminates at the vendor, and what's logged or retained there.

The agentic-coding data point

Separate from the security angle, Puter's own account of the build is a notable data point for anyone tracking how far AI-assisted engineering now reaches: an estimated $25,000 worth of Claude Opus and Fable token usage went into the port, largely offset in practice by a Claude Max subscription rather than metered API billing. Porting a browser engine to WebAssembly is compiler- and systems-level work, not boilerplate scaffolding — a useful reference point for how organisations should be scoping and budgeting agentic coding work on genuinely hard problems, not just CRUD features.

Why it's worth noting

Nothing here suggests Puter's demo is unsafe for what it is — a public curiosity, clearly labelled, with the encryption behaviour openly verifiable. The value for a security audience is the reminder it provides for free: whenever traffic gets tunnelled through someone else's server to work around a sandbox or network restriction, that server becomes part of your threat model, whether the product is a weekend WASM experiment or a paid enterprise browser-isolation platform.