questions on query()

[ShijunS]

Here are some questions on the query() method - some might just be implementation issues, while others might need further consideration in the spec. @jyasskin, it'd be nice to know your takes on them.

• When a device is removed from the system, would that be any onchange event fired? There seems no valid state in that case for that device.
• When a persistent permission is stored for a device class, would temporarily unplugging all devices in the class change anything to permission state?
• When a device is removed from or added to the system, the permission state for the device class can potentially change. How would the apps distinguish the change and actual permission changes by the users manually?
• In a per-use permission mode, if a device is in use based on a user granted (one-time) permission, what will be the permission state returned by query()? What will it mean for the next access to the same device if it returns "granted"? Or, how would app tell the difference if the returned value is not "granted" while the device is actually being used?

BTW, is there any security concern for apps to silently detect a granted permission - especially any per-use or short-term permissions? Meanwhile, it'd be quite awkward if query() triggers a permission UI to allow the page to query. I expect the security experts here must have given thoughts on this one already, wonder if anyone could point me to discussions in the mailing list or github.

[jyasskin]

1. If a user has granted access to a device, and then they remove and re-add it, would the site still have permission to access the device? If so, I think its permission state should still be "granted" while it's unplugged. Folks shouldn't assume that having permission to access a device means access will always work. We see this in Bluetooth also: having a live BluetoothDevice object doesn't mean the device is in range, and you can get NetworkErrors when trying to reconnect to it.
2. I'm not sure exactly what a device class is—I assume it's like "all devices that produce video streams"? If that's correct, then like in question 1, I think unplugging all devices of a given class shouldn't affect the permission state.
3. The browser should only change the permission state for a device or device class if it has some indication that this is what the user intended to do. That can happen without the user's explicit interaction (for example, the user might want the browser to use a web service to identify untrustworthy sites, and then auto-revoke those sites' permissions), but because it's a reflection of the user's intent, I currently don't think there should be a different signal to the site. I could be wrong there, in which case we could add fields to PermissionStatus.
4. We have the "ephemeral" model used by Firefox and the "temporary" or "per-realm" model used by Edge and Safari.
   • In "ephemeral" mode, which you can see by going to https://permission.site/ and clicking "Location" multiple times, query() should always return "prompt", because any request for the feature will prompt the user. Once Firefox's https://bugzilla.mozilla.org/show_bug.cgi?id=1270572 is implemented, then query() should probably return "granted" while a stream is open, and switch that to "prompt" when the stream is closed. I won't argue that this permission model makes sense, but I do think query() can accurately represent it.
   • In "per-realm" mode, query() in realm A should initially return "prompt". If the user grants permission, query() should switch to returning "granted" in realm A, but stay with "prompt" in realm B. If the tab holding realm A is reloaded, which leads to it holding realm C, then realm C's query() should return "prompt". Does that make sense? https://github.com/w3c/permissions/pull/114 makes this a little more explicit, but nobody's reviewed it yet.
5. Yes, there's a privacy concern for apps silently detecting a granted permission: https://github.com/w3c/permissions/issues/52. I don't think we've adequately described that issue in https://w3c.github.io/permissions/#privacy-considerations yet. I don't think Chrome and Firefox plan to have query() prompt by default to address this, but I'm not certain of that for either browser. There might be a browser-wide setting to turn on such prompts.

[jyasskin]

It also makes sense to fix the spec and/or add examples to clarify all of this. I'll get around to that eventually based on just the questions here, but would love pull requests or pointers to particular places in the spec that need improvements.

[jan-ivar]

Note that with http, Edge appears to use the same "ephemeral" model used by Firefox. FWIW this behavior is (or at least was) mandated by the mediacapture spec, so Edge's https behavior here might be considered non-compliant. @ShijunS thoughts?

[ShijunS]

@jyasskin, thanks for the detailed feedback! It seems issue #52 could be a blocking factor if not resolved.
A couple quick notes to facilitate further discussions

• in case-1, the deviceId can be different even if the same hw device is plugged-in again.
• in case 2, yes, your definition of "device class" is reasonable.

@jan-ivar is correct about the Edge http model. The https model is still evolving, so a work-in-progress.

[jyasskin]

For case 1, in the "per-realm" model, if https://example.com/ is granted access to device "abcd", "abcd" is disconnected, and the UA knows that it will get a new deviceId if it's plugged in again, then

1. Whether you return "prompt" or "granted" from query() after "abcd" is disconnected, the page won't actually be able to access the device, so to some extent it doesn't matter.
2. Since you know that "abcd" will never appear again, you might be able to let the page save some resources by changing "abcd"'s state back to the default (probably "prompt").

If the UA doesn't know that the physical device will get a new deviceId, you probably have to leave the device as "granted" just in case.

In "ephemeral" mode, you'd revoke as soon as all active streams stop, which I assume happens automatically when the device is disconnected.