Trip report, 29c3

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!