This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.
Harald has promised to write up a proposal.
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.
If people think this is a good start, let's put it into the spec and continue to work on it from there.
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.
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
https://github.com/fluffy/webrtc-w3c/pull/30
https://github.com/fluffy/webrtc-w3c/commit/6d6cb760205597f29c267c9438ea330034027454