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 <pya...@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.
Chaals
Not exactly confidence inspiring either, as a UX.On Mon, Feb 4, 2013 at 1:28 AM, Tobie Langel <to...@fb.com> wrote:On 2/2/13 12:16 PM, "Florian Bösch" <pya...@gmail.com> wrote:This is not an either / or problem.
>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.
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
cha...@yandex-team.ru Find more at http://yandex.com
cha...@yandex-team.ru Find more at http://yandex.com