>Actually, a lot of apps need access to the preview before starting to >capture (an image or video). Any app that wants to do realtime >transformations or effects will need the preview stream and then >display it themselves. Also, there are a class of apps that do >"pre-cording" so that you can capture fleeting events (think of being >at a kids sporting event). The apps are recording into a temporary >buffer so that when you hit the record/capture button they add or show >earlier images to the store. > >On Apr 13, 2012, at 8:19 AM, Serge Egelman wrote: > >> Again, this is a complete misunderstanding. We are not requiring a >> button to start preview. We are requiring a button to start >> *capture*. No current camera app, of which I am aware, gets access to >> the preview data before the user actually starts recording or snaps a >> photo. This would completely undermine any notion of consent. >> Serge
My severe apologies, but I'm going to add another layer of complication to this discussion: (tl;dr: We need to consider how these choices will impact WebRTC as well so we don't end up having to change them after a short time, or end up with very different user security models for Interactive and Capture/Record.) For WebRTC, we also need access to the camera and mics. We also have use cases where security warnings will rapidly become too painful for users to deal with (think a Skype-equivalent). And we need the api decided on to not be at odds with what we want to do there; the current Camera API (recording) cases are just part of the overall need and constraint. I'm not saying we have to have full support for WebRTC in the tree for Camera API to move forward, but we at least need to know that the UI/UX we design will be extendable for interactive cases without going back to square one. We need to be able to support *choosing* a camera (yes, devices have more than 1!), whether to use a camera, or multiple cameras at once. See the Media Capture Task Force use-cases for capturing - http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html and http://dev.w3.org/2011/webrtc/editor/getusermedia.html WebRTC likewise will need to support multiple cameras and mics. The webrtc folk considered the "unstylable button" idea; we were very concerned with the potential security risks that approach engenders (clickjacking, etc) as well as it could seriously constrain the UI of apps. We've gravitated to some type of doorhanger that also functions as a preview and visual way to identify the correct camera. (Mic selection is a little trickier, though usually they're mostly tied to cameras.) Note also that there are two forms of Camera API for recording: the <input> tag form, which inherently limits the amount of interaction with the app in terms of preview, etc, and what the Media Capture Task Force is defining, navigator.getUserMedia(). As getUserMedia will supply a MediaStream when fully implemented, this allows for full preview and modification in the app, and all sorts of other things. The WebRTC group has talked about "installed" webapps in order to deal with Requester Fatigue, especially in things like Skype-equivalents, and have discussed leveraging the installed-app model for security. Note that at the full Skype-like level, the app can turn on the camera and mic, either anytime or at least in response to any user UI action/click. For WebRTC, we'll also want the user to be able to supply a picture or maybe a video in some cases in place of a camera stream. For security, the equivalency model is that if you were to install Skype, WebEx, etc, you've given total access to skype to camera, mics, probably the internet, etc (plus all your files, etc). So there's precedent that some level of installed webapp be given extended permissions. Lastly, there's an issue of access by the app to the raw data in the mediastream, especially for non-fully-trusted apps (installed or not). This is mostly an issue for interactive use, but recording cases can trigger it as well. The issues and some possible solutions (leveraging cross-origin controls) are detailed in my slides here: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-2.pdf My apologies for complicating the issue, but we need the solution for image/video capture to not box in the design for WebRTC. -- Randell Jesup, Mozilla Corp remove ".news" for personal email _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
