Intent to Implement: Permissions API

[Mounir Lamouri]

Primary eng emails:
mlam...@chromium.org, timvo...@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.

Motivation:
The purpose of the API is to improve general UX with regards to
permissions on the Web, allowing developers to be aware of what is going
to happen will enable better flow.

Compatibility Risk:
Firefox: Public support (during WebApps F2F at TPAC)
Internet Explorer: No public signals
Safari: No public signals
Web developers: Positive

Describe the degree of compatibility risk you believe this change poses:
Nothing significant; the API is only introducing new concepts, doesn't
break backward compatibility and Mozilla sounds interested.

Ongoing technical constraints:
None.

Will this feature be supported on all five Blink platforms (Windows,
Mac, Linux, Chrome OS, and Android)? Yes

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

Entry in Chromium Dashboard:
https://www.chromestatus.com/features/6376494003650560

Requesting approval to ship?
No.

-- Mounir

[Chris Harrelson]

Sounds great!

Could you post a couple of examples to the thread so everyone can see the flavor of the API without digging deep into github?

Chris

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

[Mounir Lamouri]

On Thu, 13 Nov 2014, at 05:05, Chris Harrelson wrote:
> Sounds great!
>
> Could you post a couple of examples to the thread so everyone can see the
> flavor of the API without digging deep into github?

I've added two examples in the specification, they will easier to read
from there:
https://w3c.github.io/permissions/#examples

-- Mounir

[Philip Jägenstedt]

Exposing this information sounds great, non-owner LGTM to that!

Why does Permissions.get() return a promise? Are there permissions in
Chromium where the current state cannot be retrieved synchronously?

Also, have you given any thought to whether or not this API may evolve
to request permissions in batch, as a way to avoid many async infobars
where the app will only work if all of them are approved? If so,
Permissions.get() would sound a lot like Permissions.request(), in
which case e.g. Permissions.query() might be a more suitable name for
the current API.

(I'm not on public-webapps, hope spec feedback here is OK.)

Philip

[Chris Harrelson]

On Wed, Nov 12, 2014 at 2:17 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Wed, Nov 12, 2014 at 7:40 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On Thu, 13 Nov 2014, at 05:05, Chris Harrelson wrote:
>> Sounds great!
>>
>> Could you post a couple of examples to the thread so everyone can see the
>> flavor of the API without digging deep into github?
>
> I've added two examples in the specification, they will easier to read
> from there:
> https://w3c.github.io/permissions/#examples

Exposing this information sounds great, non-owner LGTM to that!

Why does Permissions.get() return a promise? Are there permissions in
Chromium where the current state cannot be retrieved synchronously?

e.g. it could be on disk or behind an async system API.

In general, new APIs should be async, since that is more general than sync. async is also performance-optimization-compatible.

[Philip Jägenstedt]

On Wed, Nov 12, 2014 at 11:20 PM, Chris Harrelson <chri...@chromium.org> wrote:
>
>
> On Wed, Nov 12, 2014 at 2:17 PM, Philip Jägenstedt <phi...@opera.com>
> wrote:
>>
>> On Wed, Nov 12, 2014 at 7:40 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
>> > On Thu, 13 Nov 2014, at 05:05, Chris Harrelson wrote:
>> >> Sounds great!
>> >>
>> >> Could you post a couple of examples to the thread so everyone can see
>> >> the
>> >> flavor of the API without digging deep into github?
>> >
>> > I've added two examples in the specification, they will easier to read
>> > from there:
>> > https://w3c.github.io/permissions/#examples
>>
>> Exposing this information sounds great, non-owner LGTM to that!
>>
>> Why does Permissions.get() return a promise? Are there permissions in
>> Chromium where the current state cannot be retrieved synchronously?
>
>
> e.g. it could be on disk or behind an async system API.
>
> In general, new APIs should be async, since that is more general than sync.
> async is also performance-optimization-compatible.

I was really wondering about the current state of things. I've now
taken a look at Geolocation.h, and it says "Unknown means that the
embedder still has to be asked for the current permission level."
WebGeolocationPermissionRequest looks like an async thing, in which
case a promise makes perfect sense.

Philip

[Peter Beverloo]

As far as I know only Notifications has a synchronous getter right now (Notification.permission), which is implemented using a synchronous renderer -> browser IPC. This is obviously not ideal.

There usually are three states for permissions: allowed, denied or prompt/default/unknown. Generalizing on a single, consistent pattern for checking the permission level is great, so a big +1 from me :-).

Thanks,

Peter

 

Philip

[Mounir Lamouri]

On Thu, 13 Nov 2014, at 09:17, Philip Jägenstedt wrote:
> On Wed, Nov 12, 2014 at 7:40 PM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
> > On Thu, 13 Nov 2014, at 05:05, Chris Harrelson wrote:
> >> Sounds great!
> >>
> >> Could you post a couple of examples to the thread so everyone can see the
> >> flavor of the API without digging deep into github?
> >
> > I've added two examples in the specification, they will easier to read
> > from there:
> > https://w3c.github.io/permissions/#examples
>
> Exposing this information sounds great, non-owner LGTM to that!
>
> Why does Permissions.get() return a promise? Are there permissions in
> Chromium where the current state cannot be retrieved synchronously?

For the moment, except a few permissions (that are sent and synchronized
via WebSettings), the permissions are actually asynchronous. We could
make them synchronous in Chromium by keeping a cache of the permission
status in the renderer and have that cache updated by the browser
process but we definitely don't want to write an API with the assumption
that this system is implementable.

I see two downsides of using an asynchronous method here:
- it will be very painful to use in collaboration with a synchronous API
but for now all the candidate APIs to use this system (geolocation,
notifications and push) are asynchronous by nature;
- user gesture bit can be lost between permission check and using the
related API - this is a problem that isn't really specific to this API
but general to Promises in Blink.

> Also, have you given any thought to whether or not this API may evolve
> to request permissions in batch, as a way to avoid many async infobars
> where the app will only work if all of them are approved? If so,
> Permissions.get() would sound a lot like Permissions.request(), in
> which case e.g. Permissions.query() might be a more suitable name for
> the current API.

The initial intent was to have a request method but it has been dropped
because Mozilla wasn't excited by it but were interested to implement
the getting part. Given that we had no short term plan to do request
merging, we dropped that and kept a minimal version that got wide
agreement and on which we can iterate.

You can look at the design doc that was shared to public-webapps, it's a
bit outdated but might give some information:
https://docs.google.com/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview

(Note: that doc is in the Documentation section in the chromestatus page
for some reasons, the Intent to Implement template doesn't include that
section.)

-- Mounir

[Philip Jägenstedt]

Thanks Mounir, that was a useful question that answers my questions!

Philip