[dead]
Show HN: Firefox in WebAssembly
111–120 of 134 posts
Re: Show HN: Firefox in WebAssembly
#112Earlier quoted context omitted.
what do you mean? we're a team of 10 and have 390 contributors. We post regularly, including me.
The 21 on github, do you mean? And only nine above 3 commits ever? Yes you post regularly, too much even, and in the face of the guideline Please don't use HN primarily for promotion
Why are you being so hostile?
Re: Show HN: Firefox in WebAssembly
#113I checked internet speed inside and outside the wasm, and inside wasm its 10x slower, what could be the reason?
Re: Show HN: Firefox in WebAssembly
#114Oh and for anyone asking, you can run firefox-wasm inside firefox-wasm inside firefox! I only got this to load once though since it gets pretty unstable at that level.
Its the first thing I tried as well :D
Re: Show HN: Firefox in WebAssembly
#115I've been waiting for this to happen. The websites that don't want you to block ads will serve you an obfuscated "inner browser" that will render their site. All your ad blockers, etc, are rendered moot. Once accessibility is solved this is absolutely going to be a thing on major websites.
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
#116Oh 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 on https://magik.net if you want to debug for whatever reason)
Re: Show HN: Firefox in WebAssembly
#117I think it should check if my browser is compatible before downloading 50+ mb.
Re: Show HN: Firefox in WebAssembly
#118Earlier 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 is a cors bypass but part of this demo is that it's full Firefox including TLS support. Using this still means intercepting all requests in an inspectable medium and does defeat part of the point
Re: Show HN: Firefox in WebAssembly
#119I checked internet speed inside and outside the wasm, and inside wasm its 10x slower, what could be the reason?
There's several opportunities for a bottleneck but it could be either the TCP implementation just not being good at receiving packets or the TCP proxy side just being congested from HN traffic
Re: Show HN: Firefox in WebAssembly
#120> 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 the TLS tunnel, we only transport the TCP side. 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. The peer you are requesting has ensured only you can see the data, not any intermediary
(Unlike in http where it's completely plain text or a corsproxy where all data is visible to the proxy).