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" <cha...@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 <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. > > cheers > > 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: > > >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 > cha...@yandex-team.ru Find more at http://yandex.com
