----- Original Message ----- > From: "Adrienne Porter Felt" <[email protected]> > To: "Lucas Adamski" <[email protected]> > Cc: [email protected], [email protected], "Zack > Weinberg" <[email protected]>, "dev-b2g list" > <[email protected]>, [email protected] > Sent: Sunday, 15 April, 2012 4:32:06 PM > Subject: Re: [b2g] WebAPI Security Discussion: Camera API > > Would the following suggestion solve the problem? > > * Applications may embed the "magic" photo or videorecord icons. As > soon > as the user presses the button, the app receives the data. A > notification > is present as long as the app is recording. The API provides an > optional > preview window, but the app cannot get the data.
I'm just catching up to this thread now, but I'd like to propose a solution based on a more fine-grained approach to permissions. For example: * Permission 1: Allow this app to use the camera to take pictures/video? yes/no If the user picks 'yes', the above scenario is enabled, but the app is forced to use the stock camera UI: viewfinder, buttons, etc., and may only capture data (either still or video) when the user presses the stock shutter/record button. The UI will have all the expected dressings: a shutter noise, a blinky recording indicator, etc. In essence the app would be allowed to invoke the camera, and would be allowed to get the data returned by it. If the user picks 'no', a well-written app should allow other functionality to work, but won't be able to use the camera. > * Foreground applications can begin video recording or previewing > without > the user pressing a button or accepting a dialog. A notification > appears > as soon as the app requests to begin recording/previewing; if the > user > clicks on the notification, she is shown a small dialog that has a > "Stop > recording" option. However, there is a slight delay between when the > application requests the data and when the OS begins delivering it. > This > short delay allows the user to notice the presence of the > notification and > either (1) quit the app, or (2) click on the notification and tell it > to > stop recording. This scenario could be addressed by a different permission: * Permission 2: Allow this app to use a custom camera interface? yes/no If 'yes', the camera may customise anything, including the viewfinder, the capture button, indicators (though perhaps we'll need to keep the shutter sound, as per local regulations), etc. Here, the app would have access to lower-level camera APIs, essentially the ones used by the stock camera in Permission 1, provided it was in the foreground. If 'no', well-written apps may gracefully degrade to the Permission 1 experience, but still be (somewhat) useful. > * Background applications cannot begin video recording or previewing. I don't think a blanket prohibition of camera usage while in the background in the right solution--although I can't think of a use case as it applies to me, the user may see it differently. Perhaps s/he is an artist who wants to put together an exhibit of photos taken at 1-minute intervals over the course of a day. If B2G is about giving the user complete control over his/her phone, we have to accept Scenario 3: * Scenario 3: Allow this app to take photos and/or video ANY TIME IT LIKES WITHOUT WARNING? yes/no If 'yes', the app may run in the background and do whatever it wants. If 'no', the app may not use the camera at all, or may degrade to the Permission 2 or 1 scenarios. I just looked back over Lucas' original proposal, and out of his proposed use cases, 'stolen phone tracking' definitely falls under Scenario 3; and 'baby monitor' may fall under Scenario 2 or 3, depending on where we slot in "camera active while display backlight is off" fits in. --m. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
