View source for Security/Discussions/WebRTC

==Orig email (from Randall)==
Security for WebRTC is (with no surprise) becoming a real rats-nest for some of the use-cases, such as screensharing ala WebEx, remote assistance ala Windows or VNC, ongoing permission ala Skype, etc. (See roc's recent blog posting on screen/browser-window bits access triggered by discussion of WebEx-like cases for webrtc.)       
      
See  http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-00.txt  and
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06
      
A number of the use-cases might be easier to handle by leveraging the webapp security model (or give us a way to let the user decide semi-rationally to extend more trust to the apps in this case). (Normally the threat model is typical JS - we assume the app is malicious.) 
      
* Where does the research into or current state of installed-webapp security stand?  
* What is the model being planned/proposed/noodled?  
* What are the UI implications?  
* When is it likely to be available for us to leverage, or are there some workarounds we can use in the meantime?
==Info below from Michael Hanson==
* My notes on the "activities" API, which proposes extending some new cross-domain capabilities to installed apps: http://etherpad.mozilla.com:9000/p5sbmv56Fh 
* Notes from a joint security review of Activities and F1 (which uses this API for "share"): https://wiki.mozilla.org/Security/Reviews/OWA-F1 
* roc's recent posting on permissions: http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html 
===And, summarizing recent conversations with Alex, Jonas, and Fabrice: ===
We propose that there are three default permissions buckets: "All Web Content", "Installed Web App", "Installed Web App from Trusted Source". This means that we keep both a list of installed apps (keyed on domain), and a optional "installed-from" URL for each of these apps. The set of "trusted sources" would be client-resident and user-customizable. The per-domain permissions would still exist, of course.
The "installation manifest" for the domain would include the maximal list of capabilities the domain would ever request. This is an upper bound on the capabilities of the site - but the user is not required to grant permissions at install time. Changes to this capabilities list would require an explicit confirmation from the user (through an "app install" sort of flow). 
Some APIs would be granted automatically in certain buckets - i.e. if you're an installed app, you get 50MB (or more?) of appcache storage for free. 
Some APIs would be allowed only in certain buckets, i.e. "only in installed app from trusted source". (open question: should "trusted source" be orthogonal to "installed", i.e. if I navigate to a domain that is "trusted" can normal web content invoke new APIs? or is a high-ceremony "installation" step required?) 

The UI implications would be (at least): 
* New top-level rows in about:permissions 
* A list of "trusted app sources" somewhere 
* New rows in per-domain about:permissions 
* Prompting/notification of capabilities at install time (with acceptance by user, optionally) 
* Prompting of changes to capabilities later than install time 
* Possible improvements to infobar permissions UI 
== What we want to enable ==
* Webcam access and Microphone access
* Query and find out what webcams and microphones you have, w/o asking for permission
** Fingerprinting risk
== Chrome vs Content UI ==
* Should content be able to enable/disable camera and microphone, or should this access be controled only via Chrome?
* Do we need a separate chrome UI for enabling a website to control camera and microphone via its own UI, or do we have a UI for controlling the camera/microphone that avoids "permissions" prompts.
* Clickjacking with in-content UI (see Flash experience)
* People might not understand that microphone/camera data is being sent to a third party ("do you want to allow this *website* to have access to your camera/microphone").
== Other UI stuff ==
* Web pages that are in background tabs/windows still need camera/microphone access.
** should this turn off with tab focus loss?
** we do this for DeviceMotion, for example
* First-party vs third-party access
** Can an embedded iframe request permission? What would the UI look like? Does the user understand what we are asking them to decide in these scenerios?
* Firefox UI must always indicate that camera and/or microphone is active
** how to tell them wich tab is asking or using this?
* Emergency shut-off in UI, outside of all tabs?
* Preview in permission prompt
== Network security requirements ==
* Coffee shop / non-HTTPS / automatic permission grants danger
* Requiring HTTPS
== What to look at for threat model ==
* Android malware
* Flash
* probably want a pref to globally disable webcam/microphone
== Peer to Peer Aspects ==
* Now, we are connecting to peers that are not websites
== Action Item ==
* [boriss] needs to do some work on UI/API privacy/security issues for further discussion