Methodology
What this tool tests, how each check works technically, what the scoring model is, and what it cannot detect.
The Six Checks
We run a server-side echo: your browser fetches /api/echo, our server captures the incoming request headers, strips all known infrastructure headers (Vercel, CDN, standard browser headers), and returns the remainder as JSON. Your browser then compares that remainder against a list of known ISP tracking headers.
- ✓X-UIDH (Verizon supercookie)
- ✓X-ACT-Tracking (AT&T tracking header)
- ✓X-Subscriber-ID (generic subscriber identifier)
- ✓X-Device-ID (device identifier injection)
- ✓X-BlueCoat-Via (Blue Coat proxy)
- ✓X-Squid-Error (Squid proxy)
- ✓X-Characteristic (DPI marker)
- ✓X-Network-Info (network info injection)
- ✓X-Client-IP (IP exposed by proxy)
Only detects headers we have rules for. An ISP could inject a novel header name we have not catalogued. The strip list must be kept current as platforms add new infrastructure headers.
We capture User-Agent and Accept-Language server-side (separate from the injection check) and compare them to navigator.userAgent and navigator.languages in your browser. If the base language tag changed or the User-Agent string was modified, a proxy rewrote them in transit.
- ✓Proxies that normalise User-Agent strings
- ✓Middleboxes that strip or replace Accept-Language
- ✓Corporate DLP appliances known to modify headers
Requires a mismatch to be detectable. A proxy that passes headers through unchanged but adds a new header would only be caught by the injection check, not this one.
We check whether the connecting IP address belongs to a known VPN or privacy-network ASN (Cloudflare WARP, Mullvad, ProtonVPN, etc.). We also parse the Cloudflare /cdn-cgi/trace response for warp=on or gateway=on signals. If the user self-attests that they use DoH/DoT, we give partial credit.
- ✓Cloudflare WARP active (warp=on in trace)
- ✓Cloudflare Gateway active (gateway=on in trace)
- ✓Connecting IP belongs to a known VPN/privacy-network ASN
We cannot determine which DNS resolver your device is actually using from an HTTP request. The connection IP tells us who owns the network, not which resolver was used. A Comcast subscriber using 1.1.1.1 DoH still has a Comcast IP. For a real DNS leak test you need a dedicated DNS server you control. We link to dnsleaktest.com for this.
We fetch https://cloudflare.com/cdn-cgi/trace and inspect the response. A genuine Cloudflare edge response contains a fl= field (the datacenter ID). A MITM proxy that intercepts and rewrites TLS traffic typically cannot replicate this field correctly.
- ✓TLS-terminating middleboxes that rewrite the Cloudflare trace response
This is an indirect signal, not a definitive proof of interception. A sophisticated proxy with a valid certificate and access to Cloudflare's infrastructure could potentially reproduce the trace. Certificate pinning would be more reliable but is not possible in a browser context without a browser extension.
We use RTCPeerConnection with two STUN servers (Google and Cloudflare) to collect ICE candidates. Public IPv4 and IPv6 addresses are extracted from the SDP candidates, filtering out RFC-1918 private ranges (10.x, 192.168.x, 172.16-31.x), loopback, and link-local addresses.
- ✓VPN bypass: VPN is active but WebRTC exposes the real ISP-assigned IP
- ✓Unexpected secondary IPv4 addresses different from the connection IP
For non-VPN users, seeing your ISP IP via WebRTC is expected: it's the same IP already visible via HTTP. We only score this as a problem if a VPN is active (bypass) or if an unexpected different IPv4 appears. We ignore IPv6 in the leak comparison since the connection IP we extract server-side is always IPv4.
We maintain a static database of ISPs with documented surveillance practices. The ISP name is identified from your connection IP via ipinfo.io and matched against the database. No real-time data is fetched.
- ✓Verizon (UIDH supercookie, location data sales)
- ✓AT&T (GigaPower surveillance program, Room 641A)
- ✓Comcast/Xfinity (DNS hijacking, JavaScript injection)
- ✓Spectrum/Charter (DNS hijacking)
- ✓Cox (DNS hijacking, data breach history)
- ✓CenturyLink/Lumen (DNS hijacking, data monetisation)
- ✓T-Mobile (repeated data breaches, T-EDGE ad platform)
- ✓Frontier (DNS hijacking, location data)
The database is static and based on publicly documented practices. It doesn't reflect current behaviour; an ISP may have changed since those incidents, or may be doing something new that hasn't been documented yet.
Scoring Model
The score starts at 100 and each detected signal applies a weighted adjustment. Scores are clamped to 0–100.
| Signal | Score adjustment |
|---|---|
| Known ISP tracking header detected (X-UIDH, X-ACT-Tracking, etc.) | −35 |
| TLS interception signal detected | −40 |
| Header modification in transit (proxy tampered User-Agent/Accept-Language) | −25 |
| No VPN / WARP / self-attested DoH detected | −20 |
| ISP with documented surveillance history (AT&T, Verizon) | −10 |
| ISP with documented practices (Comcast, Spectrum, Cox, etc.) | −8 |
| WebRTC bypass while on VPN (real IP exposed) | −15 |
| WebRTC exposes unexpected secondary IPv4 | −8 |
| Possible proxy headers detected (medium severity) | −18 |
| VPN/WARP IP confirmed, or Cloudflare WARP/Gateway detected | +9 |
| User self-attested DoH/DoT usage | +8 |
| Clean echo — no suspicious headers | +2 |
What This Tool Cannot Detect
Being honest about limitations is more useful than overstating what a browser-based test can do.
Privacy & Data Handling
Your IP address is never stored in plain text. It is hashed using HMAC-SHA256 with a daily-rotating salt before being written to the database. The hash cannot be reversed; we cannot look up a run by IP.
Test results (score, findings, ISP name, country) are stored in Supabase and associated with a random UUID run ID. The run ID is in the share URL; anyone with the link can see the results.
No cookies are set. No tracking pixels. Vercel Analytics collects anonymised page view data (no IP, no fingerprint).