NetworkInformation is only present on Chromium engines
Check id connection-api-vs-engine
What an ordinary browser yields
The row does not appear — either the UA claims V8 (where NetworkInformation legitimately exists), or navigator.connection is absent on a Firefox/Safari identity.
What a detector infers
This check compares an API's mere existence against the engine family named by the User-Agent. It reads two things: status.hasConnection (whether navigator.connection is present at all) and claimedEngine(ua), which maps the UA string to V8 (Chrome/Chromium/Edge/CriOS), SpiderMonkey (Firefox/FxiOS), JavaScriptCore (iOS browsers, or Safari without a Chromium token), or null when no family is recognized. The row is only added when navigator.connection exists AND the UA claims a non-null engine that is not V8 — and in that case it is emitted with pass:false unconditionally. The mechanism is surface-area rather than value inspection: NetworkInformation is a Chromium-only API, unshipped by Gecko and WebKit, so its presence is itself evidence of a Chromium engine underneath. When a UA string says Firefox or Safari, a detector observes an API that browser does not implement, and infers that the UA string was rewritten while the underlying engine's surface was not. That inference is reliable because it requires no measurement or tolerance — an object either exists or it does not, and the browser vendors' shipping decisions are public fact. Note the null branch: if claimedEngine returns null (an unrecognized UA), no assertion is made and the row never appears.
How to resolve it
Remove navigator.connection entirely when presenting a Firefox or Safari identity, so the exposed API surface matches the engine the UA names. The alternative resolution is the reverse: present a Chromium UA that matches the Chromium engine actually running. Do not try to make navigator.connection's values look Firefox-like — the contradiction is the object's existence, not its contents.
Read in the wild by
Kasada
Reads navigator.connection.rtt in both the main window and an iframe realm, and separately records whether window.chrome is absent in each.
window_conn_rtt, iframe_conn_rtt, window_nav_info_no_chrome, iframe_nav_info_no_chrome — source: "Kasada ips.js teardown — the full 427-probe list", https://web.archive.org/web/2026/https://emro.cat/blog/how-i-broke-the-anti-bot-behind-nike-kick-and-twitch/
PerimeterX / HUMAN
Records the presence of the Network Information API as an explicit boolean — `!!(navigator.connection || navigator.mozConnection || navigator.webkitConnection)` — shipped as the `support` field of a dedicated ev2 entry, alongside a `status` object holding NetworkInformation.prototype's own enumerable non-null properties.
main.min.js (stample/ifood/source): `function xw(t){try{var n,e=hU,r=e[hQ(369)]||e[hQ(370)]||e.webkitConnection,h={};for(var i in r)r[hQ(274)][hQ(145)](i)&&null!==r[i]&&(h[i]=r[i]);t[hQ(371)]=((n={})[hQ(372)]=!!r,n.status=h,n)}catch(t){}}` — hQ_map.json: 369='connection', 370='mozConnection', 274='__proto__', 145='hasOwnProperty', 371='eWVMLzwFSRQ=', 372='support' → all_fields_map.json EV2 "eWVMLzwFSRQ=" = {"support":true,"status":{"effectiveType":…}} (warterbili/PerimeterX_RE, ifood collector, 2026-05-19 SDK snapshot)
Every 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… - 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 connection-api-vs-engine belongs to.