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
