Tor Browser in numbers

Tor Browser is the secure and anonymous way to browse the web and access onion services. Tor Metrics' new visualization of Tor Browser downloads and updates shows that Tor Browser is downloaded 100,000 times from the Tor website every day! These could be new Tor users or existing users who are downloading it again.

The Signature downloads subgraph shows that between 5,000 and 15,000 users per day tried to verify that Tor Browser was signed by our developers after downloading it. Verifying the signature is the surest way to know that that executable is the legitimate version from Tor and not a benign or malicious third-party one. It is important to increase the number of users that verify their downloads in the future through education and assistance, and knowing the numbers is the first step.

The Update pings subgraph shows ~2,000,000 checks for a new Tor Browser version being made every day. Each running instance of Tor Browser makes a minimum of two such requests per day, and another request at the start of each session. As of now, we don't have any data on how long a typical Tor Browser session lasts or how often users restart their browser. But the update number is still useful to observe trends. For instance, look at the sharp drop of update pings at the end of January. We don't yet know what happened there, though it coincides with the Tor Browser 6.5 release, and the pattern looks similar to what happened when the first version of the 6.0 series was released. We use these graphs to recognize such anomalies, investigate them, and track our explanations here.

Lastly, the Update requests subgraph shows spikes every few weeks with peaks between 750,000 and 1,000,000 requests. This happens when a new Tor Browser version is released, which tells us that automated updates are working!

We sourced the data used above from Tor Project web server logs. Don't worry—we don't record what we do not need (your IP addresses or time of day of requests) and remove potentially identifying information (such as request parameters and the user agent string) before processing. We also delete the original logs afterwards and only keep a sanitized version.

Come back to Tor Metrics often! All of our graphs and tables are updated daily, and we are working to add additional ones in the future. We also encourage you to dig through the data we use and tell us if you find something interesting.

We would like to thank the generous community donations for funding our work. Donations to Tor Project not only help fund new work, but lessen our dependencies on institutions for funding. Keep us independent by donating today!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hacker House just published a blog post on using this sort of attack to unmask Tor Browser users

This seems unrelated to Tor Browser metrics based on sanitized web server logs, but still worth considering for the Tor Browser developers. Thanks for sharing the link.

Thanks. Yes, external applications can bypass Tor Browser's defenses. I just had wished the folks had shown the warning dialog we provide as well in their demo (as they said in the text). But they disabled that one, probably to make the demo fancier. Now it looks like we would just easily allow a user to open an external helper application and boom! Anyway, alas there is not much we can do here.

"TorBrowser does warn you that 3rd party files can expose your IP address and should be accessed in tails. This is not an attack against Tor or the TorBrowser directly but a useful way that could be leveraged to identify people attempting to access illegal media content."

It's not a vulnerability, just social engineering.

There is a fine line to distinguish "illegal" among the child molesters and the anti-establishment activists who may never have the luxury to trust the other side (server) of being respectful of their anonymity.
If and when it is possible for the server to collect identity information, even though it discards it, I would think with my limited knowledge of secure things that a MIM may also collect such information and not discard it. To tell who is who among the pool is the strong point of this type of "security".
Who said that? said the teacher addressing the crowd of kids in the high school playground. Counting on the snitch right beside you to tell on you!
I guess if it is all about getting kids safer to walk the streets and play in the park it is still worth it. But there is always the group that nobody knows how they had an accident and ended up dead in the ditch. And big brother has never played fair, or even legally for that matter.


Signature downloads sub-graph for Linux only?

This is one of many interesting questions about this new data. But we cannot add new graphs for each of them, or we'll drive attention away from the main graphs. A future version of Tor Metrics will have more inputs, so that people can customize graphs as they want them. But that new version might not appear before summer or fall this year. If you really care, please download the linked .csv file. And if you find out something cool, please post it here.

Update pings: to dist or aus? What about
Common usage: open several pages, mem size > 1GB for empty browser, restart. So, nearly every day restart.

Update pings are "GET requests to all sites with resource strings '%/torbrowser/update_2/%' and response code 200." See the CSV file format for details, Tor Browser Update Pings are "tbup".

We're not looking at requests for the RecommendedTBBVersions file. I can't say whether that would work better or worse than the requests we're looking at. Maybe a Tor Browser dev would know.

Regarding your memory issue, I'm afraid I also can't comment on that. Hard to say how many users run into that problem, and how that influences restarts.

Update requests sub-graph also shows your infrastructure overload on the release date.

I'm not sure I agree with that statement. Update requests nowadays go to a CDN, and I wouldn't expect that to run out of resources easily.

Tor Browser usually downloads the update after 10th attempt. Do you see downloads complete/incomplete ratio?

We do see partial downloads. But we don't see how many downloads are completed. The absolute number of update requests doesn't mean that this many Tor Browsers are updated, just that this many requests are sent by Tor Browsers. Hope this was not too confusing in the post.

> remove potentially identifying information (such as request parameters and the user agent string)
This info from Tor Browser is not identifying, so you can split (improve) your stats by TBB/other browser data.

This may be true for update pings and update requests, but not for initial downloads and signature downloads. But even if we kept these pieces of information (which we shouldn't), I wouldn't expect to learn much there.

Not those pieces of info, just Tor Browser detected - yes/no.

We're not adding that information, and I don't see why it would be vital to have it.

Tor Browser Team has the decision not to hide the differences between platforms by now. So what about collecting stats for Win/Mac/Lin separately?

Good question. We indeed have that information, and it's already contained in the .csv file. Maybe we should add another graph for downloads by operating system, just like we have one for downloads by locale.

Please don't.

As stated earlier, this information is already public. The graph is now available here:

Wow, interesting, why did the Linux platform downloads spike to nearly 150,000?

See below: "That looks a lot like a bug, not like actual requests. I'll take a look on Monday."

Can you also add that for the case of Tor Messenger?

Sorry, but we should limit graphs to the most interesting views. The data is available in the .csv file linked from existing graphs.

Thanks for all of your work! :D

Because tails will not provide an option to easily discuss it publicly it seems. without jumping through tedious hoops like setting up and XMPP account and will not let people comment on the news article about tails release either it seems, (for what possible reason?!...both of which should be changed in my view & are creating too many obstacles to dialog), I will post about tails here instead...

The print screen feature is no longer working on the latest tails version! What is the issue here? Has anyone else noticed this?

[moderator: OT but please pass: this is an urgent Tor security question]

Since Tails 2.10 I *always* see "unable to fetch Tor consensus" and "unable to synchronize system clock" (my system clock is actually OK) after a few minutes, but after another five minutes or so Tails appears to connect to the Tor network.

Is it safe to ignore the warning messages?

who use Tor ?
abnormal user : your friends , your family.

@ Roger:

Is it safe to use TB (on Tails) after seeing a message "unable to fetch Tor consensus"? Since Tails 2.10 I always see this but sometimes Tor client eventually appears to connect.

Put another way: does Tor client refuse to connect if it cannot fetch a consensus, or does it eventually connect anyway if it can? (This could put users at risk, yes?)

Big peak in Feb-2017 with TBB downloading for Linux.
Correlated with Locale:Other?
What is "Other"?

That looks a lot like a bug, not like actual requests. I'll take a look on Monday.

So, there is a mistake in the graphic respect to Linux downloads, no?

I only looked at it briefly, but I am assuming you're referring to the huge spike in Linux downloads at the beginning of February?

It looks like it is indeed a huge spike.

A download doesn't necessarily equate to a human or a new user.

But it doesn't look like a mistake -- whatever caused it, it looks like it really did happen.

Isn't trying to interpret metrics graphs fun. :)

(I also see a comment from Karsten above saying that he thinks maybe it is a mistake, and that he's looking into it. Hopefully we'll learn more!)

Syndicate content Syndicate content