Open Bug 1333186 Opened 8 years ago Updated 2 years ago

Cannot deny camera/microphone sharing permissions individually

Categories

(Core :: WebRTC, defect, P3)

Product:
Core
Component:
WebRTC
Version:
49 Branch
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr45 --- unaffected
firefox51 --- wontfix
firefox52 --- fix-optional
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 --- fix-optional
firefox55 --- fix-optional

People

(Reporter: pawandubey, Unassigned)

References

Details

(Keywords: privacy, ux-control, ux-discovery)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161209094039 Steps to reproduce: 1) Go to Facebook chat (or messenger.com) 2) Call a friend 3) Try to deny the permission to use the camera in the popup Actual results: There is no option to deny the permission for the camera individually. The default webcam is selected. Expected results: In Firefox version 47.0 (the version I upgraded from), there used to be an option to selectively deny permissions to the camera while still being able to use the microphone for a voice call. This is no longer the case (on version 50.1.0). This is a potential privacy issue as the camera stays enabled (the webcam light is on the whole time) even if I "face-mute" during the call. I am using Firefox version 50.1.0 on Ubuntu 14.04.4.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Blocks: 802326
status-firefox51: --- → wontfix
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox-esr45: --- → unaffected
Component: Untriaged → WebRTC
Keywords: regression, ux-control, ux-discovery
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All
Version: 50 Branch → 49 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: privacy
Jan-Ivar -- I'm aware of the working group decision here that makes this bug invalid, but does it make sense to provide black in place of a camera to allow the call to go through? Would that be in violation of the spec or does the spec leave us that wiggle room? This wouldn't be any different than the user installing a fake camera source and selecting that. (This use case does highlight the potential privacy downsides of the wg decision to do "all or nothing" if we don't do something in the implementation to mitigate the situation.) Thanks.
Flags: needinfo?(jib)
I don't know what the reasoning behind the decision to make this the behavior was, but I don't understand how this is the expected behavior. For example there are separate options for a voice call and video call on messenger.com, but even if I select the voice call option, Firefox forces me to grant it access to the default camera. I have been using Firefox for over 10 years at this point and this bug surprises me because I have not had any privacy related issues with Firefox till now. I am tech savvy and can work around this issue but the fact is that the majority of the population won't know/bother to spoof the camera option. This for me is a huge privacy concern. I don't think this is a limitation of the Messenger API since I was able to connect to voice calls after denying it permission to my camera on Firefox 47. I would strongly suggest the working committee to reconsider their decision on this.
The feature we had in 47 wasn't a great solution. Even though it tended to work with a lot of web sites, it broke others, because they expected (quite rightly according to the spec) to find both a video and audio track in the resulting stream from a successful gUM call, and then the call didn't work. (In reply to pawandubey from comment #0) > This is a potential privacy issue as the camera stays enabled (the webcam > light is on the whole time) even if I "face-mute" during the call. This is the real issue. We should turn off the hardware light on mute/disabled (bug 1299515), which the spec now allows us to do in a manner that respects privacy (Bug 1333468). We should up-prioritize that work IMHO. As to what we can do to bring back user control, note that the spec defines both "disabled", which is something the website can alter at any time, and "mute", which is something only the user controls through the browser, giving them the safety of knowing the site can't turn on their camera or mic (audio/video is silent/black unless mute == false && enabled == true). Once we have that, we could explore ways of implementing a privacy shield, since the spec clearly allows that with the "mute" feature. E.g. joining a call face-muted in a way that a website could not override. It's all UX at that point. However, I would caution against attaching too many features to the permission prompt. It's easy to think of it as the control panel for starting an audio-video call, but this model falls down when we consider that it actually disappears if the user checks "Remember this decision". There are also cases where the permission prompt gets in the way, like when websites implement their own camera or mic selector UX.
Flags: needinfo?(jib)
The gUM spec allows any media source to be used, and we could provide a privacy stream. When implementing a we will need to think carefully about the interaction with remembered gUM permissions. From the Media Capture and Streams spec, section 10.2.1, getUserMedia, item 6. [1] "User Agents are encouraged to default to using the user's primary or system default camera and/or microphone (when possible) to generate the media stream. User Agents MAY allow users to use any media source, including pre-recorded media files." [1] https://www.w3.org/TR/mediacapture-streams/#dom-mediadevices-getusermedia
Making this a P2 based on bug 1299515. Feel free to upgrade as necessary.
Rank: 25
Priority: -- → P2
Too late for a fix for 53, as we are in the last week of the 53 beta cycle.
status-firefox53: affected → wontfix
Maire, is a fix for this in the 54 timeframe likely? We should just mark it fix-optional or wontfix if not.
Flags: needinfo?(mreavy)
I have a much better understanding of the problem now, and this is actually not a regression. We updated our code to match the spec which resulted in a change in behavior. So I'm removing the regression keyword. We will do more work in this area, in particular in bug 1299515, but *this* particular bug is "fix optional" at most for the foreseeable future IMO. See Comment 3 from Jan-Ivar for more details.
Flags: needinfo?(mreavy)
Keywords: regression
(In reply to Maire Reavy [:mreavy] On PTO, back April 18th from comment #8) > I have a much better understanding of the problem now, and this is actually > not a regression. We updated our code to match the spec which resulted in a > change in behavior. So I'm removing the regression keyword. We will do > more work in this area, in particular in bug 1299515, but *this* particular > bug is "fix optional" at most for the foreseeable future IMO. See Comment 3 > from Jan-Ivar for more details. Thanks for the explanation! Marking appropriately, then.
status-firefox54: affected → fix-optional
status-firefox55: --- → fix-optional
status-firefox-esr52: --- → wontfix
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3

This is a really unintuitive interface.
Any good WebRTC application will fall back to audio-only if the camera is not available, but in order to permit microphone but not camera you currently need to:

  1. Deny all permissions, remember selection.
  2. Open the WebRTC panel in the address bar and delete the "Blocked" microphone permission.
  3. Refresh the page.
  4. Allow the microphone permission when prompted again.

That's an insane workaround for what should be an extremely common use-case of "I want to join a meeting with audio only".

Since it is possible (though difficult) to manually permit Microphone permission while blocking Camera permissions, there's no reason why the UI shouldn't have that option readily available to begin with.

Severity: normal → S3

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

The feature we had in 47 wasn't a great solution. Even though it tended to
work with a lot of web sites, it broke others, because they expected (quite
rightly according to the spec) to find both a video and audio track in the
resulting stream from a successful gUM call, and then the call didn't work.

What do the sites that broke with this Firefox 47 solution do if the user doesn't have a camera attached to their system at all? In that case, Firefox can only ask for permission to use the microphone, which it does.

To provide another use case, I'm totally blind and the controls for face muting on some sites (e.g. Jitsi Meet) are very confusing for a screen reader user. Granted, that's an issue Jitsi should fix. However, it would have been ideal if I could have been assured of my (visual) privacy by being able to deny access to the camera, in which case Jitsi Meet happily accepts only the microphone. Instead, I was unwittingly streaming my camera when I thought I wasn't.

You need to log in before you can comment on or make changes to this bug.