Re: Allow ... centralized dialog up front

TL;DR: Being able to declare the permissions that an app asks for might be  
useful. User agents are and should continue to be free to innovate in ways  
they present the requests to the user, because a block dialogue isn't a  
universal improvement on current practice (which in turn isn't the same  
everywhere).

On Mon, 04 Feb 2013 01:35:43 +0100, Florian Bösch <pyalot@gmail.com> wrote:

> So how exactly do you imagine this going down when an application that  
> uses half a dozen such capabilities starts? Clicking trough half a dozen  
> allow -> allow -> >allow -> allow -> allow -> allow, you really think  
> the user's gonna bother what the 5th or sixth allow is about?

Where there are multiple permissions required the way to ensure user  
attention isn't as simple as "a list that doesn't get read, witha single  
button clicked by reflex", or "multiple buttons to be clicked by reflex  
without reading".

At least that seems to be what the research shows.

> You'll end up annoying the user, the developer and scaring people off a  
> page. Somehow I can't see that as the function of new capabilities you  
> can offer on a >page. Furthermore, some capabilities (like pointerlock)  
> actively interfere with the idea that when you need it you can click it  
> (such as the concept of pointer-lock->drag which requests pointerlock on  
> mousedown and releases it on mouseup) where your "click it when you need  
> it" idea will always fail the first usage.

This may be true. But pointer-lock is an example of something that needs  
the entire UX to be thought through. simply switching from one to the  
other without the user knowing is also poor UX, since it risks making the  
user think their system is broken. Add to this a user working with e.g.  
mousekeys, or a magnifier at a few hundred percent plus high-contrast.

The problems are not simple, and it is unlikely the solutions will be  
either. Ian's claim that everything can be done seamlessly without making  
it seem like a security dialog may be over-confident, and as Robin points  
out the first UI developed (well, the second actually) might not be the  
best approach in the long run, but it is certainly the direction we should  
be aiming.

So where are we? The "single up front dialogue" doesn't work. We know  
that. Mutliple contextual requests go from being effective to being  
counter-productive at some magic tipping point that is hard to predict.

To take an example, let's say I have a chat application that can use  
web-cam and geolocation. Some user agents might decide to put the  
permissions up front when you first load the app. And some users will be  
fine with that. Some will be happy to let it use geolocation when it  
wants, but will want to turn the camera on and off explicitly (note that  
Skype - one of the best-known video chat apps there is - allows this as a  
matter of course. I don't know of anyone who has ever complained).

Some "app stores" might refuse to offer the service unless you have  
already accepted that you will let any app from the store use geolocation  
and camera. Others will be quite happy with a user agent that (like skype  
- or Opera) puts the permissions interface in front of the user to modify  
at will. And there are various other possible configurations.

At any rate, having a way of declaring the things that will be requested  
(as I mentioned a zillion messages ago, most platforms have implemented  
this somewhere, sometimes several times) would at least simplify the task  
for implementors of deciding which approach to use, or how to blend the  
various different possiblities.

cheers

Chaals

> Not exactly confidence inspiring either, as a UX.
>
>
> On Mon, Feb 4, 2013 at 1:28 AM, Tobie Langel <tobie@fb.com> wrote:
>> On 2/2/13 12:16 PM, "Florian Bösch" <pyalot@gmail.com> wrote:
>>
>>> Usually games (especially 3D applications) would like to get  
>>> capabilities
>>> that they can use out of the way up front so they don't have to care
>>> about it later on.
>>
>> This is not an either / or problem.
>>
>> First, lets clarify that the granting of a permission (and for how long  
>> it
>> is granted) can be dependent on a variety of factors defined by the user
>> and or the user agent and is out of control of the developer and of any
>> spec body to standardize.
>>
>> Different User Agents will behave differently depending on what market
>> they target. Different users will react differently depending on their
>> security and privacy thresholds, the trust relationship they have with  
>> the
>> URL they're visiting, etc.
>>
>> The permission to carry out a certain task on the user's behalf (such as
>> taking a picture) might change at any time for any number of reasons  
>> (such
>> as the device's camera being unplugged or broken). There's only one
>> solution to this: code defensively.
>>
>> APIs that require specific user permissions are designed so that the
>> user's can be prompted every time the API is required to be used.  
>> Whether
>> the device chooses to do so or not is implementation specific (and  
>> again,
>> depends on external factors such as user settings, etc.).
>>
>> Generally, this solution has proven to be both flexible and secure.
>>
>> Handling permissions up front has three unwanted effects:
>>
>> 1. Users tend to not read the upfront permission settings that much thus
>> often accidentally granting more privileges than they would like to.
>> That's a security and privacy issue.
>> 2. Users tend to reject apps which have too many permission requests or
>> permission requests that feel out of scoop of the app. Eg. A chess game
>> asking for permissions to use the camera is rather off-putting until you
>> realize it uses it to take snapshots of a chess-board and suggest next
>> moves. This awareness generally comes with app usage, or because you're
>> aware of the feature set of the app through information provided by the
>> developer (marketing) or third parties (reviews, friends, etc.).
>> 3. Upfront permission lists rapidly get out of sync with real  
>> application
>> requirements. What happens then?
>>
>> In fact, Upfront permission requirement only really makes sense when the
>> user has already built a relationship of trust with the developer of the
>> application or trusts a third party that has means of enforcing good
>> behavior from the app developer (e.g. through an app store system).
>>
>> A hybrid approach that considers upfront permissions as hints of
>> permission requirements to come offers the best of both worlds. It  
>> allows
>> developers to ask permissions upfront for things that make sense given  
>> the
>> context (e.g. a camera app would require camera access upfront) and at a
>> later stage for features that might not be so obviously connected to the
>> app's main use case or present a bigger risk for the user. It also  
>> allows
>> the User Agent to treat these hints as it wishes, e.g. by prompting the
>> user upfront, by automatically granting some permissions using various
>> kinds of heuristics, or by deciding to only prompt the user when the
>> feature is actually going to be used.
>>
>> It is worth noting that the developer will still need to code  
>> defensively
>> for such an approach, as the user (or user agent) might very well not
>> grant all permissions upfront and still require prompting at a later
>> stage. Previously granted permissions might also be recalled at any  
>> time.
>>
>> This approach doesn't require the User Agent to let the developer know
>> which permissions the user has granted upfront nor would that be useful
>> given permissions can change at any time.
>>
>>
>>>> --tobie
>>
>



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