Re: Proposal for a Permissions API

The Permissions API moved to the WebAppSec WG, and there's an open
call for comments on publishing its FPWD:
https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0131.html.
It would probably make more sense to discuss in that group.

On Sat, Mar 21, 2015 at 2:47 PM, Florian Bösch <pyalot@gmail.com> 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).
>
> On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>
>> On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri <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 22:04:25 UTC