[eis]

The problem is that you grant the privileges on the application level and not library level. You grant network access to your app and then some updated dependency suddenly starts communicating home and it wont prevent that.

It is also possible in Deno to set permissions for Workers but that's not just plug and play for existing libraries.

[Hovertruck]

I suppose that depends on if you're blanket-allowing network, though. You could pass an allow list of ips/hosts that are allowed, though that's not going to be feasible for every application: https://deno.land/manual@v1.26.0/getting_started/permissions...

[eis]

Yea you could restrict the app by whitelisting only the network services and folders that it will use and that's pretty valuable though at least on Linux could already easily be achieved otherwise. It's good that Deno makes it easy but let's be honest, most people will just pass -A.

I'd love to see a permissions system on a library basis. It would ask the first time a dependency is added and when a new permission is requested after an update. Javascript doesn't make that easy though by being so dynamic. SES could maybe help: https://github.com/endojs/endo/blob/master/packages/ses/READ...

[johannes1234321]

On a library level won't be easy, as there will be wrapper libraries of some kind (axiom-style or whatever) and those wrapper lib will get the permission, so you'd then need a mechanism to prevent somebody calling into that library directly ... and not indirectly (say telling a third module to use the http-wrapper as a callback for some other thing) it is a rabbit hole

[laurencerowe]

Workers are the solution here since they provide a security boundary. Access to the outside world must then be intermediated by your app. You might provide a version of fetch inside the worker that works through postMessage or SharedArrayBuffer allowing your app to filter the requests made by the untrusted script inside the worker.