I just read the paper, which you can get here: http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf It builds on the work of several other papers that explored the issue of multiple relays in the same autonomous system, or in different autonomous systems that are run by the same organization. For those that don't know, the internet is comprised of thousands of subnetworks that are controlled by different organizations (corporations, universities, governments, etc). For example, your ISP runs an autonomous system. The web site you want to visit is at a hosting provider in a data center that runs an autonomous system (or perhaps several). Large organizations like Amazon with its cloud hosting service (AWS) run autonomous systems in many locations around the world. OVH is a dedicated server provider that has data centers in multiple locations and many Tor relays run on OVH servers. So a few ISPs like OVH and Hetzner are potentially powerful adversaries. If your entry guard is an OVH server in France and your exit node is an OVH server in Montreal, then OVH can watch both ends of your connection and see who you are and what site you are visiting, thus rendering Tor useless. The problem is made worse by internet exchange points, which are places where autonomous systems exchange traffic. Someone who controls an IXP can watch the traffic of two or more autonomous systems simultaneously as it traverses those networks. Western intelligence agencies like the NSA and GCHQ are almost certainly tapping many of these IXPs. This is why we need to diversify the Tor network, and why I suggested running relays in South America and Asia in my relay guide. If you look at a map of Tor relays by geolocation, you'll see that way too many are in North America and Europe. Way too many of the high bandwidth relays are in a handful of autonomous systems, which is especially bad since circuit path building is weighted by relay bandwidth. 20% of Tor circuits will begin and end within an autonomous system that is controlled by the same organization, at any one time! According to the simulations in the paper, 80% of Tor users can be deanonymized within 6 months through normal Tor use, and without the adversary doing anything special, just watching the networks they already have control over. Interestingly, some of the suggestions they make at the end of the paper to improve security are the same thing we've been saying here for months. Entry guards are the weakest point, so you can increase your security by reducing the number of entry guards (from 3 to 2 or 1) and increasing the entry guard rotation period. The number of entry guards can be changed in torrc with: NumEntryGuards NUM You can manually specify which entry guards you want to use, for example, selecting entry guards that are in autonomous systems where no exit nodes exist. Do that with: EntryNodes node,node,node Where "node" can be a relay nickname, identity key fingerprint, or country code (ie, {us},{de}). You can look up information about relays and ASes on the Tor Compass web site: https://compass.torproject.org There is no torrc option to increase the entry guard rotation period. You have to modify the source code and compile a custom version of Tor, which I've explained elsewhere on the forum, but it's not a viable option for most people. A better option may be to use bridges. Since you set them manually, they act like persistent entry guards. There is no rotation period. You keep them for as long as you want, as long as they are up and set in your torrc. Also, since they are theoretically private, the adversary may not know that they are Tor entry point, especially if they are using the obfsproxy protocol to defend against DPI. Keep in mind that these stats are based on Tor users visiting clearnet sites. It is more difficult to deanonymize hidden service users because the adversary must control specific relays, such as the hidden service's entry guard or service directory, rather than just any exit node. However, it is still possible to attack hidden service users. There are proposals to make Tor "AS-aware", meaning that it would come bundled with information about ASes and who controls them, and it would avoid building circuits through ASes that are controlled by the same organizations. None of these proposals have been implemented yet (right now Tor only avoids building circuits through relays that in the same /24 subnet, I believe). So it's up to us to defend ourselves against this threat. Probably the safest thing you could do is grab the list of exit nodes, figure out which AS numbers they are in, and who controls them, then find bridges that are in ASes not controlled by those organizations.