Closed Bug 795024 Opened 12 years ago Closed 12 years ago

getUserMedia() privacy review

Categories

(mozilla.org :: Security Assurance: Review Request, task)

Product:
mozilla.org
Component:
Security Assurance: Review Request
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ekr, Assigned: mmc)

References

Details

Priority for your Team: High Timeframe for Completion: a week Goal: Deliver WebRTC functionality Business Objective: Other Party: Description: Firefox is adding functionality to support WebRTC, a joint effort between W3C [0] and IETF [1] to expose videoconferencing style functionality to Web applications in the browser. This work comprises two major sets of Web APIs: * Media Capture (aka getUserMedia()) which is responsible for access to local devices [camera and microphone]. * PeerConnection which is responsible for media negotiation between browsers as well as setting up a direct transport channel. The primary privacy issues here relate to Media Capture. The capabilities provided by PeerConnection can largely be emulated by existing Web APIs such as WebSockets, but access to the camera and microphone is new (see the security analysis [2] and security architecture [3]). The current model is that access to camera and microphone will be mediated by a permissions dialog in the browser. The bug for that is: https://bugzilla.mozilla.org/show_bug.cgi?id=729522 The immediate goal is to make sure that there's nothing grievously wrong with the proposed UI. The longer-term goal is to figure out how to do a better job in terms of giving the user visibility into the privacy properties of this feature. [0] http://www.w3.org/2011/04/webrtc/ [1] http://tools.ietf.org/wg/rtcweb/ [2] http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-security/ [3] http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-security-arch/
Assignee: nobody → mmc
Keywords: privacy-review-needed
Hi Eric, Can you confirm that this is landing prefed off by default, as you mentioned yesterday? Thanks, Monica
Adding Jesup and Mreavy to answer the question about landing.
(In reply to Monica Chew from comment #1) > Hi Eric, > > Can you confirm that this is landing prefed off by default, as you mentioned > yesterday? Almost certainly. I haven't called for consensus on this yet (which is why I say "almost"), but all the major players including the product lead (me) and the WebRTC module owner (Randell Jesup) feel it is safest and best to land this preffed off. Once people have had chance to digest this work, we may ask if it's ok to flip the pref for the media capture piece only to "on" later in the release cycle. But that would be another, separate review from this one.
Hello folks, If the feature is launching pref'ed off by default, I see no reason why it shouldn't land for privacy reasons. That being said, here are some of the problems that I see with this feature, according to latest mockups: - For a person who just wants to PTFB (http://www.ptfbpro.com) and stop interacting with the dialog, there's no obvious way to dismiss the dialog without changing state. The little "x" in the top right corner is small and not easy to discover. - Along the same lines, for the user that never wants to share camera/mic with a particular site, there's not a way to permanently dismiss the dialog. They could of course pref web RTC back off entirely, but that doesn't address users who want it on for some sites and never for others. - Although the spec (according to our chat, not that I have plowed through the RFCs) requires an exact origin match, I could easily see this feature being abused in a portal that hosts a lot of user-supplied content or widgets, making framebusting that much worse. - There's no obvious way to recover from mistakes. Once permission is granted to use the microphone and camera on a site, there's no way for a user to introspect the list of sites for which permission has been granted. This is especially damaging for cases where the user has decided, whether deliberately or through fat-fingering, to always allow use of camera and microphone. A dashboard would go a long way towards mitigating this. - Every user study I've encountered suggests that iconography on the URL bar is largely ignored or misunderstood by average users, so the notification icon is likely to be overlooked. Has any user research been done to see if this is the case? - (security issue, not a privacy one): Just because a feature is prefed off by default doesn't mean that the codepath isn't reachable. However since ekr and bsmith are the comsec people, and the security assurance people have been looking at this, I assume this is all right. - (process problem, not a technical one): The timeframe allowed for review allows for zero changes to be made before the merge deadline, given that the UI hasn't even been completed yet. I'd suggest the following as action items before landing this code: AI (mreavy): Verify that it is truly landing off prefed off by default. If not, this review becomes much more complicated, as we need to make sure that the privacy principle of "no surprises" is not violated. AI (mmc, boriss, ekr, other privacy friends, lco if we can get her): Go through the mocks or implementation and make sure that the Mozilla privacy principles are followed to the best of our ability. Larissa has done some really great work on security usability principles and could probably help us. AI (mreavy): Please create a human-friendly landing page, not a bugzilla bug, that pulls together all the relevant docs and mocks in one place, preferably with a high level description of the feature that is not an RFC. Does this sound reasonable? Thanks, Monica
Hi Monica -- I can verify that this feature and UI are landing preffed off by default. Can you provide an example of a "human-friendly landing page" for another feature so I/we have something to model? I'm sorry for the disconnect on this (and using a bug to show the UI). This is first time I've needed to pull a UI together for reviews. (I typically work on features deeper down in the code that don't have a UI or can make sure of an existing one that has already been approved.) Most importantly: do you see the current UI as one we can build on, or do you see it as needing to be completely redone? The reason I ask: if we feel the current UI is a good starting point but it needs additional pieces and more work before we can expose it (i.e. before we can pref it on by default), then landing what we have is a useful step forward. If instead, we likely need to go back to the drawing board on the UI design and not use the current UI as a foundation, then it seems to make no sense to land what we have (whether it is exposed or not). What do you think?
Hi Maire, No worries about the disconnect -- I'm new here and frankly not sure of the right procedure for requesting reviews either. As I mentioned to ekr last week, no one wants to block anything, and the most important thing at this point is to document privacy-related issues so that you or someone else are aware of them and can factor them into your future work. About the landing page: a wiki page would be fine, or if you've already got a roadmap page or similar that would be fine as well. Basically, the goal is to get someone who's new to web RTC to understand the feature in 5 minutes of reading. About the current UI: no one expects the UI to be right on the first iteration, and especially without user testing. You can't get serious feedback without a UI, so for that reason alone I think it's worth landing in its current state, asking your friends to enable the pref, and getting feedback. My impression from talking to ekr is that the first iteration is an imitation of the Chrome UI. Is that true? If so, a good first step might be digging up user feedback on Chrome's initial implementation. User testing is hard and there's no point in throwing away work that someone's already done. Thanks, Monica
Thanks for giving me the chance to review. Short answer is that I think the design is on the right track from a "usable privacy" standpoint. I just have a few more comments about design improvements in addition to Monica's: (In reply to Monica Chew from comment #4) > > - For a person who just wants to PTFB (http://www.ptfbpro.com) and stop > interacting with the dialog, there's no obvious way to dismiss the dialog > without changing state. The little "x" in the top right corner is small and > not easy to discover. I'm not super concerned about this use case. This is a FX pattern (so hopefully we've trained some people on how to do this) and since the pref is off by default, this isn't a privacy risk. > > - Along the same lines, for the user that never wants to share camera/mic > with a particular site, there's not a way to permanently dismiss the dialog. > They could of course pref web RTC back off entirely, but that doesn't > address users who want it on for some sites and never for others. I think this is an important point for protecting users from sketchy sites. I would suggest adding an option for this in the dropdown menu, if not a secondary button in the dialog itself (sometimes people don't realize that the button is also a dropdown when it's a combo button) > - There's no obvious way to recover from mistakes. Once permission is > granted to use the microphone and camera on a site, there's no way for a > user to introspect the list of sites for which permission has been granted. > This is especially damaging for cases where the user has decided, whether > deliberately or through fat-fingering, to always allow use of camera and > microphone. A dashboard would go a long way towards mitigating this. > I think this is also a great point, but one that we'll have to design a solution for in the larger context of site permissions. (Incidentally, there's About:Permissions, which is totally not discoverable) I suggest that the moment the user visits a site that he's given permanent permissions to, we could call his attention to the permissions bar so that he notices any permissions he's already granted to the site. It could be as simple as a light glow, flash, color change, etc. Just a little something to direct his eyes to the permissions bar. > - Every user study I've encountered suggests that iconography on the URL bar > is largely ignored or misunderstood by average users, so the notification > icon is likely to be overlooked. Has any user research been done to see if > this is the case? Yes, this is generally true, but in this case, the privacy risk of having an obscure icon is mitigated by the fact that this feature is OFF by default and we have a doorhanger that's displayed to ask for permission in most cases. So we do have mechanisms for helping the user understand what the icon means. The corner case that I can think of where this might be potentially privacy-invasive is when the user is sharing the computer/browser with someone else, and that someone else has already granted permanent access to the camera for a particular site. The first user might not notice the webRTC icon in the url bar and not realize that he's sharing his webcam or microphone. This case would be mitigated by the ability to check what you're sharing before you actually start sharing. Or by a subtle attention-grabbing animation or color change in the permissions bar when the site loads. The other comment I have about iconography is that we might want to use a different color other than grey or green for the icon. The grey icon doesn't strongly convey that the media device is "ON" or "Sharing". I get that the icon currently means something more like "permission granted" and not necessarily "on" (i.e. your camera could be broken but you've still granted a permission), but it seems to me that we should try to convey "ON-ness" as well. I think this is something worth discussing though. At the same time, using a green icon (such as the one proposed for the tab) is overloaded with meanings, since we've generally used green icons for "secure" iconography like the lock icon or the EV indicator (debatable whether this is successful, but that's a whole other story). We don't want the user to infer that sharing his video or audio is in any way safe or secure. Maybe a blue / glowing icon instead? Last couple of points: 1. While the phrase "Would you like to share your webcam with X?" is to the point, it doesn't explain why the user is being asked to share his camera. The user might be a little surprised about it and perceive the message as something initiated by the browser, not the site. What about something like "Site X is asking for permission to share your webcam?" (not perfect) instead? 2. It would be nice to still have some indication that a page has access to your camera or mic even when you're on a different tab. If we can't have two icons, would it be possible to just have a different glow to the tab? I realize this isn't a perfect solution. Ideally, we'd have an indicator that also gives the user the idea that the "glow" is related to access to the camera or mic. But this might be a good first step.
> > - Along the same lines, for the user that never wants to share camera/mic > > with a particular site, there's not a way to permanently dismiss the dialog. > > They could of course pref web RTC back off entirely, but that doesn't > > address users who want it on for some sites and never for others. > > I think this is an important point for protecting users from sketchy sites. > I would suggest adding an option for this in the dropdown menu, if not a > secondary button in the dialog itself (sometimes people don't realize that > the button is also a dropdown when it's a combo button) Absolutely we should add this option to the dropdown on the split button. > > - There's no obvious way to recover from mistakes. Once permission is > > granted to use the microphone and camera on a site, there's no way for a > > user to introspect the list of sites for which permission has been granted. > > This is especially damaging for cases where the user has decided, whether > > deliberately or through fat-fingering, to always allow use of camera and > > microphone. A dashboard would go a long way towards mitigating this. > > > I think this is also a great point, but one that we'll have to design a > solution for in the larger context of site permissions. (Incidentally, > there's About:Permissions, which is totally not discoverable) As Larissa points out, while we do have about:permissions now, there is indeed no very discoverable tool within Firefox to survey all permissions for sites. However, that's a larger project that would include permissions like geolocation and even password saving. For now, keeping the permission icon visible in both the URL bar and the tab of the page itself will give users a quick way to access options such as disabling access and doing so on each visit. > > > - Every user study I've encountered suggests that iconography on the URL bar > > is largely ignored or misunderstood by average users, so the notification > > icon is likely to be overlooked. Has any user research been done to see if > > this is the case? Hence the dropdown and the persistent icon in the URL bar. Incidentally, a number of concerns in this thread are regarding Firefox's standard permissions-asking model of a dropdown icon. While that feedback is welcome, making a change to Firefox's overall permissions dialog is not one that should happen around gUM in particular. This case should ask for a permission in the way users are accustomed to it, with a few extra bells and whistles to account for the more sensitive nature of data being transmitted - namely the tab indicators. > 1. While the phrase "Would you like to share your webcam with X?" is to the > point, it doesn't explain why the user is being asked to share his camera. > The user might be a little surprised about it and perceive the message as > something initiated by the browser, not the site. What about something like > "Site X is asking for permission to share your webcam?" (not perfect) > instead? While you raise an interesting point, I feel we should use the tone of voice that Firefox does consistently in requests for permissions. To drive home the point that the request is coming from a website, the arrow-panel is rooted in the URL bar itself - area associated with the site rather than with Firefox. > 2. It would be nice to still have some indication that a page has access to > your camera or mic even when you're on a different tab. If we can't have two > icons, would it be possible to just have a different glow to the tab? I > realize this isn't a perfect solution. Ideally, we'd have an indicator that > also gives the user the idea that the "glow" is related to access to the > camera or mic. But this might be a good first step. Actually, that's exactly the plan.
FYI -- The start of landing page for Desktop gUM's UI: https://wiki.mozilla.org/Media/getUserMedia/Desktop_gUM_UI
No reason this needs to be in v1 necessarily, but showing a picture of what the camera is currently seeing seems like a valuable affordance.
I sent out an email to Monica, Larissa, Boriss, Anant, Randell, and Ekr on October 22, summarizing our Oct 18 meeting about gUM privacy for version 1, but never copied the info from the meeting into this bug. Here is the summary of our decisions coming out of our gUM UI meeting Thursday (10/18 @ 12 pm Pacific). We want to enable the gUM (getUserMedia) feature by default as soon as possible. We asked ourselves: what is the minimum set of UI design changes necessary to do that? We decided the following are necessary: 1) Adding a "Never share with this site" option to the choices offered to users -> if we do this, we'll need to have a way for the user to undo this. (Bug 804611) UPDATE: We realized after the meeting that this was really part of the persistent permissions feature, which we explicitly said in the meeting was beyond the scope of version 1. 2) Adding an easy way within Firefox to shut down camera/microphone access after access has been granted (Bug 805632) UPDATE: The user can just close the tab or browse to another site (like Home) if the user needs to shut down access quickly. Since we aren't doing any long-term/persistent permissions (or persistent denial, which is the previous item on this list) for version 1, this becomes a very nice-to-have for version 1. 3) Adding a "glow" or color change to the tab or some visible indicator when the page in the tab has access to camera/microphone data (Bug 799417) We decided the following are nice-to-have: 1) Adding a pop up and warn or a growl (e.g. a pop up saying, "site X now has access to your camera") 2) Adding persistent permissions (e.g. an option saying "always share with this site, don't ask me again") . Even if we have the time to implement persistent permissions, we probably should not try to get them into v1 since adding this feature means considering, handling, and debugging lots of edge cases.
Since curtisk already removed privacy-review-needed, I'm going to go ahead and close this bug. I think Maire, jesup and ekr are doing a great job on the followup bugs and I will keep an eye on them, but from my POV this team has absorbed privacy-related concerns and bug has done it's job.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: 804611, 805632, 799417
You need to log in before you can comment on or make changes to this bug.