Privacy Policy

1. What this service is

The Connection Risk Scanner is a security tool that produces a probabilistic risk score, not a definitive statement about who you are. A high score means the connection has traits commonly associated with automation, tunnelling, or spoofing — it is not proof, and false positives and false negatives are possible. See our Terms of Service for how the score may and may not be used.

2. Network signals (collected automatically from your connection)

When you connect, the server passively observes properties of your TCP/IP connection, TLS/QUIC handshake, and HTTP request. This happens for every visitor and does not require JavaScript.

These signals live only in volatile RAM. Once a signal's window elapses it is no longer used and is overwritten as new traffic arrives; the per-OS-class flag totals and the capture's operational counters (how many packets were captured or dropped, how many TLS ClientHellos were read, how many of those came without a captured SYN, in more than one TLS record or after a TLS warning alert, and how many connections did not start with a readable ClientHello) are not windowed: they hold counts only, with no address, port or time, and are kept until the service restarts. All of it is also cleared whenever the service restarts. None of it is written to a database.

3. In-browser signals (only if JavaScript runs on the scanner page)

If your browser runs the page script, it submits a one-off measurement set to the /me and /api/fp/observation endpoints so the server can compute a cumulative score. This includes:

• WebRTC ICE candidates, which can include local/private and, in some configurations, public IP addresses beyond your connection IP (used to detect split-tunnel VPNs);
• automation / headless indicators (e.g. navigator.webdriver, driver properties, permission-state anomalies), and whether the same navigator values (user agent, platform, languages, core count, time zone, media-codec support) read inside a background worker match the page's — this adds no new data, it only compares;
• time-zone, locale and languages;
• an active timing measurement over a WebSocket in which your browser hashes a challenge, so the server can time the true round-trip and compare it to the network RTT;
• an OPFS/storage-timing measurement (read/write latency distribution) used to tell physical devices from virtual machines — this measures timing only, it does not read file contents;
• while the page is open, counts of how it was moved: how many scrolls began with a touch, a wheel, a key or a pointer and how many with no input at all, how many wheel and mouse-move events occurred, how many input events were dispatched by a script rather than by you, and whether the page was marked as used without any input event reaching it. No keys, coordinates, pointer paths or per-event timings leave the page. When these counts change in a way that could matter, they are sent again and your result updates on the page;
• screen metrics, CSS media features as your browser evaluates them (primary pointer and hover type, touch support, screen size, pixel density and colour gamut), and how many of the page's honeypot images finished loading;
• bucketed GPU/WebGL renderer, audio, canvas, WebGPU, media-codec, WASM and User-Agent Client Hints values used by the consistency scorer (for the client hints also the brand names and major versions your browser reports to scripts, the same ones its sec-ch-ua header carries);
• whether one of a few fonts that ship with every copy of the operating system your User-Agent names renders (Segoe UI, Tahoma, Consolas, Lucida Console on Windows; Helvetica Neue, Menlo, Geneva, Monaco, Avenir on macOS): a single yes/no, measured from text layout, not a list of your fonts.

These raw browser measurements are processed within the request and are not written to a database or aggregated into a profile. The response is sent with Cache-Control: no-store. Some of the values you submit (for example a leaked WebRTC IP or a mismatched platform) may be echoed back to you inside the explanation of your own result.

Short-term comparison hashes. To notice abrupt changes and count how often a similar profile has been seen very recently, the server keeps small HMAC-SHA256 hashes derived from these signals for up to 15 minutes. These hashes contain no raw values, are keyed to a coarse network prefix (a /24 IPv4 or /48 IPv6 block, not your exact IP) plus a device hash, and build no cross-site or long-term identity graph.

4. Honeypot images & the DNS-leak check

Honeypot decoy images

The page embeds a few invisible decoy images of a few kilobytes each at unique, single-use URLs (/h/<token>/N.bmp). Some are loaded only when your input or screen matches a CSS media query (for example a touch screen, a mouse, or a phone-sized screen), and one is a lazy-loaded image that a browser never needs to show. The server records which of them your client fetched and in what order — a genuine browser loads the images it lays out and never the hidden one, while many bots do otherwise. This record (your IP, the per-page token, which tiles loaded and when, relative to the page) is held in memory for up to about 10 minutes after the page loaded or last asked for a scan, and never more than about 30 minutes. Until both of the page's two scans have answered and their results are logged together (see section 8), the record also keeps the first result of each scan (its scores, action and finding codes); it drops them once they are logged.

Our own WebRTC endpoint

The page's WebRTC check contacts one server only: our own endpoint at bot.pwn-all.com, at its IPv4 and its IPv6 address, UDP port 3478, with a username and password made for this page alone. It records the address your browser's UDP traffic came from over each IP version, to compare it with your connection's address (a split-tunnel VPN shows two different ones; a VPN that carries only IPv4 lets IPv6 leave from your own network), for as long as the page token lives (up to about 30 minutes). The network (ASN) and country of these addresses come from the same on-server database as your connection's. It relays nothing and does not answer anyone without this page's credentials.

DNS-leak check

To detect when a VPN/proxy is used but DNS still resolves elsewhere, the page includes a resource hint for a unique host name under our own zone. Your device's recursive DNS resolver (your ISP's resolver, or a public provider such as Cloudflare, Google or Quad9) then queries our authoritative name server. We record that resolver's IP address — a piece of your network infrastructure, not typically your own device — for up to about 10 minutes, and compare its country/network to your connection's. We look the resolver up against the same on-server database; its IP is not sent to anyone.

5. What we deliberately do not do

The scanner intentionally avoids covert and persistent tracking techniques. In particular it does not:

• read pixels back from your canvas (it only checks that the API exists);
• record your keystrokes, pointer paths or coordinates, or replay your session (it only counts what started each scroll);
• plant supercookies via HSTS, favicons, or ETags;
• use external STUN servers to harvest your public IP;
• run GPU execution-timing (DrawnApart), sensor-calibration (SensorID), TCP clock-skew, or TLS session-ticket tracking to link you across connections;
• set any tracking cookie, or load any third-party advertising, analytics, social, font, or CDN script;
• sell, rent, or share your data with data brokers.

6. Cookies, local storage & theme

We set no cookies and use no sessionStorage or IndexedDB. The site keeps a single small value in your browser's localStorage: cg_privacy_ack, which records the version of this notice you dismissed so it can reappear when the policy changes. It does not identify you and is never sent to the server. The light/dark appearance follows your operating-system preference automatically — there is no theme switch and no theme preference is stored. You can clear the stored value any time in your browser settings.

7. Sharing, third parties & data location

We do not share or sell your personal data. The limited external relationships are:

Our servers are located in Mumbai, India, so the limited data above is processed in India.

8. Server logs

For security and debugging, the server writes operational log lines to its standard error output. Most decision logs use only a coarse network prefix and non-reversible hashes. Decision lines also say, for each IP version, whether the WebRTC check saw your UDP traffic and whether it came from another path than your connection, without the addresses. When both scans of one homepage load have answered, one decision line logs their results side by side (scores, actions and finding codes) under the page's coarse prefix, and says for each scan whether its request came from another address than the page's, without that address. If your address changed during the page load (for example from IPv4 to IPv6), that line and the scan's own decision line, which carries the coarse prefix of the address the scan came from, together show that the two prefixes belonged to one page load. Decision lines for HTTP/3 visits also carry that connection's QUIC ClientHello fingerprint (JA4q), three yes/no bits about its transport parameters and a coarse class of its HTTP/3 settings (the header order, whether a reserved GREASE setting was present and how many settings there were), next to the coarse prefix. For Safari and other WebKit browsers, the decision line may also carry the connection's TLS ClientHello fingerprint (JA4) and the Safari version from the User-Agent (for example 26.0), but only when we do not check that Safari version yet or when the result flagged the connection's TLS or HTTP/2 stack, so that such results can be verified. When we flag a Firefox connection's TLS ClientHello as not Firefox's, a log line carries the coarse prefix, that JA4, the Firefox version from the User-Agent (for example 158) and which of two TLS-library marks failed (an ALPS extension was present, or the record_size_limit extension was missing), so that a new Firefox release that trips the check is noticed. When a connection's TLS ClientHello offers obsolete cipher suites, its decision line also names which of five classes it offered (RC4, NULL, export, anonymous, single DES). Decision lines also carry a few yes/no bits saying which TLS ClientHello rules the connection's hello broke, if any (for example key shares sent out of order), and say whether the TLS ClientHello fingerprint the result used was the connection's own, one from an earlier connection from your address, or none. When the client hints your page reports contradict themselves or the request, the decision line names which of four checks failed (the form of the OS version, the OS version, the two brand lists, the Chromium version), not the values. None of these values is unique to you: every copy of the same browser version sends the same ones. A decision line may also carry rounded server-side counts for that one page load (decoy images that arrived, how many requests its page made and how evenly spaced, how often it asked for a verdict, whether its timing connections completed), never an address, a page token or anything the page's scripts measured. However, some security log lines — for example when we detect a spoofed User-Agent — may record your full IP address and the associated TLS fingerprint. These logs are used only for operating and defending the service; they are not aggregated into visitor profiles, and the server's log store keeps them for about 7 days before deleting them.

9. Legal basis, your rights & children

Processing relies on our legitimate interest in detecting and preventing automated abuse, fraud, and bot traffic (Art. 6(1)(f) GDPR where the GDPR applies). Because our servers are in India, data is processed under the Digital Personal Data Protection Act, 2023. If you access the site from the EU/EEA or the UK, the GDPR / UK GDPR also applies and using the site involves a transfer of the limited data described here to India.

You have the rights of access, rectification, erasure, restriction, and objection. In practice we hold no persistent, searchable record tied to your identity: apart from the server logs in section 8, everything is short-lived in-memory data that expires within the windows above and cannot be looked up after the fact, so in most cases there is nothing left to retrieve or delete by the time a request reaches us — erasure effectively happens by waiting out the short window. The service is not directed at children, and we do not knowingly collect data from anyone under the age required by their local law.

10. Security & changes

All traffic is served over TLS (HTTPS, including HTTP/2 and HTTP/3). Apart from the server logs in section 8, scanner data lives only in process memory for its short lifetime and is not exported. If this policy changes materially, the on-site notice will reappear so you can review it. Questions or requests: hello@pwn-all.com.