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"...