Introducing PrivCount, a Distributed System for Safely Measuring Tor

Rob G. Jansen     9 minute read

I’m pleased to introduce some new work on developing better techniques and systems for safely measuring the Tor anonymous communication network. This work was done together with my colleague Aaron Johnson, and a related paper entitled Safely Measuring Tor will be published in the proceedings of the 23rd ACM Conference on Computer and Communication Security (CCS 2016) (I’ll be presenting it at the conference later this week). A bibtex citation for our paper is:

  author = {Rob Jansen and Aaron Johnson},
  title = {Safely Measuring Tor},
  booktitle = {Proceedings of the 23rd ACM Conference on Computer and Communications Security (CCS '16)},
  year = {2016},
  publisher = {ACM}

In this post, I will summarize our work and provide some additional perspectives not found in the paper.


We designed a new system for measuring Tor called PrivCount (extending the PrivEx-S2 protocol of Elahi et. al.), implemented and released it as open source software on github, and deployed it across 7 Tor relays, 6 operators, and 4 countries. We then used our deployment to safely collect and publish various differentially private network statistics that may be useful for modeling purposes. To briefly highlight our results, we found that during an average 10 minute period, Tor has 550,000 active of 710,000 total users connecting from unique IP addresses, and that bytes associated with web ports constitute 91% of all bytes exiting Tor (up from about 42% in 2010).

Why should we measure Tor?

Data allows us to create a more secure and usable network. Analyzing real network measurement data is one of the best ways to understand how a network or system functions. This understanding allows researchers and developers to make informed decisions about how to tune existing algorithms, how to develop new algorithms to mitigate performance and security problems, and how to determine if new algorithms are working properly. It may also help to identify when the network is under attack or when certain participants are misbehaving. Without data, much of this becomes difficult and some of it impossible.

Usage data can also help the Tor project and the Tor community focus their effort and resources on important use cases, to make sure that Tor is accessible and usable for everyone. As an example, consider Tor pluggable transports: a modular architecture that is used to provide censorship resistant communication. The pluggable transport ecosystem includes bridge relays that help clients connect to the rest of the network and various protocols that obfuscate traffic between a client and the network. Tor was not initially focused on circumventing censorship, but started to develop and support censorship resistant technologies when it became clear that many users were using Tor to achieve free and open communication in the face of censorship (a goal that aligns with Tor’s mission).

Finally, data helps us fight against bad policies and laws that get could otherwise get enacted due to a lack of information. This is nicely and concisely stated by security expert Bruce Schneier (see here):

“Tor metrics are the ammunition that lets Tor and other security advocates argue for a more private and secure Internet from a position of data, rather than just dogma or perspective.”
– Bruce Schneier (June 1, 2016)

Wait, doesn’t Tor already collect and provide network metrics?

Yes, they absolutely do! The Tor metrics website lists a variety of network and user metrics that Tor collects and provides to the public. These metrics have been extremely useful for helping us understand the state of the network and have provided a glimpse into how the network has been growing and changing over time. The metrics that have been and are currently being collected — including but not limited to relay bandwidth used, relay bandwidth capacity, the number of daily users, the number of users per country, and the amount of exit traffic per port — have gone far to help us continue to improve the network.

However, as I have previously suggested on the Tor-dev mailing list (here and here), some of the statistics that are being published could potentially leak information about individual Tor users (we have no reason to believe that any Tor metrics have resulted in attacks on individual users in practice). In addition to safety concerns, many of the statistics are of unknown accuracy. This is because:

  • some of them are inferred rather than directly measured
  • some of them are opt-in and not reported by many relays
  • some of them are rounded or get noise added by every reporting relay

While privacy techniques like rounding and binning are used for many of the sensitive statistics, most of them lack privacy proofs and therefore we are unable to make strong privacy guarantees. Using recent advances in differential privacy and secure multiparty computation, we can improve the security and privacy of Tor measurements. Not only can we make the existing measurements safer, but this also may allow us to collect measurements that have not been collected before while also achieving a desirable level of accuracy.

The PrivCount Measurement System

We developed a distributed Tor measurement system called PrivCount which extends and enhances the PrivEx-S2 protocol. Like PrivEx, PrivCount is designed to count a series of events over time and compute various statistics from those events. For example, PrivCount can count statistics such as the amount of data that is transferred over the measuring relays or the number of users that are connecting to the measuring relays. PrivCount incorporates elements of secure multi-party computation and differential privacy to secure the measurement process and guarantee privacy of the final aggregated output.

Briefly, each PrivCount data collector runs on an existing Tor relay. PrivCount works by adding noise to a counter before starting the counting process, and also “blinding” each counter by adding in uniformly random numbers. These “blinding values” are then sent to other PrivCount share keeper nodes that simply hold on to them until the end of the measurement phase. Because the data collector counters are “blinded”, an adversary that compromises the machine will not learn anything about the value of the counters before the time of compromise. The data collectors then collect different types of events from the Tor relays over time and increment the associated counters. Once the measurement phase is complete, the data collectors send the blinded and noisy counter values to a PrivCount tally server, and the share keepers send the “blinding values” to the tally server so that the tally server can subtract those “blinding values” from the counter. As long as one single share keeper is honest and waits until the end of the measurement phase to send the blinding values to the tally server, no one can learn anything except for the final count. This final count is differentially private because it contains the noise added by each data collector.

For many more details about the PrivCount protocol and for proofs of security and privacy, please see the paper. For our python implementation of PrivCount, please our git repository on github.

Deploying PrivCount and Collecting Measurements

In order to use PrivCount for measurement, we ran 7 relays (3 guards and 4 exits) in the Tor network. We setup a PrivCount deployment with 7 data collectors, 6 share keepers, and 1 tally server; these nodes were run by 6 operators in 4 different countries. We used our deployment to count various statistics in Tor.

The effects of exit policies on traffic

We focused some of our measurements on understanding the effects of relay exit policies on traffic, including the number of circuits, streams, and bytes observed at our relays.

We investigated exit policies:

  • Default is the default exit policy applied by the Tor software if one is not explicitly specified by the relay operator;
  • Open is a policy that allows all ports; and
  • Strict is a stricter-than-default policy that also blocks port 80 and 443.

Note that the main difference between “Default” and “Open” is that “Default” blocks a range of ports that are known to be used for file sharing while “Open” does not. We also considered different categories of traffic:

  • Web consists of traffic from port 80 and 443;
  • Interactive includes SSH port 22 and those used for IRC; and
  • Other are the remaining ports.

Notice that when moving from Default to Open (meaning file sharing ports are allowed), the number of Other circuits and streams increase as more file sharing traffic is observed on our nodes — but interestingly, the number of Web circuits and web streams do not change by much. However, Other bytes take up a much larger proportion of the traffic than Web bytes, indicating that file sharing traffic may be drowning out browser traffic. We also found that Interactive traffic is a very small part of the overall traffic observed at our relays.

We extrapolated our measurements to infer total network-wide statistics by combining the measurements we took with each of 6 total exit policies that we measured with the popularity of those exit policies among all exit relays in Tor. We compare our network estimates from measurements taken this year (2016) to those take in 2008 by McCoy et. al. (viz. “Shining Light in Dark Places: Understanding the Tor Network”) and to those taken in 2010 by Chaabane et. al. (viz. “Digging into anonymous traffic: A deep analysis of the Tor anonymizing network”).

We observed an increase in the percentage of “Web” connections corresponding to ports 80 and 443 since 2010, and a large increase in the amount of “Web” traffic since both 2008 and 2010. This could be due to a combination of factors, e.g., perhaps more file sharing traffic uses port 80 and/or 443 than in the past or perhaps fewer users are using Tor for file sharing (instead opting for popular services like Netflix and Spotify). Splitting ports 80 and 443 into their own traffic classes could be useful in future PrivCount collections.

Number of Tor users

Finally, we measured the average number of unique users connecting to our relays over 10 minute periods, and the number of those users that were active (built and actively used circuits) and inactive (built circuits but never used them). We again used our measurements to infer the total number of active users across the entire Tor network during an average 10 minutes.

Based on our observations, we estimate that Tor has about 710,000 unique users connecting to the network in an average 10 minutes, and of those about 550,000 (77%) are active while 160,000 (23%) are inactive.

We compare our results to Tor’s user estimates. Although Tor does not directly measure the number of users, there are a couple of ways they estimate it. Based on Tor Browser update ping data (update pings happen twice per day), we can very roughly estimate between 800,000 and 1.6 million concurrent Tor users during the same period that we did our PrivCount measurements. This is in line with our initial user measurements, and we hope to improve our estimate in the future. Also, based on downloads of Tor consensus documents, Tor estimates about 1.75 million daily users. These estimates of concurrent and daily users suggest that Tor users turn over about 2.5 times per day.

Please refer to our paper for additional Tor statistics that were not described in this post.

Where do we go from here

We are currently working on improving our measurement tool and adding support for more types of statistics including various onion service statistics that will help Tor improve onion service performance and scalability. We are also working on developing techniques that will allow us to safely count the number of users over arbitrary time periods rather than just over 10 minutes.

We hope that The Tor Project finds our tool useful. We envision a PrivCount deployment that can be operated by Tor and that we can use to improve the privacy and security of the Tor measurement process.


Leave a Comment