Live data from Hacker News

Show HN: Firefox in WebAssembly

developer.puter.com

121–130 of 134 posts

Re: Show HN: Firefox in WebAssembly

#121
post #64
post #52

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.

Can concur, we use a proxy based on the wisp protocol to efficiently proxy TCP packets over websocket

Re: Show HN: Firefox in WebAssembly

#122
post #106

Earlier 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).

This is already possible (actually because of a related project, https://github.com/ading2210/libcurl.js/ ) which compiles... I think WolfSSL or mbedTLS and libcurl to the wasm and then uses the same TCP proxy protocol we're using here (wisp) to tunnel HTTPS over a websocket connection securely and opaquely.

Re: Show HN: Firefox in WebAssembly

#123

Oh 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…

Performs so well is... Subjective but generally what matters here surprisingly is not CPU speed but GPU driver quality (all on Chromium)

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?

Seems like it was $25k worth of tokens

Re: Show HN: Firefox in WebAssembly

#125
post #78
post #74

It'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.

So funny story, supporting web codecs may have been a bad idea because it led to people using more traffic per session than we assumed at first. We had to add more servers mid HN post

We had completely saturated NICs on like the two original servers

Re: Show HN: Firefox in WebAssembly

#127

Earlier 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

I think it was worded badly

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

#128
Firefox ESR in Debian12, won't start. 140.12.0esr (64-bit)

This 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
post #96

> 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…

> We can't look inside the TLS tunnel, we only transport the TCP side.

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

#130
post #110
post #48

Earlier 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…

This isn't enough for every website to load normally.
Post reply on HN