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

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

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Tue, 15 Jan 2019 21:16:03 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-454554330-1547586962-sysbot+gh@w3.org>
> It then means that the device IDs persist after the user granted permission once.
> I do not think WebKit would implement this behavior.

The spec [says](https://w3c.github.io/mediacapture-main/getusermedia.html#def-constraint-deviceId): *"The same identifier MUST be valid between browsing sessions of this origin, but MUST also be different for other origins."*

[and](https://w3c.github.io/mediacapture-main/getusermedia.html#constrainable-interface): *"If any local devices have been attached to a live MediaStreamTrack in a page from this origin, or stored permission to access local devices has been granted to this origin, then this identifier MUST be persisted, except as detailed below."*

We decided sites are responsible for managing devices for users. How is a site to remember a user's choice without this?

But that's irrelevant to my point here: In Firefox, `deviceId` is invariant; it's always honored, and never changes from `""` to something else during the session, which is the part I object to.

> What is the difference between "default" and "" in that case?
In both cases, the device IDs might not be unique per-origin.

`"default"` is invariant. You're right it's not origin-unique, so it technically violates the spec. However, because of how it's is implemented—always giving you the system default—it reveals no information about the user's system, so I'd say it's following the spirit if not the letter of the spec.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/551#issuecomment-454554330 using your GitHub account
Received on Tuesday, 15 January 2019 21:16:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:15:00 UTC