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
