What kind of performance hit do you incur on something like file read serializing in and out of protobuf? Also, what is the problem this is trying to solve when it says "secure"? Obviously the code is not that secure because TypeScript is a bit loose on purpose (so, why TypeScript and not just a Go sandbox?). From reading, it seems to solve a problem of restricting local system access, so it's going to run unprivileged code? Surely there are many other exploitation factors such as running up the CPU...the primary use case would be ideal to help me understand.
> Surely there are many other exploitation factors such as running up the CPU...the primary use case would be ideal to help me understand.
You're probably running untrusted JavaScript in your browser right now. The difference between the V8 in Node and the V8 in your browser is that one is heavily locked down and the other can do essentially whatever the OS lets it.
If you have untrusted code to run, you can eliminate a whole class of security concerns by just not having a way for the code to do those things (i.e., making syscalls it shouldn't, forking, reading and writing to the disk or network, etc.). Sure, resource use can be an issue, but that's a problem that's more easily solvable further up the stack with VMs or containers. Just putting an instance of Node running untrusted code in a VM doesn't solve much, since the mechanism whereby you give it input and collect output can be manipulated by the untrusted code itself.
By making the runtime secure, you get the security of the browser (i.e., being able to visit a website without having to wipe your machine), but designed to run in a server environment.
I mean, it certainly depends. But relying on your interpreter to manage CPU scheduling and memory use is almost certainly less ideal than letting your OS/hypervisor do that for you.
