If you can have a way of accurately capturing a user's intent to use the camera/location in an application, you don't need a prompt. The buttons that Adrienne suggested in her original email (or at least the first email I saw) let you do this, or get closer to it.
One of the reasons that existing solutions to problems like this involve prompts is that prompts are one of the only ways to get a secure UI. If you can make a secure UI that's embeddable by an application, it functions more seamlessly as part of the application, rather than breaking the flow. It's also not a warning that users can become habituated to; they only click it if they want the application to use the camera. Making an embeddable UI secure does mean not allowing it to be active when overlaid by other content (or overlaid at all), protecting against clickjacking (e.g., with an activation delay when it appears), etc., as others have pointed out. Franzi On Thu, Apr 12, 2012 at 9:05 AM, Adrienne Porter Felt <a...@berkeley.edu>wrote: > > On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller <ja...@developit.ca> wrote: >> >> What would be wrong with using the same UI from Geolocation access for >> something like camera access? An API method requests that the user grant >> camera permissions, which shows them the appropriate dialog to confirm. >> Events are fired to inform the requesting application whether it was >> granted access or not. It could even differentiate between video >> recordings and still picture taking, as long as there was a limited >> "preview" API (perhaps a low-quality media stream). >> > > Standard runtime dialogs like that don't work well because of habituation. > Over time, people become so conditioned to click "yes" that they will > approve access under virtually any circumstance. Runtime dialogs can work > if they are very *infrequent* because people don't see them enough to > become conditioned to them. Once they start to be applied to multiple > different types of (commonly-used) capabilities, they lose their > effectiveness. > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
