On Fri, Apr 13, 2012 at 6:19 PM, Lucas Adamski <ladam...@mozilla.com> wrote:

> 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.
>

Yes.  I had not realized that applications actively edited streams of data
during the preview phase.  This is indeed a problem with the approach.  We
don't want people to have to click an extra button (one to start preview
and another to capture) -- we'd been hoping that fitting the permission
granting to the capture action would implicitly add the permission prompt
to the user's flow without adding an extra step.


> 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?
>

I do agree that the proposal is mostly the same: I think that the
permission should be granted at run-time, and there should be a
notification.  However, the way that the actual permission prompt is shown
to the user is very important, and a runtime dialog is not equivalent to a
magic permission button.  Traditional permission dialogs do not work (there
are many, many studies that show this).  The traditional permission dialog
gets in the way, so people want to click through it as fast as possible in
most cases, which leads them to click through as fast as possible out of
habit every time.  A special "capture" button isn't an extra step -- it's
the same step that people take in most camera apps.

I'm trying to brainstorm a new way to fit trusted UI into the user's normal
flow that would enable preview modification, without throwing up a standard
dialog.  If anyone buys my case that we need such a thing, suggestions for
how to get around the preview problem would be awesome.  :)
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to