As you can probably guess, I love this idea and am very excited by it!
I previously explored if it would make sense to author the logic of XBlocks themselves in WebAssembly as opposed to Python, but came to the conclusion that JavaScript made more sense than WebAssembly for that use case, because until wasm gets garbage collection, you can’t write code in nice high level languages. I still think we could gain hugely from letting course authors write mini XBlocks with their own JS code, and have it run in a sandbox, and that’s trivial to do with JS but difficult with python (unless you go this wasm route, which is great but has way too much overhead for the XBlock logic use case).
Anyhow, for this use case, I think wasm makes a ton of sense.
I think this approach is stronger from a security perspective. Python doesn’t have the security primitives you need for sandboxing; codejail works by taking a dangerously permissive python runtime and applying a bunch of OS rules to lock it down. If there is any mistake in how it’s locked down, you have a security issue. On the other hand, running WebAssembly in this way (from a non-JS runtime) inherently creates a sandbox, and there aren’t even APIs for the code to access things like the host file system. (A fake in-memory filesystem is presented to python if needed.) Plus as you mentioned, the use of “fuel” is great for managing load.
Yes! This would also solve the potential problem we found in the copy/paste work, where people copy a problem block then paste it into a course with an incompatible python_lib.zip - instead, let each individual problem select its own runtime.
Is there a list of these packages somewhere, or is that part of what we need to figure out?
I’d be happy to help with this effort.