My understanding of previous discussions:

- All Web pages may enumerate devices; in the deviceInfoList returned, the "id" and "kind" fields are populated. I think this category also includes the "group".

- For any device where the JS would get access without an user prompt ("trusted" script, stored permissions or previously granted access), the "label" field will be populated.

I also believe we have decided that "deviceId" should be different for pages from different origins, so that one page cannot tell another page about devices (information leakage). This also hasn't been captured in the spec, as far as I can tell.

This is a fingerprinting vulnerability (it provides previously-unavailable unique bits to identify the user), and thus should be considered in a privacy context.

This is a potential abuse vulnerability (combined with other APIs, it allows the author to send content to remote speakers without the user's consent).

As a user, I would not want a Web page to be able to enumerate any devices I have without my explicit opt-in.

(In reply to Ian 'Hixie' Hickson from comment #2)
> This is a fingerprinting vulnerability (it provides previously-unavailable
> unique bits to identify the user), and thus should be considered in a
> privacy context.

There has been a lot of thought put into this from a privacy perspective.  The actual exposure is limited to a count of devices of each type, plus, if we include "group" correlation of matched devices.

There's a tension here between usability and privacy.  I expect browsers to include controls that allow a user to control this exposure.

(In reply to Martin Thomson from comment #3)
> There's a tension here between usability and privacy.

Perhaps a refresh of the usability would be helpful?

The best usability argument I have to hand is this:

A user frequents a site that uses gUM, but does not provide persistent permissions (maybe because they use the peerIdentity constraint exclusively).  The site is able to use the device identifier, which is stable, to ensure that the same device is used every time.

The site is able to detect when that device is not available and use the device identifiers to provide predictable fallback behaviour.

(In reply to Martin Thomson from comment #5)

That seems doable without this feature. gUM({sourceId:x}) fails == n/a detected.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #6)
> (In reply to Martin Thomson from comment #5)
> 
> That seems doable without this feature. gUM({sourceId:x}) fails == n/a
> detected.

True, for this case.  As long as you make it fail hard, gUM won't trigger the user prompt.  That's not true of some of the other use cases.  I know that I shouldn't have trouble summoning the details, but I am.  I'll have to get back to this.

"group" allows an application to select a paired camera and microphone.  It also prevents cases where audio output is directed to one set of headphones, and input is derived from the same.

Suggested resolution:

Add a new section under 9.2 MediaDevices, called "Access control model".
Content:

The access to media device information depends on whether or not permission has been granted to the page's origin for use of any media devices.

If no such access has been granted, the MediaDeviceInfo dictionary will contain the deviceId, the kind and the groupId.

If access has been granted for any media device, the MediaDeviceInfo dictionary will contain the deviceId, the kind, the label and the groupId.

Add to the definition of "deviceId":

The unique id is valid for the page's origin only.

Are we supposed to take it on faith that there are use-cases that require this feature?

Pull request #8 addresses part of this.

(In reply to Stefan Hakansson LK from comment #10)
> Pull request #8 addresses part of this.

I've updated PR 8 to add the missing bits, and fixing an incorrect understanding of when mediadeviceinfo gets exposed.

Fixed in http://w3c.github.io/mediacapture-main/archives/20140924/getusermedia.html