> There is nothing special about computer that allows us to put complete trust into any piece of code, and that is okay. Instead, we strive to build trust among developers so that we don't have to read every line of code in every level of abstraction to make sure our files won't be deleted.

I don't understand why this is so often treated as a dichotomy, where either you trust every single author to not delete your files, or you review every line of code to make sure it doesn't delete your files. Both seem unsustainable. I think we need to look at the problem from a different perspective: why is every single transitive dependency able to delete your files?

Take a look at the node-ipc method reference: https://www.npmjs.com/package/node-ipc#ipc-methods

What functionality does node-ipc have that requires it to have unfettered access to the filesystem? Well, with its current implementation, it needs to be able to create a unix socket for e.g. 'serve()'. But if you changed the API a bit, you could conceivably pass it a file handle to a unix socket that you've just created, instead. Now that module doesn't need any arbitrary filesystem access at all! You could make similar changes to those methods responsible for making outbound network connections, etc. At that point, you could almost completely sandbox this module, because all it needs is what you've given it.

In other words: let's apply the principle of least authority for real.

https://medium.com/agoric/pola-would-have-prevented-the-even...

If you find this resonates, Lavamoat is basically the continuation of that 2018 blog post. Hopefully it catches on to get enough traction that SES (or something similar enough providing an API for controlling capabilities) makes it into runtimes.

https://github.com/LavaMoat/LavaMoat

https://news.ycombinator.com/item?id=30707096