[mostlylurks]

I, too, would like to have per-dependency security policies. But I can't really see where you would realistically draw the line between dependencies, other dependencies, and your own code. Is a callback, created in your own code, that potentially accesses dangerous APIs allowed? Presumably yes, but what about when it is passed to a dependency that proceeds to call it? What if the dependency returns the callback back to your own code, can you call it then? What if the dependency wrapped the callback in another callback that calls the original callback with altered arguments, and returns that to your code? Do you enforce any potential restrictions statically, necessitating much stricter restrictions on what you can do than typescript on its own does, or at runtime, necessitating some sort of non-trivial bookkeeping tracking all the parts of the codebase that any piece of behavior has touched?

[danenania]

While I don't have the answers to all these questions, I imagine we could come up with some sane defaults.

Even if you have to 'eject' and provide overly broad permissions to certain libraries, I'd imagine these would be quite a small percentage and you'd still get the huge win that the 90% (or whatever) of your dependencies that don't need any system or network access at all and don't have the kind of issues you describe can effectively be removed as viable targets for attack.

For callbacks, Deno could provide a wrapper function that is only available to the top-level app (not dependencies) and causes the permissions in the callback to be evaluated at the app level, not the dependency level. There may be a better way, but that's one idea.

Static checking would be great too. I think a combination of static and runtime enforcement would be ideal.