Security prompt by default (instead of throw)

[jsejcksn]

Opening per @bartlomieju's request in #3811 (comment)

It appears that only --prompt shipped in 1.9.0, and that the team is considering making it the default option based on feedback:

Please let us know if --prompt is useful for you. We are considering turning it on by default in a future release.
↳ https://deno.com/blog/v1.9#interactive-permission-prompt

I haven't found any further discussion/notice about potential implementation of --no-prompt, but both provide different behavior from what's there now, and unique value to the user in different cases:

--prompt:
The user wants to run a script without considering permissions in advance, and interactively respond to permission requests.

--no-prompt:
The user wants to run a script, providing only permissions determined in advance, and expect the program to exit (either successfully or due to an error) without interaction arising from unmet permission requirements.

--no-prompt seems especially important in environments where interaction is not possible so that the process doesn't just hang.

I imagine the implementation would be similar to this:

1. The state of every permission's status is set to "denied" by default (instead of "prompt").
2. For every permission granted as a CLI argument to the relevant runtime command (run/test/etc)., those permissions' statuses will be changed to "granted" before the script is executed.

[hayd]

"no prompt" is the default behavior and should remain so. Having --prompt and --no-prompt is nonsensical.

Personally i am strongly against making --prompt the default behavior (again), and this seemed to be the consensus in #3811.

deno should remain "secure by default".

[jsejcksn]

"no prompt" is the default behavior

@hayd This is not the case. Currently (in Deno 1.9.0), by default, all permissions' status states are set to prompt when a script is run unless they are granted using flags on the command line:

A permission state can be either "granted", "prompt" or "denied". Permissions which have been granted from the CLI will query to { state: "granted" }. Those which have not been granted query to { state: "prompt" } by default, while { state: "denied" } reserved for those which have been explicitly refused. This will come up in Request permissions.
↳ https://deno.land/manual@v1.9.0/runtime/permission_apis#permission-states

If my implementation description is unclear, please let me know so I can revise it. I want to make sure it is not miscommunicated.

[hayd]

the status may be set to "prompt" but unless you pass --prompt deno errors:

❱ deno run --unstable cli/bench/deno_http_native.js
error: Uncaught PermissionDenied: Requires net access to "127.0.0.1:4500", run again with the --allow-net flag
const listener = Deno.listen({ hostname, port: Number(port) });
                      ^
    at unwrapOpResult (deno:core/core.js:100:13)
    at Object.opSync (deno:core/core.js:114:12)
    at opListen (deno:runtime/js/30_net.js:18:17)
    at Object.listen (deno:runtime/js/30_net.js:184:17)
    at Object.listen (deno:runtime/js/40_net_unstable.js:12:18)
    at file:///Users/me/deno/cli/bench/deno_http_native.js:5:23

❱ deno run --prompt --unstable cli/bench/deno_http_native.js
⚠️  ️Deno requests net access to "127.0.0.1:4500". Grant? [g/d (g = grant, d = deny)] d
error: Uncaught PermissionDenied: Requires net access to "127.0.0.1:4500", run again with the --allow-net flag
const listener = Deno.listen({ hostname, port: Number(port) });
                      ^
    at unwrapOpResult (deno:core/core.js:100:13)
    at Object.opSync (deno:core/core.js:114:12)
    at opListen (deno:runtime/js/30_net.js:18:17)
    at Object.listen (deno:runtime/js/30_net.js:184:17)
    at Object.listen (deno:runtime/js/40_net_unstable.js:12:18)
    at file:///Users/me/deno/cli/bench/deno_http_native.js:5:23

It seems reasonable if --prompt is not passed that these "prompt" permissions states should be set to "denied".

---

We are considering turning it on by default in a future release.

I love the --prompt behavior but think it would make a terrible default.

IMO libraries/scripts should assert permissions they require at the beginning/import* so that they error prior to beginning execution - but this is something that might take a little time for community to agree on best practices/approach.

*Noting the edge case where you may only want to import only some functionality that requires lesser permissions...

[nayeemrmn]

@jsejcksn What it boils down to is you want a way to disable the prompts from Deno.permissions.request(). This has no relation to --prompt, which enables prompting on permission checks in regular operations, while explicit requests are always enabled. This shouldn't be conflated with --prompt nor its potential inverse since that's not its purpose.

Assuming it was represented by some different flag, your use case is:

--no-prompt seems especially important in environments where interaction is not possible so that the process doesn't just hang.

You would just disable stdin... otherwise user code could consume stdin for whatever they want and easily hang up the process anyway. I don't think there's any need for a flag to alter the behaviour of explicit requests because there's no expectation for them to do anything else and other "prompts" can be issued regardless in user code.

[jsejcksn]

I love the --prompt behavior but think it would make a terrible default.

@hayd I agree.

It seems reasonable if --prompt is not passed that these "prompt" permissions states should be set to "denied".

I haven't seen a detailed explainer of how the permissions/prompt mechanisms work, so I'll try below. I'd like for someone on the core team to correct me if I'm wrong.

This is my understanding of how Deno utilizes the state value of a permission's status when one of the methods of Deno.permissions is used:

query

• Read-only (no change)

revoke

• If state is "prompt" or "granted", it resolves to "prompt"
• If state is "denied", it resolves to "denied"

request

• If state is "prompt", an interactive permission request prompt will be displayed at the command line, and the user's choice will determine whether it resolves to "granted" or "denied"
• If state is "granted" or "denied", a prompt is not shown and its value does not change.

The following is my understanding of how the behavior is implemented in Deno when there is a scenario regarding a permission which has not been previously requested or revoked:

Permission request

If the permission is not granted using a flag when running the script:

	default permission state	outcome
default (Deno 1.9.0)	"prompt"	Prompt is shown
--prompt (Deno 1.9.0)	"prompt"	Prompt is shown
--no-prompt (proposed)	"denied"	No prompt

If the permission was granted using a flag, none would show a prompt because the default permission state would already be "granted".

Evaluation of code requiring permission

example: Deno.env.toObject()

If the permission is not granted using a flag when running the script:

	default permission state	outcome
default (Deno 1.9.0)	"prompt"	Throws Deno.errors.PermissionDenied
--prompt (Deno 1.9.0)	"prompt"	Prompt is shown
--no-prompt (proposed)	"denied"	Throws Deno.errors.PermissionDenied

If the permission was granted using a flag, none would show a prompt and all would succeed because the default permission state would already be "granted".

[jsejcksn]

you want a way to disable the prompts from Deno.permissions.request()

@nayeemrmn Yes, this is exactly what this issue is about. I hope my previous comment illustrates that well.

[nayeemrmn]

It seems reasonable if --prompt is not passed that these "prompt" permissions states should be set to "denied".

This would make Deno.permissions.request() useless. Since it's an API explicitly for requesting, it should do so without --prompt. And as I explained above there's no reason to have a way of disabling Deno.permissions.request().

[hayd]

This would make Deno.permissions.request() useless. Since it's an API explicitly for requesting, it should do so without --prompt.

I disagree - it's plenty useful to ask for permissions (or error) at the beginning of a program rather than half-way through.

[ry]

I'm in favor of making --prompt the default behavior.

Personally i am strongly against making --prompt the default behavior (again), and this seemed to be the consensus in #3811. deno should remain "secure by default".

@hayd Deno can remain secure by default while doing prompt-by-default. Or maybe I'm missing something?

[getspooky]

Like browser permission experience, it would be more useful to include permission prompt by default instead of throwing error.

[kitsonk]

Closed by #13650