+1 to everything Zack said

Standard runtime dialogs that ask for Allow/deny are familiar, so system
designers seem to like them -- but a lot of literature establishes that
they don't work.  Android tried moving them to install-time, which works
for a small minority of users sometimes. Unfortunately, they're either
ignored or impossible to interpret without context.  (People who aren't
programmers have a hard time imagining how install-time permissions connect
to what applications actually do.)

There are certain resources that might need to be represented as either
install-time permission prompts or standard runtime dialogs.  (For example,
I can't think of another way to represent the ability to read all of the
user's text messages.)  However, I view these as last resorts in the
toolbox.  A very small number of prompts/standard dialogs will be OK.  OTOH
if a new one is added along with each new WebAPI, we end up with
dialogs/prompts that are completely useless because people will see them
all the time.

On Tue, Apr 17, 2012 at 8:18 PM, Zack Weinberg <[email protected]> wrote:

> I feel very strongly that we should initially attempt to design a system
> where there are no install-time permission prompts, and more generally, no
> prompts for which "remember this decision" is a desirable option.
>
> As Adrienne has been pointing out, permissions dialogs in general do not
> work.  They ask a non-expert user to make a security-critical choice, based
> on inadequate information, at a point in the workflow where most users will
> actively *avoid* stopping to think. (I don't have studies to hand, but I'm
> sure Adrienne does.)  From the UX perspective *and* the security
> perspective, anything we can do to get away from them is worth doing.  And
> we have a known better alternative: implicit, one-time-only deduction of
> permission from intentional user actions, such as pressing a "take photo"
> button.
>
> I'm frustrated by the Camera API discussion because there seem to be a
> bunch of people who don't even want to *try* to do something better. Sure,
> there exist applications for which it's not obvious how to fit them into an
> only-if-the-user-pressed-the-**button-just-now paradigm, but that doesn't
> mean we should give up!  (I'm pretty sure we can fit all camera use cases
> into a combination of "you can draw over the preview but you can't see the
> results" and "video recording mode".)
>
> Let's treat permissions dialogs as an option of last resort.  Let's only
> do them if we really can't find any other way for a particular privilege.
>
> zw
> ______________________________**_________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security>
>
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security

Reply via email to