The "prompt" permission state maps poorly across browsers

jan-ivar commented 3 years ago

The permission state is a triumvirate of the following states (with no opposites):

enum PermissionState {
  "granted",
  "denied",
  "prompt",
};

The third state is the default. Browsers like Safari & Firefox (unless user opts in) stay in the default state for camera & mic.

Yet, many web developers treat the default state as undesirable¹. This results in privacy-hostile UX to prime repeat users as newbies every visit (a slow lane) until they're beaten into submitting to persisting permission (if available); a privacy issue.

At Mozilla, we discussed this a while back and I'm catching up with recording two proposals we have here:

Proposal 1: change the name of the third state to `"default"`:

enum PermissionState {
  "granted",
  "denied",
  "default",
};

This is to emphasize that 1) this state isn't an obstacle to overcome; 2) prompts aren't necessarily exclusive to this state.

Proposal 2: remove guarantees of no browser UX in `"granted"`

Browsers like Safari use unknown heuristics to determine permission in some cases – hypothetically such heuristics might include: waiting too long, visiting other windows, navigating + back button, another app opening the camera concurrently, laptop having slept, lack of user gesture etc. All combinations that may cause a re-prompt where otherwise there would be none — It's not clear to us what use case requires sites to be privy to updates about these changes, nor require UAs to make these determinations on an ongoing basis simply to update all sites about them.

Note that getUserMedia calls wait for focus, so there's already no immediacy invariant even with "granted".

In Firefox, we'd like to return "granted" while still gating camera & microphone going hot on some browser button for privacy, to avoid the priming UX many sites would otherwise slow down repeat Firefox users with. We'd base this on recent successful grants.

The "granted" value would retain its value as a strong signal about this user trusting this site with their camera/microphone, and that they are not likely to permanently block the site (which would still require new information about the user's intent).

_{1. We can speculate why devs find the "prompt" state undesirable, but two factors are likely contributors:} _{- The risk of being permanently blocked is much higher in Chrome's Allow/Block model} _{- Temporary permissions don't span navigation well in Safari & Firefox, causing reprompts (something we're working on).}

youennf commented 3 years ago

Browsers like Safari use unknown heuristics to determine permission in some cases

These heuristics are not unknown, if needed. I can describe them here. Safari could expose getUserMedia permission state consistently with those heuristics. Agreed that lack of user gesture would not make it consistent.

Proposal 2: remove guarantees of no browser UX in "granted"

One identified use case for exposing the permission state to web pages is to let them know whether they should help the user on answering to the prompt properly. If we go with proposal 2, what would be the point of exposing the permission state to web pages? FWIW, for Safari, we are not keen on exposing 'denied' and would probably end up exposing 'prompt' instead.

marcoscaceres commented 3 years ago

Removing "granted" doesn't seem right for the reasons @youennf mentioned.

I'd be in favor of renaming "prompt" to "default" tho, and it would match the Notifications API's permission model, where default is:

"This is equivalent to "denied", but the user has made no explicit choice thus far."

And avoids talking about an implied UI ("a prompt"), and more accurately reflects that it's about user choice.

However, given that "prompt" has shipped for a few years, the cost of the change that is high... if we got agreement to make the it could be done tho?

w3c / permissions