a slow effectiveType comes with a non-zero round-trip estimate
Check id connection-ect-vs-rtt
What an ordinary browser yields
A slow effectiveType (3g/2g/slow-2g) comes with a non-zero rtt. A 4g bucket is the no-estimate default and is never scored.
What a detector infers
navigator.connection reports the link two ways that come from one estimator: effectiveType is a coarse bucket (slow-2g, 2g, 3g, 4g) and rtt is a round-trip estimate in milliseconds. Because both are derived from the same network-quality estimator, a slow bucket arrives with a slow rtt; the estimator never reports a slow connection with instant latency. A stealth build that stubs NetworkInformation to control its shape tends to freeze rtt at 0 while leaving a non-4g effectiveType in place, which claims exactly that impossible pairing. The check corroborates against a source the stub cannot touch: the page own PerformanceNavigationTiming, which records that a real network round trip actually happened, so the estimate is not ready yet cannot explain a zero. The gating is deliberate and heavy. A 4g bucket is never scored, because 4g is also what Chromium reports when the estimator has no reading at all, and the finding only stands once a navigation round trip has provably completed. Severity is warn rather than critical because CDP network throttling in DevTools and Lighthouse drives effectiveType and rtt through the same override, so a caller could set a cellular type with zero latency as a legitimate if artificial configuration.
How to resolve it
effectiveType and rtt come from one estimator and move together. If NetworkInformation is being presented, derive both from a single plausible link profile rather than leaving rtt pinned at 0 — or leave the API untouched, since it is Chromium-only and its mere presence already carries meaning.
Read in the wild by
CloakBrowser issues
A stealth-browser tracker records the stubbed-NetworkInformation shape this reads: the connection object present but its latency frozen while the browser otherwise presents as Chrome.
CloakHQ/CloakBrowser #447 (navigator.connection rtt behaviour)
CloakHQ/CloakBrowser#447Every attribution traces to a published artifact. See the sources and their limits.
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. - 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. - 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.
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 connection-ect-vs-rtt belongs to.