Sudhir
Sudhir

Reputation: 352

webrtc: mediaDevices.enumerateDevices() returns empty deviceId

I'm currently exploring webRTC and what I want to do is to get all the mediadevices info along with deviceId using navigator.mediaDevices.enumerateDevices(); and then separate it out according to its kind attribute and allow user to choose which media device to use for specific kind. Like Show a dropdown of cameras found and allow user to choose which camera to use which is why i need deviceId of each device.

This is code I'm currently using to get mediadevices:

 const getConnectedDevices = async (type, callback) => {
  const mediaDevices = await navigator.mediaDevices.enumerateDevices();
  console.log(mediaDevices);
  callback(mediaDevices.filter((device) => device.kind === type));
};

And this is what I got back as output:

[
    { 
      deviceId: ""
      groupId: "51081772b5c5df2dbcb2ca2b8ae36c5d693d816f8d4bf4039cdb15802b7ffc54"
      kind: "audioinput"
      label: ""
    },
    {
      deviceId: ""
      groupId: "2e7a46f912e66fea3b6af4822e427c02a7725c39d86194dccdf5b7993293d7da"
      kind: "videoinput"
      label: ""
    },
    {
     deviceId: ""
     groupId: "51081772b5c5df2dbcb2ca2b8ae36c5d693d816f8d4bf4039cdb15802b7ffc54"
     kind: "audiooutput"
     label: ""
    }
]

getting a empty deviceId all the time. I also tried calling await navigator.mediaDevices.getUserMedia( {video: true,audio: true,}) before await navigator.mediaDevices.enumerateDevices() but still got same result.

Upvotes: 5

Views: 5427

Answers (1)

jib
jib

Reputation: 42430

It returns empty deviceIds now ahead of getUserMedia because tracking libraries were (and still are) calling enumerateDevices en masse to fingerprint people, with no intention of ever asking for camera or microphone.

The spec was reviewed by the Privacy Interest Group (PING), and, as a result, this enumerate first strategy (enumerating devices before asking the user for their camera or microphone) was deprecated, to improve user privacy. This is true even in browsers that opt users into persistent permission. (caveat: this last part got backed out in Chrome, so please go ★ crbug 1101860!)

All the big WebRTC sites already use a device first strategy instead (asking for camera or microphone first, then implementing device switching under ⚙️ options while live). So web compat of this breaking change was deemed acceptable.

In other words, ahead of getUserMedia resolving, you can only learn whether the user has no camera or no microphone. Those are the only two fingerprinting bits that remain (you won't see multiple devices listed).

I also tried calling [getUserMedia] before, ... but still got same result.

Then you did something wrong, because both labels and deviceIds are available then, to make device switching still work. See WebRTC Samples for a demo. You can even still store those deviceIds and use them with getUserMedia on future visits, that part still works. You just can't enumerate them (track their presence) before asking for them with the deviceId constraint.

The operating assumption is that the most popular tracking libraries operate in the shadows, and won't risk ever actually prompting the user for their camera or microphone on behalf of their client sites.

Upvotes: 11

Related Questions