Deno's permissions are per-process though, it's a big jump for sure, but also still leaves the door wide open for abuse by dependencies of any serious project.

It does allow for some coarse grained improvements for certain services, though.

You might write an smtp daemon that only delivers email on to another service via LMTP - thus without ability to write to (or read from, depending on configuration) the file system, for example.

Yes, you can accomplish this via containers, too - but it's nice to get as much out of process isolation as possible, not to mention it is likelier easier to test and debug the closer to the surface of the runtime limitations are implemented.

How is that different from Node.js which also runs in a single process? Or does Deno create per-request processes (or v8 "isolates" etc) like CGI does?

I think the point was that it's not different from Node.js - and thus not much of a benefit.

If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.

Yes, this was my point. It's only trivially better in practice since you'll have to open all the doors nearly all the time.

We have so many dependencies that really only need to work in-memory and have zero IO needs. That part is not solved in Deno at all.