Re: [w3c/permissions] Allow returning "prompt" rather than "denied" (Issue #388)

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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/388#issuecomment-1323946527
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/permissions/issues/388/1323946527@github.com>