navigator.connection.rtt obeys Chromium's 25ms quantisation
Check id connection-rtt-quantization
What an ordinary browser yields
Pass — Chromium rounds rtt to 25ms steps, so any genuine reading is a multiple of 25.
What a detector infers
The probe reads navigator.connection.rtt from the NetworkInformation API, and the check runs only when that value is a number. The assertion is a single modulo: rtt % 25 === 0. The mechanism is that Chromium does not report a raw measured round-trip time — it deliberately rounds RTT to 25ms steps as a privacy measure, so every genuine reading is a multiple of 25 (0, 25, 50, 75, 100, …). This makes the value's residue class, not its magnitude, the discriminating signal. A detector reading rtt=87 learns something structural: 87ms is an entirely plausible round-trip time, but it is not a number Chromium's quantizer can emit, so the value did not come from Chromium's network stack. The inference is reliable precisely because it does not depend on whether the number looks realistic — a hand-picked "realistic" random value fails the modulo instantly, while the quantization grid is a fixed, documented property of the engine. Severity is warn; a value that is a multiple of 25 (including 0) passes.
How to resolve it
Round any reported RTT to a multiple of 25 so it lands on Chromium's quantization grid, or leave NetworkInformation untouched and let the engine produce the value. If navigator.connection is absent or rtt is not a number, the row is not emitted.
Read in the wild by
Kasada
Reads the Network Information RTT in both realms.
window_conn_rtt, iframe_conn_rtt
ips.js 427-probe teardown (emro.cat, Apr 2026)
PerimeterX / HUMAN
Carries the whole navigator.connection object as an ev2 field.
ev2 cyNFaTZDQ1I= (navigator.connection object)
warterbili/PerimeterX_REAkamai
Lists connection type, effectiveType, RTT and downlink as its network signal category.
signal_categories.md - 7. Network - Round-trip time / Downlink speed
Edioff/akamai-analysis — signal_categories.mdEvery 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. - 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 connection-rtt-quantization belongs to.