ICE gathering offers at least one candidate on a working network
Check id webrtc-gathering-suppressed
What an ordinary browser yields
Gathering completes with at least one candidate — typically an mDNS .local host candidate, which is what a privacy-preserving browser on a working network offers.
What a detector infers
The other WebRTC rows on this page read what the candidates SAY. This one reads whether there were any, which is a different question and keeps working when the others fall silent. A browser with a working media stack always offers at least one host candidate, because mDNS obfuscation was designed to keep the candidate while hiding what it points at: the LAN address is replaced by a random .local hostname, unique per origin, and the candidate is still offered so a real peer can still connect. Measured on stock Chrome on the reference machine: two host candidates, both .local. So gathering that runs to completion and yields an empty set is not a browser being careful, it is a media stack that was told not to speak — an IP-handling policy of disable_non_proxied_udp, an enterprise policy, a VPN or privacy extension, or a build that suppresses WebRTC by default. The distinction the check turns on is completion. A browser that has not finished gathering also has no candidates yet, and treating that as a finding would flag every slow network, so the row only speaks once the browser has signalled end-of-candidates; short of that it declines. It also explains itself: when this fires, the neighbouring WebRTC checks report N/A, and a reader deserves to know that the silence is the reason rather than wondering why half the section is blank. This row is CONTEXTUAL and never counts against the score, and that calibration was measured rather than assumed. An unmodified Chrome 150, launched with the documented switch --webrtc-ip-handling-policy=disable_non_proxied_udp, produces exactly this state: zero candidates, gathering complete. Enterprises deploy the same setting through the WebRtcIPHandling policy key to keep internal addresses off the media path. Scoring the row would therefore mark a supported configuration down for being configured, and nothing incoherent has actually happened — a media stack told not to speak, and then not speaking, is the browser agreeing with itself. The same launch matrix is worth knowing in full, because the intermediate setting behaves differently: default_public_interface_only yields two server-reflexive candidates and no host candidate at all, which passes this row while changing what the other WebRTC rows see. A note for anyone reproducing this: the --force-webrtc-ip-handling-policy spelling has no effect in Chrome 150, measured at four candidates, identical to no flag at all.
How to resolve it
Nothing needs fixing if this is deliberate. Suppressing WebRTC is a legitimate privacy choice and it is the correct answer to a media-path address leak, which is why this row is contextual and never counts against the score — a stock Chrome carrying the supported IP-handling policy reaches the same state, so scoring it would penalise a configuration rather than catch a lie. It is worth knowing that the choice is visible: a site can tell a browser that offers an obfuscated candidate from one that offers none, and total silence is rarer than obfuscation. Leaving mDNS host candidates enabled hides the LAN address while looking like everyone else.
Read in the wild by
CloakBrowser (measured)
Zero candidates with gathering signalled complete, on every launch measured, on a real HTTPS origin rather than a local server — the distinction matters, because an earlier localhost observation was set aside here as a probable artifact of the origin and that guess turned out to be wrong. Stock Chrome on the same machine and network gathered four candidates in the same conditions, which is what makes the silence attributable to the browser. Reported and not scored, for the reason set out above.
3/3 launches: iceGatheringState "complete", 0 candidates, no host and no server-reflexive. Stock Chrome 150 on the same network: 4 candidates (2 host, 2 srflx). Stock Chrome 150 with --webrtc-ip-handling-policy=disable_non_proxied_udp: 0 candidates, complete — the same state from a supported switch.
CloakBrowser (measured)Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Network & WebRTC
- the address WebRTC exits from matches the address this page was served to
webrtc-ip-vs-connectionThis is the one check on this page that cannot be answered from inside the page, and the only one that makes a network call. - relay-forced WebRTC exits the same address this page arrived from
webrtc-turn-egressEvery other WebRTC check on this page reads what the browser is willing to show it. - 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. - 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. - The WebRTC SDP offer matches the engine the User-Agent claims
sdp-engine-signatureAn RTCPeerConnection is constructed with no iceServers key, which makes the probe entirely offline: the native stack builds a local SDP… - 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.
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 webrtc-gathering-suppressed belongs to.