Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What you're describing is basically SES: https://medium.com/agoric/ses-securing-javascript-in-the-rea...

There's pros and cons to that, most folks don't enjoy being inside such a restricted sandbox.



Your linked article mentions it as well: For people looking to get these benfits today, LavaMoat[0] builds on endo (Agoric) and SES to expose a user-friendly interface and make it easy to integrate into your build and dev processes. Just curious as to what you perceive as the major cons.

Intro video[1].

[0]: https://github.com/LavaMoat/LavaMoat

[1]: https://youtube.com/watch?v=Z5Bz0DYga1k


Is this usable today? I was about to go down the path of compiling quickjs to WASM to evaluate untrusted code in the browser, but I'd be happier without that. Another concern is that untrusted code might loop forever, I am not sure I can deal with that with either method.


You can use jco to both compile a JavaScript module into a WebAssembly Component (with spidermonkey running as wasm inside), and to generate a Javascript embedding for that component. This solves all of your problems except for untrusted code looping forever, and that’s something which could be added to spidermonkey.wasm. https://github.com/bytecodealliance/jco

You can also run these same components server-side with Wasmtime.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: