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
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
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
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
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
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
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
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 the
Really nice usability, Ian :-)
2013/2/4 Ian Hickson i...@hixie.ch:
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
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
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
the
On 2/4/13 1:35 AM, 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
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
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
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
On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke ke...@fry-it.com 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
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
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
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 pya...@gmail.com
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 ke...@fry-it.com wrote:
I didn't think of that. The app would have to maintain its
On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com 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
On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com 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
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 ann...@annevk.nl wrote:
On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com wrote:
I would propose to
On Fri, 01 Feb 2013 11:48:33 +0100, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com wrote:
I would propose to centralize this and make it an up-front dialog
remembered for a site such that:
(Your proposal is
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.
This
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
On Fri, Feb 1, 2013 at 12:56 PM, Arthur Barstow art.bars...@nokia.comwrote:
Web Security Experience, Indicators and Trust: Scope and Use Cases
http://www.w3.org/TR/2008/**NOTE-wsc-usecases-20080306/http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/
Yeah, has anybody actually even read
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.
On Fri, 01 Feb 2013 12:59:35 +0100, Florian Bösch pya...@gmail.com wrote:On Fri, Feb 1, 2013 at 12:56 PM, Arthur Barstow art.bars...@nokia.com wrote:
Web Security Experience, Indicators and Trust: Scope and Use Cases
http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/Yeah, has anybody actually
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
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 pya...@gmail.com 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
OK, I think I'm getting this now.On Fri, 01 Feb 2013 13:39:34 +0100, Florian Bösch pya...@gmail.com 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
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. First of
On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt adriennef...@gmail.com
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
On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch pya...@gmail.com wrote:On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt adriennef...@gmail.com wrote:
My user research on Android found that people have a hard timeconnecting upfront permission requests to the application feature that needs
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
On Fri, Feb 1, 2013 at 3:12 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com 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.
On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch pya...@gmail.com 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:
-
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
39 matches
Mail list logo
