Open Bug 1142123 Opened 9 years ago Updated 6 days ago

Unable to remember which camera to ALWAYS share

Categories

(Firefox :: Site Permissions, defect, P3)

Product:
Firefox
Component:
Site Permissions
Type:
defect

Tracking

()

People

(Reporter: peterbe, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

Steps to reproduce:

1. Have a USB camera plugged in. 
2. Go to a page that uses getUserMedia() which invokes the share pop-up to appear. 
3. Select a non-default camera. E.g the USB camera, not the built-in one
4. Select "ALWAYS SHARE" 
5. Take a picture or something :)
6. Now stop the stream so that the little orange camera icon disappears
7. Go back to a page that uses getUserMedia()

Actual results:
* The second time you come back, it will remember that you chose "Always Share" but it will switch on the DEFAULT camera. Not the USB one. 

Expected results:
* That it always shares the selected camera. Not the default.
FYI, this is a problem on Mozilla Peekaboo, where at the Mozilla spaces they have Microsoft Surfaces propped up with a USB camera at the office reception desks. 
They either have to have the non-USB (the built-in one) camera on all the time or the people who come to sign in have to select the camera.
(coming from bug  1410421) The permission prompt asks the user to select which device inputs to use - this implies that the permission is being granted (and saved) for these devices specifically on this host. I get that permission and device defaults are separate issues, but maybe the bug here is that the wrong expectation is set in the prompt?
We have some customers complaining about this at TokBox. Are there any plans for fixing this?
OS: Windows 8.1 → Unspecified
Priority: -- → P3
Hardware: x86 → Unspecified
Version: 36 Branch → Trunk
Severity: normal → S3

We also seem to be hitting this. Our scenario (Using FF 80.0.1):

  1. Check if we have permissions to access any devices (no on fist time)

  2. Do a GUM with {audio: true, video: true}

  3. Select Camera B and Mic B (non defaults) in the browser dialog.

  4. We get streams for CamB and MicB (so far so good).

  5. We save CamB and MicB DeviceIds in a cookie

  6. We start a new "call".

  7. Check we have permissions to access any devices (which we do now since last call)

  8. Do a GUM with {audio: { deviceId: cookieValueOfLastUsedDevice(MicB) }, video: { deviceId: cookieValueOfLastUsedDevice(CamB) } }

  9. Get streams for MicA and CamA (defaults)

If in step 8 we do a {audio: { deviceId: { exact: cookieValueOfLastUsedDevice(MicB) } }, video: { deviceId: { exact: cookieValueOfLastUsedDevice(CamB) } } } We get an OverConstrainedError.

If in the first call we allowed permissions to access CamB and MicB,, when we come to next request them via an exact or even just by non-exact deviceId request we should get streams from CamB and MicB, and not the defaults of CamA and MicA.

Seems to be a persistence of Permissions issue. I'm not familiar with how Firefox deals with saving Permissions for specific devices? Does it save a generic "Yeah you have permissions to use a camera and mic, but we don't know which one?"

This issue is still an issue on Firefox 83.

This is an extremely serious privacy issue: it allows a website to, without authorisation, activate and record on a user's webcam. I discovered this issue when a website suddenly rendered a camera I'd never given it access to.

This is pretty much the scariest type of issue that can exist, from a consumer perspective.

Reproduction steps:

  1. Visit https://mozilla.github.io/webrtc-landing/gum_test.html.
  2. Select "camera" on that page.
  3. On Firefox, select a camera that is not the first. In my case, I selected a camera which has a physical lid on it.
  4. Select "Remember me decision".
  5. Reload the page.
  6. Click webcam again.

Actual behaviour

The website can now access another webcam -- one that does not have a lid, and points to a location that it not okay for this website to see.

Expected behaviour

Websites should not have access to a webcam if they have never been given authorisation by the user.

See Also: → 1687395

Still in issue in Firefox 85.0, Feb 2021.

In addition, this issue can be reproduced with one hardware webcam + one software webcam. The software "Logitech Capture" uses your hardware webcam to make a software webcam available called "Logi Capture". So your system will have a choice of 2 webcams available.

  1. Visit a website that will ask to use your webcam
  2. Firefox dialog appears, click the drop-down to select the software webcam ("Logi Capture" in this case)
  3. Click "Remember this decision" and click "Allow"
  4. Leave page and visit it again. Firefox will use the wrong webcam, and I can't find a setting to make it choose the correct webcam.
See Also: → 1129254

There's a lot of confusion here, all from an incorrect interpretation of ☐ Remember this decision (based on what it does).

The "decision" is not the device choice. Firefox cannot remember which device you chose for next time, because that's the job of the site in the web model. Well-behaved sites will remember the device you chose every time whether you check this box or not.

The "decision" is whether to ask permission every time for this device category (all cameras or all microphones). ☑ = no more prompts = Chrome.

Untangling multiple issues from this confusion:

  1. Site bugs (comment 0, comment 1, comment 11) — Well-behaved sites remember your choice even if you leave ☐ blank, as well as offer a ⚙️ settings page where you can switch devices. Fix your sites. Not a Firefox bug.
  2. Pilot error — comment 9 works for me with https://jsfiddle.net/jib1/e89jp3hv. I suspect a bug in the example's cookie parsing.
  3. Mismatched expectation — comment 10 expected Firefox to persist permission per-device. This is a great idea, but would be a new feature. Firefox is already the only browser to implement per-device permission, but only if you leave ☐ blank. It's all or nothing today; a tradeoff.

Options I see:

  1. Close this as works as intended
  2. Focus this issue on clarifying the UX. E.g. ☑ Ask every time (inverting the logic) though this still doesn't clear up one vs. all.
  3. Focus this issue on requesting that Firefox implement persistent per-device permission, either instead of or in addition to persist all (Chrome).
See Also: → 1713292

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #13)

Options I see:

  1. Close this as works as intended

The intention is for the user to understand the decision they make in response to the prompt, but users are not understanding, so option 2 at least would be addressing a defect.
"When asking the user’s permission, the User Agent MUST disclose whether permission will be granted only to the device chosen, or to all devices of that kind."

  1. Focus this issue on clarifying the UX. E.g. ☑ Ask every time (inverting the logic) though this still doesn't clear up one vs. all.

This may be the issue in duplicates bug 1315890, bug 1410421, bug 1598359, and bug 1627744.

A solution could be as simple as changing the label on the check box. Options might include:

  • Apply this permission to all microphone/camera devices
  • Apply Block/Allow to all microphone devices

Or perhaps multiple buttons or radio-buttons, instead of a single checkbox:

  • Allow
  • Block
  • Always allow all microphone devices
  • Always block
  1. Focus this issue on requesting that Firefox implement persistent per-device permission, either instead of or in addition to persist all (Chrome).

Yes, perhaps, or
4. Remember the choice made for each unique ordered list of "preferred" speakers, and provide a way to change or reset the decisions, and fix 2, or
5. Fix bug 1713292 and fix 2.

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:pbz, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(pbz)
Flags: needinfo?(pbz)
Duplicate of this bug: 1889003

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

:pbz, could you consider increasing the severity of this bug to S2?

For more information, please visit BugBot documentation.

Flags: needinfo?(pbz)

Clarifying the status quo by updating the checkbox string would be a good first step.
Perhaps something like "Remember this choice for all <cameras|microphones|speakers>". Though that could(?) suggest that if you don't select the checkbox that you're granting a persistent allow for that specific device. Jeff, do you have a suggestion on how we could improve the prompt language to not suggest to users that they're granting permission for a specific device only, but for all devices of that category (e.g. all cameras)? See comment 13 for a good summary.

As a next step I'm curious how much we'd increase friction if we supported per-device persistent grants. This seems acceptable to me. For the implementation: We already support per-device temporary permissions so introducing persistent ones seems feasible. To keep the permission management UI simple we could collapse multiple per-device permissions of the same device type into one and clear all of them when the user clears the entry.

Flags: needinfo?(pbz) → needinfo?(jpfaller)

My proposal would be to change the 1st string to:

Allow <url> to use this <device category>?
<device name>

and then change the text box to

Allow all <plural device category>

Flags: needinfo?(jpfaller)

(In reply to Jeff Pfaller from comment #19)

My proposal would be to change the 1st string to:

Allow <url> to use this <device category>?
<device name>

and then change the text box to

Allow all <plural device category>

Thanks for the great suggestion Jeff! For the checkbox I'm concerned that the string doesn't really convey that it's a persistent choice. What do you think?

Flags: needinfo?(jpfaller)

How about "Always allow all <plural device category>"

Flags: needinfo?(jpfaller)

Works for me! Jib, I think this copy change would be a strict improvement. At least we would describe the current behavior better. Do you agree?

Flags: needinfo?(jib)

Did we mean to s/your/this/? Also note that the most common case is to prompt for both camera and microphone. So that would presumably look like:

Allow jan-ivar.github.io to use your camera and microphone?

📹 FaceTime HD Camera
🎙️ MacBook Pro Microphone

☐ Always allow all cameras and microphones

Do I have that right?

Flags: needinfo?(jib)

Alas, I just remembered: The ☐ Remember this decision also needs to work for the Block action, i.e. the ✅ makes it a persistent block instead of just a temporary one.

How would we handle that?

You're right.. I completely missed that somehow. Jeff, can I request your expertise again?
Something like "Remember for all cameras and microphones" / "Remember for all cameras?" / ...

Flags: needinfo?(jpfaller)

That would work for me at least.

Yes, I think that works!.

Remember for all <plural device category>

Flags: needinfo?(jpfaller)
You need to log in before you can comment on or make changes to this bug.