W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

Re: [mediacapture-main] Should we allow empty string device IDs? (#551)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Sat, 19 Jan 2019 00:41:25 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-455731272-1547858484-sysbot+gh@w3.org>
> (2) is the net privacy trade-off the spec has made, in the interest of aiding repeat visitors.

Can you describe how enumerateDevices helps repeating visitors?
getUserMedia({audio: deviceId: {ideal: previouslyUsedAudioDeviceId}}) should do the trick for them, previouslyUsedAudioDeviceId being grabbed from MediaStreamTrack.getSettings().
No need for enumerateDevices or am I missing something?

enumerateDevices seems mostly useful for building a device picker, which tends to happen after getUserMedia prompt so that nice previews can be displayed.

> The web page could likewise store the entire list of deviceIds and labels from the first visit for use on subsequent visits—Most users don't change their device setup too often.

This would indicate to me that there is no need for providing detailed enumerateDevices on the second visit ;)

That said, I can see some cases that might make a setup change happen repeatedly:
1. BT headsets on mobile devices might be problematic if they can be enumerated as well when paired.
2. Laptop connected to/disconnected from secondary screens with camera/microphone might be another case. Let's say this is the configuration I have both at home and at my office.
Any web site that I granted permission to access my camera once, could then, based on deviceIds, know whether I am at home, at my office or somewhere else.

If we look at the specific issue of picking the right device when getUserMedia is called for the first time on a page, isn't it the browser that could do the best job, and without the privacy concerns.

GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/551#issuecomment-455731272 using your GitHub account
Received on Saturday, 19 January 2019 00:41:27 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:46 UTC