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 Security Considerations section of the WEBRTC specification is empty, despite a large number of identified security considerations regarding opening network connections, sending traffic from a browser frame to other places, and allowing camera and microphone to be attached to those network sessions.
A proposed text, based on a proposal sent to the list on 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 set up real time, direct communication between browsers and other devices, including other browsers. This means that data and media can be shared between applications running in different browsers, or between an application running in a browser and something that is not a browser, something that is an extension to the usual barriers in the Web model against sending data between entities with different origins. The WebRTC specification provides no user prompts or chrome indicators for communication; it assumes that once the Web page has been allowed to access media, it is free to share that media with other entities as it chooses. A mechanism, PeerIdentity, is provided that gives Javascript the option of requesting media that the Javascript cannot access, but can only be sent to certain other entities. While a web application already before WebRTC will know the IP address to which the application is delivered, setting up communications exposes additional information about the browser’s network context to the web application, including the set of IP addresses available to the browser for WebRTC use. Some of this information has to be passed to the corresponding party to enable the establishment of a communication session. Revealing IP addresses can leak location and means of connection; this can be sensitive. Some mitigation is possible by using relays (for instance TURN servers) rather than direct connections between participants. Since the browser is an active platform executing in a trusted network environment (inside the firewall), it is important to limit the damage that the browser can do to other units on the local network, and it is important to protect data from interception, manipulation and modification by untrusted participants. Mitigations include: - Always requesting permission to communicate using ICE. This ensures that the browser can only send to partners who you have shared credentials with. - Requesting ongoing permission using ICE continued consent. This enables a receiver to withdraw consent to receive. - Requiring encryption of data, with strong per-session keying (DTLS-SRTP). - Requiring the use of congestion control. This ensures that WebRTC cannot be used to flood the network. These measures are specified in the relevant IETF documents. The fact of communication cannot be disguised, so must be regarded as public information.
Formatted Harald's proposal in a pull request at https://github.com/w3c/webrtc-pc/pull/15
WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues Please subscribe to the issues you want to keep watching.