Clarify pan/tilt/zoom capabilities (#245)

[eehakkin]

Split from #248 per @youennf's request.

[beaufortfrancois]

@youennf

This PR reflects the current state of the explainer

If the PTZ permission is not granted, the pan, tilt, and zoom are not available as capabilities, settings, and constraints, even if the camera supports PTZ.

It is also reiterated in the fingerprinting section of the explainer.

1. Pan, tilt, and zoom hardware capabilities (e.g. min, max, step) and
   current settings are not exposed to websites unless the user explicitly
   grants PTZ permission....

[beaufortfrancois]

@eehakkin IIRC, it looks like getUserMedia({video: true}) for a site that was already been granted PTZ access won't expose PTZ capabilities. Is this intended?
I thought we would use the PTZ permission regardless of the originated PTZ permission request result.

[beaufortfrancois]

@youennf Exposing PTZ camera capabilities regardless of the PTZ permission status would increase fingerprinting. If that's something you want to allow a step by step permission flow, we could make it optional in the spec.
This may cause some confusions among web developers though sadly ;(

- In that case the UA MUST NOT expose the <a>tilt</a> value range.
+ In that case the UA MAY NOT expose the <a>tilt</a> value range.

[youennf]

@youennf Exposing PTZ camera capabilities regardless of the PTZ permission status would increase fingerprinting.

We should look at whether it is an issue with regards to passive and active fingerprinting.

We do not want to increase passive fingerprinting. Since PTZ setups are not widespread, it would be terrible to expose this capability without some kind of permission. MediaStreamTrack.getCapabilities is not possible since there is no capture track in that case. InputDeviceInfo.getCapabilities() should return an empty dictionary as per spec, so PTZ will not leak whatever the PTZ permission.

As of active fingerprinting (i.e. page is using the PTZ camera as a regular camera), we have some precedents to expose PTZ capabilities:

• Camera max resolution and frame rate are exposed
• In case a headset microphone is in use, the corresponding audiooutput device is exposed to the web without additional permission
• Camera device label is exposed and potentially leaks the exact device model

[beaufortfrancois]

If that looks okay to other parties, I'll update explainer fingerprinting section and the example that currently relies on getCapabilities() instead of getSettings() to know whether PTZ can be controlled.

@jan-ivar @reillyeon @riju What do you think?

[beaufortfrancois]

Chrome privacy team got back to me and told me Chrome would expose nothing about the users camera having PTZ until the user has accepted a permission prompt that mentions PTZ.
In that case, I'd be in favor of updating this spec PR with "MAY" instead of "MUST" regarding exposing PTZ capabilities. And I'll update the explainer.

@youennf How does that sound?

[youennf]

Let's go with MUST for now. It is better to start strict and loosen things if there is enough benefit/interest.

This PR looks fine to me for MediaStreamTrack.getCapabilities.

As of InputDeviceInfo.getCapabilities, it would never expose PTZ even if PTZ permission is granted.
Maybe that is fine for now, given https://github.com/w3c/mediacapture-main/issues/672

[eehakkin]

@eehakkin IIRC, it looks like getUserMedia({video: true}) for a site that was already been granted PTZ access won't expose PTZ capabilities. Is this intended?
I thought we would use the PTZ permission regardless of the originated PTZ permission request result.

That is not intended.
I referred to the "request permission to use" algorithm which returns the current permission state if the state is not "prompt" (i.e. if the state is either "granted" or "denied"). So AFAIU if a site with PTZ access does getUserMedia({video: true}), that results in requesting permission to use a PermissionDescriptor with its name member set to "camera" and its panTiltZoom member set to true and the algorithm immediate returns "grant" and therefore PTZ capabilities will be exposed.

Do you have a better wording suggestions?

[beaufortfrancois]

Looking at it, I've misread it. We may want to add a note to clarify it for people like me ;)

[riju]

Please add a note for better clarification.

[eehakkin]

Please add a note for better clarification.

Done.

[youennf]

So AFAIU if a site with PTZ access does getUserMedia({video: true}), that results in requesting permission to use a PermissionDescriptor with its name member set to "camera" and its panTiltZoom member set to true and the algorithm immediate returns "grant" and therefore PTZ capabilities will be exposed.

That is not my understanding of how things are specified.
If a page does getUserMedia({video: true}), UA will request permission to use with a descriptor { name: 'camera' }, but without any panTiltZoom member value. Then, getCapabilities will not be exposed according the current wording.
If you want that behavior, I would suggest to downscope the requirement to a MAY.

[jan-ivar]

The current MUST wording seems most web compatible to me. Apps that rely on previously granted and persisted permission might work in Chrome, but not other browsers.

[youennf]

Agreed MUST will forbid compat issues.
MAY is useful if some browsers would be willing to disclose PTZ capabilities if the website has camera permission.

[jan-ivar]

Disclosing PTZ if the website only has camera permission would seem to undermine the permission model developed here and in the ptz-explainer, where "Users can block and revoke the PTZ permission in UA settings".

These constraints may reveal the user to be in another web conference. Mitigations we've added for width and height in Firefox seem harder to repeat for pan, tilt and zoom e.g. if they control motors.

It seems simpler to demand sites specify e.g. {pan: true} every time for this info.

[youennf]

Disclosing PTZ

Are you referring to disclosing PTZ capabilities (i.e. the page knows a camera has PTZ support) or PTZ settings (i.e. the page can read/write actual device PTZ values)?
I am only referring to PTZ capabilities, not PTZ settings.

[jan-ivar]

You're right I was thinking about settings, but I think it would be weird to expose one and not the other.

And since this spec doesn't appear to standardize the allowable ranges for pan, tilt and zoom, don't the capabilities leak device info as well?

[youennf]

And since this spec doesn't appear to standardize the allowable ranges for pan, tilt and zoom, don't the capabilities leak device info as well?

It could be implemented so that the only device info leak would be whether this is a PTZ camera or a regular camera:
If getUserMedia selects a regular camera, capabilities/settings would not list PTZ.
If getUserMedia selects a PTZ camera while PTZ is not requested, PTZ capabilities range would be [0,0] and PTZ setting values would be 0.
If getUserMedia selects a PTZ camera while PTZ is requested, PTZ capabilities and settings would be the actual values.

[jan-ivar]

I think we'd want to specify anything like that. E.g. I might have interpreted [0,0] to mean fixed camera.

Is the use case a site that already has the camera and wants to know if it should show an "Enable ptz controls" button?

[youennf]

Is the use case a site that already has the camera and wants to know if it should show an "Enable ptz controls" button?

Yes, that is what I am thinking of.

[youennf]

As discussed in #229 (comment), maybe we should have a panTiltZoom boolean constraint for getUserMedia. This could allow detection of PTZ cameras.
And then we would have pan/tilt/zoom specifically for applyConstraints, ignored by getUserMedia.