# Neither Denied nor Exposed: Fixing WebRTC Privacy Leaks
## 8 Related Work  
Thus far, the WebRTC API privacy issue has been explored by a handful of works in the literature. The work in [19] provides details on the privacy threat occurring when WebRTC is exploited by browsers. The authors conduct different experiments in order to examine which types of IP addresses can get compromised. To this end, they tested a variety of widely used VPN services on different browsers and presented the results of their experiments, concluding that none of the tested VPN services has proven to be a perfect privacy solution. From the results offered by the authors, one can realize that each VPN service exposes a different set of user's IPs, with TorGuard being the preferred privacy-preserving VPN service, exposing just the private IPv4 of the user assigned by the VPN server. However, based on their results, a VPN solution is neither a silver bullet to the IP leaking issue, nor efficient, as VPN networks are highly dependent on the bandwidth of their VPN server, which are often geographically dispersed. The issue of using WebRTC in order to map the intranet topology from an external attacker is discussed in [9]. The authors present a JavaScript code, namely _MaliceScript_, which collects intranet information abusing the features of WebRTC, and then infiltrates a targeted website from its own intranet. This work focuses on the attack implementation and only provides recommendations for end-user protection. One of the defensive measures is to notify the user of the browser and ask for explicit authorization before calling the WebRTC API, which is actually what our implementations provide. The authors in [20], among other security and privacy risks, concentrate on that of WebRTC. Specifically, the authors were able to perform a network scan on victim networks and collect sensitive network information about other internal nodes, such as open ports based on heuristics like round-trip delays. They also claim that they developed a browser extension that is able to warn users about possible malicious activities, when a certain number of connections made to the private IP address of a user is surpassed. However, the countermeasure they propose for the specific privacy issue is just disabling WebRTC or using other extensions that can expose only the public IP of the user. In addition, the work in [29] capitalizes on WebRTC in an attempt to disclose the user's private IP and execute network scans using an open source JavaScript scanner, called jslanscanner [30]. The network scan is supposed to detect not only possible online local network nodes, but routers as well. The authors extend the way a malicious user can use WebRTC to expose user's IP; nonetheless, they omit proposing a solution to safeguard against these kinds of attacks. A Browser Scanner is proposed in [31] where an online service uses an XMLHttpRequest and WebRTC for the purpose of collecting information about the network a user resides in. The authors present the results they were able to gather from the scanned networks; however, they suggest that JavaScript and WebRTC should be disabled for avoiding such scans by malicious websites. In [32], the use of mDNS [33] is proposed for protecting private IP addresses. In the proposed mechanism, the web browser registers an ephemeral mDNS name for the private IP address of the host and then provides this name in its ICE candidates instead of the IP address. The ICE candidates negotiations can proceed as usual and the mDNS names can be resolved to IP addresses only when necessary and without revealing the actual address to the other endpoint. The main issue with this approach is that it can break WebRTC applications. There are various reasons for that: (a) mDNS is built on the assumption that the names never leave the local domain, (b) the SDP protocol expects IPaddresses instead of DNS names, and (c) if a DNS server tries to resolve an mDNS name it will fail as no relevant resource record exists.