A Censorship-Resistant Web
Imagine someone put a document up at http://pentagonpapers.com/volumes/1.html that a) some people want to read and b) some people want to keep you from reading.
Step one: How it works now
On the current Web, the way you request such a document is like this:
You ask one of your pre-programmed root servers who is in charge of .com
They respond with VeriSign, so you ask VeriSign who is in charge of pentagonpapers.com
They respond with Acme ISP, so you ask ACME ISP where to find pentagonpapers.com
It responds with an IP address, so you request the page from that IP
The censors can ask VeriSign to give them control of pentagonpapers.com, they can try to shut down Acme ISP, they can try to prevent you from getting hosting, and they can try to shut down your IP. All of these have been used recently, with some success. You need a backup plan.
Let’s imagine we want this URL to resolve in an uncensorable way. How would we do it?
Step one: Domain name ownership
First we would have a certificate authority (CA) which would sign statements of the form: “As of [DATE], [DOMAIN NAME] is owned by the holder of [PUBLIC KEY].” (Let’s call this a certificate.) Conveniently, there’s already a whole industry of trusted businesses that make these statements — they’re called SSL certificates.
The problem is that CAs are presumably just as subject to attack as the registrars (in fact, in some cases they are the registrars!). One possibility is to set up a certificate authority that will not sign such statements for people attempting to engage in censorship. It seems probable that such a policy would be protected by the First Amendment in the US. However, “people engaging in censorship” is a somewhat subjective notion. Also, it’s always possible a court could order the certificate authority to turn over the private signing key (or the key could be obtained in some other way).
Another possibility is some kind of “rollback UI”. If you know vaguely when the censorship attempts started, you can only trust certifications made before that date. This is a somewhat difficult feature to implement in a way that makes sense to users, though. The best case scenario is one in which the user can clearly distinguish between a censored and uncensored page. In that case, if the page appears censored they can hit a “go back a month” button and the system will only trust certifications made more than a month prior to the certification it’s currently using. The user can hit this button repeatedly until they get an uncensored version of the page.
Step two: Web page authentication
Next the owner of the website will need to sign statements of the form “The content of had the hash [HASH] on [DATE].” (L...SRC: __http://www.aaronsw.com/weblog/uncensor
