[spartanatreyu]

We already have alternative and superior proposals, it's called Deno.

It's node + npm compatible and its permission system locks everything down by default.

If you know ahead of time, you can turn on which permissions something is supposed to have in the config file.

Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in the config file for next time. If you say no, the script throws an error where it tried to access something it didn't have permission for.

---

Example:

- My linter wants access to my file system?

  - You can have read access to ./src/ts/

- My bundler wants read and write access to my file system?

  - You can have read access to ./src/ts and write access to ./build-output

  - Huh, what's that? The bundler was trying to both read and write a file in ./src/ts?

  - We don't want input files getting overwritten, that's a recipe for hard-to-diagnose race conditions. Looks like the permission system did more than just keep things secure, it's like a type system for IO.

  - Oh, look at that, there was a very subtle bundler misconfig, let me fix that now. How long would that have existed if we didn't use deno...

- Oh what's this? An updated dependency I've been using for 6 months suddenly asking for access to my .env file, and asking to run curl in a separate process? How about "no". Why would a simple DOM utility dependency be asking for those permissions? Ah, looks like it was part of a credential stealing supply chain attack. Glad I wasn't using node.

---

Addendum: Node now has a permission system, but it's broken by design so it's useless.

[tpetry]

Can you clarify why the node permission system is broken but the deno one works? For an outsider like me both look like the same.

[spartanatreyu]

Deno's permissions are closed by default.

Node's permissions are open by default.

---

Let's suppose that node and deno both have the same 20 permissions.

If we have a project that needs read access to one specific folder and write access to another specific folder, that means:

For deno: I need to turn on 2 permissions to those folders. For node: I need to go through all 18 other permissions to turn them off, and also turn 2 permissions to access only those folders.

So from the get go, node is more work.

---

We're all lazy creatures.

We might forget to turn off the permissions, or worse: think we're safe because we only turned off what we thought were the relevant permissions.

Example:

My project reads this folder and writes to this other folder, I'll turn off the network permission so my data can't be exfiltrated, and commands can't come in down the wire if a dependency becomes part of an attack. And because I'm smart, I'll also turn off the FFI permission so a dependency can't communicate with a program outside of node.

Safe right?

No. The hacker took over a dependency and called cURL through a new process.

There's a million ways to go around things with an open-by-default security model.

Open-by-default is a broken design from the start.

It's a lesson that's been learned over and over again.

A closed-by-default security model is the only way.

---

Deno uses a closed-by-default security model, and implements it in a way that isn't annoying. It just runs your program immediately then when it tries to call a function that requires a permission that it doesn't have, it doesn't crash, instead it pauses execution and asks if it can have that permission. If you say yes, it remembers and doesn't bother you again, if you say no, then the function throws an error to be caught by your code or to bubble up uncaught and crash the program to prevent anything not permitted by you taking place.

The other great thing about it, is that you can run something on deno instead of node, and see which permissions it asks you for.

You'd be surprised how not safe some things are. Once you try it on a few example projects, you'll instantly see why npm has so many hacking incidents. It's an eye-opening anxiety raising experience.

On the other hand, when you run a project and see basically no requests for permissions, you can feel a sense of relief that it can only do what it says on the tin.