4 ms·

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

What you're describing is basically SES: https://medium.com/agoric/ses-securing-javascript-in-the-real-world-4f309e6b66a6 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.

Legogris 4y ago
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 https://github.com/LavaMoat/LavaMoat [1]: https://youtube.com/watch?v=Z5Bz0DYga1k https://youtube.com/watch?v=Z5Bz0DYga1k
remram 4y ago
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.
- phickey 4y ago
  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 https://github.com/bytecodealliance/jco You can also run these same components server-side with Wasmtime.