Every production system you’ve operated assumes you can watch it: dashboards count active sessions, APM tools trace requests by user ID, capacity planning runs off real, unmasked bandwidth numbers. Tor breaks that assumption on purpose. Its entire value proposition is that no party — not an outside observer, not a relay operator, not even the Tor Project itself — can reliably link who is talking to whom. Instrument it the way you’d instrument any other distributed system, and you haven’t built a dashboard. You’ve built a deanonymization tool.
So how do you operate, capacity-plan, and debug a network engineered to destroy the very telemetry you’d normally rely on? The answer Tor has actually built is privacy-preserving measurement: a small toolkit of inference, noised aggregation, and cryptographically-blinded reporting, substituted for the counters everyone else takes for granted. The more interesting answer is that some questions — including the one people ask most, “how much of Tor is used for crime?” — currently have no good answer, and the reason why is the most useful thing this article can teach you.
🔭 Why Ordinary Observability Is a Threat Here
On a normal service, better telemetry is an unambiguous good: more granular logs, more precise per-user counters, more distinct IDs to join across systems. On Tor, that same instinct is the threat model. A directory server that logged which specific client fetched a consensus at which second, correlated against which relay that client’s circuit later used, would be running a traffic-confirmation attack against its own users — accidentally or not. Anything that lets an operator reconstruct “this identifier did this action at this time” is exactly the join key an adversary needs.
That constraint doesn’t mean Tor runs blind. It runs on aggregate, unavoidably-exposed side signals — coarse data that leaks out of any distributed system no matter what you do (someone has to fetch a directory, someone has to route a byte) — converted into estimates through documented, openly-acknowledged-as-imprecise methods. The rest of this article walks that toolkit in the order Tor actually reaches for it: counting users without counting them, two different privacy-preserving measurement systems (routinely conflated, and shouldn’t be), pricing bandwidth when relays have every incentive to lie about their own capacity, what happens when the measurement system itself becomes an attack surface — and, as the sharpest illustration of the whole problem, a widely-repeated statistic nobody has reproduced in years.
🕯️ Counting Users Without Counting Users
Tor deliberately does not, and structurally cannot, count its users. What Tor Metrics publishes as a “user count” is an estimate built from one indirect signal: how often clients fetch the network directory.
The method is public and specific. A well-connected client that stays online all day makes roughly 15 directory requests in that time; an intermittent client makes fewer; Tor Metrics assumes an average of about 10 directory requests per client per day. Divide the total observed directory-request volume by 10, and you get an estimated count of average concurrently-connected users — not a headcount, not a list of distinct people, and explicitly not a count of bridge users, who are tracked separately because they don’t fetch the public directory the same way. Tor Metrics states the limitation itself, in language worth quoting exactly, because it’s a rare thing for a metrics system to admit: “We can’t say how many distinct users there are… whether the same set of users stays connected over the whole day, or whether that set leaves after a few hours and a new set of users arrives.”
That’s not a hedge buried in a footnote — it’s the top-line caveat on the number everyone quotes. An estimate built this way can be wrong in either direction: a stable population generating ~10 requests/day each looks identical, in aggregate, to a much larger population that churns through in a few hours. The methodology has also faced independent academic scrutiny: David Fifield’s PETS 2023 talk, “Calibrating Tor Metrics user estimates,” examines where the extrapolation’s error comes from — read it directly for current error bounds, not something to eyeball from the headline number.
If you want a live snapshot, Tor Metrics’ public graphs put the running-relay count somewhere in the 7,500–9,500 range and estimated average daily directly-connecting users around 2.0–2.5 million through the 2025–2026 window (bridge users push the practical total toward 2.5–3 million/day) — but treat that as exactly what it is, a dated snapshot from a chart that moves week to week, not a fixed fact to keep citing.
🌫️ Privacy-Preserving Measurement, Take One: The Laplace Noise Behind the Live Graphs
For statistics finer-grained than “how many users,” Tor needed something more than division. The live Onion Services charts on metrics.torproject.org — unique .onion addresses seen, traffic volume relayed through rendezvous points — are built from a differentially-private extrapolation mechanism that predates most of what people associate with “differential privacy” in production systems: Kadianakis & Loesing’s 2015 technical report, “Extrapolating network totals from hidden-service statistics.”
The mechanism is straightforward once you see it. Individual relays acting as HSDirs or rendezvous points keep local daily counters. Before those counters are ever reported anywhere, each relay adds Laplace-distributed noise (mean zero, scale tied to a target privacy budget of roughly ε≈0.3) to its own number. Only once at least 1% of the network’s relays have reported their noised counters does Tor extrapolate a network-wide total — below that threshold, the sample is considered too small and no public total is published at all. It’s a cheap, decade-old, always-on pipeline: no cryptographic handshake between relays, no coordination protocol, just add noise locally, publish, and extrapolate once you have enough samples.
🔐 Privacy-Preserving Measurement, Take Two: PrivCount, the Heavier One-Off Research System
PrivCount is a different, more rigorous system — and it is routinely conflated with the mechanism above, which is a mistake worth correcting explicitly. Where the Laplace extrapolation is “add noise, then trust the aggregator with the noised number,” PrivCount is built so the aggregator never sees any individual relay’s raw count at all, noised or not.
PrivCount is Tor’s independent implementation of the secret-sharing variant of the PrivEx protocol, published as Jansen & Johnson’s “Safely Measuring Tor” at CCS 2016. Each participating relay locally adds a random blinding value to every statistic it reports; those blinded shares only cancel out correctly once combined across enough relays, so no single relay’s contribution — and no single aggregator holding one share — ever exposes the underlying number. Laplace noise is then layered on top of the final aggregated total, giving a formally-provable differential-privacy guarantee: the deployed version used ε = 0.3, δ = 10⁻³, the same ε already in use for the hidden-service statistics above.
The distinction matters because of what each system is actually for. The largest published PrivCount-based study of live Tor — Mani, Wilson-Brown, Jansen, Johnson & Sherr’s “Understanding Tor Usage with Privacy-Preserving Measurement,” IMC 2018 — was a research deployment, run to answer a specific set of questions once, not a pipeline that keeps running. PrivCount is not the system behind the live onion-service graphs; it’s the heavier instrument Tor reaches for when a one-off study needs a provably-bounded privacy guarantee that the cheaper, continuously-running extrapolation doesn’t offer.
Put the two side by side, because the difference is the whole point:
| Laplace-noise extrapolation (2015) | PrivCount (2016) | |
|---|---|---|
| Role today | Powers the live “Onion Services” graphs on metrics.torproject.org, continuously, for a decade | One-off research instrument; not a standing production pipeline |
| What’s protected | Each relay’s own counter, noised before it’s reported | Each relay’s raw contribution, hidden from the aggregator via secret-sharing, then noised in aggregate |
| Privacy guarantee | Noise calibrated to a target ε≈0.3 | Formally proven differential privacy: ε = 0.3, δ = 10⁻³ |
| Trust model | Aggregator sees each relay’s already-noised number | Aggregator never sees any single relay’s raw or noised individual value |
| Where you’ve seen its output | Unique .onion address counts, rendezvous traffic-volume charts | Mani et al., IMC 2018 (the web-traffic-share and onion-share figures cited later in this article) |
| Operational cost | Cheap; no coordination protocol between relays | Heavier; requires relay-side participation in a secret-sharing scheme |
Same design pattern — aggregate, then add calibrated noise — at two very different levels of rigor, deployed for two very different purposes. Conflating them isn’t just imprecise; it misattributes what’s actually running behind a number you might cite.
⚖️ The Self-Reported-vs-Measured Problem: How Tor Prices Bandwidth
Traffic telemetry is one problem; capacity is a different, adversarial one. Tor’s relay-selection algorithm weights circuits toward higher-bandwidth relays for performance, which means a relay’s reported bandwidth directly determines how much real user traffic gets routed through it. Left purely self-reported, that’s an open invitation to lie.
Tor doesn’t purely trust self-reports. A subset of Tor’s nine directory authorities run bandwidth scanners — historically TorFlow, now its simpler successor, the Simple Bandwidth Scanner (sbws). sbws builds two-hop test circuits (a fixed helper relay plus the relay under test), pushes fixed-size chunks of data up and down through each one, and files an hourly “bandwidth file.” The directory authorities then vote a consensus bandwidth value for each relay from the median of at least three scanner votes, which is why the network tolerates individual scanners going offline. As of a Tor Project blog snapshot, six of the nine directory authorities ran scanners (one authority is bridge-only and does not scan) — treat that ratio as a number to re-verify, not a fixed architectural constant.
Here’s the uncomfortable finding: active probing is still an under-measurement, and it’s a quantified one. The team behind FlashFlow measured sbws against the network it’s supposed to be scoring and found it underestimates true relay capacity by about 50% and misallocates traffic by 15–25% relative to what relays can actually handle. That’s not a gaming attack — it’s sbws simply being wrong at its actual job, on the deployed system, today. If a distributed system’s own trust model produces measurement error at that scale before anyone tries to exploit it, the exploit surface underneath it is worth taking seriously.
You can measure network performance precisely on almost any other network by just watching real, unmasked bandwidth throughput. Tor can’t do that cheaply at scale without giving relays a reason to game the watcher — which is exactly the next problem.
🎯 When the Measurement System Becomes the Attack Surface
Active probing that a participant can predict is active probing that a participant can optimize against. Two independent research teams have since turned that observation into concrete, quantified attacks on sbws-style measurement, and one more is cited but deliberately left unverified here.
TorMult (2023) describes coordinating clusters of relays that quietly share bandwidth capacity behind the scenes — so each individual relay in the cluster can be probed and appear to have far more capacity than the cluster as a whole actually possesses, inflating reported bandwidth by close to a factor of the cluster size on one machine, or cluster-size-times-machine-count across several. The authors’ own numbers are the part that should worry an architect: they calculate an attacker could gain control of roughly half the Tor network’s traffic using just 10 dedicated servers hosting a cluster of 109 relays at 100 MB/s each.
MirageFlow, published at NDSS 2024, describes a related bandwidth-inflation technique against the same trust model. Its specific figures were not independently verifiable from the published paper for this article, so treat its existence and venue as the citable fact here, not any particular number attached to it.
FlashFlow’s own proposal inverts the trust model rather than patching it: instead of a small number of authorities lightly probing each relay in turn, coordinate teams of measurers to blast a single relay with enough simultaneous load to approximate its true saturation throughput. In their experiments, that bounds a malicious relay’s achievable inflation to at most 1.33x its real capacity, while measuring the entire live network in under five hours. FlashFlow is a published research design, not a confirmed production replacement for sbws — verify current bandwidth-authority tooling before asserting which system is actually live at read time.
| Finding | What it demonstrated | Reported figures | Venue / year | Status |
|---|---|---|---|---|
| FlashFlow’s sbws audit | The deployed active-probing scanner systematically mis-measures, before any attacker gets involved | ~50% capacity underestimate; 15–25% traffic misallocation | Traudt, Jansen & Johnson, ICDCS 2021 | Finding about the live sbws system |
| TorMult | Colluding relay clusters can inflate self-reported bandwidth close to the cluster’s size | ~50% of network traffic achievable via 10 servers / 109 relays at 100 MB/s | Sendner et al., 2023 | Academic attack, not observed exploited in the wild |
| MirageFlow | A further bandwidth-inflation technique against the same measurement model | Not independently verifiable — cite venue/existence only | NDSS 2024 | Academic attack paper |
| FlashFlow’s fix | Team-based saturation probing bounds achievable inflation | ≤1.33x inflation in-experiment; full network in <5 hours | Traudt, Jansen & Johnson, ICDCS 2021 | Published proposal, not confirmed deployed |
This is the same lesson anyone building DORA metrics for AI coding agents has to relearn about stopping the gaming: a metric a participant can predict is a metric that will eventually be optimized against rather than honestly reported, and the fix is never “trust harder” — it’s changing what the measurement actually costs the participant to fake.
❓ So, How Much of Tor Is Used for Crime? Nobody Currently Knows
This is the question every “what is Tor” conversation eventually reaches, and it’s worth answering as precisely as the data actually allows — which is less precisely than most confident answers online suggest.
Start with what onion-service traffic share actually is: a measure of what fraction of Tor’s traffic touches an onion service versus the open internet, not a measure of legality or content. The only methodologically transparent measurement of that fraction comes from a February 2015 Tor Project study, using roughly 70 volunteer relays reporting anonymized daily aggregates from their HSDir and rendezvous-point roles, covering an estimated 2–5% of the total HSDir space. It found onion-service traffic was 3.4% of client-side circuit traffic and 6.1% of relay-side traffic — and the study’s own authors cautioned the numbers be read “with a grain of salt,” given the sample size. A 2018 academic follow-up using PrivCount (Mani et al., IMC 2018 — the same deployment described above) was broadly consistent with that range, and separately found that web (HTTP/HTTPS) traffic made up roughly 91% of Tor’s exit-side data bytes.
Those are the two best numbers that exist, and both are now years old. There is an open, unresolved ticket in the Tor Project’s own network-health-team issue tracker — “Rederive and publish ‘fraction of network traffic that is onion service related'” — that confirms, from the inside, that nobody has re-derived the figure since. Not “the number changed and we haven’t updated the blog post.” Nobody has re-run the study.
That’s worth sitting with, because it’s not a resourcing footnote — it’s the whole thesis of this article playing out on one specific statistic. Measuring onion-service traffic share rigorously requires exactly the kind of privacy-preserving instrumentation described above: volunteer relays running a differentially-private reporting protocol, at scale, for long enough to get a stable sample. That’s expensive to organize, expensive to trust, and nobody has done it since 2018. So the honest answer to “how much of Tor is illicit?” isn’t a number at all — it’s that the underlying traffic-share question is stale, and even a fresh traffic-share number wouldn’t answer the illicit question on its own. Traffic share, service counts, and content-sampling studies each measure a different axis of “what’s on Tor,” and averaging them into one tidy “X% criminal” figure — a pattern you’ll see in exactly the kind of article this one is trying not to be — manufactures false precision out of numbers that were never designed to combine.
🧭 What This Means for You
None of this is Tor trivia if you’re the one instrumenting a privacy-sensitive system of your own. Three patterns here generalize directly.
Run two tiers of measurement, not one. A cheap, continuously-running, “good enough” noisy-aggregate pipeline — like the decade-old Laplace extrapolation — covers routine dashboards. Reserve a heavier, formally-audited, secret-sharing pipeline like PrivCount for the specific, occasional deep-dive study that actually needs a provable privacy bound. Building the heavy version as your only system wastes engineering effort on every routine query; running only the cheap version means you can never make a rigorous claim when one actually matters.
Never let a participant predict how they’ll be measured. TorFlow’s self-reports, and sbws’s lightly-probed successor, both got gamed because the target of measurement could anticipate and shape the test. FlashFlow’s answer — saturate rather than sample — generalizes to any system that allocates trust, traffic, or resources based on a participant’s own claims about capacity: peer-to-peer networks, federated systems, bandwidth marketplaces. Assume self-reported capacity will eventually be gamed, and price the cost of gaming it into your measurement design up front.
Publish your estimator’s error model instead of pretending you have exact data. Tor’s most disciplined move, methodologically, isn’t any single clever noise mechanism — it’s that Tor Metrics tells you outright it cannot distinguish a stable population from one with heavy churn, rather than quietly presenting the directory-request estimate as a headcount. If your system’s whole value proposition depends on not collecting a signal, don’t collect it anyway for a prettier dashboard. Publish the honest estimator with its error bars attached, the way Tor does — and be as clear as the open network-health ticket is about which numbers you simply don’t have yet.
❓ Frequently Asked Questions
Does Tor Metrics know exactly how many people use Tor? No. It estimates average concurrently-connected users by dividing total directory-request volume by an assumed ~10 requests per client per day. Tor Metrics states explicitly that it can’t tell a stable population from one with high daily turnover — the number is an estimate with a documented, acknowledged error model, not a headcount.
What’s the difference between the Laplace-noise extrapolation and PrivCount? The Laplace-noise method (Kadianakis & Loesing, 2015) is the cheaper, continuously-running system that has powered Tor Metrics’ live onion-service graphs for a decade: each relay noises its own counters before reporting. PrivCount (Jansen & Johnson, CCS 2016) is a heavier, cryptographically-grounded, secret-sharing system used for one-off deep studies — most visibly Mani et al., IMC 2018 — not a permanently running production pipeline. They’re routinely conflated; they aren’t the same system.
How does Tor measure relay bandwidth if a relay could just lie about its own capacity? Bandwidth authorities run active-probing scanners (sbws, successor to TorFlow) that build test circuits and push data through each relay, then vote a consensus bandwidth from the median of at least three scanners. It’s real measurement, not pure self-report — but it’s still measurably imperfect (FlashFlow found roughly 50% underestimation) and gameable by colluding relay clusters (TorMult, MirageFlow).
What percentage of Tor traffic is onion services, or “the dark web”? There is no current rigorous figure. The last methodologically transparent measurements are a February 2015 Tor Project study (3.4% of circuit traffic, 6.1% of relay traffic) and a 2018 PrivCount-based academic follow-up broadly consistent with it. An open Tor network-health ticket confirms no one has re-derived the number since. Treat any confident current percentage you see elsewhere as unsupported.
Why doesn’t Tor just build better analytics like a normal company would? Because precise, per-user analytics is itself a deanonymization side channel on this specific system — the same property that makes Tor useful (no party can reliably link who is talking to whom) makes ordinary observability an active threat rather than a convenience. Tor’s telemetry toolkit exists specifically to extract useful aggregate signal without recreating that side channel.
Is any of this useful if I’m not building an anonymity network? Yes. The two-tier measurement pattern — cheap noisy aggregation for routine dashboards, a heavier audited pipeline for rare studies needing a provable bound — and the lesson about never trusting predictable self-reported capacity both generalize directly to any privacy-sensitive or adversarial telemetry problem, from federated systems to peer-to-peer bandwidth markets.
📚 Further Reading
- Measuring Network Performance and Understanding Internet Bandwidth for Engineers and Architects — what “normal” network measurement looks like when you’re allowed to watch real, unmasked throughput.
- Postgres as a Vector Database: What Benchmarks Say and What “Attention Is All You Need” Actually Measured — more case studies in reading a benchmark or metric honestly, for its configuration and its blind spots, rather than as a bare number.
- Mutation Testing for AI-Generated Code (Beyond Coverage) — the same underlying idea as sbws’s gaming problem: a metric that can be satisfied without actually being true.
- Primary sources: Tor Metrics — reproducible-metrics.html, Tor Project blog — “Some statistics about onions”, Kadianakis & Loesing, Tor Tech Report 2015-01-001, Jansen & Johnson, “Safely Measuring Tor,” CCS 2016, Mani et al., “Understanding Tor Usage with Privacy-Preserving Measurement,” IMC 2018, FlashFlow, arXiv:2004.09583, TorMult, arXiv:2307.08550, and the open gitlab.torproject.org network-health ticket #67.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Designing Data-Intensive Applications
Martin Kleppmann & Chris Riccomini · Book · 2nd edition (2026)
The reference for reasoning about what a distributed system can and cannot know about itself — replication, consistency, and the limits of aggregate observation. The natural companion to an article about instrumenting a network that refuses to be instrumented.
Security Engineering: A Guide to Building Dependable Distributed Systems
Ross Anderson · Book · 3rd edition
Anderson treats measurement, incentives, and adversarial gaming as first-class security problems — exactly the frame you need for the bandwidth-authority trust gap and the relay-weighting attacks described above.
Database Internals: A Deep Dive into How Distributed Data Systems Work
Alex Petrov · Book
For the layer beneath the metrics: how distributed systems actually collect, aggregate, and agree on state. Useful if the consensus and aggregation machinery in this article is the part you want to understand properly.
Free and directly relevant: Tor Metrics (metrics.torproject.org) publishes the graphs — and the methodological caveats — discussed above.