Skip to content

What does WebRTC SDP reveal about a browser?

An RTCPeerConnection constructed with no iceServers key gathers host candidates only: no STUN server is contacted and not a single packet leaves the machine. Ask it for an offer anyway — a data channel plus offerToReceiveAudio/offerToReceiveVideo — and the native media stack writes a detailed manifest of itself, offline, for any page that asks. Note this is a different question from what is a WebRTC IP leak?: that one is about where you are (address exposure through ICE). This one is about what you are — which engine compiled the stack that authored the text.

The manifest is dense. Each m=audio and m=video section lists payload types in the stack's own preference order, with an a=rtpmap naming the codec and clock rate, a=fmtp lines carrying per-codec parameters, and a=rtcp-fb lines naming supported feedback mechanisms (nack, nack pli, ccm fir, transport-cc). Alongside them sit a=extmap RTP header-extension URIs. Two markers are decisive: goog-remb (Google's Receiver Estimated Maximum Bitrate) and any x-google-* attribute are emitted only by libwebrtc, the WebRTC implementation compiled into Chromium. On the extension axis, libwebrtc ships webrtc.org/experiments/rtp-hdrext experiment URIs that Gecko never carries, while Gecko ships csrc-audio-level.

None of this is a JavaScript-visible string a userland shim rewrites — the offer is authored deep in C++ by the media stack. So a detector can infer from the SDP alone whether the engine matches the identity advertised in the User-Agent. That is what the audit's sdp-engine-signature check asserts, and it reads in both directions: the presence of Chromium-only markers must equal whether the UA claims V8 (claimsChromium === hasChromiumMarker), so a Chrome UA over a stack that emits no goog-remb fails, and so does a non-Chromium UA over a stack that emits one. The companion webrtc-extmap-engine-family check works the same idea off the extension URIs — which, unlike codec lists, don't vary with the GPU — but adjudicates only under a Chrome-claiming UA, flagging a Gecko-only csrc-audio-level or a missing libwebrtc experiment URI.

The crucial discipline is to match at family level only, never an exact codec set. Chromium builds compiled without proprietary codecs legitimately omit H.264; enterprise codec policy and distro builds vary; and the exact extension set moves with Finch gating, so two identical stock Chromes of the same version can differ. A check that demanded an exact m=video payload list would flag real browsers as fakes. Both checks therefore assert family membership and nothing narrower, and both decline to judge rather than fail: the SDP check goes indeterminate when the UA names no engine family it adjudicates or the offer carries no audio and no video sections, and it isn't run at all when the stack is blocked; the extmap check goes indeterminate under any non-Chrome UA, when no extension URIs are found, or when WebRTC is unavailable. A blocked stack is a privacy setting — an environment fact rather than a tell. The same restraint applies to codec fingerprinting generally.

The offline probe also yields the host candidate's connection-address, and here a well-known tool gets it wrong: CreepJS treats anything other than 0.0.0.0 as a leak, which reports Chrome's mDNS <uuid>.local hostname as an exposure when it is in fact the obfuscation working — the real LAN address was withheld and replaced with a per-origin random name. The audit classifies the address instead (mdns-local, rfc1918-private, link-local, cgnat, routable-public, none) and only routable-public is a finding, because that one reveals the machine's real network identity regardless of any proxy in front of it. Read together, the SDP is a small lesson in coherence: the media stack, the JS engine and the User-Agent must tell one story, and the SDP is the layer least reachable by the patches that rewrite the other two — which is why Clearcote governs identity in the C++ engine rather than over it. See identifying the engine behind the User-Agent and the fingerprint flags.

Related reading

Q&AWhat is a WebRTC IP leak?WebRTC can gather your real local and public IPs via ICE candidates even behind a proxy — exposing the true address and contradicting the proxy IP the page otherwise sees.Q&AWhat is codec fingerprinting?Codec fingerprinting reads what a browser claims it can decode, and how it phrases it. The decode APIs share one registry, so a hard disagreement is a lie.Q&AWhat is browser fingerprinting?Browser fingerprinting identifies a device by combining signals like canvas, WebGL, fonts, and hardware into a stable, often unique hash — without cookies.ResearchIdentifying the engine behind the User-AgentA User-Agent is a claim. The JavaScript engine underneath answers independently — and it cannot easily be made to lie.ResearchAnatomy of a browser fingerprint: every signal, and why they must agreeA field guide to the signals that make a browser identifiable — grouped by where they come from and how they betray a spoof.DocsFingerprint flags and profilesReference every Clearcote fingerprint switch, including seed-derived personas, real Chrome profile imports, WebGPU/WebGL controls, locale, storage, and canvas noise.
All questions