Update enumerateDevices algorithm to make use of device-kind specific exposure checks when building cameraList and microphoneList.

[youennf]

This ensures we do not get dummy similar audioinput or camera devices if only camera or only microphone is used.

Fixes #898

---

Preview | Diff

[karlt]

Thanks!

[jan-ivar]

LGTM!

[eladalon1983]

This seems reasonable to me. (I ran into #903 while reading this, btw.) LGTM from my side, but please wait for @alvestrand to review as well, as I've not had much mileage on enumerateDevices() yet, and I'd prefer one more person from Chrome take a look.

This ensures we do not get dummy similar audioinput or camera devices if only camera or only microphone is used.

Btw, where's the part of the spec that deals with dummy objects? Looking at creating a list of device info objects, I see that:

• Lists are created for distinct device types.
• The system default device is kept first.
• In the absence of the necessary permission, the lists are truncated to a single element - the first one.

I don't see mention of dummy devices, though. Has this dropped on the edit room floor at some point, or am I misreading things?

[karlt]

Btw, where's the part of the spec that deals with dummy objects?

"videoinput" and/or "videooutput" MediaDeviceInfo objects are all dummy objects when their respective "information can be exposed" flag is false, according to creating a device info object.

[eladalon1983]

Btw, where's the part of the spec that deals with dummy objects?

"videoinput" and/or "videooutput" MediaDeviceInfo objects are all dummy objects when their respective "information can be exposed" flag is false, according to creating a device info object.

Ah, the early-exit in steps 3 and 4 (as of the time of this writing). Thanks for clarifying.

[eladalon1983]

Btw, where's the part of the spec that deals with dummy objects?

"videoinput" and/or "videooutput" MediaDeviceInfo objects are all dummy objects when their respective "information can be exposed" flag is false, according to creating a device info object.

Ah, the early-exit in steps 3 and 4 (as of the time of this writing). Thanks for clarifying.

Actually, do I read correctly that the presence/absence of a default device can still be deduced by an application, even if a permission is lacking, because a dummy object will not be produced on a machine that has no devices at all?

(This is a separate issue, of course. I'll create a new issue for it if you guys think it's real, or if we cannot settle this in one more iteration. In either case, the current PR - still LGTM with the previous caveat of wanting another Chromium reviewer this time.)

[youennf]

Actually, do I read correctly that the presence/absence of a default device can still be deduced by an application, even if a permission is lacking, because a dummy object will not be produced on a machine that has no devices at all?

Right, not really a default device though, but whether there is a camera or microphone available.
It would be good if we could find a way to remove those 2 bits of fingerprinting.
Backward compatibility concern was raised when we decided to improve enumerateDevices privacy story a while ago.

[eladalon1983]

Backward compatibility concern was raised when we decided to improve enumerateDevices privacy story a while ago.

Is there a thread I could revive, or shall I start a new one?

[youennf]

Is there a thread I could revive, or shall I start a new one?

There is some history at #646.
I think it would be worthwhile to check again what websites are doing in that area and reopen a new issue.

If it is still backward incompatible to return an empty list, we could think of specifying behaviours like:

• enumerateDevices always returns a camera and microphone at first, no matter whether there is actually one.
• After a call to getUserMedia leads to NotFoundError, enumerateDevices exposes whether there is no camera/microphone.

[alvestrand]

I have problems seeing what step is creating the empty camera object for the case where camera information can be exposed is false. Will have to read through the entire algorithm to check that.

[jan-ivar]

The following sentence creates the camera object:

• Let deviceInfo be the result of creating a device info object to represent device.

Just as for microphone, the modifications are in a for-loop over the device list.

The added condition ISN'T

• Run the following sub steps for each discovered device in deviceList, device
  • If camera information can be exposed is false ... abort

IT'S:

• Run the following sub steps for each discovered device in deviceList, device
  • If camera information can be exposed is false and cameraList is not empty, abort
  • Let deviceInfo be the result of creating a device info object to represent device.
  • [prepend or append] deviceInfo to cameraList.
  • loop

If there is a camera, then we will loop once before we exit.

[alvestrand]

Having read through the preview, I conclude that executing thisalgorithm when canExposeCameraInfo is false will produce an empty list. This is a change from the previous (and implemented) behavior, which exposes a single camera (the one that will be returned as the "default device", if one exists; the first listed camera if not).

Note: the previous version doesn't seem to have made it obvious that we return the default device without a label (if I remember correctly, that was what we wanted to do). We should fix that too.

[jan-ivar]

The conditional production of label is unchanged by this PR and happens in creating a device info object.

[youennf]

We will change the approach for clarity by truncating the lists based on microphone exposure and camera exposure.

[alvestrand]

Changing back to the approach of truncating will make it clearer that the resulting device info is for the default device, even though it exposes no information about it.

[youennf]

Labelling as Editors can integrate based on that.

[alvestrand]

Yes, this is simple to understand.
Approved.