Change:
This reverts commit 0dac1b124828835c5785c4ae703c26ad3d19f65f.

Discussion:
and Traversal Using Relays around NAT (TURN) RFC5766, and then checks the connectivity of each local-address-remote-address pair in order to select the best one.  The addresses that are collected usually <del> consist of an endpoint's private physical/virtual addresses and its public Internet addresses. </del> <ins> consist of an endpoint's private physical or virtual addresses and its public Internet addresses. </ins> <del> These addresses are exposed upwards to the web application, so that they can be communicated to the remote endpoint for its checks.  This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. </del> <ins> These addresses are provided to the web application so that they can be communicated to the remote endpoint for its checks.  This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. </ins> The information revealed falls into three categories:

used in this document, it is always in reference to an RFC1919 proxy server. <del> Of these three concerns, #1 is the most significant, because for some users, the purpose of using a VPN is for anonymity.  However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. #2 is a less significant but nonetheless valid concern.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf-rtcweb- transports is fairly benign due to their intentionally short </del> <ins> Of these three concerns, the first is the most significant, because for some users, the purpose of using a VPN is for anonymity. However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. The second concern is less significant but valid nonetheless.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf- rtcweb-transports is fairly benign due to their intentionally short </ins> lifetimes, IPv4 addresses present some challenges.  Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits

noted that private addresses are just one potential mechanism for this correlation and this is an area for further study. <del> #3 is the least common concern, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. </del> <ins> The third concern is the least common, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. </ins> Note also that these concerns predate WebRTC; Adobe Flash Player has provided similar functionality since the introduction of Real-Time

WebRTC's support of secure peer-to-peer connections facilitates deployment of decentralized systems, which can have privacy benefits. <del> As a result, we want to avoid blunt solutions that disable WebRTC or make it significantly harder to use.  This document takes a more nuanced approach, with the following goals: </del> <ins> As a result, blunt solutions that disable WebRTC or make it significantly harder to use are undesirable.  This document takes a more nuanced approach, with the following goals: </ins> Provide a framework for understanding the problem so that controls might be provided to make different tradeoffs regarding

determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same <del> routing).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the </del> <ins> routing treatment).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the </ins> application resides (e.g., on an intranet). First, the appropriate remote IPv4/IPv6 address is obtained by

8. <del> This document is entirely devoted to security considerations. </del> <ins> This document describes several potential privacy and security concerns associated with WebRTC peer-to-peer connections, and provides mechanisms and recommendations for WebRTC implementations to address these concerns. </ins> 9.