On Apr 10, 2012, at 5:59 PM, Adrienne Porter Felt wrote: > I'd like to propose the following based on discussions at Berkeley & with > others about camera access: > > -- The OS provides two trusted UI buttons. One has a photo icon, and the > other has a recording icon. Applications can embed these icons into their > UIs but cannot write over them. > -- When the user presses one of these buttons, a photo is taken or > recording begins. The result is returned to the user. > -- When the app takes a photo, some notification briefly appears on the > screen (on top of any other UI, including full-screened apps) to indicate > that a photo was just taken. > -- When the app is recording, a notification appears on the screen for the > duration of the recording. Again, the notification is on top of any other > UI, including full-screened apps. We recommend the notification be a > blinking red light since that is a standard warning that a device is > recording. > -- Applications can continue recording in the background but the > notification will persist. > -- If the user clicks on the recording notification (ie the blinking red > light) he/she is given the option of halting the recording. > -- Applications can register timeouts for taking photos instead of > recording, but the UI will make it appear as if the app is recording the > whole time. This is to satisfy apps that take time-lapsed photos without > additional user intervention (e.g., an app that you mount to the front of > your bike that takes photos at 5 minute increments), but without incurring > the battery drain of needing to record the whole time to catch those frames. >
So upon further reflection, I'm not sure this idea is that different from the original proposal. These two buttons are basically permission mechanisms that enables camera access. The photo button is just like the "agent mediated viewfinder", and the camera button permits normal streaming access. Notification models are basically the same. So we are discussing whether requiring a specific style of button is a better permission mechanism than some other permission UI. The main benefit I guess is that the user has to enable access every time? Which is the downside too I guess. Clickjacking still seems like a big risk if that's the only permission mechanism (besides the persistent notification). The issue I see is that the button proposal doesn't allow for persistence of decisions which is an problem for apps that assume realtime preview of the image for whatever purposes. In which case you'd likely see apps implementing a pattern where an app would immediately prompt a user to click on the video button, so it can start doing something useful, followed by a different shutter button to actually capture something? Even from my casual poking around in app stores its clear many mobile camera apps are applying realtime custom filters in preview, so we'd need a pretty compelling case to discourage that entire class of functionality. Put another way, maybe your proposal is how we handle the user agent mediated approach, but apps can still request direct access to camera via a more traditional, persist able permission dialog? Lucas. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
