bennett@peacefire.org, 12/30/2001
The popularity of systems like FreeNet and Gnutella, which host files on a worldwide "distributed cloud" of networked machines so that the file can't be censored unless you shut down every machine in the network, have raised questions about whether the same kind of "distributed cloud" system could be used to defeat Internet filtering. The Peekabooty browser, being developed by the Cult of the Dead Cow, is the best-known example. The idea is that a user stuck behind a censoring firewall in, say, China, would have a client that connects to a point in the cloud somewhere outside China, and uses that connection to request banned content which is passed back to the client. The client also knows about some other nodes in the cloud, so that if the node that the client is using is suddenly blocked by the Chinese firewall, the client can transparently start using some other node. The client doesn't have to know anything about the node that they're using, so volunteers all over the Internet can help fight censorship by installing the "circumventor" software on their machines and plugging into the "distributed cloud".
A "node" could be a machine at a specific IP address, and a user in China could connect to that node by opening a direct connection to some software running on that remote machine. But even if the circumvention method is tunneled over some other protocol such as email, HTTP or ICQ chat, you can still think of circumvention points as "nodes" in a "cloud". If the circumvention protocol is tunneled over email, then the "nodes" are email addresses outside of China that automatically respond to requests and send data back to the user (and the "firewall" in that scenario would be the Chinese ISP's mail server, which could block mail to addresses that are known to be helping people automatically access banned content). If the circumvention protocol is tunneled over HTTP, then the "nodes" are Web sites that handle the requests and send back banned data. The "node" is where the client connects to in order to send out its original request for data, whether by transmitting a packet, sending an email, or even posting to a forum on eBay -- even if the data is passed back to the client by some other means. (So if you send out a data request by posting a message in a particular forum on eBay, and the data is sent back to you as an ICQ message, then the "node" is the eBay forum, not the ICQ user that sent you the reply.) Whatever the protocol, the "distributed cloud" is made up of "nodes" such that if one of them is blocked, the client can switch over to another one.
There are, however, serious problems with the "distributed cloud" approach. Any system built around this idea has to take into account the following issues:
In summary, a "distributed cloud" of untrusted machines makes it too easy for the Chinese censors to find people within China who are using the circumvention scheme, and once they've found you, they'd probably do more than just block your connection to the node you were using right at that second. If your client software switches over transparently to an unblocked node, great -- you can use that for a few hours before the Chinese government contacts you, at which point you'll be lucky if all they do is take away your Internet access.
A much simpler alternative is to use a simple circumventor-type program that handles requests for banned content and sends the content back to the requester, but doesn't use a "distributed cloud" at all. Users in China can contact their friends outside of China, and ask them to install the circumvention software. Then your friend in China can connect to your machine and use it to request banned content. If the Chinese government finds out about your machine, then your friends who connect to your machine might get in trouble -- but out of the millions of machines on the Internet, there's no easy way for the Chinese government to red-flag yours (provided that you avoid the problems listed below!). Again, you can think of your machine as a conceptual "node" in a sea of nodes that are outside of China's control, and then the same logic applies if the "nodes" are not machines but rather email addresses, or Web pages, or even ICQ accounts that are set up to handle requests for data and send the data back to the client. The key point is: don't give the location of the "node" (or the ICQ account, or the email address) to untrusted parties. Users in China should only ask their trusted friends outside of China to set up nodes for them to use, and the node operator should only give the location of the node to trusted friends who need it.
A big difference between this scheme and the "distributed cloud" approach is that in this scheme, the user and the node operator trust each other. But most people in China probably have at least one friend outside of China that they can trust. (And in an environment like a school, the end user and the node operator could even be the same person, if a student sets up the circumvention software on their home machine before going to school.) In this scenario, a "rogue client" might be a Chinese agent who poses as a Chinese citizen, writing to people outside China and asking if they're running a circumvention node, or know of one. (Then the agent tells the Chinese censors to watch for anybody else who connects to that node.) A "rogue server" would be a Chinese agent outside of China who sets up a circumvention server and tries to entice users inside China into using it. The solution to both problems is simple: Whether you're a Chinese user looking for a node or a volunteer outside China setting one up, don't trust anyone on the other side of the firewall unless you knew them before the use of the circumvention software became widespread.
As noted, even if your circumvention software is not part of a "distributed cloud", there are other problems that you have to avoid:
It's a lot easier to lay out these requirements than to design a program that actually meets them, but step zero is still the most important.