Permissions API

[annevk]

• Specification Title: Permissions API
• Specification or proposal URL: https://w3c.github.io/permissions/

It seems that request() and revoke() were dropped so I suspect this is no longer controversial, but it came up in email with @marcoscaceres, @martinthomson, @jan-ivar, and @overholt.

The main question that came up in email is who gets to watch it.

[marcoscaceres]

I'd love for us to work more closely with the implementation team in Firefox on this - particularly because it's so dependent on UI/UX: any idea who inside Mozilla is maintaining the implementation? - I'd really like to get their take on the spec, and also see if there mochi tests that we should convert to web platform tests.

There are other aspects that are being proposed around allowing test-automation for this API (I've not followed closely at what is being proposed, but it feels kinda important and something Mozilla could also benefit from).

[dbaron]

Two policy/position issues I'd like to raise:

• I think it would be good to have something written down about our position on request() and revoke(), given that I've seen it come up a number of times that "Mozilla" has blocked those from being in the spec. It would be useful to at least have the rationale for the opposition to those linked from this issue (since this issue will, in turn, be linked from the standards-positions table).

• I'd like to be clear that endorsement of the Permissions API doesn't imply endorsement of all of the things that it describes permissions for. It's good that the spec is being thorough in that regard, but I don't want to include all of them in the process of evaluating it.

Also, one technical issue I'd like to bring up is whether we're OK with the onchange event handler mechanism on PermissionStatus and related lifetime issues. It's not clear to me when the PermissionStatus and its event handler can/should be garbage-collected. If the event handler has detectable side-effects (which seems likely to be the primary use of such an event handler, and therefore important to consider), it seems like garbage collecting the PermissionStatus and its event handler prior to the destruction of the page could lead to detectable differences, which seems to imply it should never be garbage-collected. However, this is not how event handlers normally work; the presence of an event listener on an element normally doesn't keep the event alive. But in this case it seems to require the awkward programming pattern of doing something explicitly to keep the PermissionStatus object alive so that the event handler will work; this pattern has been a footgun for authors in the past (at least in Gecko internal code, where I've seen it; I don't recall it being a thing on the Web). Furthermore, if they are intended to be garbage-collected, are we OK with doing that via the cycle collector on workers these days? And is the correct lifetime behavior here considered to be well-defined by the prose already in the specification, or does it need to be stated more explicitly? /cc @smaug----

It also seems like it might be less than ideal that the event handler doesn't get any information about the change, but instead has to run query() again.

There are various editorial things I could quibble with about the spec, such as:

• writing yet another definition of "powerful feature"
• inconsistency in the way the different permissions are presented (and the lack of precise use of the "boolean feature" definition)

I suppose I should file issues when I have time...

Beyond that, I think we should list this in the table as participating assuming there aren't any issues with the lifetime/GC thing above.

[jan-ivar]

our position on request() and revoke()

I think the reasons are covered well in w3c/permissions#83 and w3c/permissions#46.

If I'd attempt to summarize our position, it would be: Keep the user in charge.

Users are solely in charge of their permission settings. User permissions are managed by the user through their user agent UI. These user wishes are not subject to alteration by sites.

Users agents own the problem of making the user experience pleasant at whatever chosen level of privacy the user is comfortable with (be it one-shot or persistent permissions). Our user agent works for the user, not the site.

We want users to feel in charge of when permissions are doled out. This means combating frivolous permission escalation, gating, and making sure the user has as much context as possible to predict what value will be added, if any, and what the experience will be if answering "no".

These are areas of differentiation for browsers, typically not subject to specs.

Chrome's model of conflating permission elevation with feature requests, is too limited for Firefox.

We want to promote Web APIs that request features, not permissions. This guides web developers down a path that helps maximize the amount of context given to users when user agents (not sites) ask them for permission, and hopefully helps minimize the scope of the decision as well.

Sites cannot be trusted to manage permissions for the user. User permissions are inconvenient even for well-meaning sites.

Permission bundling has none of the qualities above, and is therefore harmful to users and the web.

[smaug----]

Sounds like PermissionStatus should be treated like WebSocket or EventSource etc. so that event listener does keep the object alive
https://html.spec.whatwg.org/#garbage-collection-3

I filed w3c/permissions#170 since I didn't immediately find other relevant spec issue.

[johannhof]

I fully agree with Jan-Ivar on keeping users in charge of their permissions and preventing permission management from becoming a thing that websites are very preoccupied with.

I'd love for us to work more closely with the implementation team in Firefox on this - particularly because it's so dependent on UI/UX: any idea who inside Mozilla is maintaining the implementation?

@marcoscaceres Sorry for showing up late to this, but I'm happy to help you out with any Firefox implementation questions, especially around permissions front-end. I feel like there's a lot in this spec that we just kind of do in Firefox without having it implemented explicitly by the spec and there are a lot of undefined areas on e.g. denied permission scope, persistent permission management and permission doorhanger UI details. I guess most of that is intentional because:

This is intentionally vague about the details of the permission UI and how the UA infers user intent. UAs should be able to explore lots of UI within this framework.

https://w3c.github.io/permissions/#ref-for-prompt-the-user-to-choose

I'm not sure how well a wptest transition would work since it's always browser chrome tests interacting with our own UI.

[marcoscaceres]

Thanks @johannhof. I've moved onto working on an unrelated API, so I'm not tracking what's happening with permissions. I'm hoping others are able to track the work.

[dbaron]

So, given the new set of positions on the table, I'm inclined to think that this should be categorized as worth prototyping, though if somebody wants to make an argument for important or non-harmful I'd be interested in hearing it.

[jan-ivar]

Until the following sentence has been struct from the abstract, I'd consider it harmful.

"It also defines an API to allow web applications to query and request changes to the status of a given permission."

Additionally, (and I may be in the minority here), I'm not swayed by the value-add of even letting sites read these settings. Can't sites already use cookies to track whether they've been blocked in the past?

[dbaron]

Given the wide latitude for user agents in how they manage permissions, I don't see how anything guarantees (or should guarantee) that the scope or lifetime of permissions matches that of cookies, so I don't think suggesting the use of cookies is a good idea. (Then people would have to write libraries that represent the different permission models of the different browsers and then store and match appropriate cookies to check against the browser-specific policy... which will still fail if one of them changes due to, say, user intervention.)

[jan-ivar]

If we start with the assumption that sites deserve the exact user permission information, then sure.

I'd argue they don't. I suspect the main use-case for this spec is priming the user to say yes.

Sites (rightly) suffer from rejection anxiety, because they risk getting permanently blocked by browsers, especially Chrome, where rejection is permanent by default (ignoring the tiny [×] in the corner of the permission prompt. Firefox is more lenient, requiring explicit user-opt-in before blocking a site permanently past page-refresh.)

This puts pressure on sites to preempt browsers' permission handling with their own UX.

With WebRTC, this typically manifests by sites triaging users to a pre-call page separate from the room, where the site takes the time to explain to the user why the site wants their permission. This isn't all bad, at least for first-time visitors.

But here's why sites should use a cookie for this: All they should care about is "have I explained our permission needs to this user?" (erring on explaining more often than not)?

Instead, what we see happening is sites use the permission signal for this (works in Chrome!) This is bad, because it treats repeat privacy-sensitive Firefox users as first-time visitors, creating a permanent slow-lane just for them (web bias toward Chrome's users and permission model). This also artificially inflates the benefits of opting in to persistent permissions (more streamlined experience), just so the website can remember them so they won't be treated like second-class web citizens.

Users who resist opt-in to persistent permissions already suffer a time-cost for doing so (the prompts). Advocating for this user group, I think would be healthy for the web and align with our privacy mission.

[annevk]

Can't sites already use cookies to track whether they've been blocked in the past?

This does not work. When users clear cookies we don't clear permissions (intentionally). And for APIs such as notifications we have advocated they use this as a signal to explain the permission to the user. That media works differently is a tad unfortunate and is perhaps another argument against having a centralized API for permissions.

In any event, don't we already ship query()? It seems we're already committed to this API to some extent.

[jan-ivar]

I think I clarified better in my last comment. The site sets the cookie to say "I've primed this user (explained our permission needs to them)". If cookies are cleared, treat them like first-time visitors again. Being conservative here seems in the site's self-protective interest, since we don't know why the user cleared cookiens, and even in line with user expectations, so I wouldn't worry about optimizing the corner case of unnecessary priming when cookies are cleared.

Firefox implements query() only for a sub-set of features atm, "camera" and "microphone" are not among them.

navigator.permissions.query({name: "geolocation"}).then(({state}) => console.log(state));
Promise { <state>: "pending" }
prompt

navigator.permissions.query({name: "camera"}).then(({state}) => console.log(state));
Promise { <state>: "pending" }
TypeError: 'name' member of PermissionDescriptor 'camera' is not a valid value for enumeration PermissionName.

navigator.permissions.query({ name: "microphone" }).then(({ state }) => console.log(state));
Promise { <state>: "pending" }
TypeError: 'name' member of PermissionDescriptor 'microphone' is not a valid value for enumeration PermissionName.

[dbaron]

We had a good discussion today, and @martinthomson's PR updated this to important with the following detail:

Mozilla believes that the ability to work with user permissions is critical for user agency. There are certain aspects of the API that are not suitable for the permissions model used in Firefox and so we would like to work on improving several aspects of the API. In particular, we think that the way that status of permissions needs to more accurately reflect the different states that exist or could exist. We also think that the interactions with Feature Policy need to be better clarified. We're committed to fixing this, because permissions has become critical in making the web a more capable platform and it is important to ensure that we preserve user control over their online experience.