Is more needed regarding revocation?

[stefhak]

This is part of Nick Doty's feedback after reviewing how his comments during LC have been addressed. What Nick says:
"I believe there were open questions on both user-side revocation and site-side revocation of persisted permissions.

On user-side revocation, Rigo had noted that RFC 7478 mandated user agents provide the capability for users to revoke permissions, and we weren't sure that had been translated into draft-ietf-rtcweb-security-arch. I think I may have dropped the ball on not creating a pull request on that point; if it's still useful for me to do so, let me know. The Media Capture spec assumes that user-side revocation is required, though I don't think it introduces any specific normative requirement.
https://lists.w3.org/Archives/Public/public-media-capture/2015Oct/0061.html

I raised the concern that sites should also have a way to revoke persisted permissions that they may have received, as one way of limiting the risk to their users where they requested camera access in a way that might have just been one-time and subsequently had a security breach of some kind (like a reflected XSS attack). The wide review document suggests this is resolved via the Permissions API:

We reworked our permission system to be based on the Permission API, where revokation is addressed

However, I couldn't find any references to the Permissions API in the Media Capture and Streams document. Is there any requirement or expectation that user agents that implement the Media Capture spec will also implement the corresponding Permissions API functionality? Or an example for how sites can use the Permissions API to query or revoke permissions using that API?

The current editor's draft of the Permissions API does include a PermissionsDescriptor for camera and microphone, and a method for revoking permissions. The Permissions API is at least under development for both Chrome and Firefox:
https://platform-status.mozilla.org/#permissions
Although I don't think the current Firefox patch includes camera and microphone among the supported permission names:
https://bugzilla.mozilla.org/show_bug.cgi?id=1105827

To the extent that it's unclear whether sites will be able to revoke their Media Capture permissions using the Permissions API, I remain concerned about this point. That said, maybe the fact that the Permissions API editor's draft has included it is a promising sign and the Privacy Interest Group could provide feedback on the Permissions API regarding this point."

[dontcallmedom]

/cc @npdoty

Right, I realize that the disposition of comments document was ahead of its time, since the work of integrating and referencing the permission API has still to be merged in the media capture and streams spec (the pending pull request is #319) — I understand this is planned for merging very soon, but @npdoty it would be great if could check whether that PR indeed addresses your point above.

Clearly, implementations haven't caught up with this since it's (demonstrably :) a fairly recent proposed change; but I do believe it addresses revocation.

[alvestrand]

With the integration of the permissions spec, can we claim that revocation is a permissions management issue?

[stefhak]

@npdoty do you think this Issue has been addressed now ( #319 has been merged, the permission spec has been updated)?

[npdoty]

Section 3 "Terminology" says:

The terms permission, retrieve the permission state, request permission, delete a permission storage entry and create a permission storage entry are defined in [permissions].

However, "delete a permission storage entry" is never used in the document.

The Working Draft version of the Permissions API that is referenced also doesn't include the definitions of "delete a permission storage entry" or "create a permission storage entry", although they're present in the latest editor's draft.

The Privacy and Security Considerations section does not make reference to site revocation of permissions using the Permissions API. The Note suggests that:

Developers of sites with persistent permissions should be careful that these permissions not be abused.

However, sites do not control whether permissions are persisted or not (which was what prompted this issue); every user of this API needs to take care that these permissions are never later abused on their site.

(Also, "permanent permissions", "persisted permissions", "stored permissions" and "persistent authorization" are used apparently interchangeably. Is that intentional?)

[jan-ivar]

I'm a little confused why, past last call, spec editors are adding normative references to a brand new spec just starting to form, with little to no list discussion. What problem is being solved specifically?

On revocation, I know we've previously covered that (perhaps vaguely) as "follow clear cookies". Has this changed significantly with this new text? If so, could someone explain?

Note that the Permissions API contains web-facing APIs for revoking and requesting permission that are still controversial.

[alvestrand]

I think this is a cross-spec issue; we need to say that when a permission is revoked, that also stops active usage of that permission, such as a track that is sourced from the device.
Given the way I solved "temporary permission", it means that it makes sense to revoke a permission that is not currently granted; this argues for putting the "revoke" stuff in the Mediacapture doc in addition to being in the permissions API doc.

Comment to Jan-Ivar: The question of permissions API integration was introduced by Mathieu Hoffman on the list on September 3 2015, and I formulated a plan for addressing the question on November 16 of the same year. This effort hasn't exactly been invisible.

[jan-ivar]

we need to say that when a permission is revoked, that also stops active usage of that permission, such as a track that is sourced from the device.

@alvestrand I'm not impressed by the clarity of this new terminology. In the above sentence, I can't tell whether you're talking about persistent permission or access.

The permissions API is a web-facing (still read-only!) API that seems to define the status of a permission to be one of 'prompt', 'granted', or 'denied'. If I may reverse-engineer a definition out of that, then a "permission" in that API is how the UA will respond to a future request for access.

It should be clear to anyone that this is a persistent permission definition.

To "revoke permission" then really means to "revoke persistent permission", specifically: change 'granted' back to 'prompt', and that is the only thing it means.

The Permissions API is really the Persistent Permissions API.

Why terminology matters:

When a user chooses "Stop sharing" in the "in-call" Firefox doorhanger, they are _revoking access_. Sharing == access. They implicitly also revoke persistent permission if persistent permission has been 'granted' to the site (sets it back to 'prompt'), because UX is hard, and Mozilla thought this was the most conservative user-protecting behavior.

Firefox doesn't currently have an about:permissions page (it was removed), but when we did have it, "revoking persistent permission" in it (that is: changing from 'granted' to 'prompt' didn't stop any active tracks. Why should it? I don't see how that follows user intent.

Now compare my terminology above with yours:

Given the way I solved "temporary permission", it means that it makes sense to revoke a permission that is not currently granted; this argues for putting the "revoke" stuff in the Mediacapture doc in addition to being in the permissions API doc.

A "temporary permission" doesn't make any sense to me at all.
Having to "revoke a permission that is not currently granted" doesn't make any sense to me at all.

These seem to be clarity problems coming from poor terminology, specifically: conflating persistent permission with access.

[jyasskin]

If you treat "permission" and "access" as synonyms, does that clarify anything? You'll note that folks talk about "temporary permission" and "persistent permission" when they want to distinguish the two, just like you might talk about "temporary access" vs "persistent access".

Firefox doesn't currently have an about:permissions page (it was removed), but when we did have it, "revoking persistent permission" in it (that is: changing from 'granted' to 'prompt' didn't stop any active tracks. Why should it? I don't see how that follows user intent.

That seems wrong: If I decide that foo.com shouldn't have access to my camera, and I revoke it from some global menu, I certainly don't want it to keep recording me from that tab I still have open. Any specs in this area should, of course, allow Firefox to implement such bad UI, but that doesn't mean we should change the terminology to pretend it's good.

[jan-ivar]

@jyasskin I'd go out on a limb and suggest that when arguments rely on conflation, they're rarely good.

By "access" I mean the site can access the user's camera or mic. By "persistent permission" I mean the UA policy setting (prompt, grant, or deny) for dealing with new requests for access. If you are using any other terms, please define them.

Another mistake: Note how 'prompt' is a command, whereas 'granted' and 'denied' are not. If this a setting for how the UA is to respond to new requests, then they should all be commands. We should rename them to 'grant' and 'deny' (or even 'auto-grant' and 'auto-deny' if you will) to make this clearer.

If I decide that foo.com shouldn't have access to my camera, and I revoke it from some global menu, I certainly don't want it to keep recording me from that tab I still have open.

Did you see that I showed two examples, and how they were different? The first one (the "in-call" doorhanger) deals directly with any current cam+mic access. The second (global "about:permissions") dealt with UA policy settings for new requests, whether to auto-grant, auto-deny or prompt.

We could certainly entertain conflating the two in UX, but not in programming specs please. The language we use to discuss and specify with needs to be sharp and clear.

Chrome is no different. Try this:

1. In Chrome, go to https://jsfiddle.net/srn9db4h/ and see camera turn on.
2. Click on the camera icon in the URL bar
3. Select "Always block camera and microphone access" and hit Done.

Did the camera go away?