Apps on other devices do get access to the preview to be able to do things with it like providing effects. The proposal to use WebGL shaders to modify the preview seems to ameliorate that issue in a way that other platforms aren't using (which is good). An API to open the preview that takes an optional shader would allow a preview to be shown and effects added without providing the preview data to the user. Overlays would be allowed (yes, a developer could completely hide the preview, but why bother when they can just not invoke the preview). And the magic button to allow access would keep the content from accessing the image stream before the user has "granted permission" using the magic button.
Thinking through some of the types of apps on other devices, this seems to be work for Instagram type cameras (shader provides effects). Looks like shaders can tesselate so apps (like PhotoBooth) showing multiples of the preview could work (not positive about this, as I'm not a WebGL Shader expert). Time machine camera apps (iOS Precorder) could work by having the user hit the magic button to start capturing multiple images and then the app could allow the user to select the images they wanted after capture has stopped. Skype type apps would get access to the video stream once the user hits the magic button (which could also be used to initiate the call) or the call could be initiated and then the magic button hit to say the user wanted to transmit video. The questions seem to me are 1) is the shader sufficient and secure enough for developer needs and 2) can we design a magic button that is secure and distinctive enough for developer needs and sufficiently distinctive to the user to let them know what they're allowing access to. I guess the final question is: can we generalize this for other APIs. I would prefer not to go through all the effort of making a secure camera without permissions prompts just to have everything else using permission prompts. That would make users feel insecure about the API(s) that use magic UI infrastructure. I'm guessing we could come up with magic UI for a class of permissions: microphone button, phone handset button for audio/voip, phone handset button for dialer, envelope button for email, globe or target button for geolocation, bluetooth icon button for bluetooth, usb icon button for usb, etc. I'm not sure about things like storage, permissions API, settings API, etc. Maybe those are handled more at the install/first launch stage and not at runtime. And background apps or services are a whole different question. -Jim Straus 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 <b...@krellian.com> 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 <se...@guanotronic.com> >> 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 <ja...@developit.ca> 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 >> dev-...@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-b2g >> >> >> >> -- >> Ben Francis >> http://tola.me.uk > _______________________________________________ > dev-webapi mailing list > dev-web...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-webapi _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
