navigator.connection leaks effectiveType, downlink, and rtt with no permission prompt, and Chromium-only support is itself a fingerprint signal.
Most fingerprinting signals describe your hardware or your software. The Network Information API describes something else entirely: the connection carrying the page itself — its rough speed class, its measured round-trip time, and whether you've asked your browser to go easy on data. None of it requires a permission prompt, and on the browser engine that implements it, any page can read it the instant it loads.
Key Takeaways
navigator.connectionexposeseffectiveType,downlink,rtt, andsaveDatawith zero permission prompt — any script can read your connection's coarse speed class on page load.- The values are deliberately bucketed, not raw, to blunt fingerprinting — but the bucket you land in, combined with dozens of other signals, still adds measurable entropy to a combined fingerprint.
- Support is Chromium-only. Chrome, Edge, Opera, and Samsung Internet implement it; Safari and Firefox implement neither
NetworkInformationnornavigator.connectionat all. - That gap is a signal on its own — a script can use the mere presence or absence of
navigator.connectionas a coarse, unspoofable engine check, independent of whatever the User-Agent string claims. - BrowserInsight's fingerprint check reports which network-level attributes your own browser exposes, alongside every other signal in your fingerprint.
navigator.connection: effectiveType, downlink, rtt, saveData
The API attaches a single NetworkInformation object at navigator.connection. Where it's implemented, reading it takes one line and no user interaction of any kind:
const conn = navigator.connection;
console.log(conn.effectiveType); // "4g", "3g", "2g", or "slow-2g"
console.log(conn.downlink); // estimated bandwidth in Mbps, rounded to the nearest 25 kbps then bucketed
console.log(conn.rtt); // estimated round-trip time in ms, rounded to the nearest 25ms then bucketed
console.log(conn.saveData); // true if the user turned on Data Saver
Four properties do the work. effectiveType is the browser's own classification of your connection into one of four generational buckets — slow-2g, 2g, 3g, or 4g — based on recently observed rtt and downlink values, not on the actual radio technology in use; a throttled Wi-Fi link can just as easily read "3g". downlink is an estimated effective bandwidth, and rtt is an estimated round-trip latency to the current server — both built from the browser's own recent network transfers, not a fresh probe run for the page. saveData simply reflects whether the user has an OS- or browser-level "Data Saver" mode turned on. Some Chromium builds also expose a type field (wifi, cellular, ethernet, bluetooth, none, or unknown), though its availability varies by platform.
Coarse Profiling and Entropy
The spec authors were explicit that raw, continuously-updating bandwidth and latency numbers would themselves be a strong fingerprinting vector — a live throughput reading is close to unique per network path at any given moment. That's why downlink and rtt are rounded and bucketed rather than reported at full precision, and why effectiveType collapses everything into just four coarse tiers. This is a real mitigation, not a token one.
It doesn't reduce the contribution to zero, though. A four-way effectiveType split, an rtt bucket, a downlink bucket, and a boolean saveData flag still combine into a modest number of distinguishable states — small next to a canvas hash, but not nothing once folded into a combined fingerprint alongside screen metrics, fonts, and WebGL output. Where it earns its keep as a tracking signal isn't raw entropy so much as stability and cross-context correlation: the same physical link tends to report the same effectiveType/rtt bucket across different sites and different tabs opened around the same time, which gives a tracker a weak but free hint that two sessions might share a network — useful for linking activity across origins even when cookies and storage are partitioned per site. It's also a plausibility check: a session that claims to be on a "4g" mobile connection with sub-20ms RTT to a residential ISP endpoint reads as inconsistent, the same way the IP-geolocation-vs-timezone mismatch technique flags contradictions between independent signals rather than relying on any one of them alone.
Chromium-Only Support as a Signal Itself
The API's reach is the part that's easy to miss. caniuse.com's compatibility table shows global support sitting in the roughly 75–80% range — not because it's a niche or experimental feature, but because it's shipped in every Chromium-based browser and in none of the others. Safari has never implemented NetworkInformation, and Firefox shipped an early version behind a flag years ago before removing it; neither browser exposes navigator.connection today. The WICG spec repository that defines the API is itself hosted under the Chromium-adjacent Web Incubator Community Group, and adoption outside that ecosystem has never materialized.
That asymmetry is useful precisely because it doesn't depend on anything a script reads from the connection's values — it depends on whether navigator.connection exists at all. A page can check 'connection' in navigator as a near-instant, zero-permission signal that narrows the browser engine down to "some Chromium build" versus "not Chromium," independent of whatever the User-Agent string or User-Agent Client Hints claim. That makes it a small but genuinely useful cross-check in the same family as TCP/IP stack fingerprinting or TLS fingerprinting: signals that are hard to spoof convincingly because faking them means either running the real underlying engine or carefully reproducing a behavior most spoofing tools don't bother touching. A UA-string spoofer that claims Safari while navigator.connection still resolves to a real object is quietly self-contradicting.
Privacy Considerations
None of this requires the aggressive defenses that canvas or WebGL fingerprinting call for, mostly because the API's own design already bounds the risk:
- The bucketing is doing real work. Because
downlinkandrttare rounded and quantized rather than raw, there's no meaningful extra protection to gain by trying to further obscure them yourself — the spec already collapsed the high-resolution version of this signal that would have mattered most. - Privacy-focused browsers already remove the surface. Since Firefox and Safari don't implement the API at all, using either one eliminates this vector entirely — no configuration needed.
- Chromium users have less direct control. There's no user-facing toggle to hide
navigator.connectionfrom pages the way there is for camera or location permissions, because the API was never gated behind a permission model in the first place — it was designed to be low-risk enough not to need one. - Treat it as one weak signal among many. Combined with screen geometry, fonts, and WebGL, it's another small increment in a broader fingerprint — worth knowing about, not worth losing sleep over on its own.
- Check what your setup exposes. BrowserInsight's fingerprint check shows whether
navigator.connectionis present in your current browser and what it reports, alongside the rest of your exposed signal set.
Frequently Asked Questions
Does the Network Information API require a permission prompt?
No. Where it's supported, navigator.connection and its properties are readable by any script on page load, with no user gesture, dialog, or grant required — unlike geolocation or camera access.
Can a site get my exact internet speed from this API?
No, not precisely. downlink and rtt are deliberately rounded and bucketed by the spec, and effectiveType only reports one of four coarse generational tiers. You'll get a rough class of connection, not a live speed-test-grade measurement — for that, a site would need to actually transfer data and time it, the way BrowserInsight's network speed test does.
Why don't Firefox and Safari support this API?
Both browsers have simply never shipped it as a stable feature; Firefox tried an early version behind a flag and removed it. Support today is limited to Chromium-based browsers — Chrome, Edge, Opera, and Samsung Internet among them — which is itself documented on caniuse.com.
Can I block this signal with a browser extension?
Indirectly, yes — an extension that blocks JavaScript execution or strips navigator.connection before page scripts run would close it, but there's no dedicated, widely-used extension built specifically for this one API, since it's a minor contributor compared to canvas, WebGL, and font signals. Using Firefox or Safari removes it without any extension at all.
Conclusion
The Network Information API is a good example of a fingerprinting signal that's small by design and still worth understanding. Its authors clearly anticipated the risk and bucketed the values to blunt it, so navigator.connection alone won't identify you. What it adds is a coarse cross-context stability hint layered onto a much larger combined fingerprint — and, just as importantly, a free, hard-to-fake check on which browser engine you're actually running, since only Chromium ships it at all. Neither property demands a special defense: it mostly rides along with whatever you're already doing to manage the rest of your browser fingerprint.
Recommended Reading:
