Intent to Ship: Permissions API

[Mounir Lamouri]

Contact emails: mlam...@chromium.org

Spec: https://w3c.github.io/permissions/

== Summary ==
The Permissions API allows a web application to be aware of the status
of a given permission, to know whether it is granted, denied or if the
user will be asked whether the permission should be granted.
The version we are shipping here is covering the following permissions:
geolocation, notifications, midi (with sysex as an option) and push
(with userVisible as an option).
In addition of querying for permissions, callers can register to be
notified if the permission changes.

== Link to “Intent to Implement” blink-dev discussion ==
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wfszE6uUmk8/r9ucFjbfvY4J

== Is this feature supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)? ==
Yes. It is using content::PermissionManager which is implemented by all
the platforms above.

== Demo link ==
https://mounirlamouri.github.io/sandbox/permissions.html
The different listed permissions will be updated when the permissions
change. Clicking the buttons will do a permission request (not using the
Permissions API but using some specific API calls).

== Compatibility Risk ==
Mozilla is planning to ship this but it is not yet a priority for them.
I have been working closely with Marcos Caceres on the API design.
Otherwise, Microsoft seemed interested. No feedback from Apple.
The risk might be that the API isn’t flexible enough to handle future
permissions but it is hard to predict that and there is a need today for
current permissions so it is a risk that we must take to solve the
current situation.
This document describe the approach to extensibility with some examples:
https://github.com/w3c/permissions/blob/gh-pages/extensibility.md

== OWP launch tracking bug? ==
https://code.google.com/p/chromium/issues/detail?id=432570

== Link to entry on the feature dashboard ==
https://www.chromestatus.com/features/6376494003650560

Thanks,
-- Mounir

[Domenic Denicola]

+1 from me! Mounir's done a lot of work addressing concerns from various parties around getting this API into the right shape---extensible for the future, yet simple for an initial MVP. Would be great to get this in developers' hands.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[mar...@marcosc.com]

On Tuesday, March 31, 2015 at 4:37:16 PM UTC-4, Mounir Lamouri wrote:

 

== Compatibility Risk ==
Mozilla is planning to ship this but it is not yet a priority for them.
I have been working closely with Marcos Caceres on the API design.

Agree. Mozilla's DOM team sees this as an important feature for allowing developers to better explain and request (right now through the appropriate APIs!) privacy-sensitive features of the Web platform. We would like to continue to iterate over the design of this API after Chrome ships it.

[Chris Harrelson]

LGTM, sounds great.

[Mike West]

-Mike

On Tue, Mar 31, 2015 at 10:37 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

Spec: https://w3c.github.io/permissions/

Note: This will be published as a first public working draft from the WebAppSec WG shortly. The successful CfC is here: https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0131.html.

  

== Summary ==
The Permissions API allows a web application to be aware of the status
of a given permission, to know whether it is granted, denied or if the
user will be asked whether the permission should be granted.
The version we are shipping here is covering the following permissions:
geolocation, notifications, midi (with sysex as an option) and push
(with userVisible as an option).
In addition of querying for  permissions, callers can register to be
notified if the permission changes.

What are the plans to extend this out to other permissions? I'm thinking in particular of the permissions called out in https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ (Fullscreen, getUserMedia, device orientation/motion, and EME).

(I also support shipping the API).

-mike

[Mounir Lamouri]

On Wed, 1 Apr 2015, at 13:36, Mike West wrote:
> On Tue, Mar 31, 2015 at 10:37 PM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
>
> > Spec: https://w3c.github.io/permissions/
>
>
> Note: This will be published as a first public working draft from the
> WebAppSec WG shortly. The successful CfC is here:
> https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0131.html.

Thanks for pointing that out :)
Indeed, the FPWD should be published any time. It's only a matter of
spinning the administrative wheel.

> > == Summary ==
> > The Permissions API allows a web application to be aware of the status
> > of a given permission, to know whether it is granted, denied or if the
> > user will be asked whether the permission should be granted.
> > The version we are shipping here is covering the following permissions:
> > geolocation, notifications, midi (with sysex as an option) and push
> > (with userVisible as an option).
> > In addition of querying for permissions, callers can register to be
> > notified if the permission changes.
>
> What are the plans to extend this out to other permissions? I'm thinking
> in
> particular of the permissions called out in
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ
> (Fullscreen, getUserMedia, device orientation/motion, and EME).

Some idea regarding GUM are listed here:
https://github.com/w3c/permissions/blob/gh-pages/extensibility.md
I believe that EME, device orientation and device motion are simple
permissions and shouldn't be a problem. Note though that only EME is
backed by a permission as of today.
Regarding fullscreen, I would like to extend the API with something like
PermissionDetails that will provide information regarding user
interaction requirements.

For the moment, the API is only shipping with permissions that are known
to be an issue (geolocation and notifications) or for which I talked to
the editors and figure out a plan. I will reach out to other editors to
include permissions related to their APIs. On top of the list is
GetUserMedia.

-- Mounir

[Philip Rogers]

LGTM. This is clearly useful for existing sites and is compatible with how Microsoft's browsers handle these requests too.

+cc egm in case there are concerns about the direction we're going with fullscreen.

[Jake Archibald]

Permission querying is incredibly ad hoc across the platform, this is an important first step to fixing that. +1 from me.

[Philip Jägenstedt]

LGTM3, this will be great!

[Dimitri Glazkov]

Looking over W3C TAG activities, seems like they provided useful feedback on the API: https://github.com/w3ctag/spec-reviews/issues/45 and https://github.com/w3ctag/spec-reviews/blob/master/2015/03/Permissions.md

Have the issues mentioned been addressed?

:DG<

[Marcos Caceres]

I believe so. Mounir went through each issue raised and made modifications to the spec as needed. Not all recommendations were accepted by the Editors. Having said that, there is still time to iterate over the design as implementation/user experience is gained. 

[Alex Russell]

/me puts TAG hat on

I'm grateful for Mounir's work on updating the design based on feedback. I think it's getting better VERY quickly.

Given the time constraints, I spent some time over the weekend updating the TAG feedback based on the latest draft. The other TAG members (and the list) need to weigh in (I'll circulate it today to get input ASAP), but I think it covers the bases.

The biggest issues are:

• The "string-ness" of the status value. I worry about the ability to model the full set of permissions without a more extensible type and it will be hard to retrofit later
• Lack of reflection for the majority of web platform permissions
• An inability to enumerate which permissions are supported by the API

Regards

[Alex Russell]

Late updates:

• Miguel caught my (serious) error, noting that the return value from query() is already an object. I had been confused and want to apologize to Mounir and everyone here for missing this.
• The extensibility document does cover the majority of un-modeled APIs in the platform. I'd still like to see 100% coverage, but I feel much, much better about the situation now.
• The lack of enumerability is still an issue, but not one which, on balance, should block shipping an early version of this.

Excited to see this go out ASAP!

[Dominick Ng]

Update: we are adding camera and microphone to navigator.permissions.query(). Neither of these two permissions shipped with the permissions API as described in this intent (see crbug.com/648553).

Concretely, the current behaviour is:

navigator.permissions.query({name: 'camera'});

Promise {<rejected>: TypeError: Failed to read the 'query' property from 'Permissions': The provided value 'camera' is not a valid enum value of type PermissionName}

This is changed so that the promise does resolve with the appropriate permission value for 'camera' and 'microphone' as described in the spec. This will match the other permissions, such as 'geolocation', 'notifications', etc.

+rbyers agreed that the change was trivial enough to not require a new intent to ship. We'll also update MDN docs to reflect the change. Let me know if there are any concerns.