Intent to put Permission API's .revoke() method behind a pref

[mar...@marcosc.com]

Summary: It seems we prematurely shipped the .revoke() method on the Permissions API before it was stable or deciding if we even wanted it in the platform.

For those that don't know it: navigator.permission.revoke() allows a site to self-revoke a permission after a user has granted that permission. For example, a user may grant foo.com access to geolocation, but upon signing out of a site, a site might call .revoke({name:"geolocation"}) so that the next user to log into the site doesn't automatically get access to geolocation (as permissions are bound to origin).

A few folks (who can chime in) working on the standard have raised concerns about the API, so we would like to suggest we put it behind a pref for now. Particularly, using in-browser user profiles can handle the above use case without a site taking away a user's decision.

There is consensus that .query() is beneficial, so that one can remain.

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

Link to standard:
https://w3c.github.io/permissions/#dom-permissions-revoke

Platform coverage: All.

Estimated or target release: Firefox 51

Preference behind which this will be implemented:
dom.permissions.revoke.enable

[Martin Thomson]

Sounds like a good plan.

(For those who might be wondering: .request() was never exposed.)

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

[Anne van Kesteren]

On Wed, Aug 17, 2016 at 6:48 AM, <mar...@marcosc.com> wrote:
> There is consensus that .query() is beneficial, so that one can remain.

Is there really?

The main problem with query as I see it is that since we haven't
agreed on what permissions are keyed on, an application cannot really
do anything with the answer it gets from query. E.g., communicating
the answer with other open tabs and then attempting to use the
permission there is futile for certain permissions. That kind of thing
would only work if they are all origin-keyed, but some are per
session, some are scoped to the top-level browsing context, etc.

(I support not exposing revoke() though. Was there even an intent to
ship for that?)


--
https://annevankesteren.nl/

[Martin Thomson]

On Wed, Aug 17, 2016 at 5:02 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> The main problem with query as I see it is that since we haven't
> agreed on what permissions are keyed on, an application cannot really
> do anything with the answer it gets from query. E.g., communicating
> the answer with other open tabs and then attempting to use the
> permission there is futile for certain permissions. That kind of thing
> would only work if they are all origin-keyed, but some are per
> session, some are scoped to the top-level browsing context, etc.

Are you suggesting that .query() has terrible flaws or that it is
completely beyond hope of fixing?

I agree that the keys are unclear[1]. But isn't that something that
can be more easily addressed by opening an issue on the spec?

[1] At the moment, the only sensible thing that can be said is that if
you had replaced the .query() call with a call to the corresponding
API, then it would not have failed due to a permission error. That
implies realm+instant-in-time are the keys. This is - of course -
super-useful in the sense that it is left to speculation about how a
result might be applied to predict future behaviour.

[Anne van Kesteren]

On Wed, Aug 17, 2016 at 9:13 AM, Marcos Caceres <mar...@marcosc.com> wrote:
> Well, it covers the 80% case (specially on mobile, where tabs are not
> at useful). But yeah... the model is not there :(

That is a good point. When isolated to a browsing context it's still
very useful information for website UX.


> We should maybe also pref .query() too... wdyt?

The main question I have is whether we ever want more than three
states, to indicate something about the scope of the permission. But
maybe we could have a new call for that.


> I think it slipped through with:
> https://groups.google.com/d/msg/mozilla.dev.platform/7RnCrXoXdG4/Oy84atEoKgAJ
>
> We might need to be more careful in the future about granularity of
> intent to ship to particular methods.

Interesting, I guess I didn't realize that covered more than just
query(). If we ship a subset of an API it probably would help to be
clear, indeed.


--
https://annevankesteren.nl/

[Martin Thomson]

On Wed, Aug 17, 2016 at 5:34 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> Interesting, I guess I didn't realize that covered more than just
> query(). If we ship a subset of an API it probably would help to be
> clear, indeed.

Well, it only mentioned .query() explicitly, but then said "other
parts will be implemented". That's what we need to watch out for.

The discussion was negative on .request(); I guess that .revoke() was
implemented because no one objected to it specifically.

[Marcos Caceres]

On August 17, 2016 at 5:02:07 PM, Anne van Kesteren (ann...@annevk.nl) wrote:

> On Wed, Aug 17, 2016 at 6:48 AM, wrote:
> > There is consensus that .query() is beneficial, so that one can remain.
>

> Is there really?

Well, the use case at least: that a developer should not need to
actually invoke the API to check if permission has been granted.

> The main problem with query as I see it is that since we haven't
> agreed on what permissions are keyed on, an application cannot really
> do anything with the answer it gets from query. E.g., communicating
> the answer with other open tabs and then attempting to use the
> permission there is futile for certain permissions. That kind of thing
> would only work if they are all origin-keyed, but some are per
> session, some are scoped to the top-level browsing context, etc.

Well, it covers the 80% case (specially on mobile, where tabs are not
at useful). But yeah...  the model is not there :(

We should maybe also pref .query() too... wdyt?

> (I support not exposing revoke() though. Was there even an intent to
> ship for that?)

[Jan-Ivar Bruaroey]

I support putting .revoke() behind a pref (I would like to go further
and remove it since I find it problematic, but a pref is a start).

On 8/17/16 3:34 AM, Anne van Kesteren wrote:
> On Wed, Aug 17, 2016 at 9:13 AM, Marcos Caceres <mar...@marcosc.com> wrote:
>> We should maybe also pref .query() too... wdyt?
>
> The main question I have is whether we ever want more than three
> states, to indicate something about the scope of the permission. But
> maybe we could have a new call for that.

Good point. I'd support preffing .query() as well, but I don't have a
strong opinion.

FWIW I did propose additional states at one point to convey temporal
permissions to JS, e.g. "Allowed temporarily", but there was no support.

.: Jan-Ivar :.