Closed Bug 805632 Opened 9 years ago Closed 7 years ago

getUserMedia: Add an easy way within Firefox to shut down camera/microphone access after access has been granted


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

Not set





(Reporter: mreavy, Assigned: jesup)



(Keywords: sec-want, Whiteboard: [getUserMedia], [blocking-gum-])


(2 files)

We want the user to be able to easily shut down camera/microphone access within Firefox after he/she has granted it.  This is needed in order to pref getUserMedia on by default.
Whiteboard: [getUserMedia], [blocking-gum+]
If a user has granted a site access to their webcam or microphone, they need to be able to revoke this permission easily.  This is both to ensure privacy and because such streams could interfere with other applications.

Currently, in-website notifications of streaming data do not show a notification outside of the streaming tab.  That tab is the end of the site's jurisdiction unless it is using an add-on or plug-in.  Positively, this means that sites can't easily annoy or trick user outside of the content area, but it also does not allow any notification of streaming outside of the content area.  This can be a problem particularly when a user has multiple tabs open (as any Firefox users trying to find the one tab playing music can attest).

For this reason, let’s display the streaming notification not only display in the tab's URL bar, as do other granted permissions, but also on the tab itself once straming access is granted.  If a user wishes to shut down their streaming camera or microphone, they can do so by clicking the icon in the URL bar or on the tab: both would bring up the same menu with the same options.
I'm not sure this is quite what we need.

Remember that there are two kinds of permission grants, one short-term and one
long-term. Fundamentally, if I've given a short-term permission to a site to
access my camera, I can revoke it just by closing the tab (tabs) that's using it.
Of much more serious concern is that I have granted long-term access to a
site (e.g., Hangouts) and now I want to revoke that, whether hangouts is using
the camera/mic or not. This means we need some control that's not tied to
active use of the device. It also suggests that we need some way to display
the existing long-term grants.
Non-blocking per privacy meeting, but definitely wanted.
Assignee: nobody → rjesup
Whiteboard: [getUserMedia], [blocking-gum+] → [getUserMedia], [blocking-gum-]
Comment on attachment 697908 [details] [diff] [review]
backend for getUserMedia:revoke

Dao: does this API seem reasonable?

getUserMedia:revoke with the windowID as the argument.

I did a quick hack test (made the dropdown send revoke) and it works.
Attachment #697908 - Flags: review?(anant)
Attachment #697908 - Flags: feedback?(dao)
Comment on attachment 697908 [details] [diff] [review]
backend for getUserMedia:revoke

The API seems reasonable to me. Is the outer window ID shared by all possible sub documents in any given content document?
Attachment #697908 - Flags: feedback?(dao) → feedback+
These are the same windowIDs I give you in the array you use to create the dropdown list, so I believe the answer is yes
In case you're referring to the handleRequest function in webrtcUI.jsm, this would work either way.

According to <>, the answer is no.
Comment on attachment 697908 [details] [diff] [review]
backend for getUserMedia:revoke

Review of attachment 697908 [details] [diff] [review]:

Looks good!
Attachment #697908 - Flags: review?(anant) → review+
Whiteboard: [getUserMedia], [blocking-gum-] → [getUserMedia], [blocking-gum-] [leave-open]
Blocks: 795024
Keywords: sec-want
I'm handling the UI changes in bug 885796, so I think this bug which added the back-end can be resolved with a target milestone matching the check-in in comment 11.
Blocks: 885796
Closed: 7 years ago
Component: General → WebRTC: Audio/Video
OS: Linux → All
Product: Firefox → Core
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [getUserMedia], [blocking-gum-] [leave-open] → [getUserMedia], [blocking-gum-]
Target Milestone: --- → mozilla20
You need to log in before you can comment on or make changes to this bug.