Ethics and privacy in IP intelligence
IP intelligence sits in an awkward place. It exists to make judgements about people's network behaviour for fraud, compliance, and abuse-prevention reasons. Those judgements can be helpful or harmful depending on what data the service collects, what it exposes, and how its consumers apply the verdicts. This is what IPLogs concretely does and refuses to do, and a frame for evaluating any IP-intelligence vendor — including this one — against the same standard.
What an IP-intelligence service should and shouldn't do
| Should | Shouldn't |
|---|---|
| Surface every signal that contributed to a verdict | Return an opaque score with no per-signal provenance |
| Publish a measurable false-positive rate against a labelled corpus | Claim accuracy without a falsifiable benchmark |
| Treat Apple Private Relay, Cloudflare WARP, and CGNAT as separate categories | Lump them in with commercial VPNs to inflate detection rates |
| Keep request logs transient and minimal | Build a persistent database of who looked up what |
| Document the data sources openly | Claim “proprietary signals” that can't be audited |
| Be honest about what IP intelligence cannot verify | Position IP detection as identity, age, or location proof |
What IPLogs concretely does
- No signup, no API key. The detection endpoint is fully unauthenticated. There is no way for IPLogs to attribute a check to a customer because the design avoids the data collection that would make that possible.
- Transient logs only. Request logs exist for abuse detection and rotate automatically. No persistent database of individual lookups, no tracking cookies, no advertising integrations, no third-party analytics. The full statement is in /privacy.
- Per-signal provenance in every response. The API returns a typed
Signal[]array showing every feed and probe that matched, with weights and human-readable detail strings. There is no single opaque risk score that can't be audited. - Published false-positive rate. /accuracy documents the ground-truth methodology and the measured error rates. Any vendor that won't share an error rate against a labelled corpus is asking you to trust a number you cannot audit.
- Apple Private Relay and Cloudflare WARP are separate categories. Both are mainstream privacy products used by ordinary consumers. Treating them as commercial VPN exits would punish real users; the API emits them as their own signal types so your policy can apply different rules.
- CC-BY 4.0 datasets at /tools. The aggregated VPN-provider, datacenter, and Tor-exit datasets are public under CC-BY 4.0. The intent is that other detection projects can use the same ground truth and audit the source data.
The legitimate privacy critique
Privacy-rights organisations like the Electronic Frontier Foundation, Access Now, and Article 19 have published serious critiques of IP-detection-as-compliance, particularly when laws require sites to verify a user's physical location even when the user is on a VPN. The critiques are correct in substance:
- IP detection is probabilistic, not authoritative. Using it as a legal determination is a category error.
- Blanket VPN blocks disproportionately harm privacy-conscious users, journalists, activists, people in censored regions, and ordinary travellers — none of whom are the population the rule was probably written for.
- IP intelligence in the hands of bad actors (state actors, stalkers, employers exceeding their authority) creates harm that the same data in a fraud-prevention context does not.
The honest answer is to use detection where it helps (fraud prevention, payment risk, signup abuse), refuse to use it where it harms (identity verification, blanket country bans, surveilling specific users), and choose tooling that exposes its work so both kinds of use are visible to the operator and to the user.
Practical rules for fraud teams
- Block writes, allow reads. Block high-risk actions (signup, payment, KYC, withdrawal, admin) on a confirmed VPN. Step up auth on weaker signals. Leave read traffic open. The full pattern is in /guides/block-vpn-traffic.
- Always provide a dispute path. Tell users a connection looked anonymized and give them a way to contact support. False positives are inevitable; the cost of one is much lower if the user can ask a human to look at it.
- Log decisions, not just inputs. Record which verdict produced which action so an auditor (or your future self) can reason about edge cases. If you only store the raw IPLogs response, you can re-derive what happened; if you only store “blocked,” you can't.
- Don't use IP detection as identity or age verification. It can't be either. A real identity-verification provider (document-based or credit-bureau-based) is a different product category. See the regulations overview for the framing.
FAQ
Does IPLogs store the IP addresses it checks?
Only in transient request logs for abuse detection. Logs rotate automatically. There is no persistent database of individual lookups, no tracking cookies, no advertising integrations, and no third-party analytics. The privacy and storage statement is at /privacy.
Is there a public API key or signup that would let me identify users?
No. The /v1/check endpoint is fully unauthenticated. There is no signup, no API key, no token. There is intentionally no way for IPLogs itself to attribute a check to a specific account or customer, because the design avoids the data collection that would make that possible.
How transparent is the detection methodology?
Every signal that contributes to a verdict is returned in the API response as a typed Signal with a weight, a matched flag, and a human-readable detail string. The full source list — provider APIs, aggregator feeds, threat-intel sources — is documented at /docs and the false-positive rate is published at /accuracy. Closed proprietary scores are an industry default IPLogs deliberately avoids.
Is blocking VPN users ethical?
Sometimes, depending on the action and the user. Hard-blocking read traffic is rarely justified — Apple Private Relay, Cloudflare WARP, CGNAT mobile users, corporate VPNs, and privacy-conscious customers all show up there. Per-action policy (block writes, step up auth on risk, allow reads) reduces collateral harm. See /guides/why-vpn-blocking-fails for the technical and product argument.
How does IPLogs handle private and CGNAT addresses?
Private (RFC 1918), loopback, link-local, multicast, IPv6 ULA, and IPv4-mapped IPv6 addresses are recognised at the routing layer and the per-IP page explains what the visitor is looking at instead of returning a meaningless verdict. CGNAT (100.64.0.0/10) is labelled explicitly as carrier-grade NAT because the same public IP may be shared across many subscribers.
Related: privacy policy, published accuracy benchmark, why complete VPN blocking can't be a compliance solution, and the API docs for the unauthenticated endpoint surface.