Call for papers: FOCI'14 workshop

The 4th USENIX Workshop on Free and Open Communications on the Internet is calling for papers. The workshop will be held on August 18, 2014 and seeks to bring together researchers and practitioners working on means to study, detect, or circumvent Internet censorship.

Past iterations of the workshop featured a number of great Tor research papers including a proposal for cloud-based onion routing, our OONI design paper, an analysis of how the GFW blocks Tor, a censorship analyzer for Tor, and a proposal for latency reduction in Tor circuits.

Given the past success of the FOCI series, we are looking forward to another round of great Tor papers.

Paper submissions are due on Tuesday, May 13, 2014, 11:59 p.m. PDT.

Trip report, German Foreign Office

In September, Karen and I attended a conference at the German Foreign Office to help
them decide what role Germany and the EU should have at regulating the sale of censorship and surveillance tools to dictators:


  • I liked Eric King (from Privacy International)'s suggestion that when companies are submitting their tools for export evaluation, they should be required to submit their brochures too. Some of these companies are just shameless in terms of how they pitch their tool in terms of number of bloggers you can round up per unit time. He convinced me that controlling "the worst of the worst" in terms of how they can present their product will influence how these products spread.
  • That said, these were all (foreign) policy experts, not technologists. They all seemed to take it for granted that you could draw a line between "bad" products and acceptable / dual-use products. I tried to hold back from saying "every time you people try to come up with legal phrasings about what technologies are ok, you end up putting tools like mine on the wrong side of the line." In retrospect, I should have said it more loudly.
  • They were really proud to have Tor representatives there. Having us there let them show the world that they had "real technologists" at their meeting. There were several cases where the whole breakout session turned to me and wanted to know what Tor thought about the given question.
  • I met a nice man who worked for a telco/DPI company that deploys its products in the Middle East. He raised a compelling argument: "Look, you folks are the ones that mandated backdoors in the telco equipment we produce, using the term 'lawful intercept'. And now you're surprised and upset when bad people use these same backdoors? You made us build it that way!" It certainly is easier for officials in countries like Germany to think of the world as divided between "good" places and "bad" places, but it sure isn't that simple.

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.

Call for papers: Free and Open Communications on the Internet (FOCI) Workshop

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.

Syndicate content Syndicate content