Replying only to dev-webapps, because I understand that's our primary mailing list for these threads.
> 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. Have you spoken with the WebRTC folks about this? Desktop does not (at the moment) have the concept of trusted/certified apps. Therefore I don't believe that the WebRTC folks intend to implement this restriction. 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)? 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
