6 ms·

I think you and the parent are working under different definitions of "script". Deno allows you to grant permissions per top-level invocation. So if you have o

I think you and the parent are working under different definitions of "script". Deno allows you to grant permissions per top-level invocation. So if you have one program that you run by typing `deno run passwordmanager.js` at the console, and another program that you run by typing `deno run downloadfiles.js`, you can give different permissions to each of those "scripts". But within one program, you can't (easily) give different permissions to different dependencies. If downloadfiles.js imports both http.js and check-if-number-is-even.js, and it wants http.js to be able to access the network, it has to request the access-the-network permission globally. So check-if-number-is-even.js would also be able to access the network. The different "script" files that make up one program all have to have the same permissions. (Sure, Deno might have other ways to sandbox parts of your program, but so does Node -- Deno's permissions improvements don't really help you in that case.)

bigyikes 6y ago
Could the solution just be to audit the permissions your dependencies require? Sure, it gets murkier with transitive deps like your http.js and number-is-even.js example, but I would argue that this scenario isn’t as dangerous as it seems because it adds an opportunity for the middle-man-dependency (http.js) to catch overreaching permissions. With node, it is very opaque. With deno, as I see it, http.js can easily check the permissions for number-is-even.js, and you can easily check the permissions of http.js. It’s not perfect, but I think each link in the dependency chain is at least more easily auditable, even if it is not strictly more secure.
- bkolobara 6y ago
  In my experience, auditable doesn't really matter. To have peace of mind you really need to be able to enforce that number-is-even.js will never do a http request.
  - bigyikes 6y ago
    I would seek to automate this audit and enforce it with a commit hook or CI stage or something
saagarjha 6y ago
As someone unfamiliar with the ecosystem as a whole, is this not an issue similar to any sort of library that you run “in process”? Like, if you’re writing a mobile app and you manage to obtain location access, the Facebook SDK that you link against gets the same thing too?
- jfkebwjsbx 6y ago
  The thing with the web is that vetting dependencies is (for the most part) very uncommon. Some people are realizing it is not a good idea to download random code. So the solution proposed by Deno is to sandbox it and put a capabilities system into it, rather than create a culture of proper dependency management. At least they are trying...
- entha_saava 6y ago
  But since there is a VM anyways, It is fair to expect library sandboxing.
- aboodman 6y ago
  Yes this is the common way computers work, but there's no reason to accept it. When today's process model was designed, there was no such thing as github or the internet. The idea of googling for a hunk of code and just pasting it into your app was ... not a thing on anyone's mind. You might argue people are wrong to do that, but the fact is it's extremely popular. And if we redesign the security model, we can allow people to do it safely. Imagine if leftpad.js had no privileges to anything, even if included in an application that has privileges to network, disk, etc.
  - jfkebwjsbx 6y ago
    The fact that something is popular in webdev does not make it right nor popular outside webdev. In almost any other CS field you would be crazy to use non-vetted third-party code and depend on external service providers for your code to simply run. I can only think of draconian DRM, which puts things in perspective...
    - 6y ago

bigyikes 6y ago

Could the solution just be to audit the permissions your dependencies require? Sure, it gets murkier with transitive deps like your http.js and number-is-even.js example, but I would argue that this scenario isn’t as dangerous as it seems because it adds an opportunity for the middle-man-dependency (http.js) to catch overreaching permissions. With node, it is very opaque. With deno, as I see it, http.js can easily check the permissions for number-is-even.js, and you can easily check the permissions of http.js. It’s not perfect, but I think each link in the dependency chain is at least more easily auditable, even if it is not strictly more secure.

bkolobara 6y ago
In my experience, auditable doesn't really matter. To have peace of mind you really need to be able to enforce that number-is-even.js will never do a http request.
- bigyikes 6y ago
  I would seek to automate this audit and enforce it with a commit hook or CI stage or something

saagarjha 6y ago

As someone unfamiliar with the ecosystem as a whole, is this not an issue similar to any sort of library that you run “in process”? Like, if you’re writing a mobile app and you manage to obtain location access, the Facebook SDK that you link against gets the same thing too?

jfkebwjsbx 6y ago
The thing with the web is that vetting dependencies is (for the most part) very uncommon. Some people are realizing it is not a good idea to download random code. So the solution proposed by Deno is to sandbox it and put a capabilities system into it, rather than create a culture of proper dependency management. At least they are trying...
entha_saava 6y ago
But since there is a VM anyways, It is fair to expect library sandboxing.
aboodman 6y ago
Yes this is the common way computers work, but there's no reason to accept it. When today's process model was designed, there was no such thing as github or the internet. The idea of googling for a hunk of code and just pasting it into your app was ... not a thing on anyone's mind. You might argue people are wrong to do that, but the fact is it's extremely popular. And if we redesign the security model, we can allow people to do it safely. Imagine if leftpad.js had no privileges to anything, even if included in an application that has privileges to network, disk, etc.
- jfkebwjsbx 6y ago
  The fact that something is popular in webdev does not make it right nor popular outside webdev. In almost any other CS field you would be crazy to use non-vetted third-party code and depend on external service providers for your code to simply run. I can only think of draconian DRM, which puts things in perspective...
  - 6y ago