25245 2014-04-03 07:41:01 +0000 Specify "access" in the context of getMediaDevices 2014-09-25 13:36:02 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified PC Linux RESOLVED FIXED P2 normal --- 1 harald stefan.lk.hakansson anssi.kostiainen eric.carlson fischman ian jib martin.thomson public-media-capture stefan.lk.hakansson oldest_to_newest 103314 0 harald 2014-04-03 07:41:01 +0000 The description of getMediaDevices says: Collects information about the user agents available media input and output devices; for example a web camera or a headset. The method must only return information that the script is authorized to access (TODO expand authorized). Expansion is needed. 103315 1 harald 2014-04-03 07:46:41 +0000 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. 103482 2 ian 2014-04-07 15:57:56 +0000 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. 103486 3 martin.thomson 2014-04-07 17:08:27 +0000 (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. 103596 4 jib 2014-04-09 15:49:15 +0000 (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? 103600 5 martin.thomson 2014-04-09 16:48:10 +0000 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. 103608 6 jib 2014-04-09 17:35:44 +0000 (In reply to Martin Thomson from comment #5) That seems doable without this feature. gUM({sourceId:x}) fails == n/a detected. 103610 7 martin.thomson 2014-04-09 17:57:20 +0000 (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. 108487 8 harald 2014-06-30 13:18:14 +0000 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. 110618 9 jib 2014-08-26 17:04:34 +0000 Are we supposed to take it on faith that there are use-cases that require this feature? 111587 10 stefan.lk.hakansson 2014-09-16 14:12:59 +0000 Pull request #8 addresses part of this. 111599 11 dom 2014-09-16 15:41:38 +0000 (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. 112171 12 stefan.lk.hakansson 2014-09-25 13:36:02 +0000 Fixed in http://w3c.github.io/mediacapture-main/archives/20140924/getusermedia.html