W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Allow ... centralized dialog up front

From: Florian Bösch <pyalot@gmail.com>
Date: Fri, 1 Feb 2013 15:29:16 +0100
Message-ID: <CAOK8ODjCOjuR4oDp7Mq5DFfx49mGpY0Xg+kQSwnap6hP+gPW-A@mail.gmail.com>
To: Charles McCathie Nevile <chaals@yandex-team.ru>
Cc: adriennefelt@gmail.com, Arthur Barstow <art.barstow@nokia.com>, Webapps WG <public-webapps@w3.org>
Repetitive permission dialog popups at random UI-flows will not solve the
permission fatique any more than a centralized one does. However a
centralized permission dialog will solve the following things fairly
effectively:

- repeated popup fatique
- extension of trust towards a site regardless of what they ask for (do I
trust that Indie game developer? Yes! Do I trust google? No! or vice versa)
- make it easy for developers not to add UI-flows into their application
leading to things the user didn't want to give (Do we want a menu entry
"save to local storage" if the user checked off the box to allow local
storage? I think not.)
- make it easy for developers to not waste users time by pretending to have
a working application, which requires things the user didn't want to give.
(Do we really want to offer our geolocated, web-camera using chat app to
users who didn't want to give permission to to either? I think not. Do we
want to make him find that out after he's been entering our UI-flow and
been pressing buttons 5 minutes later? I think not.)




On Fri, Feb 1, 2013 at 3:22 PM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> **
> On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch <pyalot@gmail.com>
> wrote:
>
> On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt <
> adriennefelt@gmail.com> wrote:
>
>> My user research on Android found that people have a hard time connecting
>> upfront permission requests to the application feature that needs the
>> permission. This meant that people have no real basis by which to allow or
>> deny the request, except for their own supposition.  IMO, this implies that
>> the better plan is to temporally tie the permission request to the feature
>> so that the user can connect the two.
>>
> In some circumstances this works, in others, it does not. Consider that
> not every capability has a UI-flow, and that some UI flows are fairly
> obscure. More often than not a page will initiate a flurry of permission
> dialogs up front to get it out of the way. Some of the UI-flows to use a
> capability happen deep inside an application activity and can be severely
> distracting, or crippling to the application.
>
> If a developer wants to use the blow-by-blow popup dialogs, he can still
> do so by simply not calling an API to get done with the business up front.
> But for those who know their application will not work without features X,
> Y, Z, A, B and C there is no point. They already know their app is not
> going to work. They already know they would have to pester the user 6 times
> with successive popups. They already know that they will severely distract
> the user or cripple themselves by making the user click trough 6 popups
> whenver it becomes necessary. They already know that 80% of their users
> will quit their page after the 3rd popup asking random questions. Why
> should there not be a way to prevent all that from happening?
>
> The stock answer (and I think it is too glib, and we should be thinking
> harder about this) is
>
> "because those who just want the user to agree to give away their security
> and privacy will be able to rely on permission fatigue. Which they can
> create, by getting sufficient users to download versions of popular stuff
> that requests unreasonably complicated permissions. So consolidating
> everything will make the system effectively useless".
>
> cheers
>
>
> Chaals
>
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
> chaals@yandex-team.ru Find more at http://yandex.com
>
Received on Friday, 1 February 2013 14:29:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT