Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WebRTC: User Security & Privacy


Published on

A review of the security and privacy concerns for WebRTC implementors.

Published in: Technology, News & Politics
  • Be the first to comment

  • Be the first to like this

WebRTC: User Security & Privacy

  1. 1. WebRTC: User Security & Privacy W3C TPAC Anant Narayanan, Mozilla October 31, 2011 Tuesday, November 1, 11
  2. 2. Overview ✤ Placement in standard ✤ Behavior on getUserMedia() ✤ Immediate & long-term permissions ✤ Permissions & user model ✤ User privacy indicators ✤ Summary Tuesday, November 1, 11
  3. 3. Placement in Standard ✤ We currently do not specify what happens when getUserMedia is called with regards to asking user permission ✤ Such a specification may not fit in the standard as user agents vary wildly ✤ We can, however, come up with a set of “recommended guidelines” for major browser vendors to adopt (a specific type of a user agent) ✤ Open question: Is the W3C spec the right place to put this? Tuesday, November 1, 11
  4. 4. User Permission ✤ getUserMedia() is asynchronous to allow the UA to ask the user permission, and choose exactly what media gets shared: ✤ ✤ Audio from microphone(s) ✤ ✤ Video from webcam(s) Transmit A/V from local media files Give user complete control over what is transmitted, irrespective of what the web application asked for Tuesday, November 1, 11
  5. 5. Early Mockup Tuesday, November 1, 11
  6. 6. Details... ✤ Firefox “Doorhanger”, distinguishes a browser request from regular web content and is a trusted space ✤ ✤ If application asked for both audio and video, default to both but allow user override (not depicted) ✤ ✤ Somewhat harder to spoof than an infobar (not really, just 2px!) Front/Back camera preferences better handled as “hints”? A list of granted permissions is always available and revocable from a “preferences” pane Tuesday, November 1, 11
  7. 7. Immediate & long-term ✤ What is the time period for which the user grants access? ✤ Default is immediate (one-time only), user may explicitly choose “Always allow to access A/V” ✤ Should the web-application be able to specify what type of access it needs? ✤ How are these permissions persisted? Tuesday, November 1, 11
  8. 8. Permissions & Sessions ✤ Initial proposal was to tie a permission grant to a time-frame and domain name ✤ Feedback from web developers: ✤ Permissions should actually be tied to a user session, not just domain. Until everyone uses BrowserID, this means cookie jar? ✤ More realistically, we could allow the application itself to “revoke” a granted permission if it detects a change in user session? Tuesday, November 1, 11
  9. 9. After permission is granted... Tuesday, November 1, 11
  10. 10. Summary ✤ Mostly a set of UI and interaction guidelines, may not be applicable to all user agents (or to varying degrees) ✤ Where do we write this stuff down? ✤ Other open questions: ✤ What happens if devices are already in use by another application? ✤ What is the interaction for an incoming call? Tuesday, November 1, 11