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

Status: RESOLVED FIXED

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

Description

[Maire Reavy [:mreavy]]

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.

Comment 1

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup: Revoking camera/microphone access once granted

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.

Comment 2

[Eric Rescorla (:ekr)]

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.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Non-blocking per privacy meeting, but definitely wanted.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Attachment: backend for getUserMedia:revoke

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 6

[Dão Gottwald [: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?

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 8

[Dão Gottwald [:dao]]

In case you're referring to the handleRequest function in webrtcUI.jsm, this would work either way.

According to <https://developer.mozilla.org/en-US/docs/Inner_and_outer_windows#Nested_windows>, the answer is no.

Comment 9

[Anant Narayanan [:anant]]

Comment on attachment 697908 [details] [diff] [review]
backend for getUserMedia:revoke

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

Looks good!

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/88b4a6217997

Comment 11

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/88b4a6217997

Comment 12

[Florian Quèze [:florian]]

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.