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 <pyalot@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 <pyalot@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  
>> <chaals@yandex-team.ru> wrote:
>>> On Fri, 01 Feb 2013 12:59:35 +0100, Florian Bösch <pyalot@gmail.com>  
>>> wrote:
>>>
>>>> On Fri, Feb 1, 2013 at 12:56 PM, Arthur Barstow  
>>>> <art.barstow@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
>>> chaals@yandex-team.ru Find more at http://yandex.com
>>
>



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