I'd like to propose the following based on discussions at Berkeley & with others about camera access:
-- The OS provides two trusted UI buttons. One has a photo icon, and the other has a recording icon. Applications can embed these icons into their UIs but cannot write over them. -- When the user presses one of these buttons, a photo is taken or recording begins. The result is returned to the user. -- When the app takes a photo, some notification briefly appears on the screen (on top of any other UI, including full-screened apps) to indicate that a photo was just taken. -- When the app is recording, a notification appears on the screen for the duration of the recording. Again, the notification is on top of any other UI, including full-screened apps. We recommend the notification be a blinking red light since that is a standard warning that a device is recording. -- Applications can continue recording in the background but the notification will persist. -- If the user clicks on the recording notification (ie the blinking red light) he/she is given the option of halting the recording. -- Applications can register timeouts for taking photos instead of recording, but the UI will make it appear as if the app is recording the whole time. This is to satisfy apps that take time-lapsed photos without additional user intervention (e.g., an app that you mount to the front of your bike that takes photos at 5 minute increments), but without incurring the battery drain of needing to record the whole time to catch those frames. On Tue, Apr 10, 2012 at 5:49 PM, Lucas Adamski <ladam...@mozilla.com> 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-webapi mailing list > dev-web...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-webapi > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
