Re: Proposal for a Permissions API

On 2015-03-21 22:47, Florian Bösch wrote:
> Time to revise this topic. Two data points:
>
> 1) Particularly with pointerlock (but also with other permission prompts
 > that sneak up on the user) I often get the complaint from users along the
 > lines of "I tried your stuff, but it didn't work." or "I tried your stuff,
 > but it asked me to do X, I don't think it works".
>
> 2) MRI scans show that user attention dramatically drops when presented with
 > a security prompt: http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
>
> Permission/Security prompts are bad UX. Particularly the kind you need to prompt
 > the user with along the way. And within that, even worse are the ones that pop up again and again (like the fullscreen popup).

I agree with this. When skimming https://webbluetoothcg.github.io/web-bluetooth/use-cases.html
I particularly noted the following lines:

   "3.2.1 The Bluetooth API must only expose those parts of the general Bluetooth
    protocol that present an acceptable risk of exploit"

This may lead to:
- Crippled functionality
- User's being confronted with questions they don't understand the consequences of
   like http://www.sconnect.com/FAQ/#permissionrequest

Although efforts making the Open Web more competitive with the Native/Platform level are
motivated, I'm personally unconvinced that DUPLICATION is the right approach for system-
level interfaces.

COMBINING these layers seems like a simpler way ahead.  FWIW, I have sort of "launched"
such a scheme: http://www.ietf.org/mail-archive/web/jose/current/msg05005.html

What's the difference you may [rightfully] wonder?  Well, the short version is that it enables
any numbers of specific (single-purpose) interfaces that does exactly what you want and at
worst needing a privacy prompt.  These interfaces can also be defined (and implemented!)
by different communities which allows for quicker turnaround which is quite important if
you are set to compete with the "App" world.

Anders




>
> On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin <jyasskin@google.com <mailto:jyasskin@google.com>> wrote:
>
>     On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri <mounir@lamouri.fr <mailto:mounir@lamouri.fr>> wrote:
>     > On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
>     >> I'm generally supportive of this direction.
>     >>
>     >> I'm not sure that that the PermissionStatus thing is needed. For
>     >> example in order to support bluetooth is might be better to make the
>     >> call look like:
>     >>
>     >> permissions.has("bluetooth", "fitbit").then(...);
>     >
>     > That's more Permission than PermissionStatus, right?
>     >
>     > What you proposed here would probably be something like that in WebIDL:
>     > Promise<> has(PermissionName name, any options);
>     >
>     > But really, we could make that option bag be a dictionary because it
>     > gives good context about what you are passing like what does "fitbit"
>     > means here? Is that a black listed device or a white listed one? The one
>     > you want to target?
>     >
>     > I agree that it might be unusual to have a required "name" than might
>     > often be used alone but it makes the API way more javascript-y and self
>     > explanatory. IMO, this call is nicer to read than the one you wrote
>     > above:
>     >   permissions.has({ name: 'bluetooth', devices: 'fitbit' });
>     > because I understand what the call is trying to do. In addition, as you
>     > pointed, it gives a lot of flexibility.
>
>     Belatedly, I'd like to suggest a slightly different model. Instead of
>     trying to stuff arbitrary queries into the permissions.has() call,
>     maybe expose the current permissions as data, and let the application
>     inspect them using custom code. This is likely to work better for
>     Bluetooth, since we're planning to have pages request devices by the
>     Services they expose, not their deviceIds, and a page may want to
>     check for either an available device exposing some services, or that a
>     device they've already opened hasn't been revoked.
>
>     Getting permission revocation to update a UI correctly is also an
>     interesting problem. You could expose an event on permission change,
>     but given that templating frameworks are moving toward
>     Object.observe() to update themselves in response to model object
>     changes, that would require developers to write extra code to
>     propagate the permission changes into their models.
>
>     So what if navigator.permissions just _was_ a suitable model object?
>     Make it, say, a Map from permission-name to an object defined by the
>     permission's standard, and extend Map to expose enough synthetic
>     change records that Object.observe(a_map) is useful.
>
>     Jeffrey
>
>

Received on Sunday, 22 March 2015 15:31:18 UTC