Re: Allow ... centralized dialog up front

I don't think you can say either an up front dialog or popups do not work.
There are clear examples of both working, Android and iPhone respectively.
Each has a different set of trade-offs and is better in some circumstances,
worse in others.

In my opinion an API should allow for both, so that the user experience can
be inline with platforms standards. It us clear iPhone users with safari
will expect one behavior, android users with chrome will expect another.

In order to allow an up front dialog permissions need to be declared up
front, preferably statically in markup (as you would do an a manifest file
for an android application). Browsers would still be able to delay asking
the user for permission until the first use. The opposite of requiring
browsers wishing to use an up front dialog to use some kind of code
scanning to detect calls to services with permissions seems unreliable and
complex. Static permission declarations in markup seems a much simpler and
more light weight solution with other benefits like searchability and app
stores being able to read and display this.

Cheers,
Keean.
On 6 Feb 2013 05:44, "Charles Pritchard" <chuck@jumis.com> wrote:

> This direction of placing permissions up there in the site info expansion
> in Chrome feels like the right direction. That spot where they show where
> an SSL cert is valid/expired.
>
> Now I can easily see cookies and flip various settings in one click as I
> look at site info.
>
> I've been working on a web app where I don't need any upfront permissions,
> but the user can elect to elevate to clipboard, XSS and a high disk quota.
> I've certainly felt the cost of multiple dialogs vs a one-time "grant
> everything" prompt.
>
>
>
> On Feb 5, 2013, at 5:09 PM, "Charles McCathie Nevile" <
> chaals@yandex-team.ru> wrote:
>
> 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
>
>