Re: Allow ... centralized dialog up front

On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch <pyalot@gmail.com> wrote:

> 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

Sure. And that is valuable in principle.

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

I don't think so. As Adrienne said, as I have experienced myself, without  
understanding what the permission is for trust can be reduced as easily as  
increased.

> - 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.)
These are not so clear. As a user, I *do* want to have applications to  
which I will give, and revoke, at my discretion, certain rights. Twitter  
leaps to mind as something that wants access to geolocation, something I  
occasionally grant. for specific requests but blanket refuse in general.
The hypothetical example you offer is something that in general it seems  
people are happy to offer to a user who has turned off both capabilities.

I think the ability for a page to declare permission requests in a  
standard way, the same as applications and extensions, is worth pursuing,  
because there are now a number of vendors using stuff that seems to only  
differ by syntax.

The user agent presentation is a more complex question. I believe there is  
more research done and being done than you seem to credit, and as Hallvord  
said, I think this is an area where users evolve too.

For the reasons outlined already in the thread I don't think an  
Android-style "here are all the requests" is as good a solution in  
practice as it seems, and there is a need for continued research as well  
as implementations we can test.

cheers

Chaals

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



-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com