Capability-based security within Node. The main module gets limited access to the system (restricted by the command-line, with secure defaults), all dependencies have to be explicitly provided with capabilities they need (e.g. instead of a module being able to import "fs", it receives only an open directory handle to the directory that the library consumer dictates). Deno already does the first half of this.
I kinda wish there were programming languages, where instead of saying `import module`, you said "I must be run in a context where I have access to a function with this prototype". Effectively functions instead of modules, alongside duck-typed OO if you use OO.
The problem is, as soon as it becomes remotely popular, every module is going to end up saying "I must be run in a context where I have access to all the functions version 13.2 of the filesystem module wrapped up in a structure that claims to be version 13.2 of the filesystem module and which has been signed by the private key that corresponds to the filesystem module author's public key" - even though they only need a random access file handle for use as a temporary file - because otherwise developers will be anxious about leaked implementation details preventing them from making version 1.4.16 (they'll just have to make version 2.0 - who cares? their implementation detail is my security).
As an alternative (and this is what capability-based design is all about), instead of replacing dependencies, just only give access to system calls to the main function of the app. It has to pass those on to any dependencies it wants, and so forth. The system calls are a small, mostly unchanging set of primitive items, and any dependency can wrap them up in whatever API suits them.
Example: in order to write to open a file, you need a capability object corresponding to write access to the file's parent directory. Now you can be sure that a dependency doesn't write any files unless you actually pass it one of these capability objects.
