Suggestion:
"Program <name> is attempting to <action> on <resource>. If you expected it to, tap
here. If not, tap below."
Then, if the same permission dialog keeps happening at the same point in the same process, and the user has
never said "no", allow the option to save a "just say yes" or "just say no" for
that particular request flow and request address only.
-Kyle H
On Tue, Apr 17, 2012 at 12:56 PM, Adrienne Porter Felt <[email protected]>
wrote:
+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
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
