Hacking Against Domestic Violence

This January the Tor Project is supporting the Central America Domestic Violence Hackathon. The goal of this effort is to address the challenge of domestic violence by building technology solutions to assist agencies that work to support victims and advance efforts to bring perpetrators to justice.

This is being done by supporting communities on the ground in six Central America countries and Washington, DC. Already some of the organizations involved, including SecondMuse and the World Bank, have worked with these communities to define problems with potential for technical solutions. Next, these problems will be refined and then hacked on at a series of coordinated hackathons on January 26th and 27th, 2013.

We want to invite the Tor community to join us in this process. How can you help? There are two ways:

  1. Join the collaboration around defining strong problems. You can do this by reading the problem definitions and adding your comments, questions, and ideas. These problems have been generated primarily by non-technical organizations and your insight from a technical perspective can be invaluable. This includes feasibility, use cases, privacy and security concerns, existing solutions, and more.
  2. Join us on January 26th and 27th in one of the seven locations: Guatemala, El Salvador, Honduras, Nicaragua, Costa Rica, Panama, or Washington, DC.

We believe we can make a difference on domestic violence, and we need you.

Finally, if you'd like to get involved on a deeper level by organizing a problem refinement event, meeting with organizations in these locations, helping organize a hackathon, or more - contact the team running this project at

Trip report, ACM CCS/WPES

In October I attended WPES and the first day of CCS. There are a bunch of new Tor-related research papers:

  • "Changing of the Guards: A Framework for Understanding and Improving Entry Guard Selection in Tor". Basically Tariq has written a suite of tools for analyzing how likely an adversary is to be able to see a Tor user's circuits given various values for guard selection and guard rotation. Early results include "three guards is probably the wrong number" and "we probably shouldn't rotate guards so often". Later results I hope will include "here's an algorithm for assigning the Guard flag to relays that makes users safer".
  • "Torchestra: Reducing interactive traffic delays over Tor". This paper suggests having two parallel TLS connections between each pair of relays — one for the loud circuits and one for the quiet ones. I've had a series of debates with Rob Jansen over whether this should really help, or if it's just shifting the round-robining to a deeper level (e.g. kernel-level buffers). My current opinion is that it should really help, not because it writes important bytes out faster, but because the other side can *read* important bytes faster — in the current state a relay can't predict which incoming bytes are going to be high-priority, but when high-priority bytes come on a separate TCP connection, it's easy to tell.
  • "Enhancing Tor's Performance using Real-time Traffic Classification". I haven't read it in detail yet, but it looks at using machine learning to classify circuits depending on what sort of traffic they're carrying. This direction is worthwhile, but it skips over the question that Rob and I are currently wrestling with, which is "ok, so you've decided to give lower priority to a circuit. What should you actually do to make that circuit put less load on the network?" See also Rob's Usenix Security paper:
  • "SkypeMorph: Protocol Obfuscation for Tor Bridges". The idea is to use the actual Skype program to make a (TCP) video call between user and bridge, and then drop the call and start up your own UDP traffic flows that mimic Skype's UDP flows in terms of size and timing. I'm not clear that trying to look like Skype is a game we can win (especially with DPI-level adversaries already playing the arms race to detect and block 'real' Skype, and with the wasted bandwidth that comes with pretending to be a Skype video call), but I think we can get a lot of mileage out of a Tor pluggable transport that carries Tor traffic over a UDP flow — especially with recent rumors of a Syrian ISP throttling all TCP flows.
  • "StegoTorus: A Camouflage Proxy for the Tor Anonymity System". Stegotorus is an obfsproxy fork with two goals: first, chop up Tor traffic flows so you can't recognize Tor traffic just by looking for more 586-byte TCP packets than usual; and second, transport those chopped-up flows over a variety of steg modules, to hide the traffic in protocols that the adversary is unwilling to block (as opposed to obfsproxy's goal, which is to make a flow that's hard enough to DPI for that the adversary has to choose between blocking all unrecognized protocols or letting the flows through). Unfortunately, there aren't any great steg modules yet; rather, it aims to be a framework where if you *did* have a great steg module, you could just pop it in.
  • "CensorSpoofer: Asymmetric Communication using IP Spoofing for Censorship-Resistant Web Browsing". It's designed for censored users who mostly consume bytes rather than produce them. This design also uses a UDP stream to deliver the bytes, but they spoof the stream as coming from a plausible-looking voip client rather than from the real source. Then they need some low-latency low-bandwidth way (e.g. instant messaging) to get the upstream packets to the server.
  • There's also "Touching from a Distance: Website Fingerprinting Attacks and Defenses". But I confess I haven't looked at it yet. Website fingerprinting remains a huge and open issue that needs more attention.

This recent variety of pluggable-transport designs and research papers is fantastic. It also makes me realize that somebody should put some effort into identifying the various components that a Tor transport system needs, and which papers provide which components. For example, it sounds like SkypeMorph and CensorSpoofer could share the same details for the link encryption and flow control for their UDP stream, rather than inventing two separately. Similarly, the "small upstream channel" requirement from CensorSpoofer reminds me of the similar goal that David's Flashproxy design faces. I see that Tariq and Ian have a new tech report out that gives that a start.

Trip report, October FBI conference

In October I attended an FBI conference, as part of my work to try to keep Tor on good relations with law enforcement. My first goal is to remind them of all the good uses of Tor, so if they ever find themselves lobbying to outlaw anonymity online, they'll understand what they're giving up. The second goal is to make sure they understand what Tor is and how it works, so if they encounter it in their investigations they'll hassle our exit relay operators less. (Here's a great way that one FBI person explained it to me: "I've got 10 leads, and 48 hours before this case doesn't matter anymore. If you can help me understand which leads *not* to follow, I can do my job better.") My third goal is to help them be able to use Tor correctly for their own jobs — remember that diversity of users is part of what makes Tor safe for everybody to use.

Overall, we've been doing a pretty good job at teaching US-based law enforcement about Tor. At the end of the conference, one of the FBI agents took me aside and asked "surely you have *some* sort of way of tracking your users?" When I pointed at various of his FBI colleagues in the room who had told me they use Tor every day for their work, and asked if he'd be comfortable if we had a way of tracing *them*, I think he got it.

I met a nice man from the DEA who worked on the "Farmer's Market" bust. This was in the news a lot back in April, where apparently some people were selling drugs online, and using a Tor hidden service for their website. At the time I thought the news stories could be summarized simply as "idiot drug sellers accept paypal payments, get busted." It turns out they were pretty smart about how to accept paypal payments — they just had random Americans receive the paypal payments, take a cut, and then turn them into a Panama-based digital currency, and the Panama company didn't want to help trace where the money went. The better summary for the news stories should actually have been "idiot drug sellers use hushmail, get busted." Way before they switched to a Tor hidden service, the two main people used Hushmail to communicate. After a subpoena (and apparently a lot of patience since Canada still isn't quite the same as the US), Hushmail rolled over and gave up copies of all the emails. Many more details here:

I should still note that Tor doesn't introduce any magic new silver bullet that causes criminals to be uncatchable when before they weren't. The Farmer's Market people ran their webserver in some other foreign country before they switched to a Tor hidden service, and just the fact that the country didn't want to cooperate in busting them was enough to make that a dead end. Jurisdictional arbitrage is alive and well in the world.

Communications Data Bill Committee publishes report

The UK parliamentary committee considering the Draft Communications Data Bill, to which I gave evidence on behalf of The Tor Project, has now published their report (PDF version). The committee is highly critical of the draft bill, and calls for the government to consult technical experts, industry, law enforcement bodies, public authorities and civil liberties groups before re-drafting the proposed legislation. The committee's recommendations for this revised bill are summarised in section 8 of the report.

Tor is not explicitly dealt with by the report other than noting that systems that use encryption, including Tor, will pose a problem (paragraph 99) for proposals to ask communications service providers to record third party's data traversing their network. The report does however address numerous points which were raised in The Tor Project's written and oral evidence (and other organisation's submissions), including the over-broad powers the bill would hand over, the sensitivity of “communications data”, limited oversight, the challenge of storing sensitive data securely, and the rather dubious cost/benefit justification.

The committee has now completed its duties, and has consequently disbanded. The committee's report will now be considered by the government and we will be very interested in their response.

Tor Browser Bundle alpha testing with Tor 0.2.4.x-branch

Testing versions of Tor Browser Bundle which include the alpha branch of the core Tor technology, version, are available directly from our archive at

Tor represents a volatile, testing branch of Tor for new and experimental features. A change log is available.

This is a very experimental version, please test and provide feedback at

New Tor Browser Packages with Tor 0.2.3 upgrade

After a year of testing, new tor browser bundles which include the new stable branch of Tor are now available. A full changelog is available for every operating system.

The Tor 0.2.3.x stable branch represents over a year of work on improvements to the core Tor technology behind Tor Browser.

Tor Browser is available for download at

Software updates included in this release are:

Tor Browser Bundle (2.3.25-1)

  • Update Tor to
  • Update Firefox 10.0.11esr
  • Update Vidalia to 0.2.21
  • Update NoScript to 2.6.2

The Tor Project's position on the draft Communications Data Bill

The UK government has proposed a new bill which would allow UK law enforcement agencies to require that "telecommunication operators" (e.g. ISPs and website operators) intercept and record their users' traffic data (i.e. details of who is communicating with whom, when, from where, and how much, but not the content of communications). The draft of this bill, the Communications Data Bill (dubbed the "Snoopers' Charter" by some), has been published and has met widespread criticism for the unprecedented intrusion of privacy it would permit.

The impact on Tor is less than some have feared, because it is likely that The Tor Project is not a telecommunication operator for the purposes of the bill (because the nodes which carry data are not run by The Tor Project) and Tor's distributed architecture reduces the harm which may be caused by the compromise of traffic data. However, the proposed bill is still bad for privacy, especially for users of systems which don't offer the same protections as Tor, so I submitted written evidence to the parliamentary committee investigating the bill, on behalf of the Tor Project.

Our submission gave an introduction to Tor, how it works, and how it is used, and in particular how important Tor was for maintaining the safety of human rights activists working in repressive regimes. The submission also discusses the risks of the proposed bill, especially the harm which would come if traffic data collected were compromised (as happened to Google) or interception equipment installed for complying with the bill were enabled without authorization (as happend to Vodafone in Greece).

Our submission has been published with the others, and I was also invited to give evidence to the committee in person. The transcript of this session has been published with some minor redactions requested by other companies presenting evidence, but none of my answers have been redacted. Further information about the activities of this committee, including transcripts of other sessions, can be found on committee's page.

Based on the discussions which have taken place, it appears that the committee has serious reservations about the bill but we will not know for sure until the committee publishes their report, expected within a few weeks. Efforts to campaign against the bill continue, particularly by the Open Rights Group.

We are hiring support assistants and translators!

Your job is to handle support requests via our ticketing system and our new Q&A website, as well as make sure translations for software and documentation are up to date. This is a part-time contractor position starting in Q4 2012 and renewing quarterly.

We are looking for candidates who are fluent in one of Arabic, French, Mandarin, Burmese, Vietnamese, Spanish, and English. All must be fluent in English.

See the full job description for more information.

Syndicate content