Don't assume implicit grant from getUserMedia.

[jan-ivar]

This text: "A successful call to the getUserMedia function of [GETUSERMEDIA] MUST cause permission to be granted for the returned devices, and MAY cause other permissions to be granted."

Sounds like it mandates permission to change from "prompt" to "granted" after a call to getUserMedia? Chrome has such persistent grants, but Firefox doesn't, so this API would be returning the wrong value in Firefox (unless this is an attempt to mandate behavior on the mediacapture-main spec?)

[mounirlamouri]

CC @alvestrand

[alvestrand]

This was when I thought we'd have to add non-persistent grants to permissions in order to support getusermedia semantics (see closed issue #63). This text should be deleted.

In general, I think the permissions spec needs to say that after requesting a permission, the permission granted MAY be stored, and the UA MAY choose to store other permissions, that this is UA specific, and that other specs may choose to give implementation advice on it, but don't have to.

[jyasskin]

In Web Bluetooth, I'm saying that "The UA MAY revoke Bluetooth access to a device for an origin at any time based on signals from the user." Is that sufficient? Then the UA is free to revoke permission as soon as the tab is closed, but the permission-using specs are able to use the permission store in their own logic. (This is important for video/audio recording and Bluetooth where we need to check for the permission still being around when the site makes certain calls, and need to take action when the user revokes permission.)

This doesn't allow one tab to have the permission and another not: is that important? If so, we could model it as a hierarchy of storages, where each permission would define how to merge their storage from the tab to the global store.

[alvestrand]

In WebRTC, we have permissions tied to origins, but not permissions tied to tabs. With the trick of checking for devices being open, we managed to avoid the concept of "temporary permission".

One tab having (temporary) access to a camera and another, from the same origin, not having it is a necessary use case for WebRTC.

[jyasskin]

Do you happen to have a link to the "trick of checking for devices being open"? I'm curious how you handle the user revoking permission within a tab that has "temporary" permission. Experimenting with https://permission.site/ shows that Firefox can revoke one tab's permission without closing another tab's stream. How do we model that?

[raymeskhoury]

This is a bit of a more general question (sorry if it's already been discussed!): how much do we want to standardize UA behavior with regard to persisting/retrieving permission decisions?

The current working draft doesn't talk about persistence at all, but we've effectively been fleshing this out in fine detail in the editor's draft.

I'm a bit torn: at one level I like the idea of having consistent behavior across browsers. OTOH it feels like the question about how persistence should work is closely tied to the UI. Different browsers may have different opinions and different UIs may lend themselves to different strategies for persisting decisions. We don't attempt to standardize UI atm.

Another example of the difficulty in standardizing this is that in Chrome we provide features which allow system administrators to override stored permission decisions. In order to comply with the spec (for features like this) we would need to insert a clause that allows the UA to override the permission decision returned.

[jyasskin]

I think #97 fixed this by letting a UA do whatever it wants with the permission state to reflect the user's intent. Request permission to use and prompt the user to choose now do say the UA may store the permission for the current or other realms.