Could there be a PEPC-light?

[simon-friedberger]

The main issues that this proposal is trying to solve is "permission regret" or "leading to unintended grants as well as unintended denials of critical capabilities".

This should be solved with improved browser UI. However, if reprompting is desirable it can also be solved by "only" requiring stronger signals of user intent. That is, without requiring a new element with specified styling and a lot of checks. It could specify that a button click is required and that this permission may only be requested once every X seconds.

Is there any data on how often sites abuse users by over-requesting permissions which suggests that such a simplified protection would not be enough?

[andypaicu]

This should be solved with improved browser UI. However, if reprompting is desirable it can also be solved by "only" requiring stronger signals of user intent. That is, without requiring a new element with specified styling and a lot of checks. It could specify that a button click is required and that this permission may only be requested once every X seconds.

Reprompting is not desirable in general, in the vast majority of cases it would be nothing but an annoyance. However, for a minority of cases, the inability to reprompt becomes a frustrating user experience (e.g. being unable to enable your microphone and start speaking during a meeting). That’s why a strong signal of user intent is what we desire for a solution, to avoid enabling reprompting when it’s not desirable to the user.

A click on a button (which I’m not convinced is a higher bar than transient activation) is not really an action that sufficiently indicates user intent, as it happens naturally during a user’s journey on a site whether or not they are interested in a particular capability. For example a user joining a meeting will likely be clicking plenty of buttons, regardless of if they wish to enable their microphone or not when joining the meeting, a “button click” does little to differentiate between the users which want to enable their microphone and those which don’t. In contrast, if the button clearly states “use microphone”, there will be clear distinction between users which click on it and those which don’t.

That’s why I believe something simpler like requiring a button click would not be sufficient to justify allowing reprompting.

Is there any data on how often sites abuse users by over-requesting permissions which suggests that such a simplified protection would not be enough?

I’m not sure what this data would look like, especially since I don’t think any browser has a similar protection (requiring a button click). Requiring transient activation might be close, so perhaps browsers that require it have some data (though again I’m not sure what the data would look like to indicate one way or another).

Perhaps as a related metric: the embargo logic in Chrome will block an origin from making further permission requests after 4 ignores or 3 dismisses from the user. This is a very conservative heuristic which ensures that we very rarely block a permission request which would be actually of interest from a user, and it’s based on metrics which tracked how likely it would be for a user to actually approve a permission request after X ignores/dismisses. And keep in mind that this is only for users which don’t mind permission prompts enough to actually make a “deny” decision on them.

So I think in general, allowing reprompting with the simplified protection will likely result in many unwanted prompts.

[simon-friedberger]

Yes, reprompting is not desirable but when there is permission regret, I think that is what needs to happen. Considering regret regarding granted permissions, I still don't see a way for a browser to let users know where the UI for permission management is without prompting there.

[simon-friedberger]

A click on a button (which I’m not convinced is a higher bar than transient activation) is not really an action that sufficiently indicates user intent, as it happens naturally during a user’s journey on a site whether or not they are interested in a particular capability. For example a user joining a meeting will likely be clicking plenty of buttons, regardless of if they wish to enable their microphone or not when joining the meeting, a “button click” does little to differentiate between the users which want to enable their microphone and those which don’t. In contrast, if the button clearly states “use microphone”, there will be clear distinction between users which click on it and those which don’t.

That’s why I believe something simpler like requiring a button click would not be sufficient to justify allowing reprompting.

To be clear, it's only allowing "reprompting". Prompting is maybe not that horrible an action....