advocacy

Today Facebook unveiled its hidden service that lets users access their website more safely. Users and journalists have been asking for our response; here are some points to help you understand our thinking.

Part one: yes, visiting Facebook over Tor is not a contradiction

I didn't even realize I should include this section, until I heard from a journalist today who hoped to get a quote from me about why Tor users wouldn't ever use Facebook. Putting aside the (still very important) questions of Facebook's privacy habits, their harmful real-name policies, and whether you should or shouldn't tell them anything about you, the key point here is that anonymity isn't just about hiding from your destination.

There's no reason to let your ISP know when or whether you're visiting Facebook. There's no reason for Facebook's upstream ISP, or some agency that surveils the Internet, to learn when and whether you use Facebook. And if you do choose to tell Facebook something about you, there's still no reason to let them automatically discover what city you're in today while you do it.

Also, we should remember that there are some places in the world that can't reach Facebook. Long ago I talked to a Facebook security person who told me a fun story. When he first learned about Tor, he hated and feared it because it "clearly" intended to undermine their business model of learning everything about all their users. Then suddenly Iran blocked Facebook, a good chunk of the Persian Facebook population switched over to reaching Facebook via Tor, and he became a huge Tor fan because otherwise those users would have been cut off. Other countries like China followed a similar pattern after that. This switch in his mind between "Tor as a privacy tool to let users control their own data" to "Tor as a communications tool to give users freedom to choose what sites they visit" is a great example of the diversity of uses for Tor: whatever it is you think Tor is for, I guarantee there's a person out there who uses it for something you haven't considered.

Part two: we're happy to see broader adoption of hidden services

I think it is great for Tor that Facebook has added a .onion address. There are some compelling use cases for hidden services: see for example the ones described at using Tor hidden services for good, as well as upcoming decentralized chat tools like Ricochet where every user is a hidden service, so there's no central point to tap or lean on to retain data. But we haven't really publicized these examples much, especially compared to the publicity that the "I have a website that the man wants to shut down" examples have gotten in recent years.

Hidden services provide a variety of useful security properties. First — and the one that most people think of — because the design uses Tor circuits, it's hard to discover where the service is located in the world. But second, because the address of the service is the hash of its key, they are self-authenticating: if you type in a given .onion address, your Tor client guarantees that it really is talking to the service that knows the private key that corresponds to the address. A third nice feature is that the rendezvous process provides end-to-end encryption, even when the application-level traffic is unencrypted.

So I am excited that this move by Facebook will help to continue opening people's minds about why they might want to offer a hidden service, and help other people think of further novel uses for hidden services.

Another really nice implication here is that Facebook is committing to taking its Tor users seriously. Hundreds of thousands of people have been successfully using Facebook over Tor for years, but in today's era of services like Wikipedia choosing not to accept contributions from users who care about privacy, it is refreshing and heartening to see a large website decide that it's ok for their users to want more safety.

As an addendum to that optimism, I would be really sad if Facebook added a hidden service, had a few problems with trolls, and decided that they should prevent Tor users from using their old https://www.facebook.com/ address. So we should be vigilant in helping Facebook continue to allow Tor users to reach them through either address.

Part three: their vanity address doesn't mean the world has ended

Their hidden service name is "facebookcorewwwi.onion". For a hash of a public key, that sure doesn't look random. Many people have been wondering how they brute forced the entire name.

The short answer is that for the first half of it ("facebook"), which is only 40 bits, they generated keys over and over until they got some keys whose first 40 bits of the hash matched the string they wanted.

Then they had some keys whose name started with "facebook", and they looked at the second half of each of them to pick out the ones with pronouncable and thus memorable syllables. The "corewwwi" one looked best to them — meaning they could come up with a story about why that's a reasonable name for Facebook to use — so they went with it.

So to be clear, they would not be able to produce exactly this name again if they wanted to. They could produce other hashes that start with "facebook" and end with pronouncable syllables, but that's not brute forcing all of the hidden service name (all 80 bits).

For those who want to explore the math more, read about the "birthday attack". And for those who want to learn more (please help!) about the improvements we'd like to make for hidden services, including stronger keys and stronger names, see hidden services need some love and Tor proposal 224.

Part four: what do we think about an https cert for a .onion address?

Facebook didn't just set up a hidden service. They also got an https certificate for their hidden service, and it's signed by Digicert so your browser will accept it. This choice has produced some feisty discussions in the CA/Browser community, which decides what kinds of names can get official certificates. That discussion is still ongoing, but here are my early thoughts on it.

In favor: we, the Internet security community, have taught people that https is necessary and http is scary. So it makes sense that users want to see the string "https" in front of them.

Against: Tor's .onion handshake basically gives you all of that for free, so by encouraging people to pay Digicert we're reinforcing the CA business model when maybe we should be continuing to demonstrate an alternative.

In favor: Actually https does give you a little bit more, in the case where the service (Facebook's webserver farm) isn't in the same location as the Tor program. Remember that there's no requirement for the webserver and the Tor process to be on the same machine, and in a complicated set-up like Facebook's they probably shouldn't be. One could argue that this last mile is inside their corporate network, so who cares if it's unencrypted, but I think the simple phrase "ssl added and removed here" will kill that argument.

Against: if one site gets a cert, it will further reinforce to users that it's "needed", and then the users will start asking other sites why they don't have one. I worry about starting a trend where you need to pay Digicert money to have a hidden service or your users think it's sketchy — especially since hidden services that value their anonymity could have a hard time getting a certificate.

One alternative would be to teach Tor Browser that https .onion addresses don't deserve a scary pop-up warning. A more thorough approach in that direction is to have a way for a hidden service to generate its own signed https cert using its onion private key, and teach Tor Browser how to verify them — basically a decentralized CA for .onion addresses, since they are self-authenticating anyway. Then you don't have to go through the nonsense of pretending to see if they could read email at the domain, and generally furthering the current CA model.

We could also imagine a pet name model where the user can tell her Tor Browser that this .onion address "is" Facebook. Or the more direct approach would be to ship a bookmark list of "known" hidden services in Tor Browser — like being our own CA, using the old-fashioned /etc/hosts model. That approach would raise the political question though of which sites we should endorse in this way.

So I haven't made up my mind yet about which direction I think this discussion should go. I'm sympathetic to "we've taught the users to check for https, so let's not confuse them", but I also worry about the slippery slope where getting a cert becomes a required step to having a reputable service. Let us know if you have other compelling arguments for or against.

Part five: what remains to be done?

In terms of both design and security, hidden services still need some love. We have plans for improved designs (see Tor proposal 224) but we don't have enough funding and developers to make it happen. We've been talking to some Facebook engineers this week about hidden service reliability and scalability, and we're excited that Facebook is thinking of putting development effort into helping improve hidden services.

And finally, speaking of teaching people about the security features of .onion sites, I wonder if "hidden services" is no longer the best phrase here. Originally we called them "location-hidden services", which was quickly shortened in practice to just "hidden services". But protecting the location of the service is just one of the security features you get. Maybe we should hold a contest to come up with a new name for these protected services? Even something like "onion services" might be better if it forces people to learn what it is.

Looking for a way to help the Internet stay open and free? This topic needs some dedicated people to give it more attention — it could easily grow to as large a project as Tor itself. In the short term, OTF's Information Controls Fellowship Program has expressed interest in funding somebody to get this project going, and EFF's Eva Galperin has said she'd be happy to manage the person as an OTF fellow at EFF, with mentorship from Tor people. The first round of those proposals has a deadline in a few days, but if that timeframe doesn't work for you, this problem isn't going away: let us know and we can work with you to help you coordinate other funding.

The problem

We used to think there are two main ways that the Tor network can fail. First, legal or policy pressure can make it so nobody is willing to run a relay. Second, pressure on or from Internet Service Providers can reduce the number of places willing to host exit relays, which in turn squeezes down the anonymity that the network can provide. Both of these threats are hard to solve, but they are challenges that we've known about for a decade, and due in large part to strong ongoing collaborations we have a pretty good handle on them.

We missed a third threat to Tor's success: a growing number of websites treat users from anonymity services differently. Slashdot doesn't let you post comments over Tor, Wikipedia won't let you edit over Tor, and Google sometimes gives you a captcha when you try to search (depending on what other activity they've seen from that exit relay lately). Some sites like Yelp go further and refuse to even serve pages to Tor users.

The result is that the Internet as we know it is siloing. Each website operator works by itself to figure out how to handle anonymous users, and generally neither side is happy with the solution. The problem isn't limited to just Tor users, since these websites face basically the same issue with users from open proxies, users from AOL, users from Africa, etc.

Two recent trends make the problem more urgent. First, sites like Cloudflare, Akamai, and Disqus create bottlenecks where their components are used by many websites. This centralization impacts many websites at once when e.g. Cloudflare changes its strategy for how to handle Tor users. Second, services increasingly outsource their blacklisting, such that e.g. Skype refuses connections from IP addresses that run Tor exit relays, not because they worry about abuse via Tor (it's hard to use Skype over Tor), but because their blacklist provider has an incentive to be overbroad in its blocking. (Blacklist providers compete in part by having "the most complete" list, and in many cases it's hard for services to notice that they're losing contributions from now-missing users.)

Technical mechanisms do exist to let anonymous users interact with websites in ways that control abuse better. Simple technical approaches include "you can read but you can't post" or "you have to log in to post". More complex approaches track reputation of users and give them access to site features based on past behavior of the user rather than on past behavior of their network address. Several research designs suggest using anonymous credentials, where users anonymously receive a cryptographic credential and then prove to the website that they possess a credential that hasn't been blacklisted — without revealing their credential, so the website can't link them to their past behavior.

Social mechanisms have also proven effective in some cases, ranging from community moderation (I hear Wikipedia Germany manually approves edits from users who don't have sufficiently reputable accounts), to flagging behavior from Tor users (even though you don't know *which* Tor user it is) so other participants can choose how to interact with them.

But applying these approaches to real-world websites has not gone well overall. Part of the challenge is that the success stories are not well-publicized, so each website feels like it's dealing with the question in isolation. Some sites do in fact face quite different problems, which require different solutions: Wikipedia doesn't want jerks to change the content of pages, whereas Yelp doesn't want competitors to scrape all its pages. We can also imagine that some companies, like ones that get their revenue from targeted advertising, are fundamentally uninterested in allowing anonymous users at all.

A way forward

The solution I envision is to get a person who is both technical and good at activism to focus on this topic. Step one is to enumerate the set of websites and other Internet services that handle Tor connections differently from normal connections, and look for patterns that help us identify the common (centralized) services that impact many sites. At the same time, we should make a list of solutions — technical and social — that are in use today. There are a few community-led starts on the Tor wiki already, like the DontBlockMe page and a List of Services Blocking Tor.

Step two is to sort the problem websites based on how amenable they would be to our help. Armed with the toolkit of options we found in step one, we should go to the first (most promising) site on the list and work with them to understand their problem. Ideally we can adapt one of the ideas from the toolkit; otherwise we'll need to invent and develop a new approach tailored to their situation and needs. Then we should go to the second site on the list with our (now bigger) toolkit, and so on down the list. Once we have some success stories, we can consider how to scale better, such as holding a conference where we invite the five best success cases plus the next five unsolved sites on our list.

A lot of the work will be building and maintaining social connections with engineers at the services, to help them understand what's possible and to track regressions (for example, every year or so Google gets a new engineer in charge of deciding when to give out Captchas, and they seem to have no institutional memory of how the previous one decided to handle Tor users). It might be that the centralization of Cloudflare et al can be turned around into an advantage, where making sure they have a good practices will scale to help many websites at once.

EFF is the perfect organization to lead this charge, given its community connections, its campaigns like Who has your back?, and its more (at least more than Tor ;) neutral perspective on the topic. And now, when everybody is sympathetic about the topic of surveillance, is a great time to try to take back some ground. We have a wide variety of people who want to help, from scientists and research groups who would help with technical solutions if only they understood the real problems these sites face, to users and activists who can help publicize both the successful cases and the not-yet-successful cases.

Looking ahead to the future, I'm also part of an upcoming research collaboration with Dan Boneh, Andrea Forte, Rachel Greenstadt, Ryan Henry, Benjamin Mako Hill, and Dan Wallach who will look both at the technical side of the problem (building more useful ideas for the toolkit) and also the social side of the problem: how can we quantify the loss to Wikipedia, and to society at large, from turning away anonymous contributors? Wikipedians say "we have to blacklist all these IP addresses because of trolls" and "Wikipedia is rotting because nobody wants to edit it anymore" in the same breath, and we believe these points are related. The group is at the "applying for an NSF grant" stage currently, so it will be a year or more before funding appears, but I mention it because we should get somebody to get the ball rolling now, and hopefully we can expect reinforcements to appear as momentum builds.

In summary, if this call to arms catches your eye, your next steps are to think about what you most want to work on to get started, and how you would go about doing it. You can apply for an OTF fellowship, or we can probably help you find other funding sources as needed too.

Tor started more than eleven years ago. The project website has gone through three major revisions in that time. It looks like it’s again time for important changes.

Tor has shifted in the recent years from being a project prominently used by researchers, developers, and security experts to the wider audience of anyone concerned about their privacy. Tor’s user base continues to grow. While this is a very good news for the anonymity of every Tor user, we need to make information that matters more accessible and better structured. The support team already receive close to 30 new requests every day, and it would be a better experience for newcomers, users, and journalists to directly find their answers.

Creating the ideal website for Tor is not an easy task. We have very diverse audiences with very diverse expectations. We need to gather information from different sources. Some pages should be multi-lingual. As outdated information could endanger our users, it should be easy to keep up-to-date. Our users deserve beautiful, clear, and comprehensive graphics to allow everyone to quickly understand Tor better. We’ve had some starting discussions, but we’re very much in need of your help.

Up to the challenge? Do you want to help improving a website visited everyday by millions of people looking for protection against surveillance? Then feel free to join the website team mailing list. We need usability experts, technical writers, designers, code wizards of the modern web, static website generator experts, documentalists… Join us and help!

Thank you from The Tor Project for your support, advocacy, and help over the past few years!

Journalists and activists have been asking me this week about the news that the Obama administration is now considering whether to support the latest version of the FBI's "Going Dark" legislation. Here are some points to add to the discussion.

• This is far from law currently. Nobody's even published any proposed text. Right now the White House is considering whether to back it, and now is a great time to help them understand how dangerous it would be for America.
• Forcing backdoors in communication tools is a mandate for insecurity. Haven't they been paying attention to just how much these same systems are under attack from foreign governments and criminals? Did they not learn any lessons from the wiretapping scandals in Greece and Italy, where CALEA backdoors were used to surveil politicians, without law enforcement even knowing about it? You cannot add a backdoor to a communications system without making it more vulnerable to attack, both from insiders and from the outside.
• The Justice Department is being really short-sighted here by imagining that the world is black and white. We've heard from people at the FBI, DEA, NSA, etc who use Tor for their job. If we changed the design so we could snoop on people, those users should go use a system that isn't broken by design — such as one in another country. And if those users should, why wouldn't criminals switch too?
• In any case, it seems likely that the law won't apply to The Tor Project, since we don't run the Tor network and also it's not a service. (We write free open source software, and then people run it to form a network.)
• The current CALEA already has an ugly trickle-down effect on the citizens of other countries. Different governments have different standards for lawful access, but the technology doesn't distinguish. So when the Egyptian general plugs in his telco box and sees the connector labelled "lawful access", he thinks to himself "I *am* the law" and proceeds with surveilling his citizens to stay in power. To put it bluntly, America's lawful intercept program undermines its foreign policy goals.

And lastly, we should all keep in mind that they can't force us to do anything. You always have the alternative of stopping whatever it is you're doing. So for example if they try to "force" an individual directory authority operator to do something, the operator should just stop operating the authority (and then consider working with EFF and ACLU to establish precedent that such an attempt was illegal). And so on, all the way up the chain. Good thing the Internet is an international community.

Jacob and I did another Tor talk at CCC this year. This time we focused on explaining all the various Tor project components (mostly development-related) that need help from the broader community.

The talk went well, but we were in the smaller room, and we and the conference organizers had failed to communicate that it was meant to be more of a workshopy atmosphere. We had a lot of people there who just wanted to see the sequel to our spectacle last year, and it meant we turned away many hundred Tor enthusiasts. Live and learn I guess. I did end up holding a post-talk Tor Q&A session that lasted for seven hours.

I'm still patiently waiting for the official video to emerge [Edit: here it is!], but in the meantime there's a youtube copy of the video stream; you can look at the slides too.

Some other highlights from Congress:

• Be sure to watch the DoJ/NSA whistleblower talk (blurb).
• We talked to Christian Grothoff about NAT piercing for Flash Proxy. One of the main deficiencies in the current Flash Proxy design is that the censored user needs to be reachable on the Internet (i.e. not behind a firewall or NAT). While we can't expect the flash proxy bridge running in a browser to be able to craft arbitrary packets (required for most NAT piercing tricks), Peter Palfrader pointed out that we *can* expect the Flash Proxy facilitator to be able to send such packets on behalf of each volunteer bridge. Cute trick — wonder if it'll work.
• I introduced Harry Halpin (W3C) to David Fifield (Flash Proxy). Web browsers are trying to catch up to Skype in terms of real-time media interactions. That means UDP flows, NAT piercing, link encryption, and more, all in the browser. Flash Proxy could sure make use of all that. And the folks working on the WebRTC specifications could use some broader use cases.
• I met several great people from Bits of Freedom, the Dutch NGO that is a sort of hybrid EFF/ACLU for the Netherlands. It seems like only a few years ago that we were lamenting that Europe has too few advocacy organizations to challenge bad laws and policies — data retention, ACTA, etc. That's changing!
• I talked to Linus Nordberg, who runs several fast exits in Sweden as part of DFRI and has been pondering running a bunch of bridges too. The question is: what are the tradeoffs between running both the bridges and exits on the same network (more centralization) vs partitioning them so they run on distinct netblocks? Counterintuitively, due to the "no more than one node on a given /16" rule in Tor's path selection strategy, centralizing the bridges and exits on the same netblock actually improves safety against some adversaries. My recommendation to him was that having more bridges and exits is still better than not, even though the diversity issues remain open and complex research questions.
• I also talked to Linus about what we should do with relays whose exit policies only allow ports commonly used for plaintext traffic. Is that a hint that they're set up by jerks to sniff traffic? Or did the operator not even think about that issue? Should we set the BadExit flag for them? It seems that's a tough arms race for us to win, since they could just choose to exit to a few more ports and suddenly they blend back in. Ultimately I think we need to work harder to establish relationships with all the fast exit relays. We're doing pretty well in terms of knowing the operators of the CCC relays, the Torservers.net relays, the Akamai relays, etc. Will we eventually get to the point where we can cap the bandwidth weights for relays that we haven't met personally? Perhaps we can even bring back the Named or Valid flags for real? In any case, the short-term answer is "send them mail and start a conversation".
• I talked to trams about sandboxing Flash. It would be great to ship the Tor Browser Bundle with some wrappers that prevent Flash from doing scary things. (Ok, it would be even better to wrap the whole OS, but let's not get hasty.) He has a set of protection wrappers that work on OS X, but his next question is what behaviors to allow? I suggested that to start, we should pick exactly the behaviors Youtube uses — then we'll make a lot of Tor users happier while still not opening the attack surface too much. Next messy steps include "that's nice for OS X users, but what about Windows users?" and "How does this relate to FF17's new plugin-container notion?"
• I met with the Wau Holland Foundation board about having WHF be our European coordinator for exit relay funding. It's tricky to get everything organized in a way that's compatible with non-profit laws in both the US and Germany, and also in a way where the community understands how the relationships work. We're getting closer.
• I met with Andy Isaacson of Noisebridge, which operates several fast exits in the US under its Noisetor project. I'd like to sign Noisebridge up to be a US-based coordinator for exit relay funding. But Andy quite reasonably worries that once we start giving Noisetor money for exits, the individual contributions they get to run their exits will disappear. One resolution might be to do one of those "matching funding" deals, where we offer to match every dollar they raise up to some amount. Ultimately, I hope they work with their community to make a plan that lets them either grow the capacity or diversity of the relays they run, or extend the lifetime of their existing relays.
• I talked to bunnie about the open laptop he's working on. Over in Torouter land, we've had a series of experiences where we pick what looks like a fine architecture for a tiny Tor relay. We work with the vendor, help everything go smoothly, and then at the last minute it seems like the vendor goes sideways with some for-profit proprietary alternate plan. :( I really want to live in a world where a fully open platform exists — hardware design and documentation, firmware, device drivers, software, everything. If you can do anything to help bunnie succeed, please do!

Recently, we've been introduced to two "Tor Project" Facebook Org pages. Neither of which are run by us at Tor, yet. There was also a Google+ page for a while, too. We currently use a few social media methods, such as mailing lists, pgp web of trust, internet relay chat, Identi.ca, and Twitter. Some people are very upset Tor is seemingly supporting Facebook, Google+ and others.

We're expanding into Facebook, Google+, Reddit, and others because our users are asking for it. There are existing Tor communities in many places, and we don't need to formally be at them all. It's great when individuals step up to the challenge and represent Tor in positive ways. However, as people join these communities, they are looking for a real discussion with us. For many people, these platforms are the primary means of communication.

We do have some concerns about social media sites. Let's enumerate these concerns.

1. Current social media solutions don't respect user privacy, however it's all we have today. With buttons like "+1", "Like", and "Tweet this" strewn about websites, tracking your normal web activity, Tor is at least one solution to help you stop this global tracking. We believe you should be fully in control of your own data and metadata.

2. The users are currently using these systems in very unsafe ways. We can join the system and set up a presence with details about how to use these systems more safely--or if they cannot be used safely at all. The goal is to educate people.The EFF has an explanation of these risks as well.

3. We can get our message out to people and have a discussion with them, where they are, even though we don't control the medium and risk getting kicked off the system.

4. Some are impersonating us now, and not at the quality level we want to see. A bad answer or impression from a fake Tor is worse than no answer at all.

Why don't we write our own?

Writing and deploying our own social media system is beyond the scope of our mission. However, tor can provide an anonymous base for such a system. We have hope for systems like Diaspora, tent, and FreedomBox.

Our progress report for April 2012 is now available. Highlights include tls/openssl updates, bridgeDB plans, tor cloud updates, obfsproxy updates, shadow tor simulator thoughts, new tor alpha release, support queue stats, and some press and speaking slots.

Available as a pdf with full color graphs, https://archive.torproject.org/monthly-report-archive/2012-April-Monthly...

or as a plain text file for portability and readability, https://archive.torproject.org/monthly-report-archive/2012-April-Monthly...

Our progress report for February 2012 is now available. It hightlights recent work with deep packet inspection and censorship circumvention in Iran and Kazakhstan. Also progress on a new tor status site based on new protocols, and general outreach and travels.

We implemented a new format this month to better reflect everything going on within Tor.

Available as a pdf with full color graphs, https://archive.torproject.org/monthly-report-archive/2012-February-Mont...

or as a plain text file for portability and readability, https://archive.torproject.org/monthly-report-archive/2012-February-Mont...

The 2nd USENIX Workshop on Free and Open Communications on the Internet (FOCI '12) seeks to bring together researchers and practitioners from technology, law, and policy who are working on means to study, detect, or circumvent practices that inhibit free and open communications on the Internet.

The Internet offers great promise for improving the communication capabilities of citizens, but our increasing dependence on networked communications also makes it easier for organizations to control, monitor, and block communications. ISPs and governments routinely restrict access to Internet content and services, either by censoring access to information or by degrading the performance of services or blocking them entirely. Similarly, ISPs can degrade network performance for certain sets of users for some or all services, for arbitrary purposes. ISPs have been found to block or throttle certain application traffic routinely. This growing trend toward blocking, tampering, or otherwise restricting communications on the Internet calls for improved techniques both for monitoring the state of restrictions on Internet content and communications, in order to inform users, and for circumventing attempts to censor, degrade, or otherwise tamper with Internet communications.

The broadening scope of attacks on Internet freedom is forcing more disciplines to address the issue. Last year's workshop brought together four research communities:

• Those studying network neutrality and performance degradation
• Those measuring content censorship and blocking of resources and services
• Those designing and evaluating censorship circumvention tools
• Those who work on the wider implications of censorship, bringing perspectives from the worlds of policy, law, ethics, and political and social sciences

This second workshop aims to repeat and promote this critical interdisciplinary approach.

Six-page short-paper submissions are due April 26 (edit: May 3), and the workshop is August 6 near Seattle. See the full Call for Papers for details.