The WebRTC SDP offer matches the engine the User-Agent claims
Check id sdp-engine-signature
What an ordinary browser yields
Stock Chrome emits goog-remb / x-google-* and claims V8 — it passes. Genuine Firefox passes too: its SDP legitimately carries goog-remb for interop. Only a Chromium-claiming UA with no Google marker at all fails.
What a detector infers
An `RTCPeerConnection` is constructed with **no `iceServers` key**, which makes the probe entirely offline: the native stack builds a local SDP offer and gathers host candidates without contacting a STUN server or emitting a single packet. The offer is then parsed for Google markers — `goog-remb` and any `x-google-*` attribute — which libwebrtc writes into its own SDP. Only one direction is adjudicated: a UA claiming a Chromium engine (V8) whose SDP carries no Google marker at all contradicts itself, because the SDP is authored deep in C++ by the WebRTC stack — it is not a JS-visible string a userland shim rewrites. The converse is deliberately NOT asserted: marker presence cannot prove a Chromium engine, since genuine Firefox carries `a=rtcp-fb:goog-remb` for congestion-control interop with Chrome — the corpus showed 100% of real Firefox failing the old bidirectional rule, so it was narrowed to the honest direction. Severity is critical. Deliberately family-level rather than an exact codec-set match: `pass` is null when the UA names no adjudicable family, or when the offer contains no audio and no video sections at all. Matching exact codecs would misread Chromium builds without proprietary codecs, enterprise codec policy, and distro builds as contradictions. This check is only evaluated when WebRTC is reachable; a blocked stack is an environment fact, not a tell.
How to resolve it
Present a UA that matches the browser whose WebRTC stack is actually compiled in. The native stack writes its own manifest; a non-Chromium engine behind a Chrome UA is contradicted by the SDP it generates, and no JS-level patch reaches that text.
Nearby checks in Network & WebRTC
- host candidates use an mDNS hostname rather than a literal LAN address
webrtc-mdns-hostWhen WebRTC enumerates the ways a peer might reach you, it offers host candidates describing your machine's own network interfaces. - ICE gathering offers at least one candidate on a working network
webrtc-gathering-suppressedThe other WebRTC rows on this page read what the candidates SAY. - The WebRTC host candidate does not expose a routable public address
webrtc-address-classReading from the same fully offline RTCPeerConnection — built with no iceServers, so host-only gathering, no STUN, no packets — the first… - every server-reflexive candidate has a host candidate behind it
webrtc-srflx-without-hostA server-reflexive candidate is not an address the browser knows about itself. - WebRTC header extensions match the claimed engine family
webrtc-extmap-engine-familyThis check generates an SDP offer and collects its a=extmap RTP header-extension URIs. - NetworkInformation is only present on Chromium engines
connection-api-vs-engineThis check compares an API's mere existence against the engine family named by the User-Agent. - navigator.connection.rtt obeys Chromium's 25ms quantisation
connection-rtt-quantizationThe probe reads navigator.connection.rtt from the NetworkInformation API, and the check runs only when that value is a number. - a slow effectiveType comes with a non-zero round-trip estimate
connection-ect-vs-rttnavigator.connection reports the link two ways that come from one estimator: effectiveType is a coarse bucket (slow-2g, 2g, 3g, 4g) and rtt…
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Network & WebRTC checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Network & WebRTC — the family sdp-engine-signature belongs to.