Consider removing Permissions.revoke().

[martinthomson]

The introduction says:

The initial intent of this document was to allow web applications to request and revoke permissions explicitly in addition to querying the permission status. This is an aspect of the specification that was controversial thus removed from the current document in a spirit of incremental changes: settling on a small API that can be improved.

However, these exist in the document. Should they be removed? (I would say "yes".)

[mounirlamouri]

We discussed the addition of these methods in a webapp sec meeting and it was well received. I forgot to update the header of the document. Will do.

[martinthomson]

For the record, I think that request is a terrible idea. Revoke just doesn't make sense (see https://w3c.github.io/webappsec/specs/clear-site-data/)

[mounirlamouri]

What should I be looking at in that spec?

[martinthomson]

It clears state for a site, which (presumably) includes permissions.

[npdoty]

@martinthomson are you saying revoke doesn't make sense in this API because the functionality might be accomplished through an addition to Clear Site Data instead? Or that it's intentionally not present in Clear Site Data because revocation doesn't make sense in general?

[martinthomson]

@ndoty, it simply doesn't have a motivation that I understand. Why would an origin choose to invoke it? What value does a user obtain by providing an origin with this capability? Where is the quid pro quo?

[ndoty]

@martinthomson I think you meant to tag @npdoty.

[npdoty]

@martinthomson Origins might choose to revoke persisted permissions for reasons similar to why they might want to clear site data in general. For example, if a user logs out and a different user logs in, the site might want the new user to have the same controls and user experience as if permission had never been granted on that origin. Or a site might try to reduce the security risk on their site (either because they know they've suffered an attack, or because the permissioned functionality is no longer necessary and so the site generally wants to reduce surface) by explicitly revoking a permission that was previously requested and may have been persisted.

The user benefits from the site knowing when it makes sense, based on that application's logic, to revoke a permission. In the log-out scenario, the browser doesn't know that the user has changed.

I could see some users who want to override the behavior and I don't think the spec needs to (or could!) prevent that; as always, users can configure their agents how they wish.

[martinthomson]

The problem with revocation is that those reasons aren't particularly convincing, and it then results in more permissions requests from the site. That's either mildly annoying ("didn't I just say yes"), or hazardous (training users to click through without consideration).

Also, I disagree that sites want to do this. We see sites actually being unwilling to ask for permission, simply because a user might deny the request and that denial might then be permanent.

The new user argument is a bad one. That's why browsers have profiles. We're not great in that regard, but we're working on it.

As far as attack surface goes, that is what we have CSP for. If the site doesn't want a permission, and we think that's a valid thing to want, then a CSP directive is the right place for that.

[jyasskin]

@martinthomson Could you open a separate issue for removing request(), with an argument for doing so? We should discuss that somewhere we can focus on it.

@raymeskhoury do you have any opinions on removing Permissions.revoke()?

I think I'm favorably inclined toward removing it (at least for initial implementations of the spec), but even if we do that I think the spec should discuss the UA's right to revoke any permission (or any piece of a permission) at any time based on user signals. For example, the Web Bluetooth spec says:

The UA MAY revoke Bluetooth access to a device for an origin at any time based on signals from the user.

We could just ask each permission'ed spec to separately include text like that, but I'd rather try to say it once.

[raymeskhoury]

I think I agree - I don't see particularly compelling uses of revoke().

[mounirlamouri]

Both Chrome and Firefox have an implementation of revoke(). Removing it because it not "useful" sounds like a weak argument.

[jyasskin]

They're not shipped, so we don't need it in the spec just to reflect implementation practice. We generally try not to ship non-useful APIs, so if everyone agrees it's not useful, we should definitely remove it. I'm not sure everyone does agree: what venue's been discussing this API, from which we could pull more opinions?

[jan-ivar]

@martinthomson I agree with you in #46 (comment) that request is a terrible idea. Did you ever file a separate issue on it? Untangling permission request from access goes against the very idea of http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html.

Fyi the note in the introduction in your first comment here has since been removed in #79 for "consistency reasons"...

[npdoty]

@martinthomson

That's either mildly annoying ("didn't I just say yes"), or hazardous (training users to click through without consideration).

Also, I disagree that sites want to do this. We see sites actually being unwilling to ask for permission, simply because a user might deny the request and that denial might then be permanent.

Are you concerned about revoke() because you think it's going to be used too much or because it's going to be used not enough? I don't expect it to be used very frequently, but I think these use cases (like the use cases for Clear Site Data) are important even if they're not the most common.

The new user argument is a bad one. That's why browsers have profiles. We're not great in that regard, but we're working on it.

Every account-based web site I've used has a logout model, so that I can log out of my account and someone else can log in, without invoking a browser feature. (Personally, I don't know offhand how to change the browser profile on any of my desktop browsers, much less my mobile phone browsers. I use private browsing modes to approximate this functionality.) I would be honestly very curious to know if there are sites that don't have a logout flow because they expect users to manage cookies or browser profiles instead. Perhaps this will be the future model one day, but right now it seems like a very large fraction of sites want to be able to control the user experience so that one user can log out and another log in.

As far as attack surface goes, that is what we have CSP for. If the site doesn't want a permission, and we think that's a valid thing to want, then a CSP directive is the right place for that.

I'd be curious to know more about how this option would work. But the persisted permissions risk cases are specifically ones where the site does want the capability to request a permission sometimes (because they're using the camera briefly to take an avatar image of the user, say) but not all the time. It seems like making the site's CSP dynamic to all those situations wouldn't be the preferred way for the site to handle these use cases, but I'm not sure.

[npdoty]

@jyasskin I know it's been discussed in the Media Capture Task Force; revoking/delete permissions has been discussed there for getUserMedia Media Capture and Streams, which now includes a reference to this Permissions spec. We've also discussed this topic in the Privacy Interest Group (PING).

[jan-ivar]

@npdoty on Media Capture and Streams, lets not take some spec editors' desire to outsource terminology and internal browser algorithms, for whatever reason - something they are doing without any list discussion mind you on an API that's supposed to be 1.0 done - and confuse that with normative references to web-facing APIs of which there are none.

[npdoty]

@jan-ivar the reference to Media Capture and Streams was just a specific response to @jyasskin's question about which groups could be asked for input on the use of the API, not an endorsement of any particular design.

[jan-ivar]

@npdoty ah sorry, makes sense now.

[martinthomson]

@npdoty

Are you concerned about revoke() because you think it's going to be used too much or because it's going to be used not enough?

I think that if it is used at all, even on the same sort of schedule as a log out (to go to your analogy) then we get into user training territory.

Every account-based web site I've used has a logout model, so that I can log out of my account and someone else can log in, without invoking a browser feature.

This is an interesting analogy, but not one that holds up. I would consider this less of a temporary break in the way that logout is temporary, but more like giving a site your mailing address, then asking them to forget it and scrub their database of the info. Sure, you can type the address into a form again every time you log in, but why would a site give that information up?

[...] a CSP directive is the right place for that.

I'd be curious to know more about how this option would work.

The model is very simple. CSP allows a site to voluntarily relinquish certain capabilities. Usually, this is used to protect the server by also protecting the integrity of the page ("only load this JS", or "only load JS from here"). And yes, this can be (and often is) entirely dynamic.

[npdoty]

@martinthomson

Every account-based web site I've used has a logout model, so that I can log out of my account and someone else can log in, without invoking a browser feature.

This is an interesting analogy, but not one that holds up. I would consider this less of a temporary break in the way that logout is temporary, but more like giving a site your mailing address, then asking them to forget it and scrub their database of the info. Sure, you can type the address into a form again every time you log in, but why would a site give that information up?

I'm not sure why you prefer the analogy of deleting information that's already been sent to the server; that could be an interesting feature, but it's not what revoke() or the Permissions API is intended for, as far as I understand it. It isn't the user that's asking for information or permission to be scrubbed, this is an API invoked by the site. (Apologies, I think I'm just not understanding your example.)

I don't just mean logging out as an analogy but as a use case. Logging out isn't just temporary, it may also indicate a situation where a different user is using the same user agent and the site may want to provide the same first-time user experience to the new user. When one of my family members logs into a mapping application using my computer and browser, they're going to be surprised if the application can access their location without being prompted by the browser. A site could fix that surprising situation by indicating to the browser when a new user logs in that any previously persisted permissions should be revoked.

[jyasskin]

Since Firefox has shipped revoke(), and the objections here are coming from Mozilla folks, I'm going to assume everyone's now on-board with revoke() and close this issue.

[marcoscaceres]

Um, I wouldn't assume there is coordination between spec folks and folks implementing, unfortunately... sometimes, features get added by community members without any coordination with platform teams.

[marcoscaceres]

(e.g., no idea why Permissions API shipped to Firefox without being behind a pref... that should probably not have happened given how early on we are in the design of this API)

[jan-ivar]

For the record, I still think giving sites the ability to mess with user settings like this is a terrible idea. It's taking power away from the user, if ever so marginally, and I suspect request is not far behind, which is an even larger intrusion IMHO.

[marcoscaceres]

For the record, I still think giving sites the ability to mess with user settings like this is a terrible idea.

I agree. This seems bad.

It's taking power away from the user, if ever so marginally, and I suspect request is not far behind, which is an even larger intrusion IMHO.

I respectfully disagree. Requesting access is less privileged than calling any of the powerful feature APIs (because it does not have the side-effect of spinning up geo, or the camera, etc). So, if anything, calling straight up geolocation.getCurrentPosition() or getUserMedia() seems like a much larger intrusion than .request().

But I might be missing something?

[jyasskin]

We need the folks speaking on behalf of Mozilla to be able to affect the code Mozilla ships.

Let's discuss request() on #83 rather than here.

[marcoscaceres]

We need the folks speaking on behalf of Mozilla to be able to affect the code Mozilla ships.

FWIW, that's the team @annevk and I are on (DOM Team). We can get whatever fixed, but we need to have a shared understanding before we can go requesting code fixes.

It feels to me that we should probably put Permissions API behind a pref. in Gecko for now.

[jan-ivar]

@marcoscaceres That sounds like a good idea until we figure this out. @martinthomson WDYT?

[martinthomson]

I am not a fan of implementing anything other than query so some sort of guard on the api certainly seems like a reasonable idea to me. A pref or even google's experimental feature api. Neither implies a commitment to maintain the functionality in perpetuity.

[jan-ivar]

@jyasskin Can we reopen this then please?

[annevk]

I'm not convinced by the arguments put forward so far either. Clear Site Data serves a clear need and does not in fact remove any stored permissions. It's a way to help sites that have been locally compromised to regain control over that local copy.

The "logging out" scenario only makes sense if "logging in" would enable the permission again. I.e., if the user agent managed authentication. Even if we ever reach that point, it would be the user agent managing it, not the site, and thus also not necessitate revoke().

[npdoty]

@annevk per conversation with @martinthomson above: it's true that added user convenience could be possible if browser profiles or some other UA feature were widely used to handle authentication. However, that doesn't happen often today. In the meantime, sites can use logic specific to their situation to indicate to a user agent that a permission shouldn't be persisted; for example, if they know that the current user is new to the site and its functionality.

Clear Site Data isn't just for the use case of recovering from an attack. For example, see: Section 1.1.1 Signing Out.

[jan-ivar]

Having sites mess with what traditionally is understood to be user settings, undermines a user's trust in their agent. Poor site behavior can affect the user experience in a way that users will attribute to the agent, more so than e.g. broken js. Basically, a user may say "Why does Firefox keep bugging me about permission for this site when I've told it not to?"

[jan-ivar]

For "Super Secret Social Network" use private browsing.

[annevk]

Yeah, that seems like a bad example / use case.

[jyasskin]

Assuming the Mozilla spec folks get revoke() unshipped from Firefox, we've got @npdoty and @mounirlamouri in favor of revoke(), several Mozilla folks opposed, and I think me and @raymeskhoury thinking it won't cause harm, but also won't be used. What's the next step? An origin trial might be a good way to validate that there are actual sites out there that want to use the function. Would Firefox be willing to try that? @raymeskhoury would Chrome?

[jan-ivar]

@ShijunS Any thoughts from the Edge team?

[ShijunS]

I do see valid point from the concern raised by @martinthomson and @jan-ivar. User permissions are typically managed by users directly through the user agent UI and also very often kept in sync with the corresponding OS settings. The revoke() method can potentially make the user permission management more convoluted.

Meanwhile, we should keep in mind that user permissions could be given and stored as either "granted" or "denied". I don't think the revoke() process has been clearly defined for all the scenarios.

• When a user set a persistent "denied" to a particular permission, the user agent won't prompt any ask for the same permission again unless the existing permission entry is deleted by the user. It'd be a common sense that the website has no right to revoke that user decision, and it is not appropriate for the user agent to pop up a UI to ask again.
• When a user set a "granted" to the permission, it is not clear either what should be expected based on the spec. For instance, does "revoke" mean to delete the permission entry, or turn it to a persistent "denied"? As another question, let's assume the user agent pop up a UI to ask for revocation, can the user dismiss the ask and keep the permission as a persistent "granted"? Would that limit the goal for the website to reliably turn off the permission using the revoke() method?

I just started looking into the spec, so hope experts in the WG can help point out if I have missed anything.

[marcoscaceres]

Just an update, we've pref'ed off .revoke() in Firefox 51.