Security Considerations

[tomrittervg]

This document lacks a Security Concerns section. I'm not an expert in the domain, but it sure seems like this exposes a lot of information about the user's device. (It also mentions the Battery Status API, which FF removed.)

As mentioned in https://www.w3.org/2001/tag/doc/unsanctioned-tracking/ :

[the TAG b]elieves that, because combatting fingerprinting is difficult, new Web specifications should take reasonable measures to avoid adding unneeded fingerprinting surface area. However, added surface area should not be a primary factor in determining whether to add a new feature.
Asserts that when a new feature does add fingerprinting surface area, it should be documented as such.

Therefore I believe that these concerns should be documented in the spec.

FF will (almost certainly) implement a mode (that will be used by default in Tor Browser) that lies about all of the information and try to choose values that work as well as feasible across all devices. This antifingerprinting mode will allow users to appear identical (with respect to this API) to prevent them from being uniquely identified. It would be awesome if the working group would make suggestions for how to do this, since you are the domain experts.

[jhlin]

The draft already mentions privacy consideration for some of the display capabilities (returns Screen.colorGamut as srgb and Screen.luminance as null) in [1]. As for screen color depth, 24 seems a good value. (People with monochrome screens might disagree, though). And for onchange events, I guess it could be dealt with the same as MediaDevices.ondevicechange [2].

For decoding and encoding capabilities [3], the concern about WebRTC SDP generation [4] sounds reasonable:

The process of generating an SDP exposes a subset of the media capabilities of the underlying system, which provides generally persistent cross-origin information on the device. It thus increases the fingerprinting surface of the application. In privacy-sensitive contexts, browsers can consider mitigations such as generating SDP matching only a common subset of the capabilities."

For example, in fingerprinting-proof mode, always return MediaCapabilitiesInfos with false smooth and powerEfficient, which should be the same as what existing MediaSource.isTypeSupported() exposes.