JavaScript anticensorship proxies

David Fifield

February 20, 2013

EE380 Computer Systems Colloquium winter 2013 (abstract).
Video stream.
Speaker's materials.


Paper authors

“Evading Censorship with Browser-Based Proxies.” David Fifield, Nate Hardison, Jonathan Ellithorpe, Emily Stark, Roger Dingledine, Phil Porras, and Dan Boneh.


Alexandre Allaire, Brian Duggan, Jorge Couchet, George Kadianakis, Griffin Boyce, Sathyanarayanan Gunasekaran, Chris Ball, tor-dev.

Flash proxies

Tiny proxies that run in a web browser, using JavaScript and WebSocket.

Web site owners paste a little bit of HTML.

<iframe src="//"
        width="80" height="15" frameborder="0" scrolling="no"></iframe>

Viewers see a little badge that turns their browser into a proxy while they are on the page. Proxies come and go all the time and are hard to effectively blacklist.

Two kinds of censorship

Blocking by address: The censor blocks packets based on a blacklist of source and destination addresses. (Addressed by this work.)

Blocking by content: The censor uses deep packet inspection (DPI) or measures side channels such as timing to classify the contents of a stream. (Addressed by traffic obfuscators such as obfsproxy.)

Comprehensive circumvention requires addressing both kinds of censorship. Doing so is now under development.


The key architectural constraint: browsers can’t receive connections. Instead we invert the usual proxy model and have the proxy connect to the client.


The client gives its address to the facilitator through an unblockable covert channel.

This sounds like pixie dust, except for the relaxed requirements of rendezvous: it may be

  1. low-bandwidth,
  2. high-latency,
  3. infrequent, and
  4. write-only.

Techniques work for rendezvous that would not work for bulk bidirectional data transport.

Email rendezvous

Send email to a distinguished Gmail address, containing your client address encrypted with the facilitator’s public key:

From: nobody@localhost
Subject: client reg f8a52ca71f


This decrypts to


A process on the facilitator polls the mailbox and registers the addresses it receives.

Challenges and limitations

The reverse proxy model means that the censored client must be able to receive connections (cannot be behind NAT). Flash proxies themselves may be behind NAT.

A potential solution to this is new browser technologies. We are looking (#5578) at WebRTC, which will allow browsers to make peer connections with built-in NAT traversal.

Number of proxies over time

“The Tor Software Ecosystem,” Jacob Appelbaum and Roger Dingledine, 28 December 2012.

Number of clients over time

Measured at the facilitator., 14 January 2013.

Actual Tor client sessions over time

Measured at the WebSocket Tor bridge.

Opt-in versus opt-out

We logged whether proxies had set the opt-in cookie over the past two weeks. 1 means opted in, unset means no preference, and -- means the proxy didn't even know it was supposed to send a cookie.

Opt-in versus opt-out

Now with heights of bars normalized to 1.

Exciting future developments

Browser plugin (#7721, Cupcake for Chrome). Don't have to keep a tab open.

Facebook app (#6291), in development by the Open Technology Institute. Lightning talk with Brian Duggan at 29c3.

Standalone flash proxy (#7944). Why limit ourselves to a browser? apt-get install flashproxy

Combine flash proxy address diversity with obfsproxy fingerprinting resistance (#7167). Made even more compelling with a standalone bridge, which doesn't have to use WebSocket.

How to help

Install the badge on your web page.

<iframe src="//"
        width="80" height="15" frameborder="0" scrolling="no"></iframe>

Opt-in your browser.

Install a browser plugin.

Add the badge to your Wikipedia skin. (Copy and paste into your “Custom JavaScript” setting.)

Look at bug reports and open tasks.

Source code

“If it’s not free software, then it sucks.”

git clone

David Fifield <>