WebRTC Network Identity and Privacy: Choosing the Right Policy

BotBrowser supports controlled WebRTC network-identity settings; it does not make peer connections anonymous or guarantee privacy outside the configured context.

TL;DR

WebRTC gathers addresses that the page proxy never sees. Choose one posture per context (profile, real, or disabled) and record it. Review ICE candidates and getStats() for the WebRTC connection, and use a separate authorized external service to check the public address; these are different observations.

Contents

• Why WebRTC belongs in a privacy policy
• What the browser can reveal
• The three policy postures
• How to interpret candidate and statistics records
• A practical governance model
• Questions teams ask
• Practical conclusion

Why WebRTC belongs in a privacy policy

WebRTC gives websites a way to support calls, meetings, live support, and peer-to-peer media. It also gives the browser a separate network identity surface. A page can see information about the addresses considered for a connection and can receive a statistics view while a session is active. That information has privacy value even when ordinary page requests use a proxy. BotBrowser can coordinate WebRTC network information with a configured profile in a controlled context; it cannot make peer connections anonymous or guarantee privacy outside that context.

The important question is not whether WebRTC should be present. Most people need it for legitimate communication. The important question is what address information the WebRTC APIs expose under the selected context policy. A privacy policy should make that decision explicit, document the tradeoff, and review observations when the route changes.

BotBrowser presents three policy postures for this decision: profile, real, and disabled. They cover configured-profile handling, host-network handling, and unavailable WebRTC, respectively. Under profile, configured SDP and ICE controls are intended to align WebRTC address information with the declared profile identity; verify the applicable proxy and UDP conditions instead of treating that intent as a public-egress measurement. The appropriate choice depends on the session purpose and the privacy boundary an organization accepts.

The policy centers on user privacy, data minimization, and careful interpretation of candidate records and statistics. For a broader overview of WebRTC privacy, see WebRTC leak prevention, and for the surrounding product controls see network features.

What the browser can reveal

When a WebRTC session is prepared, the browser gathers possible paths for media traffic. A candidate carries a candidate type (host for a local interface, srflx for a server-reflexive mapping, relay for a TURN address) plus the address itself (RFC 8445). During the session, RTCPeerConnection.getStats() reports local-candidate, remote-candidate, and candidate-pair records; the selected pair identifies the path currently carrying media (WebRTC Statistics). These records help compare observed WebRTC routing with the context policy, but they are not an independent measurement of the public egress used by page requests.

Address information is sensitive because it can connect a browser session to a network, location, organization, or household. A private address may reveal the shape of a local network. A public address may identify the egress used by the host. A relay address may identify a service or region selected for the call. Even when one item seems harmless, the combination can create a durable link between sessions. For how mDNS host candidates change what a page can learn about a local network, see WebRTC mDNS Candidates and Local-Network Privacy, which covers mDNS candidates and RFC 8828 privacy goals.

The ordinary request path and the WebRTC path are related but not interchangeable. A proxy can give page requests one public identity while WebRTC follows another route. That split is the source of many accidental disclosures. A policy that only checks page traffic is incomplete; it should also account for the address information made available by WebRTC. For how proxy routing, DNS, and WebRTC are kept aligned across a workflow, see Proxy, DNS, and WebRTC Consistency for a Coherent Browser Identity, which covers proxy, DNS, timezone, and WebRTC consistency.

Privacy work should also consider availability. Blocking every communication feature may reduce exposure, but it can prevent meetings, support calls, and collaboration tools from working. A good policy therefore starts with the business purpose of the context, records the selected posture, and makes the remaining exposure understandable to the people responsible for the session.

The three policy postures

Profile: review the configured identity policy

The profile posture is intended for a browser context that has a defined network identity. WebRTC remains available, while configured SDP and ICE controls apply to address information exposed by the browser. Review the resulting candidates under the proxy and UDP conditions used by that context.

This can fit a session that needs calls or media and a documented privacy boundary. It preserves WebRTC capability while applying the configured policy; the result still depends on the proxy and network configuration. A profile cannot make an unsuitable proxy private, and it cannot turn an untrusted provider into a trusted one. For how UDP traffic for QUIC and WebRTC can follow the same proxy plan, see UDP over SOCKS5: Private QUIC and WebRTC Routing, which covers TCP and UDP proxy policy per context.

The profile posture gives reviewers a declared context policy to compare with candidate and statistics records. When a SOCKS5 proxy supports UDP ASSOCIATE and BotBrowser establishes the association, STUN traffic can use that proxy and ICE candidates can reflect its address. A selected candidate pair still describes the WebRTC media path, not a separate public-egress check for page requests. Organizations should document the route assigned to each context and review both observations against it.

Real: use the host network identity

The real posture is a clear choice to use the network identity supplied by the host environment. It can be appropriate for local development, internal testing, or a communication workflow where the host route is the intended route. It is not a privacy posture by itself. People should understand that the host network may be visible to the other side of a connection or to services that receive WebRTC address information.

Choosing real is better than leaving the decision implicit. It makes the boundary visible in a policy and helps teams avoid assuming that a page proxy also covers every communication path. A host may have several interfaces, a changing public route, or a corporate network with its own disclosure rules. The organization should document who owns that network and whether its address information is appropriate for the session.

The real posture can also be useful when troubleshooting a connectivity problem in an authorized environment. The privacy consequence should be part of that decision. Troubleshooting sessions should have a defined owner, a limited lifetime, and a clear record of when the host identity was intentionally used.

Disabled: remove a capability that is not needed

The disabled posture is suitable when a workflow has no need for browser-based real-time communication. Removing an unused capability can reduce the amount of information available to a page and can simplify a strict privacy boundary. It also means that calls, media sharing, and other WebRTC-dependent features will not be available in that context.

Disabled should be an explicit product decision, not an accidental side effect of a broken environment. Users should know why a meeting cannot start, and teams should avoid presenting a disabled context as a general-purpose browsing environment. If a workflow later needs WebRTC, it should move to a context with a documented profile or real posture rather than changing settings in an ad hoc way.

There is a usability cost to this posture. Some pages may offer a different experience when real-time communication is unavailable. That outcome is acceptable when the privacy requirement is stronger than the communication requirement, but it should be recorded so support teams can distinguish policy from malfunction.

How to interpret candidate and statistics records

Two views can be individually plausible and still tell different stories. Candidate records may describe one route while statistics later describe another. A page request may use a proxy while the communication path reveals the host. A profile may point to one region while the observed address belongs to another. Each mismatch expands the amount of information a page can use to associate a session with a network.

Comparison is therefore a policy check, not a promise that two API views will match. With profile, inspect the candidates and selected pair, then compare what they show with the route assigned to the context. With real, interpret any exposed addresses as host-network information. With disabled, check that the WebRTC capability is unavailable. The result is evidence for a review, not proof that a particular address or route is guaranteed.

This relationship also matters when a session changes state. A proxy replacement, a network handoff, or a profile change can alter the route during the lifetime of a context. Teams should treat such a change as a new privacy decision. Reusing a context after its network identity has changed can combine observations from different routes and make records harder to interpret.

Consistency should be evaluated at the level of a browser context. Separate contexts can have separate policies, provided the ownership and route for each one are clear. A shared machine does not need to imply a shared network identity, but a context should not silently inherit another context's privacy decision.

Posture	ICE candidate types	getStats() view	Choose it when
profile	Follow the loaded profile	Inspect selected candidate and pair records	Calls must work under a declared browser identity
real	Host interface addresses (host, srflx)	Inspect host candidate and pair records	The host route is the intended identity
disabled	No WebRTC candidates	WebRTC transport is unavailable	The workflow never needs real-time media

A practical governance model

A small written policy is enough for most teams. Start by assigning each workflow a purpose: communication, local development, internal verification, or privacy-sensitive browsing. Record whether WebRTC is required. Then choose profile, real, or disabled and state which organization owns the selected route.

The next step is to decide which candidate and statistics records the review needs to inspect. Compare those observations with the context policy without assuming the values will match or identify a public egress. Avoid storing more address detail than the workflow needs. Access to operational records should follow the same data-minimization rules as access to cookies, account data, and other session state.

During maintenance, treat changes to proxies, profile files, network interfaces, and communication requirements as policy changes. Revisit the selected posture when any of those inputs changes. Keep the policy close to the workflow documentation so operators do not have to infer privacy behavior from a browser screen.

The final part is user communication. A person who starts a call should know whether the session uses a profile route, the host route, or no WebRTC capability. A person who opens a disabled context should see a clear product explanation rather than repeatedly retrying the same action. Good communication prevents privacy controls from becoming a source of accidental workarounds.

A privacy policy becomes easier to trust when its language stays stable while the surrounding network changes. Write the selected posture in terms that a support engineer, a developer, and a privacy owner can all recognize. The policy does not need a long technical inventory. It needs a purpose, an owner, a selected route, and a clear statement about what WebRTC is allowed to reveal.

The route owner should also document that ordinary browsing and communication traffic can take different paths. A successful page load does not show that every communication surface used the same route. The profile posture gives the team a declared context policy to inspect alongside candidate and statistics records, but the observations still need to be evaluated rather than assumed.

Change management is part of privacy work. A new proxy provider may change the available region. A laptop may gain an additional interface. A browser profile may be copied into a workflow with a different purpose. Each event can alter what an address means, even when the page itself has not changed. Route ownership and posture should therefore travel with the context, not remain only in a central network diagram.

Teams can make reviews lighter by separating decisions from raw observations. First record whether WebRTC is needed and which posture is intended. Next record whether the candidate and statistics observations raise a question for that policy; do not label them a match without checking the relevant records. Store detailed address information only when a time-limited operational reason has been approved. This order keeps the review focused on a privacy decision instead of accumulating a permanent record of network details.

The same principle applies to access control. People who can manage a proxy or a profile do not automatically need access to communication records. Limit access to the smallest group that can maintain the workflow. When a context is retired, remove its route assignment and decide how long related records are needed. Retention should follow the business purpose rather than the convenience of an existing log system.

There is also a human factor. A privacy posture should be visible at the point where a workflow is selected, especially for a context with real or disabled. A short label can prevent a user from assuming that a meeting will use a managed route. Clear labels also help support teams give the right advice without asking users to change a setting whose privacy consequences they do not understand.

Finally, keep the three postures distinct in documentation. profile is a coordinated identity decision. real is an intentional choice to expose the host network identity. disabled is a capability decision with a communication cost. Treating them as interchangeable settings makes later reviews harder and encourages accidental reuse. Treating them as named policies gives each context a reason, an owner, and a predictable expectation.

For a customer support workspace that needs browser calls, profile is usually the clearest starting point. It keeps communication available and gives the organization one network identity to manage. The team should still review the provider, region, retention rules, and access to session records.

For local development on a trusted network, real may be reasonable when the host route is part of the test environment. The decision should not be carried into a privacy-sensitive workflow by copying a browser profile without reviewing its network posture.

For a reading or research context that never uses calls, disabled can reduce unnecessary capability. That context should remain separate from a communication context so that enabling calls does not quietly change the policy for unrelated work.

For a managed organization with several workflows, the most important practice is separation of ownership. Each context should have one named purpose, one selected posture, and one documented route owner. This makes a privacy review easier without requiring a detailed inventory of page behavior.

Questions teams ask

Does a proxy automatically protect WebRTC?

No. A proxy can control ordinary page requests while WebRTC uses a separate communication path. Review the ICE candidates and the selected candidate-pair statistics separately, then interpret them in light of the context policy; neither view alone measures public egress.

Should every context use profile?

No. profile is a good fit when WebRTC is needed and the context has a defined network identity. real can be the correct choice for a host-owned workflow, while disabled can be preferable when communication is not part of the purpose. The policy should follow the workflow rather than a universal setting.

Does disabled provide the best privacy in every situation?

It reduces one communication surface, but it also removes legitimate browser functionality. If a user needs a call, disabling WebRTC may create pressure to use an unmanaged workaround. A documented profile policy can provide a better balance when communication is required.

Why compare candidate records with statistics?

They are separate views of the communication path. Comparing their privacy meaning helps reveal whether the browser context is presenting one coherent network identity or exposing information from more than one route. The comparison should stay within the organization’s controlled privacy review and should not collect unnecessary data.

Can a network change during a session?

Yes. Interfaces can change, routes can be replaced, and a user can move between networks. A network change should trigger a policy review for the context. Continuing a long-lived session without recognizing the change can join observations that belong to different routes.

What should be retained for privacy review?

Retain the selected posture, the purpose of the context, the route owner, and the review decision. Address details should be retained only when they are necessary for an approved operational need. A privacy review should minimize both collection and access.

Sources

• RFC 8445: Interactive Connectivity Establishment
• RFC 8828: WebRTC IP address handling requirements
• W3C WebRTC Statistics
• W3C WebRTC 1.0

Practical conclusion

WebRTC privacy is a network identity decision. profile, real, and disabled provide three understandable ways to make that decision. Choose deliberately, inspect candidate and statistics records, and interpret them against the context policy without assuming that they match or reveal public egress. When communication is needed, profile-based coordination can preserve the capability while keeping the privacy boundary clear. When the host route is intentional, real makes that exposure explicit. When communication is unnecessary, disabled removes an unused surface.

Review the WebRTC leak prevention guide for related network guidance, and keep the selected policy alongside your network feature configuration. A small, documented decision is easier to maintain than an assumption that WebRTC follows ordinary page traffic automatically.

Write one posture per context into the run record. Review ICE candidates and getStats() records in the authorized test page, then check the public address with a separate authorized external service. Treat a real context as a deliberate host-network decision rather than an oversight, and a disabled context as a workflow where WebRTC APIs are unavailable. Repeat both checks after a network change, a proxy rotation, or a browser major release.