Why Chromium Obscures Local IPs in WebRTC Peer Discovery

This article explains the privacy and security reasons behind the Chromium web browser's decision to obscure local network interfaces and host candidates during WebRTC peer discovery. Historically, the WebRTC protocol automatically exposed a user's private, local IP addresses to any website utilizing the API, which created severe risks regarding user tracking, browser fingerprinting, and internal network mapping. To resolve these vulnerabilities without breaking peer-to-peer connectivity, Chromium implemented Multicast DNS (mDNS) to mask raw local IP addresses with randomized, temporary hostnames.

The Role of Host Candidates in WebRTC

WebRTC (Web Real-Time Communication) enables direct peer-to-peer audio, video, and data sharing between browsers. To establish a direct connection, browsers use a framework called Interactive Connectivity Establishment (ICE).

During the ICE process, the browser gathers all available network addresses—known as "candidates"—that another peer might use to connect to it. "Host candidates" are the physical or virtual local IP addresses assigned to the user's device on their local area network (LAN), such as 192.168.1.x or 10.0.0.x. While sharing these addresses is necessary to connect two devices on the same local network, exposing them directly to web applications introduced major privacy flaws.

Preventing Browser Fingerprinting and Tracking

The primary reason Chromium obscures host candidates is to prevent silent user tracking. Before this protection was implemented, any website could run a invisible background script to initiate a dummy WebRTC connection. This process did not require the user's permission, such as granting access to a camera or microphone.

Through this silent request, websites could harvest the local IP addresses of all network interfaces on a user's machine. Because local IP configurations often remain static on home or corporate networks, malicious trackers combined this data with other browser attributes to create a persistent "browser fingerprint." This allowed trackers to identify and follow users across the web, even if the user cleared their cookies or used Incognito mode.

Stopping Internal Network Mapping

Exposing local network interfaces also created a significant security risk for corporate and enterprise environments. By analyzing the host candidates provided by WebRTC, an external website could deduce the internal structure and subnet architecture of a private network.

If a user had multiple network interfaces—such as a local Wi-Fi connection, an Ethernet adapter, and a corporate VPN—WebRTC would expose the IP addresses for all of them. Attackers could use this information for reconnaissance, helping them map out internal network topologies to plan more targeted cyberattacks.

Mitigating VPN Leaks

Users often rely on Virtual Private Networks (VPNs) to mask their network identity. While a VPN hides a user's public IP address, WebRTC historically bypassed the VPN tunnel during the peer discovery phase to gather the local host candidates of the physical network adapters. This phenomenon, widely known as a "WebRTC Leak," revealed the user's local network configuration and sometimes their actual public IP, undermining the privacy guarantees of the VPN.

How Chromium Obscures the Data Using mDNS

To fix these issues without breaking local peer-to-peer WebRTC functionality, the Chromium team introduced the enable-webrtc-hide-local-ips-with-mdns feature.

Instead of providing the raw local IP address in the ICE host candidate, Chromium generates a random, universally unique identifier (UUID) and appends .local to it (for example, f81d4fae-7dec-11d0-a765-00a0c91e6bf6.local). Chromium then uses Multicast DNS (mDNS) to register this hostname on the local network.

When the web application inspects the host candidates, it only sees the randomized .local address. The website cannot use this address to track the user or map their network because the UUID changes regularly and reveals no subnet information. However, if the other peer is on the same local network, their operating system can use mDNS to resolve that .local address back into the actual local IP address, allowing the direct WebRTC connection to succeed.

Exceptions to the Rule

Chromium only obscures local IP addresses when a website has not been granted explicit trust by the user. If a user actively grants a website permission to access their camera or microphone, Chromium assumes the user trusts the application to facilitate a real-time call. In these instances, Chromium bypasses the mDNS obfuscation and exposes the raw local IP addresses to ensure the fastest and most reliable connection possible, particularly on complex networks where mDNS traffic might be blocked by router firewalls.