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 > > Sent from my iPhone, hence the typos. > > On Apr 13, 2012, at 2:40, Ben Francis <[email protected]> wrote: > >> CC jcarpenter >> >> No mobile camera app I know of requires the user to press a button to start >> an image preview prior to capturing an image, the "viewfinder" starts as >> soon as you open the app. This requirement would really break the UX of the >> current B2G camera app. Preventing UI elements being overlayed on top of the >> camera video stream is also a big limitation for UI design. >> >> For Open Web Apps, the user can grant access to the camera permission during >> installation, and/or with a geolocation style request at the time of >> accessing the camera (with an option to "always allow"). >> >> Ben >> >> On Thu, Apr 12, 2012 at 11:17 PM, Serge Egelman <[email protected]> >> wrote: >> I think there's a huge misunderstanding here: >> >> We're not advocating getting rid of the preview screen. What we're >> advocating is that apps cannot receive camera data until the user has >> pressed the button (which is owned by the OS). >> >> In the current state of the world, some apps do not show preview screens. >> If this option is to remain, this is why the record button (and >> notification) need to have a trusted path. An alternative would be to make >> the preview screen the trusted UI (and therefore enforce minimum/maximum >> dimensions). However, we believe that this latter option would be more >> onerous on app developers. Those that wish to include preview windows are >> more than welcome to. >> >> serge >> >> On Thu, Apr 12, 2012 at 1:31 PM, Jason Miller <[email protected]> wrote: >> >>> I'm not opposed to a trusted UI approach, but I don't think it is possible >>> to provide adequate functionality using a "take picture" button. The >>> preview point is spot on. Think about the camera apps people use - preview >>> is a universal feature among them. >>> >>> One solution might be to bundle the preview option into the take picture >>> UI - what happens now? That's basically reducing the typical access >>> confirmation modal with a button that does the same thing, but doesn't have >>> an option to "always allow". >>> >>> As an example of another (existing) camera permissions flow, look at >>> Flash. They pop a settings dialog that can't be modified by the >>> application, and the user has an option to persist the granted access. >>> Taking that one step further, on Apple laptops there is a *hardware* >>> indicator for camera access. That is something users trust. >>> >>> Also notice that there really aren't any popular systems that are designed >>> to be secure from the ground up. Users want an experience that works and >>> uses their device to its full potential *first*, and worry about security >>> after that need has been met. For examples of this, look to Android's SD >>> security or iOS's lazy address book access control (or any iOS API access >>> for that matter). When security comes at the price of usefulness, you >>> might want to think about how much security will matter if users return >>> their devices in favor of a phone that has expected features like a camera >>> viewfinder. >>> >>> I don't mean to specifically knock your point, however. If there was a >>> way to use a trusted UI approach while still allowing for the features >>> developers need now (and to a reasonable degree in the future), then surely >>> that's the ideal path. I just have yet to see a workable concept. >>> >>> At the very least, the typical permissions based approach gives the users >>> who genuinely care about their security rather convenient tools to manage >>> it. Reading comments on the Android market does seem to confirm that this >>> group of users actively polices their apps to ensure they aren't being >>> duped. >>> >>> - Jason >>> >>> >>> Jason Miller >>> 519.872.0797 // developIT <http://developit.ca/> // Jason Miller >>> Design<http://jasonmillerdesign.com/> >>> *Developer of amoebaOS <https://amoebaos.com/>, >>> Shutterborg<http://shutterb.org/> & >>> more >>> >>> * >>> >>> >>> >> >> >> -- >> /* >> I am Serge Egelman and I approve this message. >> >> */ >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> >> >> >> -- >> Ben Francis >> http://tola.me.uk > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
