Allow for the query algorithm to return prompt or denied when document is not allowed to use

[aselya]

Updated language to allow the query algorithm to return prompt ordenied helps protect the user from exposing their available features and helps prevent retaliation against the user from developers.

closes #388

The following tasks have been completed:

• Modified Web platform tests (link)

Implementation commitment:

• WebKit (link to issue)
• Blink (link to issue)
• Gecko (link to issue)

---

Preview | Diff

[miketaylr]

There is some prior art at https://privacycg.github.io/storage-access/#permissions-integration and https://privacycg.github.io/requestStorageAccessFor/#permissions-integration

Conceptually, WDYT @marcoscaceres, should we pull this into permissions, or just add a note saying powerful features can do this in their own permission query algorithms?

[johannhof]

@aselya can you elaborate a bit more on why you think exposing Permissions Policy state (which is "allowed to use") would lead to retaliation against the user?

I could see an argument for why this technically exposes cross-origin information, but that seems by design, the same way that, say, the sandbox argument is observable by a cross-origin iframe. Also, that doesn't seem like something that should be implementation-defined. :)

[marcoscaceres]

Ok, yeah, @johannhof is right (this has nothing to do with "allowed to use")... this needs to happen further down around... we think around step 8, where the permissions store is checked. We reviewed this and added some suggested text for the note by incorporating some of Anne's wording.

[aselya]

@aselya can you elaborate a bit more on why you think exposing Permissions Policy state (which is "allowed to use") would lead to retaliation against the user?

I could see an argument for why this technically exposes cross-origin information, but that seems by design, the same way that, say, the sandbox argument is observable by a cross-origin iframe. Also, that doesn't seem like something that should be implementation-defined. :)

Apologies for the delay in response, only just saw this.

I made this PR after observing that this spec and the spec for requestStorageAccessFor (rSAFor) were not in alignment on the what permission states might be returned from a query. The explanation provided in the rSAFor spec for not revealing the denied permission state seemed reasonable and worth incorporating into the permissions spec to allow for other permissions to utilize in the same manner.

[aselya]

@marcoscaceres, moving the text to step 8 makes sense to me.

[aselya]

@marcoscaceres @miketaylr, any additional questions preventing this merge?

[annevk]

I don't really see how this addresses #388 (comment)

In particular:

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).

I guess this note is meant to indicate user agents can do whatever, but is that really desirable?