Freedom Tools

From Intelligent Designs

If you are in a nation where Internet traffic is censored, and you want to make your own decisions about what to read and write online, there are two things you need:

• tools for anonymizing your traffic
• a good manual that explains to you, preferably in your own language, how to use these tools.

With these requirements come the problems:

• How do you find the tools and manual without being detected?
• How can you download copies of them if the websites where they are hosted are censored?

Fortunately, there are millions of users out there who would be able to help you with both problems. Currently, however, they are not doing much. Perhaps a simple PHP or Perl script in combination with a central web repository of "freedom tools" and documentation could enable more people to help others to exercise their human rights.

The web script would be installed by anyone who wants to help people to get secure, censorship-resistant, anonymous Net access. The script would be called "rename-me.php" or similar, and the user installing it would be asked to give it an arbitrary name of their choosing.

After placing it in a writable directory on their server and executing it, the script would download a signed archive (ZIP file) from the central "freedom tools" repository. It would also output a bunch of HTML for the webmaster to put on their website. This HTML would contain a reference to a nice button image which would function as a link to the script.

On subsquent calls of the script, it would produce a download page which is an HTML skeleton that redirects the visitor to the ZIP file. The download page could be customized by the webmaster. As an added bonus, the script could perform platform (operating system) detection and redirect to a platform-specific archive.

[edit] What's in a ZIP?

The archive would contain all the files which a surfer in a repressive country needs to publish and retrieve information anonymously. This could include a handbook in several languages (the handbook itself could be prepared on a wiki on the repository site). Also included would be tools like Tor, Freenet, I2P, and an up-to-date list of open proxies. It could also include small hostcaches for various peer-to-peer networks. These are initial connection points to the network -- without them, eDonkey, Gnutella and similar networks are useless.

The ZIP file would be updated daily. This would not require a cron job - the script could simply check, whenever it is called, whether a day has passed, and if it has, download a new version of the ZIP file from the repository before or after rendering the download page.

[edit] Avoiding detection

The goal of the "freedom tools" campaign would of course be to get as many people as possible to install the script on their sites. If a certain tipping point is reached, it would become almost impossible for authorities to eliminate access to copies of these tools and documents -- there would be thousands of mirrors, and no central list of all of them.

One vector of attack would be to censor certain types of HTTP traffic that looks suspicious, to prevent people from getting a copy of the tools. This is why the script should have an arbitrary name and should not produce any standard webpage. As noted above, the download page content would be customizable by the webmaster. Backlinks to the campaign website could be generated by the script until it receives instructions from the server to no longer insert them.

The button remains as a repeating pattern, but is also an eye-catching and necessary way for surfers to discover the tools in the first place. To prevent detection, this button could be re-downloaded and replaced alongside the daily updates. The repository could run regular "button contests" where buttons would be submitted privately. The images could be dispatched according to a clever algorithm (e.g. hashing hostnames) to the scripts as they access the repository.

Finally, there is the ZIP file itself. Padding the file with random data might be sufficient; alternatively, it could be encrypted with a password that would be shown on the download page. The padding or the password would, of course, have to vary from host to host.

With a basic infrastructure in place and some support for self-updates, many of these mechanisms could be added over time.

[edit] Trusting the source

The final problem is that this mechanism could be used to spread Trojan horses and viruses to people interested in anonymity. In this way, it would be no different to any other website hosting the files. There is practically no way to avoid this issue if all the trusted sites offering the files are censored. Therefore, if the user wants to run executables, they should trust the source where they found them.

There are, of course, plenty of resources that do not require as much trust. This includes the documentation, but also bootstrap IP addresses for P2P networks. The user, in the end, must make a conscious decision what to do with the given information.