WebRTC team has been tracking this model discussion from the very beginning. The current model is an intermediate step and we still have to solve this permission problem in general for browser and non-trusted apps. There was discussion of using shaders to help augment the OS preview for example, or to support a magic button. Lucas.
On Jun 5, 2012, at 7:53 AM, Justin Lebar wrote: >>> 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
