>> Have you spoken with the WebRTC folks about this? > > Now I have, but only briefly (but Randall posted earlier in this thread) . > Without really knowing enough about the webrtc security model I assume that > we follow the webrtc security model for webpages and untrusted web apps, and > follow the permissions model for trusted and untrusted apps to provide any > additional capabilities that are not included in the webrtc api (such as the > camera control API?)
>> So is the proposed restriction for b2g a temporary one which will >> change once WebRTC lands and we can adopt its security model (whatever >> that is)? > > Yes that was my thought. I assume that we would still retain seperate > permission for trusted and certified apps, as maybe you would grant more > fine-grained access to control the camera that might not be possible in the > webrtc model. There's a lot of assuming going on here; it sounds to me like you haven't had a chance to learn all of the relevant information about WebRTC. Does it make sense to finalize this security discussion before we're sure we have the right model? -Justin >> On Mon, Jun 4, 2012 at 1:36 AM, Paul Theriault<[email protected]> >> wrote: >>> >>> ("Final" proposal, please reply to [email protected] by COB >>> June >>> 4 with any further comments ) >>> >>> Unless there are any further comments, I believe the previous proposal >>> still >>> remain accurate. Note that in the absence of a magic button or similar >>> implementation in B2G, realtime preview/stream will only be available to >>> trusted and certified apps. >>> >>> To summarize the model below: >>> Web Pages: Explicit (OS mediated only, e.g. web activities, trusted UI, >>> magic button etc) >>> Untrusted: Explicit (OS mediated only, e.g. web activities, trusted UI, >>> magic button etc) >>> Trusted: Explicit (some limitations) >>> Certified: Implicit, no limitations >>> >>> Note that following a discussion at the San Diego B2G work week, I have >>> added the status icon mitigation to the certified case as well. While >>> this >>> might be undesirable for a "take photos if my phone is stolen" app, the >>> consensus was that consistent UI and mitigation of privacy risk was more >>> important than the small risk that this feature might reduce the >>> effectiveness of this type of app. >>> >>> ------------- >>> >>> >>> Name of API: Camera API >>> >>> References: >>> >>> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html >>> ("Section 2 Scenarios") are use case scenarios from the media capture >>> task >>> that is creating getUserMedia() which is what this API is based on. >>> >>> Brief purpose of API: Let content take photos and capture video and/or >>> audio >>> >>> Use cases: have been moved to their respective app categories >>> >>> Inherent threats: Steal or spy on user video/audio >>> Threat severity: High per >>> https://wiki.mozilla.org/Security_Severity_Ratings >>> >>> == Regular web content (unauthenticated) == >>> Use cases: >>> *App allows user to take a picture for a profile >>> *App allows user to take a picture and record an audio clip >>> *App allows user to record a video with audio to send to someone else >>> *App allows user to record an audio clip to send to someone else >>> *App allows the user to start a podcast, open other tabs/apps while the >>> recording continues (to look up and comment on >>> information, etc) and then comes back to the tab/original app to finish >>> the >>> podcast. Note: the user may continue to record while opening or >>> switching >>> to other tabs/apps >>> *App allows foreground photo sharing with realtime preview and special >>> effects. Needs live video stream and the ability >>> to manipulate the stream on the fly (this one might be a bit of a >>> stretch; >>> can work with the magic button or WebGL shader approach but requires some >>> more research) >>> >>> Authorization model for normal content: user-mediated OS UI >>> Authorization model installed content: user-mediated OS UI >>> Potential mitigations: App can launch a user-mediated viewfinder UI take >>> a >>> picture, record the video, or use the >>> camera/mic feed which user approves prior to it being provided to the >>> content. Uses<video> >>> tag (or some such) and is validated to have a non-collapsed extent, not >>> be >>> off-screen, not be (mostly) obscured by other >>> content. Additionally (contingent upon addressing UX and clickjacking >>> concerns), we could potentially use a "magic button" rendered by OS with >>> the >>> app context. There is a persistent recording indicator (blinking red >>> light?). App can continuing recording if it loses focus. Only top level >>> content can request access. There is no "always allow" option in this >>> app >>> category. >>> TBD: Appropriate limitations to device fingerprinting >>> >>> == Trusted (authenticated by publisher) == >>> Use cases: >>> *App allows users to record video from multiple webcams >>> *App allows video monitoring such as a baby monitor or security camera >>> that >>> can run for extended periods of time >>> >>> Authorization model: explicit >>> Potential mitigations: Prompt for camera access, app then retains access >>> to >>> video/audio stream until exit. There is a persistent recording indicator. >>> >>> App can continuing recording if it loses focus. >>> >>> == Certified (vouched for by trusted 3rd party) == >>> Use cases: >>> * Main Camera app >>> >>> * App can continuing recording if it loses focus. >>> >>> Authorization model: implicit >>> Potential mitigations: >>> Settings manager could enumerate which apps have implicit access to >>> camera. >>> There is a persistent recording indicator. >>> >>> Notes: >>> *Trusted& certified apps have access to the constraints/capabilities >>> API >>> >>> >>> >>> On 4/21/12 6:24 AM, Lucas Adamski wrote: >>>> >>>> I've attempted to update the proposal per all of the recent discussion. >>>> I've almost certainly missed something so please let me know what. >>>> >>>> The controversial part of this proposal may be not allowing persistent >>>> access to the camera from unauthenticated content, only from trusted >>>> apps. >>>> The reason is that besides the UI challenges we are looking at, regular >>>> content has very different security properties from authenticated apps >>>> and >>>> allowing full persisted access to camera from an HTTP website has >>>> troubling >>>> consequences in a mobile computing environment. >>>> >>>> Name of API: Camera API >>>> >>>> References: >>>> >>>> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html >>>> ("Section 2 Scenarios") are use case >>>> scenarios from the media capture task that is creating getUserMedia() >>>> which is what this API is based on. >>>> >>>> Brief purpose of API: Let content take photos and capture video and/or >>>> audio >>>> >>>> Use cases: have been moved to their respective app categories >>>> >>>> Inherent threats: Steal or spy on user video/audio >>>> Threat severity: High per >>>> https://wiki.mozilla.org/Security_Severity_Ratings >>>> >>>> == Regular web content (unauthenticated) == >>>> Use cases: >>>> *App allows user to take a picture for a profile >>>> *App allows user to take a picture and record an audio clip >>>> *App allows user to record a video with audio to send to someone else >>>> *App allows user to record an audio clip to send to someone else >>>> *App allows the user to start a podcast, open other tabs/apps while the >>>> recording continues (to look up and comment on >>>> information, etc) and then comes back to the tab/original app to finish >>>> the podcast. Note: the user may continue to >>>> record while opening or switching to other tabs/apps >>>> *App allows foreground photo sharing with realtime preview and special >>>> effects. Needs live video stream and the ability >>>> to manipulate the stream on the fly (this one might be a bit of a >>>> stretch; >>>> can work with the magic button or WebGL shader approach but requires >>>> some >>>> more research) >>>> >>>> Authorization model for normal content: user-mediated OS UI >>>> Authorization model installed content: user-mediated OS UI >>>> Potential mitigations: App can launch a user-mediated viewfinder UI take >>>> a >>>> picture, record the video, or use the >>>> camera/mic feed which user approves prior to it being provided to the >>>> content. Uses<video> >>>> tag (or some such) and is validated to have a non-collapsed extent, not >>>> be >>>> off-screen, not be (mostly) obscured by other >>>> content. Additionally (contingent upon addressing UX and clickjacking >>>> concerns), we could potentially use a "magic button" rendered by OS with >>>> the >>>> app context. There is a persistent recording indicator (blinking red >>>> light?). App can continuing recording if it loses focus. Only top >>>> level >>>> content can request access. There is no "always allow" option in this >>>> app >>>> category. >>>> TBD: Appropriate limitations to device fingerprinting >>>> >>>> == Trusted (authenticated by publisher) == >>>> Use cases: >>>> *App allows users to record video from multiple webcams >>>> *App allows video monitoring such as a baby monitor or security camera >>>> that can run for extended periods of time >>>> >>>> Authorization model: explicit (at install, at runtime, with "always >>>> allow/deny" option) >>>> Potential mitigations: Prompt for camera access, app then retains access >>>> to video/audio stream until exit. There is a persistent recording >>>> indicator >>>> (blinking red light?) App can continuing recording if it loses focus. >>>> >>>> == Certified (vouched for by trusted 3rd party) == >>>> Use cases: >>>> *App starts recording video and/or audio in the background on some >>>> signal >>>> that the device has been stolen. Recordings >>>> are uploaded. >>>> >>>> Authorization model: implicit >>>> Potential mitigations: Settings manager could enumerate which apps have >>>> implicit access to camera. >>>> >>>> Notes: >>>> *Trusted& certified apps have access to the constraints/capabilities >>>> API >>>> >>>> >>>> >>>> On Apr 10, 2012, at 5:49 PM, Lucas Adamski wrote: >>>> >>>>> This discussion will be a bit more involved I think but I'd like to >>>>> wrap >>>>> this up by Tue 17th EOD PDT. >>>>> >>>>> Name of API: Camera API >>>>> >>>>> References: >>>>> >>>>> >>>>> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html >>>>> ("Section 2 Scenarios") are use case >>>>> scenarios from the media capture task that is creating getUserMedia() >>>>> which is what this API is based on. >>>>> >>>>> Brief purpose of API: Let content take photos and capture video and/or >>>>> audio >>>>> >>>>> Use cases are the same for all content (regular web, trusted, >>>>> certified): >>>>> *App allows user to take a picture for a profile >>>>> *App allows user to take a picture and record an audio clip >>>>> *App allows user to record a video with audio to send to someone else >>>>> *App allows user to record an audio clip to send to someone else >>>>> *App allows users to record video from multiple webcams [JStraus: How >>>>> is >>>>> this using the Camera API?] >>>>> *App allows foreground photo sharing with realtime preview and special >>>>> effects. Needs live video stream and the ability >>>>> to manipulate the stream on the fly. >>>>> *App allows video monitoring such as a baby monitor or security camera >>>>> that can run for extended periods of time [Lucas: >>>>> Is this really a universal use case or an installed-only use case?] >>>>> *App allows the user to start a podcast, open other tabs/apps while the >>>>> recording continues (to look up and comment on >>>>> information, etc) and then comes back to the tab/original app to finish >>>>> the podcast. Note: the user may continue to >>>>> record while opening or switching to other tabs/apps [Lucas: Is this >>>>> really a universal use case or an installed-only >>>>> use case?] >>>>> *App starts recording video and/or audio in the background on some >>>>> signal >>>>> that the device has been stolen. Recordings >>>>> are uploaded. [Lucas: Is this really a universal use case or a >>>>> certified-only use case?] >>>>> >>>>> Inherent threats: Steal or spy on user video/audio >>>>> Threat severity: High per >>>>> https://wiki.mozilla.org/Security_Severity_Ratings >>>>> >>>>> == Regular web content (unauthenticated) == >>>>> Authorization model for normal content: explicit runtime >>>>> Authorization model installed content: explicit runtime >>>>> Potential mitigations: Prompt user to take a picture, record video, >>>>> record an audio clip, or use the camera feed or >>>>> microphone feed. If permitted, agent mediated viewfinder UI is >>>>> launched >>>>> to take a picture, record the video, or use the >>>>> camera/mic feed which user approves prior to it being provided to the >>>>> content. A/V stream only accessible while app has >>>>> focus. Only top level content can request access. >>>>> TBD: what gets shown when recording audio only? >>>>> TBD: Is there a visible indicator that the camera and/or microphone is >>>>> active (because this is currently mandated by the >>>>> getUserMedia spec)? Is this indicator visible even if the browser >>>>> window >>>>> is partially or completed obscured? What if >>>>> there is no browser window (like for Apps and B2G?) >>>>> TBD: Appropriate limitations to device fingerprinting >>>>> TBD: Should recording stop when content loses focus? If it doesn't, >>>>> how >>>>> do we resolve concurrent audio/video feed >>>>> requests? How does the user determine which tabs are recording? >>>>> >>>>> == Trusted (authenticated by publisher) == >>>>> Authorization model: explicit [upfront|runtime]?? >>>>> Potential mitigations: Prompt for camera access, app then retains >>>>> access >>>>> to video/audio stream until exit. Uses<video> >>>>> tag (or some such) and is validated to have a non-collapsed extent, not >>>>> be off-screen, not be (mostly) obscured by other >>>>> content. Note: Video stream may need to be accessible while focus is >>>>> given to another app >>>>> >>>>> == Certified (vouched for by trusted 3rd party) == >>>>> Authorization model: implicit >>>>> Potential mitigations: Settings manager could enumerate which apps have >>>>> implicit access to camera. >>>> >>>> _______________________________________________ >>>> dev-b2g mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-b2g >>> >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
