Deprecate inputDeviceInfo.getCapabilities() for better privacy

[jan-ivar]

From https://github.com/w3c/mediacapture-main/issues/669#issuecomment-605114117:

@henbos Specifically on removing required constraints, note that Chrome today implements info.getCapabilities() which gives the site capability information about all devices after gUM.

That API exists to allow a site to enforce its constraints while building a picker, or choosing another device outright. Most sites enforce some constraints.

That API is also a trove of fingerprinting information.

Luckily, "user-chooses" provides feature-parity with this, without the massive information leak:

await getUserMedia({video: constraints, semantics: "user-chooses"});

So merging https://github.com/w3c/mediacapture-main/pull/667 would let us retire info.getCapabilities() provided we leave constraints alone. 🎉

So far, it looks like only Chrome/Edge implement it (WPT)

[eric-carlson]

WebKit also implements getCapabilities, although we are not opposed to removing the API.

Not all of the WPT tests pass because the mock capture devices only report a subset of all possible capabilities (audio, video, and screen).

[youennf]

That API is also a trove of fingerprinting information.

But only after the web page starts capturing, so this does not happen for most web pages.

I think it would make more sense to restrict enumerateDevices so that it would only list devices that have been used and not all devices. Once a device has been used, this information is provided at the MediaStreamTrack level and can be stored by the page anyway. This is inline with https://github.com/w3c/mediacapture-main/issues/640.

Note also that there is some interest for discovery of audio input/output capabilities in the audio WG/audio WG latest charter.

[jan-ivar]

That API is also a trove of fingerprinting information.

But only after the web page starts capturing, so this does not happen for most web pages.

Right, that's all we're talking about. We already did https://github.com/w3c/mediacapture-main/pull/632.

I think it would make more sense to restrict enumerateDevices so that it would only list devices that have been used and not all devices.

How would that "allow a site to enforce its constraints while building a picker"?

[youennf]

If the device was used in the past, the web page was able to grab the capabilities from the track and store them. We can therefore expose getCapabilities to any device that was used in the past from the last reset ID event, without any additional fingerprinting exposure. This seems like a handy mechanism to me.

The only case is those devices that have not been used in the past. We could decide for getCapabilities to return an empty object to keep it privacy neutral but we would loose some functionality in how web pages can discover the user setup.

I am hesitant to break this functionality. In general, I do not really like web pages to craft very complex getUserMedia constraints to express what they need (and at the end maybe fail to have it in an interoperable way). It seems live providing some information of the user setup after a user prompt is ok.