Understanding Tor Usagewith Privacy-Preserving Measurement

Akshaya Mani•∗ T Wilson-Brown‡∗ Rob Jansenᵀ Aaron Johnsonᵀ Micah Sherr••Georgetown University

{am3227,micah.sherr}@georgetown.edu

‡UNSW Canberra Cyber, University of New South Walest.wilson-brown@unsw.edu.au

ᵀU.S. Naval Research Laboratory{rob.g.jansen, aaron.m.johnson}@nrl.navy.mil

ABSTRACTThe Tor anonymity network is difficult to measure because,if not done carefully, measurements could risk the privacy(and potentially the safety) of the network’s users. Recentwork has proposed the use of differential privacy and secureaggregation techniques to safely measure Tor, and prelimi-nary proof-of-concept prototype tools have been developedin order to demonstrate the utility of these techniques. In thiswork, we significantly enhance two such tools—PrivCountand Private Set-Union Cardinality—in order to support thesafe exploration of new types of Tor usage behavior that havenever before been measured. Using the enhanced tools, weconduct a detailed measurement study of Tor covering threemajor aspects of Tor usage: how many users connect to Torand from where do they connect, with which destinations dousers most frequently communicate, and how many onionservices exist and how are they used. Our findings includethat Tor has ∼8 million daily users (a factor of four morethan previously believed) while Tor user IPs turn over al-most twice in a 4 day period. We also find that ∼40% of thesites accessed over Tor have a torproject.org domain name,∼10% of the sites have an amazon.com domain name, and∼80% of the sites have a domain name that is included inthe Alexa top 1 million sites list. Finally, we find that ∼90%of lookups for onion addresses are invalid, and more than90% of attempted connections to onion services fail.

1. INTRODUCTIONThe Tor network has been in operation since 2003 [18],

enabling millions of daily users [43] to anonymously ac-cess the Internet. Despite its relative longevity, grow-ing popularity, and prominence as a privacy-enhancingcommunication tool, surprisingly little is known aboutwho uses Tor and how they use it.

Challenges in Measuring Tor. The primary chal-lenge in conducting measurements on the Tor networkis that, if not done with extreme care, they can im-pose significant risk to the network’s users. The col-lection of statistical information implies the need to∗Equally credited authors.

store data about clients, traffic patterns, sites visited,etc.—information that may otherwise not be collectedfor privacy reasons. Even if the entities collecting thisinformation are honest, the exposure of the data (e.g.,through machine compromise or compulsion from gov-ernment authorities) could pose serious privacy risks.Additionally, the dissemination of even highly aggre-gated measurement information risks users’ privacy sinceadversaries could potentially combine this data withbackground knowledge (e.g., when a tweet was posted,ISP logs showing user accesses to the Tor network, etc.)to deanonymize users [16].

In addition to user privacy and safety, monitoringcommunication is antithetical to the mission of the Tornetwork. For this reason, the Tor Metrics Portal [43],a data repository that archives information about theanonymity network’s size, makeup, and capacity, pro-vides only a limited number of statistics, many of whichare based on indirect measurements and assumptions ofTor client behavior. We demonstrate in this paper thatsome of Tor’s estimates do not correlate well with ourown direct observations of user behavior.

Other efforts to measure Tor, such as those that recordpackets at Tor’s ingress and egress points, can pose se-rious ethical and legal issues: they rely on unsafe [41](and potentially unlawful [40]) techniques that wouldbe difficult to repeat. As a result, such studies havebeen met with criticism by the privacy community [40].

Toward safe Tor measurement. There has been anexciting recent trend in the literature that proposes dif-ferentially private [21] statistics collection techniquesfor anonymity networks such as Tor. Systems such asPrivEx [23], PrivCount [27], HisTorε [36], and PSC [24]enable useful statistics collection while providing for-mal guarantees about the privacy risks they imposeon the network’s users. However, to date, researchershave (rightfully) focused on developing these privacy-preserving measurement techniques rather than on per-forming exhaustive measurements of deployed anonymitynetworks such as Tor.

1

arX

iv:1

809.

0848

1v1

[cs

.CR

] 2

2 Se

p 20

18

Our Contributions. This paper presents the largestand most comprehensive measurement study of the Tornetwork to date, performed using newly proposed differ-entially private statistics collection techniques. To con-duct our study, we modify Tor and significantly enhanceand improve PrivCount [27] and PSC [24] (described inmore detail in the following section) to support a largervariety of measurements, and contribute our improve-ments to the respective open source projects. We run 16Tor relays that contribute approximately 3.5% of Tor’sbandwidth capacity, and deploy our measurement sys-tems across these relays in order to safely collect mea-surements of the live Tor network. We extend previ-ous statistical methodology to enable unique-countingon Tor, and extend privacy definitions (action bounds)to cover new types of user activity. We also describethe challenges and tactics for selecting appropriate pri-vacy parameters to ensure Tor users’ safety, as well asmethods for inferring whole-network statistics given lo-cal observations at our relays.

Using our improved measurement tools and extendedtechniques, we conduct a detailed measurement studyof Tor covering three major aspects of Tor usage: whoconnects to Tor and from where do they connect; howis Tor used and with what services and destinations doTor users communicate; and how many onion servicesexist and how are they used. Findings from our client-based measurements suggest that Tor has ∼8 milliondaily users, which is a factor of four more than previ-ously believed. We are the first to measure client churnin Tor, and we find that Tor user IPs turn over almosttwice in a 4 day period. We also find that ∼40% of thesites accessed over Tor have a torproject.org domainname, ∼10% of the sites have an amazon.com domainname, and ∼80% of the sites have a domain name thatis included in the Alexa top 1 million sites list. Fi-nally, we find that ∼90% of onion address lookups failbecause the address is missing or the request is mal-formed, and more than 90% of attempted connectionsto onion services fail because the server never completesits side of the connection protocol. Our findings both re-inforce existing beliefs about the Tor network (e.g., thatthe vast majority of its use is for web browsing) andelucidate many aspects of the Tor network that havepreviously not been explored. In some instances, ourmeasurements—which are based on direct observationsof behavior on Tor—suggest that existing heuristically-driven estimates of Tor’s usage (including the numberof Tor users) are highly inaccurate.

Limiting the risk to Tor’s users was paramount inboth the design and implementation of all of our mea-surements, and a significant contribution of this workis the methodology for choosing system parameters toguarantee adequate levels of protection. We discuss theprecautions we took to ensure user safety, argue for the

ethical validity of our study, and describe our experi-ences with institutional ethics boards and an indepen-dent safety review board.

2. BACKGROUNDWe begin by presenting a brief overview of Tor and

reviewing the privacy definitions and privacy-preservingmeasurement tools we use in our study.

2.1 TorTor provides anonymous TCP connections through

source-routed paths that originate at the Tor client (i.e.,the user) and traverse through (usually) three relays.Traffic enters the Tor network through guard relays.Middle relays carry traffic from guard relays to exitrelays, where the traffic exits the anonymity network.These anonymous paths through Tor relays are calledcircuits. The unit of transport in Tor circuits is the cell:Tor cells carry encrypted routing information and 498bytes of data [17]. The encryption of application-levelheaders and payloads makes it difficult for an adversaryto perform traffic analysis on circuits and learn the end-points or content of communication.

Tor has a three-tiered communication architecture.A single circuit may carry multiple streams. A Torstream is a logical connection between the client anda single destination (e.g., a webserver), and is roughlyanalogous to a standard TCP connection. A request toretrieve a webpage may produce several streams (e.g.,to example.com and ads.example.com) that are mul-tiplexed over a single circuit. Finally, Tor maintainslongstanding TLS-encrypted connections between re-lays that are adjacent on some Tor circuit. Communica-tion belonging to different circuits that share a commonhop between two relays are multiplexed through a sin-gle connection. Similarly, a user’s Tor client maintainsa single connection to each of its guards, through whichmultiple circuits (and streams) may be formed.

Tor clients periodically download “directory updates”that describe the consensus view of the network. Clientssend all user data through one guard by default, butdirectory updates are obtained through three guardsby default. Tor clients avoiding censorship may connectto the network through bridges [37], which are guardswhose identities are not public and are disseminated byTor to users requesting them.

Onion services. Tor allows services to hide their loca-tions through the use of onion services [42]. As a special(but common) case, when the onion service correspondsto a hidden website, we refer to it as an onionsite.

To operate an onion service, the operator selects sixrelays to serve as introduction points. It then (1) con-structs an onion service descriptor that contains itspublic key and the identities of the chosen introduc-tion points, and (2) forms Tor circuits to each of the

2

introduction points. The descriptor is then stored onsix or eight relays [9] (depending on Tor version) us-ing a distributed hash table (DHT) [32]. These relaysare called onion service directories (for historical rea-sons, they are also called “hidden service directories”or “HSDirs”). The DHT is indexed by the descriptorID, which is derived from the public key. The addressof the service is a domain with an .onion suffix, whichis derived from the public key.

When a user wishes to access the onion service, itqueries the DHT to obtain the service’s onion descrip-tor, which includes the identities of its introductionpoints. It also chooses a relay to serve as a rendezvouspoint (RP), and constructs a circuit to this RP. Usingthe public key in the onion descriptor, the user encryptsits choice of the RP and sends it via a Tor circuit to oneof the onion service’s introduction points. This choice isthen forwarded to the onion service, using the existingcircuit between the introduction point and the service.Finally, the onion service constructs a circuit to the RP,through which it can communicate with the user.

Importantly, Tor conceals the network locations ofboth the user and the onion service. The communica-tions between the user and the introduction point, theuser and the RP, the onion service and the introductionpoint, and the onion service and the RP are all carriedover Tor circuits.

2.2 Differential PrivacyDifferential privacy [21] is a privacy definition that

provides strong guarantees about how much is revealedby answering database queries. Differential privacy isdefined in terms of pairs of adjacent databases and guar-antees that query responses cannot be used to distin-guish such pairs. Typically, databases that differ onlyin a single user’s data are considerd adjacent, and thenthe definition ensures that query responses don’t revealmuch about any user.

Differential privacy has previously been proposed as ameans to safely study the Tor network [23,24,27,36]. Inexisting work, as in this study, adjacency is defined bynetwork activity rather than by user. For example, inits study of visits to censored sites, PrivEx defines ad-jacency as differing by at most six exit connections perhour [23]. Under this definition of adjacency, differentialprivacy’s guarantees apply to connections rather than-users. We also adopt this model and consider privacyprotections over particular user activities (for example,visiting onion sites) conducted over a fixed length oftime rather than on a per-user basis. The latter is dif-ficult to achieve, since conceptually, a single user (e.g.,a botnet) could constitute a significant fraction of theactivity on the network.

Differential privacy is typically achieved by addingnoise to query results. This noise is added in a con-

trolled manner such that the result of the query is nearlythe same for adjacent databases. More formally, a (δ, ε)-differentially private mechanism [20] is an algorithmMsuch that for all adjacent databases D1 and D2 and allS ⊆ Range(M),

Pr[M(D1) ∈ S] ≤ exp(ε)× Pr[M(D2) ∈ S] + δ

where δ and ε are parameters that can be used to tradeoff between privacy and accuracy.

2.3 PrivCountPrivCount [27] is a distributed measurement system

that provides (ε, δ)-differentially private statistics aboutthe Tor network.

A PrivCount deployment consists of three compo-nents: a tally server (TS), at least one data collector(DC), and at least one share keeper (SK). In an ex-ecution of PrivCount, the TS, DCs, and SKs act col-lectively to report (noisy) counts of the events thatwere observed during a collection period. PrivCountsupports both single number queries (e.g., “how manyclients connected during the collection period?”) andmultiple-counter queries (e.g., “how many Tor connec-tions went to {Google, Amazon, Facebook} during thecollection period?”) in which the “bins” (i.e., counters)are independent. PrivCount is shown to provide (ε, δ)-differential privacy if (1) at least one SK is honest.

2.4 Private Set-union Cardinality (PSC)PrivCount provides a safe method of counting ob-

served events across a set of Tor relays. A limitation ofPrivCount (and one shared by other privacy-preservingmeasurement systems [23, 36]) is that it cannot deter-mine the count of distinct values among the DCs. Forexample, while PrivCount can answer queries such as“how many client connections were observed?”, it can-not answer “how many unique clients connected to Tor?”

To answer questions about the count of distinct val-ues, we use the private set-union cardinality (PSC) pro-tocol introduced by Fenske et al. [24]. In PSC, each DCk maintains a set of items Ik. PSC computes the cardi-nality of the union of those itemsets; i.e., |⋃k Ik|+noise.PSC achieves (ε, δ)-differential privacy, and does not ex-pose any element of any itemset to an adversary.

The participants in PSC include one or more DCsand one or more computation parties (CPs), the latterof which perform a series of noise additions, verifiableshuffles, re-randomizations, and aggregation to computethe final cardinality (plus noise) of the union.

3. METHODOLOGYConducting safe measurements on Tor requires care-

ful experimentation design, configuration, and deploy-ment. In what follows, we describe the methodology we

3

employ to collect and analyze measurements of the Tornetwork.

3.1 DeploymentWe use several Tor relays and both PrivCount and

PSC to conduct Tor measurements. We first enhancedthe PrivCount version of Tor1 so that the PrivCountevents that Tor emits include additional informationabout connections, circuits, and streams as necessaryto answer our research questions. We also add newevents that report onion service directory usage infor-mation [9,10]. We ran 16 Tor relays with our enhancedversion of Tor (6 exit relays and 11 non-exit relays).

We then enhance PrivCount to support the new in-formation it receives from Tor, and to support severalnew counter types as necessary for our study. Mostsignificantly, we add support for counting set member-ship using PrivCount histograms which we use to mea-sure domain distribution (§4), geopolitical distributionin (§5), and onion site distribution in (§6). We also sig-nificantly extend PSC: we slightly modify the originalPSC design to include a TS to coordinate the actions ofthe DCs and CPs, we engineer PSC to collect the Priv-Count events emitted by our relays, and we add sup-port for measuring the number of unique domains (§4),clients (§5), and onion sites (§6). All of our enhance-ments have been merged into the PrivCount and PSCopen-source projects.

We set up a PrivCount deployment containing 1 TS,3 SKs, and 16 DCs (one for each Tor relay), and we setup a PSC deployment containing 1 TS, 3 CPs, and 16DCs. We use PrivCount and PSC to repeatedly mea-sure Tor in 24 hour periods, where each period focuseson measuring a small set of statistics. During somemeasurement periods, we use only the subset of the DCsand relays that are in a position to observe the eventsof interest in order to reduce operator overhead andreduce the likelihood of failure. Apart from the caseswhere server(s) was temporarily unavailable, the num-ber of CPs/ SKs we use is greater than or equal to thenumber of relay operators in all our measurements. Tomaintain our privacy guarantees, PrivCount and PSCmeasurements are never conducted in parallel, and wealways enforce at least 24 hours of delay between anysequential measurement of distinct statistics.

3.2 PrivacyWe protect the privacy of individual Tor users using

the methodology developed with PrivCount [27]. Thisapproach applies differential privacy to protect a certainamount of network activity within a certain length oftime. Limiting the application of differential privacy tobounded amounts of activity is required for producingaccurate results, as otherwise we must protect a hypo-

1https://github.com/privcount/tor

thetical individual whose activity constitutes the ma-jority of network activity, which would necessarily yieldinaccurate results. Fortunately, reasonable Tor activityby an individual should for most actions constitute asmall fraction of the total network activity, and so wecan provide privacy while providing accurate networkmeasurements.

Our publishing mechanisms formally apply (ε, δ) dif-ferential privacy to the space of inputs that includesall possible network traces in a given time period. In-puts are considered “adjacent” if they differ only in theactivity of a single user within a given length of time,and all differences in that activity stay within a set ofaction bounds. We use 24 hours as the length of timedefining adjacency, and our action bounds are shown inTable 1. One way to understand the privacy guaranteethat results is that, for any two reasonable sequences ofnetwork actions that a user could perform in a 24-hourperiod, including nothing at all, they most likely can-not be distinguished based on the statistics publishedby our mechanisms.

We derive the action bounds by considering reason-able activities that a Tor user might perform over 24hours. In this analysis, we consider protecting the pri-vacy of both Tor clients and onion services. We take intoaccount how certain type of user actions would trans-late into observable actions on the Tor network, such ascreating new circuits or sending data cells, based on ourunderstanding of the Tor protocol and software, takinginto account features such as caching and how streamsare assigned to circuits. We consider several types ofcommon Tor activities in this analysis: web browsingwith Tor Browser, chat with the Ricochet P2P onionservice [6], and running a Web server as an onionsite.We compute the amount of network actions that re-sult from reasonable amounts of these activities and usethe maximum to define the action bound. The activitythat provides the maximum value defining each boundis shown in the final column of Table 1.

For example, we choose to protect connecting to 20domains through an exit circuit, which would protectbrowsing two new websites for each of 10 hours perday, as the other activities (i.e., chat and onionsites)would not create domain connections. This analysisalso allows for additional page loads within the samesite, as they would be assigned to the same circuit andthus would not be measured as a new domain connec-tion. Note that certain observable actions apply to allTor activities, such as creating a TCP connection to aguard, and thus have no defining activity.

We use privacy parameters ε = 0.3 and δ = 10−11.The value of ε is the same one used by Tor to protectits onion-service statistics [30]. We choose δ such thatif there are n Tor users, then δ/n is still small, whichensures that each user is simultaneously protected [22].

4

Table 1: Action bounds for measurements.

ActionDailybound

Definingactivity

Connect to domain 20 domains WebSend or receiveexit data

400 MB Web

Connect to Torfrom new IP address

1 day: 4 IPs2+ days: 3 IPs

N/A

Create TCPconnection to Tor

12 connections N/A

Create circuitthrough entry guard

651 circuits Chat

Send or receiveentry data

407 MB Web

Upload descriptor 450 uploads OnionsiteUpload descriptor ofnew onion address

3 addresses Onionsite

Fetch descriptor 30 fetches OnionsiteCreate rendezvousconnection

180 connections Chat

Send or receiverendezvous data

400 MBWeb oronionsite

For example, with n = 10−6 then δ/n = 10−5.

3.3 Statistical AnalysisOur measurement techniques do not give us a com-

plete and exact view of the total amount of activityin the Tor network. Because we make measurementsfrom a small subset relays, we only observe a sam-ple of Tor’s overall activity. In addition, our privacy-preserving techniques intentionally include some ran-dom errors in the measurement. We use statistical tech-niques to overcome these limitations.

The count measurements (i.e., those made using Priv-Count) include noise generated according to a normaldistribution with mean zero and known variance. Thusfor those measurements we compute confidence inter-vals (CIs) that include the true value with 95% prob-ability. Moreover, for many values we wish to infer anetwork-wide total from our sample. We do so by divid-ing the reported values (and their CIs) by the fraction ofthe observations that our measuring relays make. Forexample, we measure 32 million streams using relaysthat comprise 1.5% of the exit weight and includingadded noise with a standard deviation of 3.1 million.We infer (3.2e7± 6.2e6)/0.015 = 2.1e9± 4.1e8 streamsin the entire network, where the range provides a 95%confidence interval.

The unique-count measurements (i.e., those made us-ing PSC) include noise generated according to a bino-mial distribution with known parameters. In addition,hash-table collisions (which can occur within PSC’s in-ternal data storage [24]) can cause the measured valueto be smaller than the true value. We adjust for theseerrors by computing 95% confidence intervals using anexact algorithm based on dynamic programming.

Extrapolating unique counts from our sample to the

entire network can be a challenge. Unlike with standardcounts, we need to know if the same items in our sampleare seen elsewhere or not. For example, when countingunique domains it could be that the domains we countare each visited very frequently and thus are observedby all relays, which would indicate that our samplecount is the same as the network-wide count. In severalcases, we can handle this using other information wehave about the frequency distribution of the observeditems. For example, there is evidence that domains arevisited following a power-law distribution [13, 33]. Wealso make some additional measurements to help deter-mine likely parameters for these distributions. We canthen construct confidence intervals for the network-wideunique counts by considering the probability of our lo-cal counts given different possible values for the overallcount. We use Monte-Carlo simulations to determinethese probabilities for more complicated distributions.Note that in some cases we cannot identify a likely fre-quency distribution. In these cases, with an observedvalue of x and a fraction p of all observations, we sim-ply present the range of likely network-wide values tobe [x, x/p], where the lower end of the range covers thepossibility that each item is frequently and the upperend covers the possibility of infrequent observations peritem.

4. EXIT MEASUREMENTSIn this section, we present results and analyses of exit

measurements taken from relays in a position to observeTor’s egress traffic.

4.1 OverviewRecall from §2.1 that Tor clients build circuits through

a sequence of Tor relays over which they multiplex mul-tiple streams. Each stream is associated with a TCPconnection between an exit relay and a user-specifieddestination and is used to transfer data between thatTCP connection and the client. For each stream, theclient specifies a destination hostname or IP addresswhich the exit relay requires in order to create a TCPconnection on the client’s behalf.

To better understand which web domains Tor usersfrequently visit, we instrument PrivCount and PSC tocount the initial streams that are created on circuits(i.e., the first stream for each circuit) given that a host-name was provided in the stream by the client andthe destination port requested by the client is a webport (either 80 or 443). We focus on initial streamsbecause the Tor Browser uses a new circuit for eachunique domain shown in the browser address bar. Theinitial stream on a circuit will therefore most directlyindicate the user’s intended destination, whereas sub-sequent streams that are created when loading a pageto fetch embedded resources (e.g., images, scripts, etc.)

5

0 10.0

0.5

1.0

1.5

2.0

2.5

Num

ber

ofS

trea

ms

(24

hrs)

×109

Total Subsequent

Initial

(a)0 1

0.00

0.25

0.50

0.75

1.00

1.25

1.50

Num

ber

ofS

trea

ms

(24

hrs)

×108

Initial Hostname

IPv6

IPv4

(b)0 1

0.00

0.25

0.50

0.75

1.00

1.25

1.50

Num

ber

ofS

trea

ms

(24

hrs)

×108

Hostname Web

Other

(c)

Figure 1: The number of streams of various types over 24 hoursin Tor inferred from our exit relay observations, including 95%confidence intervals. In each sub-figure, the left bar shows thecategory total and the right stacked bar shows the breakdown ofthat category into more specific subcategories.

provide less useful indications of user intent. Second,we focus on streams that provide hostnames rather thanIPv4 or IPv6 addresses because hostnames can be mappedto web domains much more easily than IP addresses. Fi-nally, we are interested in web domains and so we do notmeasure domains on streams that request connection todestination ports not traditionally associated with webcontent.

4.2 Exit Stream AnalysisWe first measure and analyze the breakdown of

streams that provide a hostname and web port, com-pared to other types of streams. These measurementsprovide useful Tor usage information and also providecontext about the overall fraction of Tor exit traffic thatour domain measurements will cover.

Our PrivCount stream measurements were conductedbetween 2018-01-04 and 2018-01-05 during which themean combined exit weight of our measurement relays(taken over the consensuses that were active duringthe measurement) was 1.5% of the total available exitweight in Tor. We infer the number of streams of var-ious types over a 24 hour period in the entire Tor net-work using the observations from our relays and ourfractional weight. The inferred values are shown in Fig-ure 1 with 95% confidence intervals. Figure 1a showsthat there are about 2 billion exit streams created inTor in 24 hours, and only about 5% of those streamsrepresent a circuit’s first stream. Figure 1b shows thatan insignificant number of these initial streams includean IPv4 or IPv6 address: our measured values for thesestream subcategories were negative (due to the addednoise) and therefore the most likely value of the countersis zero. Figure 1c similarly shows that an insignificantnumber of initial streams containing a hostname targeta non-web port (i.e., a port other than 80 or 443). Ourresults confirm that almost all initial streams providehostnames and target a web port; the domain measure-ments that we describe next will focus on the hostnames

provided in these streams.

4.3 Exit DomainsWe now describe the results from our measurements

of the number of domains observed in initial streamsthat also provide a hostname and a web port. To easepresentation, we refer to the measured values as primarydomains or domains in the remainder of this section.Across our measurements, we construct sets of domainnames and increment a counter for a set whenever weobserve a primary domain that matches a domain namein that set.

Alexa Top Sites. We use the Alexa top 1 millions siteslist [2] to help us understand which sites are visited byTor users. We conducted two related PrivCount mea-surements. In the Alexa rank measurement, we sortedthe sites by rank and split them into six sets of increas-ing size: set i = 0 contains the first 101 sites and seti > 0 contains the first 10i+1 sites excluding those inset i−1. We used a separate set for torproject.org sinceearly measurements revealed a significant number of ac-cesses to that domain. The Alexa rank measurementwas conducted between 2018-01-31 and 2018-02-01, dur-ing which our combined mean exit weight was 2.2%.

In the Alexa siblings measurement, we created a setfor each of the top 10 sites in the Alexa list. For eachsuch site we stripped the top level domain to producea site basename (e.g., google), and then added all en-tries from the top 1 million sites list that contained thebasename into the corresponding set. We also used dis-tinct sets for duckduckgo (rank 342, the default searchengine in Tor Browser) and torproject (rank 10,244, de-veloper of Tor Browser). As a result of this process, thegoogle set (rank 1) was the largest (212 sites, includ-ing the rank 7 site google.co.in), while the reddit (rank8) and qq (rank 9) sets were the smallest among top 10sites containing 3 sites each (duckduckgo and torprojectcontained 1 site each). The Alexa siblings measurementwas conducted between 2018-02-01 and 2018-02-02, dur-ing which our combined mean exit weight was 2.1%.

The results from the Alexa rank and Alexa siblingsmeasurements are shown in Figure 2. We highlightthree observations from these results. First, we ob-served torproject.org in 40.1% (CI: [39.9; 40.3]%) and39.0% (CI: [38.8; 39.2]%) of primary domains. Sur-prised by this result, we conducted additional measure-ments and observed the domain onionoo.torproject.orgin 43.4% (CI: [43.1; 43.7]%) of primary domains. Onionoois a web service that provides other applications withaccess to Tor network status information. We contactedthe Onionoo maintainers from The Tor Project, but wewere unable to identify a clear reason for the high num-ber of accesses to Onionoo from Tor.

Second, we observed sites in the amazon siblings setfor 9.7% (CI: [9.5; 9.9]%) of primary domains, and sites

6

(0,10]

(10,100]

(100,1k]

(1k,10k]

(10k,100k]

(100k,1m]other

0

25

50

Ale

xaR

ank

8.4

5.1 6.

24.

3

7.77.

0

21.7

40.1

47.8

Sites in Rank Set

torproject.org

google(1)

youtube (2)

facebook (3)

baidu (4)

wikipedia(5)

yahoo (6)

reddit (8)qq (9)

amazon (10)

duckduckgo

torprojectother

0

25

50

Ale

xaS

iblin

gs

2.4

0.1

0.3

0.0

0.0

0.2

0.0

0.1

9.7

0.4

48.1

39.0

Pri

mar

yD

omai

nC

oun

t(%

)

Sites in Siblings Set

torproject.org

Figure 2: Results of PrivCount measurements of the frequencyof membership of primary domains in subsets of the Alexa top 1million sites list. The top plot shows subsets containing domainsthat are sorted by Alexa rank, and the bottom plot shows subsetscontaining domains of each of the top 10 sites as well as theirsiblings.

in the google siblings set for 2.4% (CI: [2.2; 2.6]%) pri-mary domains. To further explain the unexpectedlyhigh amazon result, we conducted an additional mea-surement during which we observed www.amazon.comin 8.6% (CI: [8.3; 8.9]%) of primary domains. We con-tacted Amazon employees but again were unable to findthe reason for the relatively high number of accessesfrom Tor (here, due to lack of response).

Third, we observed that domains in the Alexa topsites list accounted for about 80% of all primary do-mains accessed from Tor, and that the smaller but morehighly ranked domain sets have roughly equal frequencyas the increasingly larger but more lowly ranked sets.We conclude from these results that the Alexa top siteslist provides a reasonable representation of destinationsvisited by Tor users. The Alexa top sites list is oftenused as a destination model in Tor research, and mostsignificantly in Tor website fingerprinting research [28].Our results provide confirmation that using the top siteslist as part of Tor research is appropriate.

Alexa Categories. We conducted a PrivCount mea-surement of primary domains by category (e.g., news,science, sports, etc.) using Alexa category lists [3] whichare limited to 50 sites per category. The measurementwas conducted between 2018-01-29 and 2018-01-30, dur-ing which our mean combined exit weight was 2.1%.Additional insights from the measurement beyond thosealready presented are limited: the category containingamazon.com accounted for 7.6% (CI: [7.4; 7.8]%) of pri-mary domains while 90.6% (CI: [90.3; 90.9]%) category(torproject.org was not in any of the categories).

Top-Level Domains. We measured the frequency with

.com .org .net .br .cn .de .fr .in .ir .it .jp .pl .ru .ukother

Top Level Domains (*.tld)

0

101

Pri

mar

yD

omai

nC

oun

t(%

)

37.2 44

.1

5.0

0.3

0.0 0.

70.

40.

20.

20.

1 0.5

0.3

2.8

0.5

7.9

26.6

1.1

1.1

0.5

0.2 0.

40.

40.

00.

0 0.0 0.

40.

2

2.4

0.1

26.1

40

.4

41.5

Lin

ear

Sca

leL

ogS

caleAll Sites

Alexa Top 1 Million Sites

torproject.org

Figure 3: Results of PrivCount measurements of the frequencyof membership of primary domains in top-level domain subsetsconstructed from all sites and from those sites present in theAlexa top 1 million sites list.

which all top-level domain (TLD) names that are con-tained in more than 104 entries in the Alexa top 1 mil-lion sites list also appeared in the observed primary do-mains. The measured TLDs include three main TLDs(.com, .org, and .net) as well as 11 country-specificTLDs. We conducted two related PrivCount TLD mea-surements, one in which we count the TLDs of all pri-mary domains using wildcards (conducted between 2018-02-02 and 2018-02-03 with 2.4% exit weight), and onein which we count the TLDs of only those primary do-mains that appear in the Alexa list (conducted between2018-01-30 and 2018-01-31 with 2.3% exit weight). Wemeasured torproject.org using a separate counter dur-ing the Alexa measurement, but our implementationof wildcard matching restricted us from doing so whenmeasuring all sites.

The TLD measurement results are shown in Figure 3.Unsurprisingly, the three main TLDs make up the ma-jority of the primary domains accessed by Tor users,though we note that .org would account for a signifi-cantly smaller fraction of domains without torproject.org.We found that the Russian TLD .ru accounted for 2.8%(CI: [2.6; 3.0]%) and 2.4% (CI: [2.2; 2.6]%) of country-specific TLDs, the largest observed by our relays. Wealso found that ∼11% of .com, ∼3% of .org, and ∼4%of .net sites accessed in primary domains are not inthe Alexa top sites list. Only 7.9% (CI: [7.7; 8.1]%) ofTLDs from all primary domains did not match one ofthe TLDs that we measured, which increased to 26.1%(CI: [25.9; 26.3]%) of TLDs for primary domains in theAlexa top 1 million sites list.

Second-Level Domains. We conducted two mea-surements of the number of unique second-level domain(SLD) names that we observed in Tor primary domains.

7

Table 2: Locally observed unique second level domain statisticsmeasured using PSC.

Statistic Count 95% CI

SLDs 471,228 [470,357; 472,099]Alexa SLDs 35,660 [34,789; 37,393]

During both these measurements, we use only 5 out ofour 6 exit relays (1.24% mean exit weight) in order toreduce operator overhead. We summarize our results inTable 2. In the first measurement, we measured thenumber of unique SLD names among those Tor pri-mary domains which contain a TLD in the public suf-fix list [5]. From a measurement conducted between2018-03-31 and 2018-04-01, we find that 471,228 (CI:[470,357; 472,099]) unique SLDs were accessed throughour exits. We also measured the number of uniqueAlexa top 1 million SLDs (i.e. the SLDs of Alexa top 1million sites) among those Tor primary domains. Froma measurement conducted between 2018-03-24 and 2018-03-25, we infer that 35,660 (CI: [34,789; 37,393]) of suchunique SLDs were accessed through our exits. Fromthese results, we find that the unique count of accessedSLDs is more than ten times that of the unique countof Alexa top one million sites. From our measurements,we conclude that a long tail exists in the distribution ofsites accessed over Tor.

To extrapolate the unique second-level domain mea-surements for the entire Tor network, we need to knowthe distribution of SLDs as seen by the exits. Fromprevious research studies, we know that domains arevisited following a power-law distribution [13, 33]. Butwe need additional measurements to determine the ex-ponent of this power-law distribution. Therefore, weperform a series of simulations of clients visiting ran-dom destination sites (based on power-law distributionwith random exponents) and construct confidence inter-vals for the network-wide unique SLD counts. We usethe locally observed unique SLDs count as a self-check.

This method appears to work well for the uniqueAlexa top 1 million SLDs. The results of 100 simula-tions reveals an inferred network-wide unique count of513,342 (CI: [512,760; 514,693]) accesses to the Alexatop 1 million list. That is, slightly more than half of theAlexa top sites are accessed over Tor over 24 hours. Un-fortunately, the inability to closely fit SLD accesses toa distribution prevented us from using this approach toextrapolate the number of network-wide SLD accesses.

5. CLIENT MEASUREMENTSWe conducted a number of measurements to better

understand who uses Tor and to determine how manyusers access the network.

5.1 Tor Connections and Clients

We first measure the number of client connectionsusing our PrivCount deployment. Over the 24 hourmeasurement period beginning on 2018-04-07, the meanprobability of selecting our relays in the entry positionwas 0.0144. Since clients typically choose their guardsaccording to guard weights, we can project our localPrivCount measurements to infer Tor-wide results bydividing our observed counts by 0.0144. We summarizeour results in Table 4.

The amount of daily data being transferred acrossTor is 517 TiB (CI: [504; 530] TiB), which representsthe sum of client uploads and downloads. We note thatthis includes Tor cell overheads, so the actual amountof client payload data transferred would be 2-3% less.

We find that there are about 148 million (CI: [143;153] million) client connections, through which 1,286million client circuits (CI: [1,246; 1,326] million) aremultiplexed, per day, across the Tor network. This issignificantly higher than the 80.6 million client connec-tions reported by Jansen and Johnson [27] two yearsago. We suspect that the discrepancy is due to ongoingdistributed denial-of-service (DDoS) attacks that beganaffecting the Tor network back in December 2017 [25].

Tor Clients. We next consider the number of uniqueclients access the Tor network. Here, we use PSC tosafely capture the approximate number of clients ob-served by our guard relays. Unlike existing work thatalso attempts to quantify the number of Tor users [15,27, 35, 38], we do not store (even temporarily) IP ad-dresses since PSC uses oblivious counters. Similar toprevious studies, we assume that there is a one-to-onemapping between client IPs and unique Tor clients, al-though this may be violated, for example, by mobileusers with changing IP addresses or by clients behindNetwork Address Translation (NAT). In addition, wecount bridges as clients, as their identities are private.

We use PSC to collect data from our relays that havea non-zero guard probability, for a 24 hour period be-ginning on 2018-04-14 during which our guards had acombined weight of 1.19%. Measurement results are re-ported in Table 5. We observe over 313 thousand uniqueclient IPs using our guards (this experiment used twoCPs due to the temporary unavailability of one). This isa surprisingly high number, given that Tor Metrics [43](using a very different and unvalidated estimation tech-nique) reports 2.15 million clients per day in April 2018for the entire Tor network. We would expect a typicalclient to connect to three guards (clients currently useone guard for data but two additional guards for direc-tory updates [8]), and so we would expect to see closerto 0.0119× 3× 2.15e6 = 76, 755 unique clients IPs. Tothe extent that each unique IP observed in a 24-hourperiod represents a new user, this suggests that Tor isunderestimating its total number of users by a factorof 4, and the total number of daily users is closer to

8

313, 213/0.0119/3 ≈ 8, 773, 473.To better understand the network-wide number of

unique client IPs in Tor, we perform additional PSCmeasurements using sets of relays of different sizes. Wecan then compare how the count grows with the mea-suring set to its predicted growth under different clientmodels to identify the most likely model. In particularwe would like to validate a model of how many guardseach client contacts, which we expect to typically be3, but could be less or more for several reasons, includ-ing guard/exit conflicts, multiple clients behind a singleNAT IP, Tor bridges serving many clients, and tor2webinstances [12]. We made two 24-hour measurements,one starting on 2018-05-12 using DCs with 0.42% ofthe guard weight and the other starting on 2018-05-13using a disjoint set of DCs with 0.88% of the guardweight. We counted 148,174 (CI: [148, 161] thousand)and 269,795 (CI: [269, 315] thousand) unique client IPsduring these measurements, respectively. Observe thatthe latter number is significantly smaller than we wouldexpect if client contacted only one guard, in which casewe would predict 148, 174×(0.88/0.42) ≈ 310, 460. Thisindicates that indeed client IPs typically connect tomultiple guards.

To identify the number of guards that typical clientIPs connect to, we consider a range of guards per clientand analyze the resulting consistency with our measure-ments. Let g denote the number of guards each clientconnects to in the model. We use simulation to extrap-olate from our two measurements two separate confi-dence intervals for the network-wide unique client IPcounts. We discover that these CIs are disjoint unlessg is in the range [27, 34]. This is a much higher valueof g than should be the case for typical clients, and webelieve that this indicates that this is a poor model ofhow clients connect to guards. It does imply, however,that there are some clients IPs that are connected tomany more guards than is typical.

Thus we consider a refinement on this model in whicha set of “promiscuous” clients connect to all guards ina 24-hour period, and the remaining “selective” clientsconnect to g guards only. The promiscuous clients cap-ture the likely behavior of Tor bridges, tor2web clients,and clients behind a NAT IP. We then determine a rangefor the number p of promiscuous clients by consider-ing values of g that are likely given our understandingof the Tor protocol: g ∈ {3, 4, 5} (all clients shouldconnect to 3 guards for directory updates, some clientsmay connect to 1 or 2 more due to guard churn). Foreach of these values of g, there were some values forthe number p of promiscuous clients that was consis-tent with our two client-IP measurements, that is, thatyielded a non-empty intersection of the two CIs. Table 3shows these ranges, which indicates about 14–22 thou-sand promiscuous clients. Observe that bridges alone

Table 3: Network-wide promiscuous clients and client IPs

Guards perclient

Promiscuousclients 95% CI

Network-wideclient IPs 95% CI

3 [15,856; 21,522] [10,851,783; 11,240,709]4 [15,129; 21,056] [8,195,072; 8,493,863]5 [14,428; 20,451] [6,605,713; 6,849,612]

Table 4: Network-wide client usage statistics, inferred from Priv-Count measurements.

Statistic Count 95% CI

Data (TiB) 517 ± [504; 530]Connections (×106) 148 ± [143; 153]Circuits (×106) 1,286 ± [1,246; 1,326]

seem unlikely to make up this population, as this rangeis much larger than the 1640 bridges reported by TorMetrics at the time of our measurements, and in April2016 Matic et al. [37] only discovered 50% more bridgesthan reported by Tor Metrics. Table 3 also shows con-fidence intervals for the number of network-wide clientIPs, calculated for each g as the union of CIs over all p inthe range shown. For what we believe is the most likelynumber of guards per selective client (g = 3), our mea-surements indicate about 11 million unique client IPsnetwork-wide, which suggests a true value over 5 timesthe number of users estimated by Tor Metrics. Even forg = 5, the range suggests over 3 times as many dailyusers as Tor currently estimates.

Client churn. Tor clients may go offline, and we expectthat the Tor network experiences a high degree of clientchurn. Using PSC, we recorded the count of uniqueclient IPs over a four-day period beginning on 2018-05-15. We observed 672,303 (CI: [671,781; 1,118,147])unique client IPs. Comparing this result with our one-day measurement (see Table 5), we can conclude thatthe client churn rate is 119,697 (CI: [119,581; 247,268])client IPs per day. We can infer similar network-widebehavior i.e.client IPs turn over almost twice over afour-day period.

5.2 Client Composition and DiversityWe additionally explore the geopolitical distribution

of Tor clients. We resolve each client IP address toits host country using the MaxMind GeoLite2 coun-try database, and use PrivCount to count the num-ber of client connections, bytes transferred, and cir-cuits created, broken down by country. For most ofthe world’s 250 countries, we were unable to determineuseful counts since the added noise (to achieve differen-tial privacy) overwhelm the actual count. We show thecountries with significant inferred counts in Figure 4.

The United States (US), Russia (RU), and Germany(DE) have both the greatest client connection counts

9

US RU DE UA FR VE NA NZ BV CA

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5C

onne

ctio

ns×107

US RU DE UA GB FR CA SC MX IM BR SK ES AR SE

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

Byt

es

×1014

US FR RU DE PL AE CA ES VG PR NI BM NL SS

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

Cir

cuit

s

×108

Figure 4: Tor per country client usage statistics inferred from PrivCount measurements - the counts of client connections (left), amountof client data transferred (center), and the counts of client circuits (right). Error bars show 95 percent confidence intervals.

Table 5: Locally observed unique client statistics measured usingPSC.

Statistic Count 95% CI

IPs 313,213 [313,039; 376,343]Countries 203 [141; 250]ASes 11,882 [11,708; 12,053]

IPs (4-day) 672,303 [671,781; 1,118,147]Churn 119,697/day [119,581; 247,268]/day

and data transfer amounts (see Figure 4, left and cen-ter). Assuming that the distribution of client connec-tion counts reflects the distribution of client usage, wecan surmise that these three countries use Tor the most.

Interestingly, our results disagree with those from theTor Metrics Portal, which ranks the United Arab Emi-rates (UAE) as contributing the second largest numberof Tor users; in contrast, we did not find the UAE tobe among the most significant contributors. Althoughwe cannot fully explain this discrepancy, we are some-what skeptical of the Tor Metric Portal’s results: thevalue reported by the Tor Metrics Portal implies thatnearly 4% of the entire population of the UAE accessesTor on a daily basis, which seems unlikely. However, al-though the UAE has neither a significant client connec-tion count nor client data transferred, it ranks sixth inthe number of client circuits (see Figure 4, right; markedas “AE”). One intriguing possibility is that the majorityof the Tor clients from the UAE are partially blockedfrom using Tor: while they are able to construct direc-tory circuits (recall that Tor’s user statistics are esti-mated from the number of directory requests), they areprevented from establishing regular Tor circuits, caus-ing the Tor software to repeatedly perform directoryfetches. We leave the exploration of this strange Torclient behavior in the UAE as a future research direc-tion.

To determine whether Tor has a global userbase, weuse PSC to count the number of unique countries fromwhich clients originate. Since the actual count can onlybe at most 250 (i.e., the total number of countriesworldwide), invariably the differentially private noiseoverwhelms the actual count. Therefore to reduce the

effect of noise, we average the country counts betweentwo consecutive one-day measurements, beginning on2018-05-09. We find that clients from 203 (CI: [141;250]) different countries access Tor. Comparing our re-sults to earlier studies from McCoy et al. [38] (2008) andChaabane et al. [15] (from 2010) that report clients fromapproximately 125 countries, we can conclude that thelocations from which Tor is accessed has significantlydiversified in the past decade.

We were unable to extrapolate the unique countrycount for the entire Tor network since the frequencydistribution of the countries, as seen by the guards, isdifficult to determine. However, we can still roughlyestimate the range of network-wide values to be [141,250], where the lower bound is the least possible ob-served count and the upper bound is the total numberof countries that exists worldwide.

Network Diversity. We also measure the network di-versity of Tor users by mapping each client IP addressto its autonomous system (AS) using the IPv4 and IPv6datasets (dated 26th November 2017) from CAIDA [7].Using PSC, we first measure the unique AS count ofthe client IPs, for a 24 hour period beginning on 2018-04-18. We observe clients from about 11,882 ASes (CI:[11,708; 12,053])—approximately 20% of the number ofdefined ASes.

To extrapolate the unique AS count for the entireTor network, we must first identify the frequency dis-tribution of the ASes, as seen by the guards. This ischallenging. Therefore, we present the range of most-likely network-wide values as [11,708; 59,597], where thelower bound is the least possible observed count and theupper bound is the total number of ASes.

To determine whether there are “hotspot” ASes, wealso ran PrivCount and recorded counts for each ofCAIDA’s 1000 highest ranked ASes [4], where an AS’srank is based on the number of ASes in its customercone. Over the 24 hour measurement period begin-ning on 2018-05-01, we found that none of the Top 1000ASes had results that were statistically significant (i.e.,clearly distinguishable from noise). Although, we didnot find any individual AS that contributes a large frac-

10

Table 6: Network-wide number of unique onion addresses in-ferred from our HSDir PSC measurements.

Statistic Count 95% CI

Addresses published 70,826 [65,738; 76,350]Addresses fetched 74,900 [34,363; 696,255]

tion of Tor users, we found that the ASes outside thetop 1000 have about 53% of the client connections, 52%of the client data, and 62% of the client circuits.

6. ONION-SERVICE MEASUREMENTSWe conducted a number of measurements to deter-

mine how many Tor onion services exist, which kinds ofservices are popular, and how these services are used.

6.1 Unique Onion AddressesRecall from §2.1 that Tor onion services store their

descriptors at onion service directories (HSDirs) in aDHT. To measure the number of unique onion servicesin the Tor network, we instrument our HSDirs to reportthe onion service address for each version 2 (v2) [9] de-scriptor that is published to and fetched from the DHT.(We don’t measure version 3 (v3) onion service descrip-tors because the onion address is obscured using keyblinding [10].) We use the PSC deployment describedin §3.1 to safely capture the approximate number of v2onion services observed by our HSDirs. Unlike existingwork that also attempts to quantify the number of onionservices [26,30,31,39], we avoid the need to store (eventemporarily) onion addresses, since PSC uses obliviouscounters. The results of our onion service address mea-surements are summarized in Table 6.

Unique Onion Service Addresses Published. Froma PSC measurement conducted between 2018-04-23 and2018-04-24 during which our mean combined HSDir pub-lish weight was 2.75%, we observed 3,900 (CI: [3,769;4,045]) unique v2 onion addresses in descriptors pub-lished to our HSDirs. We extrapolate these resultsbased on HSDir replication to infer that the total num-ber of unique onion service addresses published for theentire Tor network is 70,826 (CI: [65,738; 76,350]). Ac-cordingly, our relays observed at least 4.93% of Tor’sunique onion addresses. Using a different extrapolationmethod [26], the Tor Metrics Portal [43] estimates a to-tal of 79 thousand unique v2 onion services publishedin the Tor network at the time of our measurement.The Tor metrics estimate does not include a confidenceinterval which we expect to be significant since everyreporting relay adds noise (due to the lack of secure ag-gregation of Tor metrics reports). Therefore, we expectthat our confidence intervals would overlap.

Unique Onion Service Addresses Fetched. Froma PSC measurement conducted between 2018-04-29 and

Table 7: Network-wide onion service descriptor statistics in-ferred from our HSDir PrivCount measurements.

Statistic Count 95% CI

Fetched 134 million [117; 150] millionSucceeded 12.2 million [10.6; 13.7] millionFailed 121 million [103; 140] millionFail rate 1,400 failed/s [1,192; 1,620] failed/s

Public 56.8% [36.9; 83.6]%Unknown 47.6% [28.8; 72.7]%

2018-04-30 during which our mean combined HSDir fetchweight was 0.534%, we observed 2,401 (CI: [1,101; 3,718])unique v2 onion addresses in descriptors fetched fromour HSDirs. We extrapolate these results based on HS-Dir replication to infer that the total number of uniqueonion service addresses fetched for the entire Tor net-work is 74,900 (CI: [34,363; 696,255]). By comparingthe number of unique onion addresses published andfetched, we estimate that between 45% and 100% of ac-tive onion services are used by clients. Note that theTor Metrics Portal [43] does not estimate the numberof unique onion addresses fetched by clients, and its es-timate of the number of unique v2 onion addresses pub-lished occasionally varies significantly (e.g., it increasedby 40 thousand during our measurement).

6.2 Onion Service Directory UsageWhile the number of unique onion addresses (§6.1)

informs our understanding of how many onion servicesexist, the number of descriptor actions informs our un-derstanding of usage. Therefore, we use the PrivCountdeployment described in §3.1 to safely measure the num-ber of v2 onion service descriptors that are fetched fromour HSDirs. We also count the number of requests fordescriptors that are not stored in the DHT, typically be-cause the service is inactive. Our onion service descrip-tor measurement results are summarized in Table 7.

Onion Service Descriptors Fetched. From a Priv-Count measurement conducted between 2018-05-20 and2018-05-21 during which our mean combined HSDir fetchweight was 0.465%, we infer that there were a totalof 134 million (CI: [117; 150] million) v2 descriptorsfetched in the entire Tor network. Surprisingly, 90.9%(CI: [87.8; 93.2]%) of these fetches failed, i.e., the cor-responding descriptor was not present in the HSDir’scache or the request was malformed. Our results in-dicate that there are at least 103 million failures perday, or about 1,192 failures per second. To be sure wedid not observe a network anomaly, we conducted thismeasurement multiple times and observed consistent re-sults. We speculate that this large failure rate may bedue to botnets or onion site scanners with outdatedonion address lists. Tor’s current statistics reportinginfrastructure is unable to collect HSDir lookup fail-

11

Table 8: Network-wide rendezvous statistics inferred from ourRP PrivCount measurements.

Statistic Count 95% CI

Total Circuits 366 million [351; 380] millionSucceeded 8.08% [3.47; 13.1]%Failed: conn. closed 4.37% [0.0; 9.23]%Failed: circuit expired 84.9% [77.0; 93.5]%

Cell payload 20.1 TiB [15.2; 24.9] TiBCell payload / second 2.04 Gbit/s [1.55; 2.53] Gbit/sCell payload / circuit 730 KiB/circ. [341; 2,070] KiB/circ.

ures [29], but we have demonstrated the feasibility ofusing the PrivCount protocol to collect this statistic ina privacy-preserving manner.

From the measurement described above, we infer thatthere were a total of 12.2 million (CI: [10.6; 13.7] mil-lion) v2 descriptors successfully fetched in the entireTor network. For every successful descriptor fetch, wechecked if the address was available in the latest ahmiaonion site search index [1]. We found that 56.8% (CI:[36.9; 83.6]%) of descriptors fetched were present in theahmia list at the time of our measurement, while 47.6%(CI: [28.8; 72.7]%) were not. Our results indicate thata majority of successful onion service accesses are visitsto onion sites with publicly available addresses.

6.3 Rendezvous Point UsageRecall from §2.1 that in order for a client to commu-

nicate with an onion service, both parties build circuitsto a relay called a rendezvous point (RP), and that thisrendezvous circuit carries all end-to-end encrypted ap-plication payloads. While we cannot measure onion ser-vice usage by counting streams (onion service streamsare unobservable by our RPs because data cells are end-to-end encrypted), we can infer rendezvous circuit ac-tivity by counting the number of cells on the circuit.We instrument our RPs to report the number of cellssent on v2 [9] and v3 [10] rendezvous circuits, and usethe PrivCount deployment described in §3.1 to safelymeasure the approximate number of onion service ren-dezvous circuits and cells relayed at our RPs. Table 8summarizes the results of our RP measurements.

Rendezvous Circuit Activity. From a PrivCountmeasurement conducted between 2018-05-22 and 2018-05-23 during which our mean combined rendezvous weightwas 0.88%, we infer that there were a total of 366 mil-lion (CI: [351; 380] million) rendezvous circuits in theentire Tor network. Note that since a successful ren-dezvous involves a client and service circuit, each suchrendezvous is counted as 2 circuits at the RP. Surpris-ingly, only 8.08% (CI: [3.47; 13.1]%) of the circuits thatwe observed succeeded and were active, i.e., they wereused to transfer at least one cell containing an applica-tion payload. We found that 4.37% (CI: [0.0; 9.23]%)

of the observed rendezvous circuits failed because theconnection to the RP was closed before the service com-pleted the rendezvous protocol, and 84.9% (CI: [77.0;93.5]%) of the observed rendezvous circuits failed be-cause the circuit expired (timed-out) before the servicecompleted the rendezvous protocol.

Rendezvous Circuit Data. From the same PrivCountmeasurement as above, we infer a total of 20.1 TiB (CI:[15.2; 24.9] TiB) of cell payload data on rendezvous cir-cuits in the entire Tor network. Our inference corre-sponds to a mean of 2.04 Gbit/s (CI: [1.55; 2.53] Gbit/s)of payload data. By combining our circuit and cell ob-servations, we calculate that the mean amount of dataper active Tor rendezvous circuit is 730 KiB (CI:[341;2070] KiB).

7. RELATED WORKSeveral efforts have attempted to improve our under-

standing of the live Tor network. Most notably, theTor Project has allowed researchers to access aggregateand longitudinal data about the Tor network throughits Tor Metrics Portal [43] since 2010, with directorydata spanning back to May 2004 [34].

Tor Metrics Portal. The Metrics Portal indirectly es-timates the number of Tor users by counting the num-ber of requests to the subset of Tor directory mirrorsthat participate in statistics collection, and then ex-trapolating to the entire network by dividing by thefraction of participating directory mirrors. This tech-nique was originally proposed by Loesing et al. [35]. Incontrast with the Tor Metrics Portal, our measurementsare based on direct observations of connecting users anddo not depend on heuristics about how often clients ac-cess directory mirrors. (Indeed, as described in §5, ourdirect measurements do not align well with the MetricPortal’s indirect estimates.)

Towards safe Tor measurements. McCoy et al. per-formed one of the first studies that attempted to dis-cern how users used Tor [38]. There, the authors per-formed packet capture at a small subset of Tor ingressand egress points to determine the distributions of userlocations and exit traffic by port (i.e., by application).Chaabane et al. used similar methods to examine Bit-Torrent behavior on Tor [15]. Approaches such as thesethat collect unobfuscated and potentially sensitive net-work traces have been criticized on both ethical andlegal grounds [40,41].

There has been an increasing effort in developing tech-niques to safely measure the Tor network. Elahi etal. [23] were the first to propose the use of differentialprivacy to provide privacy-preserving aggregate dataabout Tor. Specifically, they propose two schemes knowncollectively as PrivEx. PrivCount [27], which we usein our measurements, extends the secret-sharing vari-

12

ant of PrivEx by supporting repeatable measurementphases. HisTorε [36] also proposes the use of differen-tial privacy to safely measure statistics on anonymitynetworks, and adds integrity protections by boundingthe influence of malicious data collectors (DCs). How-ever, compared to PrivCount, HisTorε is limited in thetypes of queries that it supports and lacks PrivCount’smature implementation. The private set-union cardi-nality (PSC) protocol of Fenske et al. [24] also providesdifferentially private measurements. We review differ-ential privacy in §2.2. Sections §2.3 and §2.4 describePrivCount and PSC in more detail.

Understanding Onion Services. Goulet et al. [26]describe the benefits and privacy risks of statistics col-lection for onion services. They conclude with sugges-tions for privacy-preserving statistics collection, includ-ing the use of differential privacy. Their proposal partlyinspired our work, in which we use differential privacyand other techniques [24] to conduct measurements ofonion sites. Biryukov et al. demonstrate how the designof onion services allows an attacker to gauge the popu-larity of an onion service and potentially deanonymizeit [14]. However, their envisioned attacks are not suit-able for conducting privacy-preserving measurements.Recently, Jansen et al. show how to use PrivCount tosafely measure the Tor network to discover the popular-ity of onion services [28]. Their work focused on trafficanalysis attacks and the popularity study of a single so-cial networking onion service. Finally, Owen and Sav-age perform empirical measurements of Tor’s onion ser-vices [39]. We apply similar techniques—operating Torrelays and observing HSDir lookups—but also protectuser privacy by using differentially private techniques.

8. ETHICAL AND SAFETYCONSIDERATIONS

Statistics collection in the setting of an anonymitynetwork inherently carries risk since the exposure of in-formation could degrade the privacy of the network’susers and potentially subject them to harm. Guidingour study were the four criteria for ethical network re-search established by the Menlo Report [19]: we up-hold the principle of respect for persons through thecareful and principled application of data protections,including the use of differentially private techniques andthe avoidance of collecting personally identifiable infor-mation (e.g., IP addresses). Following the principle ofbeneficience, we balance the (low) risk of harm with thepotential benefits of the research—namely, an increasedunderstanding of the Tor network that could inform re-search on improving the network’s security and perfor-mance. Our techniques achieve the Menlo Report’s no-tion of justice, since our statistics do not target a specificsubpopulation of Tor’s users. Finally, we achieve respectfor law and public interest through transparency in our

methods: we use open source tools [24,27] for statisticscollection and we submitted our research plan (prior toits implementation) to several review bodies. We pre-sented it to the Tor Research Safety Board [11], whichconcluded that our plan “provides a plausible strategyfor safely measuring trends on the Tor network.”2 (Al-though some of the authors serve on the TRSB, wewere not involved in the TRSB’s deliberations of ourresearch plan.) Our measurement study was approvedby the ethics board at the University of New SouthWales and certified as being exempt as non-human sub-jects research by the Institutional Review Board (IRB)at Georgetown University Additionally, aspects of thisstudy were discussed with members of Georgetown’s Of-fice of General Counsel, who raised no concerns.

9. CONCLUSION AND DISCUSSIONThis paper presents the most comprehensive privacy-

preserving measurement study of the live Tor networkto date. Our findings confirm that Tor is used predomi-nantly for web browsing and that Tor users tend to visitthe same popular (i.e., top Alexa) sites as do ordinary(and non-anonymous) Internet users. We observe a sur-prisingly large number of Tor connections and uniqueclient IP addresses, suggesting that the heuristically-derived estimates from the Tor Metrics Portal are sig-nificantly underreporting Tor’s userbase. We find thatthe network’s clients are highly distributed, connectingfrom more than 200 countries and nearly 12,000 ASes.These clients construct more than 1.2 billion anony-mous circuits per day, carrying approximately 517 TiBof data (6.1GiB/s). Unexpectedly, our measurementsshow that more than 90% of onion service descriptorfetches fail, suggesting the presence of botnets on Toror aggressive onion site crawlers with outdated addresslists. We report 20 TiB of data transferred daily overcircuits to onion services, representing roughly 3.9% ofall Tor traffic.

Our study does not attempt to distinguish betweenhuman-driven and automated activity on the Tor net-work. An intriguing open problem is the construction oftechniques to identify when measurements are heavilyinfluenced by automated activities (for example, whenswarms of infected hosts belonging to a botnet connectto Tor). Indeed, the enormously high failure rate ofonion service descriptor fetches strongly suggests thatautomated behavior likely does occur on Tor. Our hopeis that measurement studies such as this will help in-form developers and security researchers of unexpectedautomated activities—a necessary prerequisite to un-derstanding and potentially defending against maliciousautomated processes.

2The full text of the TRSB’s findings is availableat https://security.cs.georgetown.edu/measurement-study/trsb-feedback.txt.

13

AcknowledementsThis work has been partially supported by the Office ofNaval Research, the National Science Foundation un-der grant number CNS-1527401, and the Departmentof Homeland Security Science and Technology Direc-torate, Homeland Security Advanced Research ProjectsAgency, Cyber Security Division under agreement num-ber FTCY1500057. The views expressed in this workare strictly those of the authors and do not necessarilyreflect the official policy or position of any employer orfunding agency.

10. REFERENCES[1] Ahmia. https://ahmia.fi.[2] Alexa Top 1 Million Global Sites.

https://www.alexa.com/topsites. Data availableat http://s3.amazonaws.com/alexa-static/top-1m.csv.zip.Accessed 2017-12-21.

[3] Alexa Top Sites by Category.https://www.alexa.com/topsites/categories.Accessed 2018-01-11.

[4] CAIDA AS Rank Service.http://as-rank.caida.org/api/v1/.

[5] Public Suffix List. https://publicsuffix.org.[6] Ricochet. https://ricochet.im/.[7] Routeviews Prefix-to-AS mappings (pfx2as) for

IPv4 and IPv6. http://data.caida.org/datasets/routing/routeviews-prefix2as/.

[8] Tor directory protocol, version 3.https://gitweb.torproject.org/torspec.git/plain/dir-spec.txt.

[9] Tor Rendezvous Specification (version 2).https://gitweb.torproject.org/torspec.git/plain/rend-spec-v2.txt.

[10] Tor Rendezvous Specification (version 3).https://gitweb.torproject.org/torspec.git/plain/rend-spec-v3.txt.

[11] Tor Research Safety Board.https://research.torproject.org/safetyboard.html.

[12] Tor2web: Browse the tor onion services.https://www.tor2web.org/.

[13] Lada A Adamic and Bernardo A Huberman.Zipf’s Law and the Internet. Glottometrics,3(1):143–150, 2002.

[14] Alex Biryukov, Ivan Pustogarov, and Ralf-PhilippWeinmann. Trawling for Tor Hidden Services:Detection, Measurement, Deanonymization. InIEEE Symposium on Security and Privacy(Oakland), 2013.

[15] A. Chaabane, P. Manils, and M.A. Kaafar.Digging into Anonymous Traffic: A Deep Analysisof the Tor Anonymizing Network. In IEEENetwork and System Security, 2010.

[16] Thomas M. Dalton. Affidavit of Special AgentThomas M. Dalton. Available at

https://cbsboston.files.wordpress.com/2013/12/kimeldoharvard.pdf.

[17] Roger Dingledine and Nick Mathewson. TorProtocol Specification.https://spec.torproject.org/tor-spec.

[18] Roger Dingledine, Nick Mathewson, and PaulSyverson. Tor: The Second-Generation OnionRouter. In USENIX Security, 2004.

[19] David Dittrich, Erin Kenneally, et al. The MenloReport: Ethical Principles Guiding Informationand Communication Technology Research.Technical report, US Department of HomelandSecurity, August 2012.

[20] Cynthia Dwork, Krishnaram Kenthapadi, FrankMcSherry, Ilya Mironov, and Moni Naor. OurData, Ourselves: Privacy via Distributed NoiseGeneration. In Advances in Cryptology(EUROCRYPT), 2006.

[21] Cynthia Dwork, Frank McSherry, Kobbi Nissim,and Adam Smith. Calibrating Noise to Sensitivityin Private Data Analysis. In Theory ofCryptography Conference, 2006.

[22] Cynthia Dwork and Aaron Roth. The AlgorithmicFoundations of Differential Privacy. Foundationsand Trends® in Theoretical Computer Science,9(3–4):211–407, 2014.

[23] Tariq Elahi, George Danezis, and Ian Goldberg.PrivEx: Private Collection of Traffic Statistics forAnonymous Communication Networks. In ACMConference on Computer and CommunicationsSecurity (CCS), 2014.

[24] Ellis Fenske, Akshaya Mani, Aaron Johnson, andMicah Sherr. Distributed Measurement withPrivate Set-Union Cardinality. In ACMConference on Computer and CommunicationsSecurity (CCS), 2017.

[25] David Goulet. tor-project listserv post, availableat https://lists.torproject.org/pipermail/tor-project/2017-December/001604.html, 2017.

[26] David Goulet, Aaron Johnson, GeorgeKadianakis, and Karsten Loesing. Hidden-serviceStatistics Reported by Relays. Technical Report2015-04-001, The Tor Project, Inc., April 2015.

[27] Rob Jansen and Aaron Johnson. Safely MeasuringTor. In ACM Conference on Computer andCommunications Security (CCS), 2016.

[28] Rob Jansen, Marc Juarez, Rafael Galvez, TariqElahi, and Claudia Diaz. Inside Job: ApplyingTraffic Analysis to Measure Tor from Within. InNetwork and Distributed System SecuritySymposium (NDSS), 2018.

[29] George Kadianakis. Some Statistics about Onions.https://blog.torproject.org/some-statistics-about-onions.

14

[30] George Kadianakis, David Goulet, KarstenLoesing, and Aaron Johnson. Better HiddenService Stats from Tor Relays.https://gitweb.torproject.org/torspec.git/tree/proposals/238-hs-relay-stats.txt, 2014.

[31] George Kadianakis and Karsten Loesing.Extrapolating Network Totals fromHidden-Service Statistics. Technical Report2015-01-001, The Tor Project, January 2015.

[32] David Karger, Eric Lehman, Tom Leighton, RinaPanigrahy, Matthew Levine, and Daniel Lewin.Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving HotSpots on the World Wide Web. In ACMSymposium on Theory of Computing (STOC),1997.

[33] Serge A Krashakov, Anton B Teslyuk, and Lev NShchur. On the Universality of Rank Distributionsof Website Popularity. Computer Networks,50(11):1769–1780, 2006.

[34] Karsten Loesing. 10 Years of Collecting TorDirectory Data. Tor Blog post. Available athttps://blog.torproject.org/10-years-collecting-tor-directory-data.

[35] Karsten Loesing, Steven J. Murdoch, and RogerDingledine. A Case Study on MeasuringStatistical Data in the Tor Anonymity Network.In Financial Cryptograpy and Data Security, 2010.

[36] Akshaya Mani and Micah Sherr. Historε:

Differentially Private and Robust StatisticsCollection for Tor. In Network and DistributedSystem Security Symposium (NDSS), 2017.

[37] Srdjan Matic, Carmela Troncoso, and JuanCaballero. Dissecting Tor Bridges: a SecurityEvaluation of Their Private and PublicInfrastructures. In Network and DistributedSystems Security Symposium, pages 1–15, 2017.

[38] Damon McCoy, Kevin Bauer, Dirk Grunwald,Tadayoshi Kohno, and Douglas Sicker. ShiningLight in Dark Places: Understanding the TorNetwork. In Privacy Enhancing TechnologiesSymposium (PETS), 2008.

[39] Gareth Owen and Nick Savage. EmpiricalAnalysis of Tor Hidden Services. IET InformationSecurity, 10(3):113–118, 2016.

[40] Chris Soghoian. Researchers Could Face LegalRisks for Network Snooping.http://www.cnet.com/news/researchers-could-face-legal-risks-for-network-snooping/, July 2008.

[41] Christopher Soghoian. Enforced CommunityStandards for Research on Users of the TorAnonymity Network. In Workshop on Ethics inComputer Security Research (WECSR), 2011.

[42] Tor: Onion Service Protocol. https://www.torproject.org/docs/onion-services.html.en.

[43] Tor Project, Inc. Tor Metrics Portal.https://metrics.torproject.org/.

15