Intent to Implement and Ship: Permissions API

[Birunthan Mohanathas]

Hi,

navigator.permissions.query has been Nightly-only for a few weeks. We
are going to let it ride the trains. Other parts of the spec (such as
Permissions.request) will be implemented when the spec is complete.

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.

Use cases: See https://docs.google.com/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview?pli=1#heading=h.yeaa13evs6re

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1105827

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

Platform coverage: All platforms

Target release: Firefox 43

Other vendor implementations: Supported by Chrome (43)

Cheers,
Biru

[Jonas Sicking]

I'm less psyched about Permissions.request, but looking forward to
having .query ship!

Does it also work in workers?

/ Jonas

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Birunthan Mohanathas]

On 22 August 2015 at 06:24, Jonas Sicking <jo...@sicking.cc> wrote:
> Does it also work in workers?

Not yet, that was left for bug 1193373.

[Ehsan Akhgari]

On 2015-08-21 11:03 PM, Birunthan Mohanathas wrote:
> Hi,
>
> navigator.permissions.query has been Nightly-only for a few weeks. We
> are going to let it ride the trains. Other parts of the spec (such as
> Permissions.request) will be implemented when the spec is complete.

Just to double check, do we support "geolocation", "notifications" and
"push"? If yes, SGTM to ship this!

[Birunthan Mohanathas]

On 24 August 2015 at 09:47, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Just to double check, do we support "geolocation", "notifications" and
> "push"?

Yep!

[Anne van Kesteren]

On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
<biru...@mohanathas.com> wrote:
> 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.

I'm not a big fan of this API.

1) It doesn't map well to what browsers do internally. Rather than
simple strings it uses some kind of convoluted dictionary design.
2) It would be better to simply expose the permission status of a
particular feature near a particular feature. If you want to know
whether geolocation is already granted you should just be able to call
navigator.geolocation.permission() or some such.
3) It seems the API is evolving in ways to also request permission
without then directly using that permission. It's not clear that is a
good idea.


--
https://annevankesteren.nl/

[Mounir Lamouri]

On Tue, 25 Aug 2015, at 07:57, Anne van Kesteren wrote:
> On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
> <biru...@mohanathas.com> wrote:
> > 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.
>
> I'm not a big fan of this API.
>
> 1) It doesn't map well to what browsers do internally. Rather than
> simple strings it uses some kind of convoluted dictionary design.

Browsers internal implementation can change. The API will have to stay
as it is in the long run. It's better to have an flexible API that would
allow different implementation strategies.

> 2) It would be better to simply expose the permission status of a
> particular feature near a particular feature. If you want to know
> whether geolocation is already granted you should just be able to call
> navigator.geolocation.permission() or some such.

This isn't working for some APIs. For example, MIDI has a very basic
navigator.requestMIDIAccess(). Should we start having
navigator.queryMidiAccess()?

> 3) It seems the API is evolving in ways to also request permission
> without then directly using that permission. It's not clear that is a
> good idea.

This is something that is already doable. If a webpage calls
navigator.geolocation.getCurrentPosition(), it doesn't need to do
anything with the position (this can apply to roughly any API). The
Notififcations API has an explicit call for requesting too. Furthermore,
allowing requests will open some new possibilities like requesting a
'paste' permission which can't be done today.

-- Mounir

[Anne van Kesteren]

On Tue, Aug 25, 2015 at 11:06 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> Browsers internal implementation can change. The API will have to stay
> as it is in the long run. It's better to have an flexible API that would
> allow different implementation strategies.

Even if you have only strings today, there's several ways you could
imagine changing that in the future if the need indeed arises. We've
learned long ago that we shouldn't ship complicated frameworks where a
simple API would do.

> This isn't working for some APIs. For example, MIDI has a very basic
> navigator.requestMIDIAccess(). Should we start having
> navigator.queryMidiAccess()?

Sure, or navigator.midiPermission().

>> 3) It seems the API is evolving in ways to also request permission
>> without then directly using that permission. It's not clear that is a
>> good idea.
>
> This is something that is already doable. If a webpage calls
> navigator.geolocation.getCurrentPosition(), it doesn't need to do
> anything with the position (this can apply to roughly any API). The
> Notififcations API has an explicit call for requesting too.

The Notifications API is a special case as is noted in its
specification. It's one of the few cases where we decided this was
acceptable.

> Furthermore,
> allowing requests will open some new possibilities like requesting a
> 'paste' permission which can't be done today.

If we do indeed need that we could add an API for it. But we should
first carefully consider if another approach is not better.


--
https://annevankesteren.nl/

[Martin Thomson]

On Tue, Aug 25, 2015 at 2:12 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
>>> 3) It seems the API is evolving in ways to also request permission
>>> without then directly using that permission. It's not clear that is a
>>> good idea.
>>
>> This is something that is already doable. If a webpage calls
>> navigator.geolocation.getCurrentPosition(), it doesn't need to do
>> anything with the position (this can apply to roughly any API). The
>> Notififcations API has an explicit call for requesting too.
>
> The Notifications API is a special case as is noted in its
> specification. It's one of the few cases where we decided this was
> acceptable.

On this point, I agree with Anne. Notifications doesn't get the
option of an in-context request, and what we have there is the best we
could do at the time. It is possible that we could do better; I've
not given up on that just yet.

>> Furthermore,
>> allowing requests will open some new possibilities like requesting a
>> 'paste' permission which can't be done today.
>
> If we do indeed need that we could add an API for it. But we should
> first carefully consider if another approach is not better.

I'd like to more directly encourage that as well. Asking permission
in context has its risks, but out of context has relevancy problems.
I'd rather we carefully examine every instance where we are tempted to
ask users questions, because I don't believe that asking questions
like that is good.

Reducing the friction for adding new ways to bother users with
questions is a drawback of the API.

[Jonas Sicking]

On Mon, Aug 24, 2015 at 11:57 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Sat, Aug 22, 2015 at 5:03 AM, Birunthan Mohanathas
> <biru...@mohanathas.com> wrote:
>> 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.
>
> I'm not a big fan of this API.
>
> 1) It doesn't map well to what browsers do internally. Rather than
> simple strings it uses some kind of convoluted dictionary design.

I agree that this is somewhat unfortunate. But in practice it'll mean
that the syntax will be

navigator.permissions.query({ name: "foo" })
rather than
navigator.permissions.query("foo")

which I think in practice is not that big of a problem.

> 2) It would be better to simply expose the permission status of a
> particular feature near a particular feature. If you want to know
> whether geolocation is already granted you should just be able to call
> navigator.geolocation.permission() or some such.

I'm not convinced of this argument. I think this runs the risk of each
API having subtle differences in the querying which IMO is even worse.

Most importantly, I think this API fills a need long asked for by
developers. I.e. while geolocation and similar APIs have taken their
sweet time solving this problem, this API solves the problem here and
now. That's much more valuable than arguing over the exact syntax.

> 3) It seems the API is evolving in ways to also request permission
> without then directly using that permission. It's not clear that is a
> good idea.

I don't see that this risk is higher with a dedicated API compared to
a per-API solution.

But I agree that we should make it clear that we do not intend to
implement a request API.

/ Jonas

[Ehsan Akhgari]

On 2015-09-01 9:57 PM, Jonas Sicking wrote:
> But I agree that we should make it clear that we do not intend to
> implement a request API.

There is actually a valid use case for a request API. It has become
clear that we need to expose pasting functionality to the Web, and the
most natural way of doing so is document.execCommand("paste"). This
operation however cannot be exposed without permission because of
privacy reasons. And this is an API where modifying it to add support
for requesting permission doesn't make sense.

AFAIK right now the Chrome team is experimenting with creating a
solution for this use case using the request API. If they manage to
come up with a good UX, I think we need to implement it (at least for
the "paste" permission) as well.

Cheers,
Ehsan

[Mounir Lamouri]

Correct.

I don't want to derail the thread and it should probably be a question
for later but I don't understand why websites shouldn't be able to
request permissions when Notifications allows it, Persistent Storage
(latest version) allows it and for the other API it is possible to
actually write a polyfill to request permissions (eg.
navigator.geolocation.getCurrentPosition(function(){}) actually request
the permission). We are just making web developers life harder by
requiring them to request permission indirectly.

There are other reasons why request() would benefit the platform. For
example, being able to request permission for a feature that is used in
some kind of Workers (where permissions can't be requested). Though,
again, I don't want to derail the thread.

-- Mounir

[kale.w...@stu.white.k12.ga.us]

> Turn this off