27 comments

[ 2.4 ms ] story [ 68.0 ms ] thread
Running user provided js in quickjs in webassembly in a worker in an sandboxed iframe on a different domain would offer many layers of security
One of the companies I worked for did exactly that to safely run customers' JS code, while also limiting / extending the API surface available.

The performance was quite adequate.

Imagine something like "base system" with WebAssembly, bare bones HTML engine with canvas support and no CSS. So now you can just download your favourite JS engine, your favourite HTML, CSS engines. But browser does not necessarily need to sheep those. It would allow to lower the bar for entry into browser market. I think that even a single person could implement that kind of base browser.

Of course there're many hard questions. For example downloading an entire JS+HTML+CSS engine with every website is not a good approach, some caching must be done. There should not be version hell with every website asking for a different version of engine. But those questions could be approached as a more general web library issues.

Check out Geminispace https://gemini.circumlunar.space - one of the design requirements of the protocol is that it be simple enough that a single person can implement a browser for it in a weekend.

But convergence on a minimal set of solutions is inevitable. Even though Geminispace could have hundreds of browsers, most people just use one of the most popular ones, like Lagrange.

Your solution wouldn't lead to a vibrant marketplace of competing web engines, everyone would just ship the equivalent of Chromium like they do now and call it a day.

I'm not sure, just for the fact that the best browser is something that could vary quickly, there might be niches, different native versions...
Cross origin caching of resources is a privacy risk

If site A can tell based on timing information that you probably visited site B recently, that's a pretty big privacy issue

This has largely killed cross-origin caching on the web, as I understand it

Ah yes, Java applets.
Would you use this to run untrusted JS on the server?
From what I understand, this allows you to run untrusted js anywhere, as long as there’s a wasm runtime.

This repo in particular is for JavaScript host environments

Not sure if I'd trust the wasm runtime. If someone breaks out of that it's game over. QuickJS in a unikernel in something like Firecracker VM would be the most secure approach and still provide good performance and startup time.

Another thing is resource consumption where you likely want to limit cpu- and mem-usage.

I recommend Lambda as an easy way to create ephemeral Firecracker VMs and set overall limits on host + guest. For casual use, the memory and CPU limits available in the library should be enough.
I use it on both client and server. A easy way to get excellent security in the server is to run inside AWS Lambda or similar FaaS that uses strong VM isolation; ideally with a lambda instance per user.
You can just run QuickJS (without std lib) as a separate process running as an unprivileged user with seccomp rules.

WASM probably doesn't add much there.

Hello, library author here. Happy to answer whatever questions you have.
The npm package isn't working in the browser. I get `process is not defined`. There is a commit that fixes that issue, but no npm publish was made after that.