Re: Allow ... centralized dialog up front

I think a static declaration is better for security, so if a permission is
not there I don't think it should be allowed to request it later. Of course
how this is presented to the user is entirely separate, an the UI could
defer the request until the first time the restricted feature is used, or
allow all permissions that might be needed to be reviewed and
enabled/disabled in one place.

Cheers,
Keean.
 On 2 Feb 2013 09:45, "Florian Bösch" <pyalot@gmail.com> wrote:

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