Currently, when a site requests camera or microphone access in Firefox, we show a permission panel which lets the user choose which device the user wants to share with the site. Presumably, this was the UI that was built before the enumerateDevices API shipped, so it was the only place where users could choose which device started feeding data to a site.

The enumerateDevices API allows sites to let the user configure which device is being used for the input streams. For example, if one goes to https://talky.io, clicks "Start a Chat", and then "Allow camera access", once the camera access has been offered, we do let the site show the other devices on offer. If, however, the user tries to change the device on the site, the user has to reauthorize the site to use that device. It's similar for microphones.

Both Google Chrome and Safari use the model where a site can request permission for a camera or microphone once, and from then on, if the user chooses a different device that the site lists via enumerateDevices, then the permission isn't re-asked for.

I'd like to understand why Firefox is different here. It presents real friction to a user who might be trying to use a WebRTC application to have to grant permission each time.

Ideally, we could drop the list of devices from the camera and microphone permission doorhangers all together (simplifying them a great deal), and then refer to that same permission when the user switches devices.

This is another one for you jib: do you know the reason why Firefox behaves differently here, and offers per-device permissions for a site rather than device-type permissions for a site?

Hey pbz, since we worked on some WebRTC UI changes recently, I wondered if you might have an opinion on this, too.

I think offering a device-agnostic camera or microphone permission can be done by making sure that the activePerms for a site are keyed only on windowID and mediaSource, and not on device ID (so removing device ID from these lines: https://searchfox.org/mozilla-central/rev/85f20360d898501f0fac12dd35fe8b7475e01848/browser/actors/WebRTCParent.jsm#348,359,1038,1070)

Then I think it's a matter of cleaning up the panel to no longer show the select dropdowns with the camera / microphone devices, and then (I think) cleaning up some of the messaging going back and forth to remove the extraneous stuff that we've removed.

I'm all for simplifying the WebRTC permission UI. However, are we sure that having a device dropdown (which has the default device pre-selected) is really that much friction to the user? I'm wondering if switching devices is a common use case. I'd expect most users to only have a camera and a mic. Why would they need to switch devices often?

From a privacy point we would be regressing here. Users might only want to share a specific device with the site. Websites allowing the user to select devices is definitely the more user friendly way. Still, I think we should prompt the user for permission (again) when sites wants to access a new device.

Perhaps we could remove the device selection for the initial request and use the default device instead. This way we simplify the common case but still protect users from sites using all of their devices when they don't expect it.

Johann, do you have thoughts on this?

Sorry, editing collision, see comment 4.

I'd like to understand why Firefox is different here.

It's different because we think it's better than Chrome's and Safari's models, as does the Privacy Interest Group (PING), which prefers a privacy by default flow. Users shouldn't have to grant access to all their cameras just to use one. E.g. a user may share their front camera only, and not risk sharing their back camera and location (if they're on a beach instead of at work).

When Chrome asks "x.com wants to: use your camera. Allow?" it lies. It's really: "x.com wants to: use your cameras" (plural), because even for users with only one camera, the ask extends to any USB camera they have yet to plug in, because the permission is to a category = all cameras.

So if we changed to do that, would we lie as well or use plural? 😉

Also, if I have several cameras, there's no way in other browsers to choose the right camera upfront. Also cost seems low: Since the default camera is pre-chosen, there's no extra clicks needed in the default case, you simply learn which camera will be used, which seems like a plus. Firefox seems better here.

These are the advantages.

Both Google Chrome and Safari use the model where a site can request permission for a camera or microphone once

This is not accurate about Safari which apparently uses some form of heuristics to decide (I suspect time and focus-pattern). Also, like Firefox and unlike Chrome, Safari doesn't implicitly persist the permission across visits. So Firefox is not unique in experimenting with permission models. It's an area of differentiation.

It presents real friction to a user who might be trying to use a WebRTC application to have to grant permission each time.

We have the ☑ Remember this decision checkbox for these users. Once they check it they'll never be prompted again for this site. Is that insufficient? Or is the concern friction for users who don't check this box?

The enumerateDevices API allows sites to let the user configure which device is being used for the input streams.

enumerateDevices is a target for trackers, called by 7% of the web 😱, far eclipsing getUserMedia at ~0.5%.

Thanks to PING, the spec was changed to neuter enumerateDevices ahead of getUserMedia (IOW deprecate the "enumerate-first" strategy), which means there's no way for users using a secondary camera to get their correct camera chosen upfront except to use Firefox.

For example, if one goes to https://talky.io, clicks "Start a Chat", and then "Allow camera access", once the camera access has been offered, we do let the site show the other devices on offer.

Yes, this is the "device-first" strategy most sites use, and the Firefox prompt is compatible with this strategy, i.e. our prompt does not have its own memory, but merely offers first-time visitors an early opportunity to get their choice in without having to visit the web site's ⚙️ Settings page, and for users who never check ☐ Remember this decision, a second UI for accessing the same memory.

If, however, the user tries to change the device on the site, the user has to reauthorize the site to use that device.

Again, only if they chose not to ☐ Remember this decision. This extra prompt on device selection does feel redundant.

However, Firefox's camera picker is proving to be the solution here, not the problem.

enumerateDevices is still under criticism for exposing device labels for all your devices, which is considered an unnecessary privacy leak for the simple task of switching devices. So the working group has been moving away from in-content device selection, in favor of in-browser pickers, something there's an opportunity for Firefox to lead on, if we can get UX resources.

When it comes to privacy, this won’t necessarily be worse than the current implementation.

In the current implementation, if I give a sire access to one camera, and click the checkbox for my choice to be selected, the checkbox is broken. The next time I visit that website, it can access ANOTHER camera.

Changing the model [and wording] to expose all cameras at least won’t result in surprises where websites can access a camera to which I NEVER gave it access.

That said, I often have video calls and use a camera with a physical lid. I’d be somewhat concerned if Firefox always gave access to ALL cameras, and there’s no way to disallow access to a specific one.

OTOH, many websites seem kinda broken, since they have a camera (and microphone) picker, but only one device is visible.

The above related Jira issue is private.

Can we get a summary of what's up?

Closing as WONTFIX. We're not going this route. There are some user-privacy characteristics of asking per-device that we don't want to cede, and we think we can improve the UX of microphone / camera sharing without trading user privacy like this.