Re: Allow ... centralized dialog up front

[Charles McCathie Nevile]

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 it as "requestAPIs" and it would work a bit like this:

var gotAPIs = function(mandatorEnabled, optionalAPIs){

  if(!mandatoryEnabled){ ...; return;}

  if(optionalAPIs.desktopNotification){ ... }

} 

Look at the feature element in the Widget stack, or permissions property in Chrome/Yandex extensions, or in Mozilla apps [3].

[1] http://www.w3.org/TR/widgets/#the-feature-element-and-its-attributes

[2] http://developer.chrome.com/apps/declare_permissions.html

[3] https://marketplace.firefox.com/developers/docs/manifests

Right now, although this stuff is in Webapps charter and we have delivered specs, mozilla seems to prefer to do the work in Sysapps, Google and Opera seem uninterested, and Apple has a habit of forcing Patent Groups, which so far tend to delay but not derail the work.

I'd be happy to work on this in either group, or it *may* (I haven't looked) fall within the charter of the webapps-security group.

document.requestAPIs({mandatory: ['fullscreen', 'pointerlock', 'WebRTC', 'Webcam', 'geoLocation'], optional: ['desktopNotification', 'keyboardSymbolResolution', 'peer2peer'], onAPIs: gotAPIs});

How a vendor presents that to a user is the vendors choice, but the semantic lets the vendor use that information for good UX. If a developer wants to use that API is up to the developer, if he doesn't, he'd still go down the "popup by popup" UX, that's up to the developer. But at least it would be possible way forward.

Right now vendors look at a page and can often heurisitically generate a permission request that is either consolidated, or depends on actual usage. For example, and app may be able to use my camera, location, audio, orientation and contacts db, but not necessarily need to use them all. One of the patterns clear with Android apps (which use a central dialogue like you are proposing) is applications that request a massive number of permissions that are irrelevant to their main purpose, and which effectively train users to ignore the whole question and click yes. :(

cheers

Chaals

On Fri, Feb 1, 2013 at 1:27 PM, Florian Bösch <pya...@gmail.com> wrote:

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 <cha...@yandex-team.ru> wrote:

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 even read that notes TOC, you can scroll straight to section 2.6: http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/#trust-decision-management

Lots of people, lots of times. It is one of the better-known truisms in designing security interfaces, and a really well-known principle for managing security on the Web.

It doesn't invalidate what Anne said - but what Anne said doesn't invalidate your suggestion either. As I said, what you propose is what most of the industry seems to already be moving towards.

Having it written in a new specification doesn't seem to make much sense - it is already there. And it is one of they key ideas repeated almost every time security or privacy comes up in relation to a specification.

cheers

Chaals

No matter how well security context information is presented, there will always be users who, in some situations, will behave insecurely even in the face of harsh warnings. Thus, the Working Group will also recommend ways to reduce the number of situations in which users need to make trust decisions.

--

Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com

--

Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com