I like deno's security model where you have to enable things. But I think it made a HUGE mistake to the point of being useless.
Realistically, we need to grant access to env variables, network, etc. So those flags are functionally useless as always enabled.
The issue we face is making sure our dependencies don't do something nefarious. Demo doesn't solve that. I would really, really like to be able to specify these flags at the package level.
It’s definitely nice to know that nothing gets executed, read, written or sent without permission from the user when running a program/script with Deno.
You complain the flags always have to be set to get anything working so they are supposedly useless. No, you don’t have to set them in a grant-all fashion. All flags allow fine-grained permissions, e.g. --allow-env=API_KEY,PORT only allows access to the env vars API_KEY and PORT instead of all env vars. The same principle applies to --allow-net, --allow-run, --allow-read, --allow-write, etc. See `deno run --help` or https://docs.deno.com/runtime/fundamentals/security/ for more.
I think that’s still a win for Deno. Even using all but one flag is better than carte blanche. That said I often —allow-all because Im lazy. Containerising stuff helps.
Realistically, we need to grant access to env variables, network, etc. So those flags are functionally useless as always enabled.
The issue we face is making sure our dependencies don't do something nefarious. Demo doesn't solve that. I would really, really like to be able to specify these flags at the package level.