"This browser doesn't support WebAssembly JSPI, which Firefox WASM needs to run."
Show HN: Firefox in WebAssembly
21–30 of 134 posts
Re: Show HN: Firefox in WebAssembly
#22I'm so glad this exists, I've been considering doing something like this for a few months. I recently got a TV based on VIDAA os, a locked-down linux-based OS where everything is rendered from Web pages. It has a built-in browser that doesn't support ad-blocking (I suspect VIDAA is profiting from showing ads on the TV), and you can't install new apps unless they're Web pages. This would hopefully allow one to run Fir…
Firefox should really bundle ublock origin as-is. I install it afterwards anyway but I don't understand Mozilla here. They seem to want to stay behind Google.
Re: Show HN: Firefox in WebAssembly
#23All the network traffic from that browser is routed through a server. My IP inside that browser was in India and on CloudFlare network. I don’t particularly trust Puter. Why not route traffic through my actual browser?
Re: Show HN: Firefox in WebAssembly
#24I'm so glad this exists, I've been considering doing something like this for a few months. I recently got a TV based on VIDAA os, a locked-down linux-based OS where everything is rendered from Web pages. It has a built-in browser that doesn't support ad-blocking (I suspect VIDAA is profiting from showing ads on the TV), and you can't install new apps unless they're Web pages. This would hopefully allow one to run Fir…
Firefox should really bundle ublock origin as-is. I install it afterwards anyway but I don't understand Mozilla here. They seem to want to stay behind Google.
In 2024, "search royalties" brought in approximately $585 million for Mozilla, largely from Google. It's not hard to see why they tread very lightly around ad blocking. It's actually impressive that ublock remains easy and painless to install as an extension.
Re: Show HN: Firefox in WebAssembly
#25All the network traffic from that browser is routed through a server. My IP inside that browser was in India and on CloudFlare network. I don’t particularly trust Puter. Why not route traffic through my actual browser?
Puter's networking is open-source and e2e encrypted. Also, a regular browser doesn't give access to raw TCP sockets used for this, so it wouldn't be possible to route through your browser.
Re: Show HN: Firefox in WebAssembly
#26All the network traffic from that browser is routed through a server. My IP inside that browser was in India and on CloudFlare network. I don’t particularly trust Puter. Why not route traffic through my actual browser?
Because the web browser can't make arbitrary network connections. Even if it was implemented intercepting at the HTTP layer (which would probably be much more difficult than just intercepting the low level socket operations) you wouldn't be able to properly manage CORS headers, cookies and various other things.
Re: Show HN: Firefox in WebAssembly
#27All the network traffic from that browser is routed through a server. My IP inside that browser was in India and on CloudFlare network. I don’t particularly trust Puter. Why not route traffic through my actual browser?
The TCP proxy exit node we're using is running on Cloudflare, you can check that your traffic is still TLS encrypted by OpenSSL (also compiled to webassembly). The browser does not have a native API to send raw TCP so the proxying is done by the http://github.com/MercuryWorkshop/wisp-protocol protocol. You can check your packets in dev tools, look for a socket connection with "puter.cafe" as the host for our TCP proxy. This application is meant to be a demo for it actually (why it says at the bottom that its powered by puter networking). That is the only server side component of this.
Re: Show HN: Firefox in WebAssembly
#28Browser sandboxing is now fully solved.
In mean... It kinda feels like this is legitimately true? An attacker trying to do anything on a user's machine through this would have to find a Firefox vulnerability and a vulnerability in the wasm runtime, which is such a high bar that I would actually feel remarkably safe running this thing. The only question is how performance works and whether there are any pain points using as a daily driver, but those feel likely to be a pretty minor point. Oh, and the usual caveat that an attacker can still compromise things inside the sandbox which does leave a certain amount of exposure (but if you run different things in different instances they're isolated).
Re: Show HN: Firefox in WebAssembly
#29>This port cost over 25k in opus/fable tokens for debugging and JIT research
> This was just a fun experiment to push the boundaries of WebAssembly
I'm a huge fan of the project, but I have to ask. If spending $25k is a "fun experiment", where exactly is your threshold for serious work?
Re: Show HN: Firefox in WebAssembly
#30All the network traffic from that browser is routed through a server. My IP inside that browser was in India and on CloudFlare network. I don’t particularly trust Puter. Why not route traffic through my actual browser?
The TCP proxy exit node we're using is running on Cloudflare, you can check that your traffic is still TLS encrypted by OpenSSL (also compiled to webassembly). The browser does not have a native API to send raw TCP so the proxying is done by the http://github.com/MercuryWorkshop/wisp-protocol protocol. You can check your packets in dev tools, look for a socket connection with "puter.cafe" as the host for our TCP prox…
I was reading your landing page at https://developer.puter.com/networking/ and was very confused by how you were achieving the "with no server or proxy" part, until much further down the page:
> "the connection is tunneled over a single WebSocket to a Puter relay"
Come on, it's both a server and a proxy, and it doesn't stop being those things just because you're calling it a relay.