I would be careful with this demo. When you go to whatismyip.com, it's showing: 104.28.233.73. Someone could use this to cloak their IP address and do some damage.
I think they had to solve the TCP connection, as normally you can't easily implement TCP sockets in WASM. So I suppose they just need to tunnel all the connection through some websocket.
Show HN: Firefox in WebAssembly
121–130 of 134 posts
Re: Show HN: Firefox in WebAssembly
#122Earlier quoted context omitted.
If ublock origin guards the connections above, ads still won't load. (Except embedded ads, that also show now)
The future product will tunnel all the connections from the inner browser over an opaque pipe (like WebSockets) with the encryption handled by the inner browser (and using cert. pinning).
Re: Show HN: Firefox in WebAssembly
#123Oh wow didn't expect this to be either possible or this perform so well. Also fascinating how small the wasm binary is. I made a Wasm port of FreeCad (also had a fairly popular thread here a few days ago) but that image was close to 300MB uncompressed / 90MB compressed with Brotli. (btw none of my wasm CAD ports seem to run, each with slightly different flavors of missing wasm features it seems - I have them linked o…
I tested a bunch of stuff before this post went live Apple M1/M2/M3/M4 on macOS Sequoia, good
Apple M5 and prior chips on tahoe, bad due to a known GPU regression (this is actually why my personal machine runs sequoia)
Windows on ARM Qualcomm Adreno X1 driver - bad to usable performance
Ubuntu 26.04 Aarch64 upstream mesa with freedreno - works really well but encounters artifacting
Pixel 10 Pro - doesn't work here at all
Intel HD4600 on Windows 11 i7-4790k- works quite well up to 2 tabs where the renderer starts really suffering
Re: Show HN: Firefox in WebAssembly
#124>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
#125It's kind of ironic how this doesn't work in Firefox.
Worked in my Firefox on Steam Deck. I was amazed it could run YouTube.
We had completely saturated NICs on like the two original servers
Re: Show HN: Firefox in WebAssembly
#126Impressive and surprisingly performant, but what's the use-case? If anything, this is an ad for WASM!
Re: Show HN: Firefox in WebAssembly
#127Earlier quoted context omitted.
I imagine it is 25k tokens not dollars
https://news.ycombinator.com/item?id=48927724 seems to say dollars? Although yes the phrasing could be clearer in the post
it was 25k WORTH of API billed tokens, but only actually 1 claude max 5x plan, so it was more like 100 dollars
Re: Show HN: Firefox in WebAssembly
#128This is the entirety of the log message.
[chrome-demo] chrome assets + engine wasm ready
[gecko] warning: unsupported syscall: __syscall_madvise
[gecko] embed-xul: main() on the app pthread (PROXY_TO_PTHREAD)
[gecko] embed-xul: GECKO_GL_PASSTHROUGH=0
[gecko] embed-xul: GECKO_COARSE_CLOCK=1
[gecko] [libxul] abort: Assertion failed
[gecko] Aborted(Assertion failed)Re: Show HN: Firefox in WebAssembly
#129> This is fully end to end encrypted! We use the WISP protocol for TCP-over-websockets. Umm, that doesn't sound right. By definition, i dont think you can be end2end encrypted in a web browser, since your server controls what code is run by the web browser. Puter would fully be able to spy on you if they were so inclined because they control what wasm you load.
You can inspect the wasm binary, we can't take that ability away from you (or you can compile using the sources we provide on GitHub and see it provides the same result, it's actually built from an actions runner anyways) End to end Encrypted is valid here because both peers of the request (client and server) have their information being exchanged through TLS and they both manage their own keys. We can't look inside…
But you could if you were malicious, you control the tunnel creation code.
> It's end to end encrypted in the same sense that when you go to hackernews your ISP can't see your password because of TLS.
But its not like that. I do not have to trust my isp to not be evil. There is nothing my isp can do to read the password. I do have to trust you, you could easily modify the software in a way to read my password.
Re: Show HN: Firefox in WebAssembly
#130Earlier quoted context omitted.
>Why not route traffic through my actual browser? Because you can't. Not even an Extension is able to. Browsers don't want you to bypass their content enforcement. I wish we had at least one hacker friendly browser.
No, it is possible with extensions. Extensions can inject headers, such as Access-Control-Allow-Origin: *, to unblock cross-origin requests. In the Manifest V3 context, however, that might require patching window.fetch and window.XMLHttpRequest. For example, // content.js window.fetch = async (...args) => { const request = args[0] instanceof Request ? args[0].url : args[0] const config = args[1] || {} return new Prom…