Re: Allow ... centralized dialog up front

I thought this was obvious but maybe not. Of course I had in mind that:

- A user gets some centralized place to "manage his sites"
- He can change permissions
- If the sites preferences change, the permissions pop up again.
- Some way for the user to re-engage the permission dialog for the site
he's on on his own.

But none of this is in the domain of a standard really, it's up to the
vendors how to best structure their UX.

Now, indexability/markup, I kinda like that. I've thought (at times) to
create a news site or search crawler that looks for examples of
technologies. And sometimes I wish I could google filter out pages that
entertain certain technologies when searching for something. It would be a
nice semantic.

Now there are still use-cases that might occur where a developer wants to
group a bunch of permissions up front, and later come with a different
bunch. Or where a developer derives the set of permissions he'll need from
the set of permissions his frameworks/libraries advise. Which would favor a
permission API. On the other hand most developers would probably be happy
to state permissions once for the page, and the markup could just be a
"remote-control" for the API.


On Sat, Feb 2, 2013 at 10:38 AM, Keean Schupke <keean@fry-it.com> wrote:

> I would like the permissions to be changeable. Not a one time dialog that
> appears and irrevocably commits me to my choices, but a page with
> enable/disable toggles I can return and review the permissions and change
> at any time.
>
> How about instead of a request API the required permissions are in tags so
> they can be machine readable on page load.
>
> The browser can read the required permissions tags as page load and create
> a settings page for the app where each permission can be toggled.
>
> This had the advantage that search engines etc can include permission
> requirements in searches. (I want a diary app that does not use my
> camera...)
>
> Cheers,
> Keean.
>
> Cheers,
> Keean.
> On 2 Feb 2013 09:09, "Florian Bösch" <pyalot@gmail.com> wrote:
>
> I do not particularly care what research you will find to support the
> UI-flow that the existence of a requestAPIs API will eventually give rise
> to. I do say simply this, the research presented, and pretty much common
> sense as well easily shows that the current course is foolhardy and ungainy
> on both user and developer.
>
>
> On Sat, Feb 2, 2013 at 3:37 AM, Charles McCathie Nevile <
> chaals@yandex-team.ru> wrote:
>
>> **
>> 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
>>
>
>