Allow returning "prompt" rather than "denied"

[annevk]

"denied" at times reveals information about prior visits that user agents might not be willing to expose. For certain permissions we might want to categorically outlaw it if all user agents are in agreement.

"denied" should be fine to return when it's the result of Permissions Policy or when lacking a secure context. I don't think that needs changing.

For other cases, user agents should be permitted to return "prompt", probably implementation-defined? But also, for certain permissions all implementations might be in agreement to not return "denied" (except as per above), such as for "storage-access". The specification should provide infrastructure for that as well as it'll leave less up to implementations.

[marcoscaceres]

Yeah, totally makes sense. We should definitely add this.

[johannhof]

@miketaylr mind if I take a stab at this?

[johannhof]

Actually, can't storage-access just provide its own permission query algorithm? Was there anything beyond that you were hoping to achieve here, @annevk? I suppose we could still add a note that UAs can always run implementation defined steps to hide/change the return value?

[annevk]

I didn't know that existed. privacycg/storage-access#60 (comment) is what I based this issue on. That might be sufficient if query() is the only way this state ends up being exposed.

I guess we should consider whether we want to do be doing that more generally, but that's probably best tracked separately as a follow-up.

(I'm a little wary of all these pluggable algorithms though as what actually ends up happening is not exactly clear.)

[annevk]

After discussing this a bit further I think there is a difference. The current setup is such that the internal algorithm is not pluggable, but the public API is. This means that specifications that build on top of this will still see "denied" (due to the end user having denied; seeing "denied" for other reasons is not a problem as that state can already be observed via other means). This has some minor fallout:

1. Specifications building on top of Permissions might end up exposing "denied" (do to the end user having denied) through a side channel. Any such case should probably be considered a bug, but it would be impossible if they couldn't observe that state to begin with.
2. Attackers could probably "Spectre read" the state. This is not a very problematic "Spectre read" attack, but it's also avoidable.

As such, I think Storage Access using "permission query algorithm" for now as well as ensuring that it doesn't expose "denied" (due to the end user having denied) through a side channel other than "Spectre read" is fine and we keep this issue as a follow-up to make "permission query algorithm" run at a lower-level (or possibly not expose "denied" (do to the end user having denied) at all anymore).

[miketaylr]

I think Storage Access using "permission query algorithm" for now as well as ensuring that it doesn't expose "denied" (due to the end user having denied) through a side channel other than "Spectre read" is fine and we keep this issue as a follow-up to make "permission query algorithm" run at a lower-level (or possibly not expose "denied" (do to the end user having denied) at all anymore).

SGTM. @johannhof, if you'd like to tackle the follow-up once y'all get there, that's fine as well - but you probably have more pressing concerns up front.

[jan-ivar]

I like Safari's cam/mic mitigation here: after I click "Never For This Website" I get "denied", but on reload I get "prompt". Only after calling getUserMedia() again and seeing it fail do I see "denied". We'll aim for doing the same.