Discourage device enumeration, prefer less powerful alternatives

[hober]

Consider an API which exposes a certain kind of attached device to websites. For instance, an API which can vend one or more monitor objects that represents one or more of the monitors attached to the computer.

Common approaches

1. a device enumeration API: exposes / returns a list of all devices
2. a sorted device enumeration API: exposes / returns an ordered list of all devices, ordered by some set of site-provided preferences
3. a filtered device enumeration API: exposes / returns a filtered list of devices which meet some set of constraints
4. a picker-style API: exposes / returns one device which meets some set of constraints
5. an availability-style API: exposes that at least one device is available to use and a way to use an available device without exposing any devices directly

Examples

1. a device enumeration API: "give me a list of all the screens attached to this computer" (see also Screen Enumeration API design-reviews#413, Screen Enumeration API design-reviews#413 (comment), and Picker-style API webscreens/screen-enumeration#23), "give me a list of all the USB devices", "give me a list of all the cameras and microphones" (see also Move enumerateDevices behind permission w3c/mediacapture-main#612, Only reveal labels of devices user has given permission to w3c/mediacapture-main#640, and Should enumerateDevices by default return an empty list? w3c/mediacapture-main#646)
2. a sorted device enumeration API "give me a sorted list of all the GPUs on the system"
3. a filtered device enumeration API: offhand I can't think of one, but I'm sure there's one out there.
4. a picker-style API: "give me a high-performance or low-power GPU" "give me a USB device that meets some criteria", <input type=file>
5. an availability-style API: "switch to remote playback if the user wants"

Observations

Only some of these approaches center the user's device preferences.

Merely exposing the presence of devices is itself a fingerprinting concern.

Exposing device data grows the fingerprinting surface per exposed device, which can get very bad very quickly if the API exposes a large amount of per-device information.

The Rule of Least Power suggests that we should go with the least powerful API which meets its use cases.

Conclusion

Therefore, we should recommend that, when API designers need to expose devices in some manner, that they consider these in reverse order.

An availability-style API is best: it allows the site to use the device the user wants to use without exposing device information. It is the least powerful option.

A picker-style API also respects user preferences. It exposes device information, but only of one device. This minimizes the fingerprinting data exposed.

A filtered device enumeration API exposes a subset of devices, so is potentially better re: fingerprinting than the next possibilities

A sorted device enumeration API exposes too much information, but at least it does so in a way that makes the site's job easier

A device enumeration API is to be resorted to only when the other options are infeasible for some reason (compat, perhaps).

[pes10k]

I think this is great, and echos a bunch of ongoing issues with Media Capture group. I’m very supportive

[IreneKnapp]

+1, this is excellent. Is it in-scope to describe alternative patterns that could be followed? It occurs to me that it would be even better for privacy to prompt the user as to whether they want to expose a device, and which one. Of course, that's only viable for use-cases where it's acceptable to add an extra click, and for which the user can reasonably be expected to understand the question.

Edit to add: Oh, sorry, I see that you mentioned that.

[lknik]

Hi @hober, interesting (thanks)!

3. a filtered device enumeration API: exposes / returns a filtered list of devices which meet some set of constraints
4. a filtered device enumeration API: offhand I can't think of one, but I'm sure there's one out there.

Similar to the current Bluetooth scan-like

.navigator.bluetooth.requestDevice({
filters: [{
namePrefix: 'a'
}]

While of course to actually pair the API has a "picker", the initial scanning can be filtered, for example based on device name (i.e. look for all starting with 'a*'). So not quite exactly the same as 'filtered device enumeration'.

[hober]

Similar to the current Bluetooth scan-like

.navigator.bluetooth.requestDevice({
filters: [{
namePrefix: 'a'
}]

I think that's a picker-style API in the nomenclature I used in the OP.

[ylafon]

Is it only for devices? I can see that for font lists and in general all API that list "all available ..." should have a lesser alternative, which can be far more efficient as well.

[hober]

Is it only for devices?

No, but those are many of the obvious cases. One non-device case I listed is <input type=file> as an example of a picker-style API. Files aren't usually considered to be devices (though Unix considers devices to be files :)).

I can see that for font lists and in general all API that list "all available ..." should have a lesser alternative, which can be far more efficient as well.

Yes, for sure.

[pes10k]

Since the subject matter here overlaps a lot with what PING discusses, and similar concerns are being worked on for the PING threat model document, how would the TAG like to coordinate?

Should PING "upstream" our the parts of the threat model that are explicitly design-principal-y? Or better to push these things "down" into PING, and have the TAG design principles point to the PING doc w/ a note that the TAG considers them equally significant? Other?

[hober]

@snyderp wrote:

Since the subject matter here overlaps a lot with what PING discusses, and similar concerns are being worked on for the PING threat model document, how would the TAG like to coordinate?

Should PING "upstream" our the parts of the threat model that are explicitly design-principal-y? Or better to push these things "down" into PING, and have the TAG design principles point to the PING doc w/ a note that the TAG considers them equally significant? Other?

(Speaking only for myself)

The TAG's Client-side API Design Principles document is "a small-but-growing set of design principles collected by the W3C TAG while reviewing specifications." This issue is an example of that: this kind of thing has come up in several of our design reviews, so I think it's time to try to distill our observations and learnings into a new principle.

That said, I certainly think that the Privacy Threat Model can (and should) inform design reviews, and it seems totally reasonable for me to have links from specific threats in the model to specific design principles that help mitigate the threats, and vice versa, of course—design principles should link to other models, thinking, findings, etc. that inform them.

[npdoty]

Specifying sorting also has a privacy benefit in mitigating fingerprinting based on the sort order revealing some other information about the user or their device (as the order of fonts did in some cases), see this best practice.

I was thinking that the getUserMedia constrainable pattern might be an example of your filtered device enumeration, but I believe that just does the filtering and returns a single stream or promise that is guaranteed to match the constraints. It is possible that this constraint-matching system can reveal more information if it's called multiple times with different combinations of constraints, so it may not be obvious how much fingerprinting surface is revealed on any particular query.

[pes10k]

Other things to emphasize / points for consideration.

1. I suggest flipping the priority of "availability-style API" and "picker-style API", as documents can play games to change what devices are "available" under different constraints, and so can leak information this. (when different "availability paths" might be taken under different constraints, and its not just a single YES / NO)
2. There is some distance between "availability-style API" and "picker-style API", but that space is much smaller than the distance between the first two options, and the last three options.

[pes10k]

Also maybe worth considering how permissions factor in here. In general PING has been pushing that idea that any APIs that leak hardware identifiers (hard or soft) need to be behind permissions and restrictions. Presumably a permission would be redundant or implied with the picker option. Depending on the size of the space of the possible answers, it might be a requirement for the others.

[lknik]

@hober numbers-wise, we put it in the context of more or less 5.1 or more or less 6.1? (inside/after/separate/etc).

[hober]

IIRC another example is Web Bluetooth Scanning, which has a filter-style API ("give me all the nearby bluetooth devices that meet these criteria").

[hober]

@hober to draft a PR.

[lknik]

IIRC another example is Web Bluetooth Scanning, which has a filter-style API ("give me all the nearby bluetooth devices that meet these criteria").

I mentioned Bluetooth already (scanning is close!)

[lknik]

@hober to draft a PR.

I'll be happy to review as needed.

[pes10k]

@lknik @hober I just want to make sure #152 (comment) is being considered. In many cases an availability-approach will not prevent fingerprinting, where a picker would

[hadleybeeman]

This came up in our review of WebHID API, when we were discussing unique identifiers that come from the system. Minutes.

[npdoty]

As mentioned in the PING call today, WebXR is preferring exposing capabilities rather than specific device identifiers. That might be a good pattern/principle to recommend.

[ylafon]

I see a possible link with #137 if capabilities becomes a way to identify devices (based on npdoty's comment)

[alice]

Another one: w3ctag/design-reviews#399 (comment)