- From: Florian Bösch <pyalot@gmail.com>
- Date: Fri, 1 Feb 2013 14:24:47 +0100
- To: Charles McCathie Nevile <chaals@yandex-team.ru>
- Cc: Arthur Barstow <art.barstow@nokia.com>, Webapps WG <public-webapps@w3.org>
- Message-ID: <CAOK8ODiofTmmAYx2QAiML7BYA0SYhDDjcn9U=fDZdgUg51281w@mail.gmail.com>
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 <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){ ... } > } > > 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. > > > 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 >>> >> >> >
Received on Friday, 1 February 2013 13:25:15 UTC