Am I wrong in thinking that this example specifically does not protect against the threat posed immediately preceding it? As in, one is running a script that foolishly imports a nefarious package that uploads tasty environmental variables to an evil server, which it can do when network access is not controlled. Well, what if myWebserver.ts imports that package? A more fine-grained approach that limited network access by source file might be valuable.
> A more fine-grained approach that limited network access by source file might be valuable.
This is what I think I'd like to see as well. The most common case isn't that I don't trust the program I'm running, it's that the level of trust for my dependencies plus their dependencies is essentially opaque.
Each package published to Deno could come with a set of declared permissions (similarly to Android apps).
When importing the package in a module, Deno should detect that permissions scoped at current module level are wider than what the package requires, and automatically narrow down the list of authorized calls.
This would probably be very costly. Suppose that I'm importing a function from lodash (that requires no permissions) and my module calls it repeatedly while also accessing the file system...
