22354 2013-06-13 19:27:33 +0000 Security and Privacy Considerations section needed 2014-06-20 13:41:22 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified PC All RESOLVED FIXED P2 normal --- 1 w3c harald adam.bergkvist harald public-media-capture stefan.lk.hakansson w3c oldest_to_newest 89275 0 w3c 2013-06-13 19:27:33 +0000 The specification needs a "Security and Privacy Considerations" section to be added giving guidance to both user agent implementers as well as web application developers of the API. Topics may include user consent to capture, user notice that capture is 'on', means for user muting or disabling capture, security and protection of recorded data (including temporary storage) and other items. 89394 1 harald 2013-06-17 12:28:01 +0000 Pointer: There's a security discussion in draft-ietf-rtcweb-security-04 section 4.1 - that text is strictly communication-oriented for the most part, but we should at least have a pointer that allows people to find that document. 93728 2 w3c 2013-09-24 15:02:37 +0000 we need an explicit "security and privacy considerations' section, this should make clear statements about potential concerns (or lack thereof) as well as links to other material as needed. 104149 3 stefan.lk.hakansson 2014-04-22 08:18:16 +0000 Harald has promised to write up a proposal. 104411 4 harald 2014-04-25 07:14:15 +0000 Proposed text, based on a proposal from April 23 and subsequent discussion: Security considerations This section is non-normative; it specifies no new behaviour, but instead summarizes information already present in other parts of the specification. This document extends the Web platform with the ability to manage input devices for media - in this iteration, microphones and cameras. It also allows the manipulation of audio output devices (speakers and headphones). Without authorization (to the “drive-by web”), it offers the ability to tell how many devices there are of each class. The identifiers for the devices are designed to not be useful for a fingerprint that can track the user between origins, but the number of devices adds to the fingerprint surface. When authorization is given, this document describes how to get access to, and use, media data from the devices mentioned. This data may be sensitive; advice is given that indicators should be supplied to indicate that devices are in use, but both the nature of authorization and the indicators of in-use devices are platform decisions. Authorization may be given on a case-by-case basis, or be persistent. In the case of a case-by-case authorization, it is important that the user be able to say “no” in a way that prevents the UI from blocking user interaction until permission is given - either by offering a way to say a “persistent NO” or by not using a modal permissions dialog. In the case of persistent authorization, it is important that it’s easy to find the list of granted permissions and revoke permissions that the user wishes to revoke. 104540 5 adam.bergkvist 2014-04-28 10:48:54 +0000 If people think this is a good start, let's put it into the spec and continue to work on it from there. 105961 6 harald 2014-05-14 12:52:36 +0000 The comment on the list that I've seen is that we need to have the privacy considerations related to UA alerting that devices are open be part of the "security and privacy considerations". Decision: We will add this text, and add a TODO: Describe privacy considerations related to UI for alerting that devices are open. I'll suggest more text on the list. 106026 7 stefan.lk.hakansson 2014-05-15 10:06:46 +0000 As discussed on the list ([1]), something should be said about rate limiting gUM calls (to avoid fingerprinting). [1] http://lists.w3.org/Archives/Public/public-media-capture/2014May/0071.html 108004 8 harald 2014-06-18 13:56:34 +0000 https://github.com/fluffy/webrtc-w3c/pull/30 108116 9 harald 2014-06-20 13:41:22 +0000 https://github.com/fluffy/webrtc-w3c/commit/6d6cb760205597f29c267c9438ea330034027454