Regardless, this is not incompatible with what we are proposing. Serge
Sent from my iPhone, hence the typos. On Apr 13, 2012, at 8:27, Jim Straus <[email protected]> wrote: > 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
