Re: Allow ... centralized dialog up front

Something is better than nothing, and both the iPhone and Android systems are better than not asking the user at all. The principle of security in depth is that you don't rely on a single security feature that may be flawed, but have a multi layered approach to security. I think that giving a user

Re: Allow ... centralized dialog up front

On 06/02/2013 08:36 , Keean Schupke wrote: 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. If by "wo

Re: Allow ... centralized dialog up front

On Wed, Feb 6, 2013 at 2:09 AM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > ** > 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

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

Re: Allow ... centralized dialog up front

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 w

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 ever

Re: Allow ... centralized dialog up front

On 04/02/2013 20:06 , Ian Hickson wrote: Geolocation can use a similar asynchronous UI: ++ | (+) example.org wants to know your location. [ San Jose (IP)|V] X| +---| Mountain View |-

Re: Allow ... centralized dialog up front

Really nice usability, Ian :-) 2013/2/4 Ian Hickson : > On Thu, 31 Jan 2013, Florian Bösch wrote: >> >> There is a problem confronting applications desiring to use a variety of >> APIs such as pointerlock, fullscreen, WebRTC, local storage and so on. >> >> The problem is that each instance of atte

Re: Allow ... centralized dialog up front

On Thu, 31 Jan 2013, Florian B�sch wrote: > > There is a problem confronting applications desiring to use a variety of > APIs such as pointerlock, fullscreen, WebRTC, local storage and so on. > > The problem is that each instance of attempting to use such an API leads to > a new "Allow ..." popup

Re: Allow ... centralized dialog up front

On 2/4/13 1:35 AM, "Florian Bösch" 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 o

Re: Allow ... centralized dialog up front

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? You'll end up annoying t

Re: Allow ... centralized dialog up front

On 2/2/13 12:16 PM, "Florian Bösch" 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 permissi

Re: Allow ... centralized dialog up front

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. On Sat, Feb 2, 2013 at 11:59 AM, Keean Schupke wrote: > I didn't think of that. The app would have to maintain its own set of > permi

Re: Allow ... centralized dialog up front

I didn't think of that. The app would have to maintain its own set of permission flags updated by the callback. I am not sure that's easier than just chaining an anonymous function... But I guess that's a programming style issue. Cheers, Keean. On 2 Feb 2013 10:47, "Florian Bösch" wrote: > And

Re: Allow ... centralized dialog up front

And you can have the *the* callback (singular, centralized) as onAPIPermissionChange just fine. If you want to improve things for the user and the developer, you can't go with a solution that doesn't make it any easier for the developer. Your solution will be ignored, nay ridiculed. If you want de

Re: Allow ... centralized dialog up front

There are benefits to the user, in that it allows all permissions to be managed from one place. I am not sure I like the idea of making the popups an application thing. I think it should be decided by the browser. In any case you would still need the ...Allow callbacks as the user may have gone to

Re: Allow ... centralized dialog up front

On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke wrote: > 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 re

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 al

Re: Allow ... centralized dialog up front

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

Re: Allow ... centralized dialog up front

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

Re: Allow ... centralized dialog up front

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 bot

Re: Allow ... centralized dialog up front

On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch 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 f

Re: Allow ... centralized dialog up front

On Fri, Feb 1, 2013 at 3:12 AM, Anne van Kesteren wrote: > On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch wrote: > > I would propose to centralize this and make it an up-front dialog > remembered > > for a site such that: > > That kind of bulk approach does not work. Users don't understand > wha

Re: Allow ... centralized dialog up front

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

Re: Allow ... centralized dialog up front

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 - extension of trust towards a site regardless of

Re: Allow ... centralized dialog up front

On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch wrote:On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt 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.

Re: Allow ... centralized dialog up front

On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt 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 r

Re: Allow ... centralized dialog up front

On Fri, Feb 1, 2013 at 2:29 PM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > ** > Right now vendors look at a page and can often heurisitically generate a > permission request that is either consolidated, or depends on actual usage. > A heuristic is fine but, it only goes so far. Firs

Re: Allow ... centralized dialog up front

OK, I think I'm getting this now.On Fri, 01 Feb 2013 13:39:34 +0100, Florian Bösch wrote:The idea is to allow vendors to improve their UX (if they're so inclined) by allowing developers (if they're so inclined) to use a central, up front API. For lack of a better term let's dummy it as "requestAP

Re: Allow ... centralized dialog up front

More precedent http://kb.mit.edu/confluence/download/attachments/151094600/android-install.jpg On Fri, Feb 1, 2013 at 1:39 PM, Florian Bösch wrote: > The idea is to allow vendors to improve their UX (if they're so inclined) > by allowing developers (if they're so inclined) to use a central, up

Re: Allow ... centralized dialog up front

The idea is to allow vendors to improve their UX (if they're so inclined) by allowing developers (if they're so inclined) to use a central, up front API. For lack of a better term let's dummy it as "requestAPIs" and it would work a bit like this: var gotAPIs = function(mandatorEnabled, optionalAPI

Re: Allow ... centralized dialog up front

I don't propose writing into a specification how the dialog would look like. There does need to be a specification however on the API that developers can use to indicate an applications desire to use any of the dozen or so restricted APIs. On Fri, Feb 1, 2013 at 1:25 PM, Charles McCathie Nevile <

Re: Allow ... centralized dialog up front

On Fri, 01 Feb 2013 12:59:35 +0100, Florian Bösch wrote:On Fri, Feb 1, 2013 at 12:56 PM, Arthur Barstow wrote: Web Security Experience, Indicators and Trust: Scope and Use Cases  Yeah, has anybody actually even read t

Re: Allow ... centralized dialog up front

Section 9.4.3 Poor usability of dialog boxes Desktop software commonly reports problems through modal pop-up dialog > boxes. Such dialog boxes frequently appear during normal software use. > Also, the user is frequently given no reasonable course of action other > than clicking the OK button. Cons

Re: Allow ... centralized dialog up front

On Fri, Feb 1, 2013 at 12:56 PM, Arthur Barstow wrote: > Web Security Experience, Indicators and Trust: Scope and Use Cases > > > > Yeah, has anybody actually even read that notes TOC,

Re: Allow ... centralized dialog up front

On 2/1/13 6:30 AM, ext Charles McCathie Nevile wrote: Yep. There was some security work done a few years ago specifically looking at the sort of things that users understood, which recommended that for security it is helpful to have consistent presentation across browser UI. Florian - FYI, I

Re: Re: Allow ... centralized dialog up front

On Fri, Feb 1, 2013 at 12:30 PM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > That kind of bulk approach does not work. Users don't understand >>> what's going on. >>> >> > That's what research shows. To be fair, we've generally presented the > options in ways that are over-technical.

Re: Re: Allow ... centralized dialog up front

On Fri, 01 Feb 2013 11:48:33 +0100, Hallvord Reiar Michaelsen Steen wrote: On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch wrote: > I would propose to centralize this and make it an up-front dialog > remembered for a site such that: (Your proposal is broadly in line with the common thinki

Re: Allow ... centralized dialog up front

You suggest a bulk up front permission dialog doesn't work, whereas pinging the user at random intervals with a popup does? On Fri, Feb 1, 2013 at 10:12 AM, Anne van Kesteren wrote: > On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch wrote: > > I would propose to centralize this and make it an up

Re: Re: Allow ... centralized dialog up front

On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch wrote: > > I would propose to centralize this and make it an up-front dialog remembered > > for a site such that: > > That kind of bulk approach does not work. Users don't understand > what's going on. To what extent are we sure users understand a

Re: Allow ... centralized dialog up front

On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch wrote: > I would propose to centralize this and make it an up-front dialog remembered > for a site such that: That kind of bulk approach does not work. Users don't understand what's going on. (This has been discussed in the past too, I suggest you re

Allow ... centralized dialog up front

There is a problem confronting applications desiring to use a variety of APIs such as pointerlock, fullscreen, WebRTC, local storage and so on. The problem is that each instance of attempting to use such an API leads to a new "Allow ..." popup the user has to click away. By some discussion on the