In January I met with the Serious Organised Crime Agency (SOCA) in London, UK. One of the challenges when dealing with online threats (cybercrime/e-crime) is understanding which leads not to follow. My goal was to help them understand what Tor is, how it works (both from a user and a relay operator point of view), and what it can and cannot do.
I talked about the Tor software ecosystem, including ExoneraTor (the website that tells you whether a given IP address was a Tor relay), and mentioned that we list all official projects on our website. I also mentioned Roger’s trip to the FBI conference in October 2012, and talked about some of the experiences we have had teaching US-based law enforcement about Tor.
Overall, I would say the meeting went well. They learned more about Tor and the projects we are working on, and they are aware that the protections that prevent us from figuring out what Tor users are doing - and who they are - is what’s keeping all Tor users safe.
Over the weekend, I attended the Hacking against Domestic Violence event in Washington DC, sponsored by the World Bank and Second Muse. I was there to help define problem statements, think about security and privacy risks of the solutions, and to help judge the solutions crafted by the attendees. A total of 10 teams congealed over the weekend. Everyone had creative solutions to the problem statements. Generally the sheer quality of output and enthusiasm was the first thing I noticed about all of the teams and their apps. Everyone in DC focused on mobile phone compatibility, even if their solution worked on the general web itself. There are plenty of photos available from the 7 involved countries.
I ended up spending most of my time with the team working to develop protocols to protect survivors from surveillance. We called ourselves Team Fuerza. The full presentation is available. A volunteer recorded a video of the presentation as well. Related images and videos are uploaded to my Tor people site.
Because I was involved with a team, I volunteered to give up my voting rights on the judges panel to avoid any issues. I then ended up presenting for the team for the status update and final presentation.
Overall, it was a great two days and the team made a lot of progress in a short amount of time. A big thanks to the team (Sarah, Az, Cid, Adriana, Andrew, and Justin), SecondMuse, the World Bank, and all of the attendees for their efforts in holding a hackathon in 7 countries simultaneously.
The World Bank and Second Muse should have their final press release and announcement of the results soon.
UPDATE 2013-02-08: World Bank accounces their press release about the hackathon. Team Fuerza, won the USA hackathon!
We have some test Tor Browser Bundles available for testing! They contain Firefox 17.0.2esr which we're planning to switch to in February. Just as a reminder: these are alpha bundles. We're still testing them ourselves but we want to get them out for wider circulation so we can find out about any dealbreaker bugs before moving Firefox 17 into the stable bundles. For the more sophisticated users out there, we'd love it if you could run Wireshark with the bundles and let us know if you see anything untoward.
Alpha Tor Browser Bundles can be downloaded here:
All of the Tor packages have been updated with Tor 0.2.4.9-alpha as well.
Tor Browser Bundle (2.4.9-alpha-1)
- Update Firefox to 17.0.2esr
- Update Tor to 0.2.4.9-alpha
- Update Torbutton to 1.5.0pre-alpha
- Update NoScript to 126.96.36.199
- Update HTTPS-Everywhere to 4.0development.5
- Add Mozilla's PDF.js extension to give people the ability to read PDFs in
- Prevent TBB from trying to access the X session manager (closes: #5261)
- Firefox patch changes:
- Isolate image cache to url bar domain (closes: #5742 and #6539)
- Enable DOM storage and isolate it to url bar domain (closes: #6564)
- Include nsIHttpChannel.redirectTo API for HTTPS-Everywhere (closes: #5477)
- Misc preference changes:
- Disable DOM performance timers (dom.enable_performance) (closes: #6204)
- Disable HTTP connection retry timeout (network.http.connection-retry-timeout) (closes: #7656)
- Disable full path information for plugins (plugin.expose_full_path) (closes: #6210)
- Disable NoScript's block of remote WebFonts (noscript.forbidFonts) (closes: #7937)
If you were to give a non-technical person a brief overview of the Tor network, how would you begin? And if you had a picture or diagram to assist you, how would that look like?
We're looking for better visualizations of the Tor network as introductory material. Most people already know EFF's visualizations from Tor's Overview page. Recently, an Italian hack meeting came up with a fun picture of how to imagine a Tor circuit. A discussion among Tor developers brought up an ugly, but potentially useful analogy with road traffic.
Want to help make these visualizations better or suggest your own? Prettier drawings that we can actually show to the world are as useful as content-wise improvements what to add or leave out from these visualizations. Simply leave your ideas or links in the comments. Thanks!
Please help us test new experimental bundles that have flash proxy and pyobfsproxy enabled by default.
Flash proxy is a transport that uses proxies running in web browsers as access points into Tor. pyobfsproxy is a Python implementation of the obfsproxy modular transport that makes network traffic look unlike normal Tor traffic. Both of these technologies make it harder to block access to Tor. If you previously used the obfsproxy bundle, please upgrade to this bundle, which in addition to flash proxy has new obfsproxy bridges.
Flash proxy works differently than other pluggable transports, and you need to take extra steps to make it work. In particular, you will probably need to configure port forwarding in order to receive connections from browser proxies. There are instructions and hints on how to do that at this page: flash proxy howto.
These bundles contain fresh obfs2 bridge addresses, which may work for you if the bridges in the obfsproxy bundle are blocked. The bundles also includes an experimental obfs3 bridge—obfs3 is a new protocol designed to be harder to identify than the previous obfs2. If even these new bridges become blocked, you can find your own obfs2 bridges.
There are other ways you can help beyond testing the bundles. One is to run a bridge with pyobfsproxy. Another is to put the flash proxy badge on your web site or blog, or add it to your Wikipedia profile. If you want your browser to continue to be a proxy after a switch to an opt-in model, click the “Yes” button on the options page.
Tails, The Amnesic Incognito Live System, version 0.16, is out.
All users must upgrade as soon as possible.
Notable user-visible changes include:
- Minor improvements
- Replace the too-easy-to-misclick shutdown button with a better "Shutdown Helper" applet.
~/Persistentin GNOME Places and Gtk file chooser.
- Install dictionaries for a few languages.
- Set Unsafe Browser's window title to "Unsafe Browser".
- Install ekeyd to support the EntropyKey.
- Install font for Sinhala script.
- Update Poedit to 1.5.4.
- Expose Vidalia's "broken onion" icon less.
- Hide the persistence setup launchers in kiosk mode.
- Disable IPv6 on all network interfaces. This is a workaround for the IPv6 link-local multicast leak that was recently discovered.
- Tails may previously have been able to list GPT partitions labelled "TailsData" on hard drives (!) as valid persistence volumes... this is now fixed.
- Fix SCIM in the autostarted web browser.
- Talk of DVD, not of CD, in the shutdown messages.
- Make tordate work in bridge mode with an incorrect clock.
- Update iceweasel to 10.0.12esr-1+tails1.
- Set the homepage to the news section on the Tails website.
- Hide the iceweasel add-on bar by default.
- Don't hide the AdBlock-Plus button in the add-on bar anymore.
- Don't install xul-ext-monkeysphere anymore.
- tails-greeter: add German translation, update Portuguese (Brasil) and Russian ones.
- tails-persistence-setup: update French, German and Italian translations.
Plus the usual bunch of bug reports and minor improvements.
See the online changelog for technical details.
Want to try it or upgrade?
See the Getting started page.
As no software is ever perfect, we maintain a list of problems that affects the last release of Tails.
What's coming up?
See the release schedule for Tails 0.17.
Have a look to our roadmap to see where we are heading to.
Would you want to help? As explained in our "how to contribute" documentation, there are many ways you can contribute to Tails. If you want to help, come talk to us!
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.
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!
In December I attended the award ceremony for the 2012 Access Innovation Awards. Their finalists included three projects that Tor maintains or co-maintains: OONI (a framework for writing open network censorship measurement tests, and for making the results available in an open way; see its git repo), Flash Proxy (a creative way to let people run Tor bridges in their browser just by visiting a website; see its git repo), and HTTPS Everywhere (a Firefox extension to force https connections for websites that support https but don't use it by default; see its git repo). Of these, OONI and Flash Proxy ended up being winners in their respective categories.
(The Access Innovation Prize gave $100,000 across 5 categories to individuals, organizations and networks who submitted "the best actionable ideas on how to use information technology to promote and enable human rights and deliver social good.")
I'm happy that people are recognizing some of the cool projects that Tor works on. But more than that, it's interesting to watch how our projects are integrating into the broader community. The HTTPS Everywhere website is hosted by EFF, and the tool is co-developed by EFF and The Tor Project. The Flash Proxy submission was actually submitted by the New America Foundation's OTI group, where they plan to work on integrating the Flash Proxy badge into a Facebook app (don't worry, they're splitting the prize money with David Fifield, the main Flash Proxy developer). We (Tor) wouldn't be able to have this reach if we didn't have these other organizations working on our topics too.
More generally, the line around what counts as a Tor project has been getting blurrier over the years. We're a community based around free software and transparent design and development, and when we encounter somebody else who is "doing it right", we embrace them and offer whatever resources we can to help them succeed. One nice example is Nathan Freitas of Guardian — he started maintaining an Android version of Tor, and we liked how he was doing it, so we called him a Tor developer. When Nathan uses his Tor affiliation to get funders to listen to him about mobile security issues, everybody wins. Similarly, while David Fifield spends most of his time being a Stanford grad student, he's made such progress on Flash Proxy that we're paying a second Flash Proxy developer to help him with Windows deployment. It's great that OTI is working in this pluggable transport space too. There's no shortage of hard problems and development tasks to go around.
I'm glad I attended the awards evening. I confess that I was worried it would be full of media hype, with journalists lined up to write hasty and shallow articles. (I suppose I'm jaded by being followed around at hacker conferences by journalists with quotas and deadlines. But I was particularly worried this time because both OONI and Flash Proxy are young projects, and we'd be wisest to make some real progress before drawing mainstream media attention to them.) Instead, the attendees were a variety of enthusiastic, not-very-technical New York City residents. Most of them hadn't heard of Tor and had only a very general understanding of Internet privacy and censorship issues; so I had my work cut out for me in terms of advocacy and awareness-building. Highlights included conversations with people from Committee to Protect Journalists, Human Rights Watch, and several similar organizations — these are exactly the sort of orgs that needs the neutral censorship measurement results that OONI aims to provide.