1449783 - Add support for "camera" and "microphone" in navigator.permissions.query()

Status: RESOLVED DUPLICATE of bug 1916993

(Core :: WebRTC: Audio/Video, enhancement)

Description

[Brian Peiris]

`navigator.permissions.query({name: 'camera'})` currently throws an error in Firefox.

It's useful to be able to query permissions without having to prompt the user. E.g You can skip steps in a setup flow for video conferencing if you already know they've granted permissions. 

Google apparently added support for this in Chrome 64.

https://w3c.github.io/permissions/#media-devices
https://developer.mozilla.org/en-US/docs/Web/API/Permissions/query

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Firefox's permission model differs from Chrome's.

Firefox does not grant persistent permissions for repeat use of camera and microphone implicitly, instead leaving users in control over every time the camera and microphone can turn on on them. There's a "☐ Remember this decision" checkbox in Firefox's permission prompts, but it's off by default. Some of our users are privacy-sensitive, and never check this box, even for sites they visit regularly.

(In reply to Brian Peiris from comment #0)
> You can skip steps in a setup flow for video conferencing if you already know they've granted permissions. 

Please use a cookie instead to detect first-time users. Using query() the way you describe, lumps repeat Firefox users in with first time users, creating a permanent slow-lane for them on your site. These users have been to your site before and don't need the indirection of an explainer.

Requiring users to give persistent permission to get out of the slow-lane, is bad UX, because it says "we don't trust you know how this works" to repeat visitors.

It's also a false choice that undermines privacy. Privacy-sensitive users already live with an extra click on a permission prompt every visit. Punishing this group with artificial side-steps, incentivizes people to give up more privacy than they need to. This permission overreach is bad for users.

I understand the need to prime users to answer yes. Chrome's permission prompt blocks you forever if you show it too soon (Firefox doesn't, unless the user takes time to explicitly check "☑ Remember this decision").

Priming first-time users makes sense. The site can explain why it needs the camera and microphone, to the user. But priming repeat Firefox users who prefer tighter control over their camera and microphone, punishes them with a slow-lane. Use cookies to detect first-time users, not this infernal API.

Firefox only partly implements navigator.permissions.query() API today, and not for camera and microphone. I think this API is too biased toward Chrome's limited permission model, and bad for the web. I've argued this as a Mozilla position [1], and I'm closing this issue for now based on that. We can re-open if there's a challenge to that position.

[1] https://github.com/mozilla/standards-positions/issues/19#issuecomment-370087341

Comment 2

[Dmitry Zlygin]

The proper permissions API for camera/microphone is now required for web page to setup user video meeting. Web page for example cannot obtain proper devices list without media permission. To ensure we have it in Firefox we have to acquire real media stream, then immediately stop it - that is very suspicious for the most users (we're not in the meeting but we already trying to capture media). Chrome allows web dev to do that only in case when page have no prior permissions.

Even worse, Firefox won't allow web dev to enumerate devices without active stream when user haven't allowed it forever. But it's possible to reacquire stream and enumerate devices when it's active - without any notice for the user and any additional confirmation.

For the security model - as far as I can see now Firefox has "Permissions" section in "Privacy & Security" settings, and this section has "Camera", "Microphone" just as "Location" and "Notifications". But web devs are only allowed to access latter two.

So to sum up - maybe times have changed, and it's worth to reopen this issue again.