Personally, I think this is enough to stop the spread (if not the storage) of horror. In other words, someone might safely store their cache on my computer without my knowledge (heaven help me) but I refuse to store anything that is searchable as a horror.
If you're fine with that, that's good enough; you can run this system, and political activists and perverts alike will be able to stick their blocks there, accessible to anyone to whom they can pass the relevant short keys. But many people will be uncomfortable with even this much.
api's requirements:
> How do we design a system that is anonymous and un-censorable where users can opt out of being relays for certain types of data?
As long as we are reasonable by taking "un-censorable" to mean very difficult to censor and "users can opt out of certain types of data" to mean highly limit traffic of data type <x>, it seems like a hard problem until proven impossible.
How then can it be used to share anything? I can see how it could be used as a secure, distributed backup (which itself is rather handy) but I'm not sure how it can be used to distribute data.
In the OMG, think of the children case: A number of cases that went public (some even linked here) agreed that legally, child porn is 'i recognize it when I see it' kind of subjective. I'm obviously talking about teenagers here and different moralities or a missing context (such as those 'taken for fun' or 'sent to a friend, privately and deliberately' cases).
Api might, from his subjective view, decide that this as-yet-never-encountered image is bad/evil/perverse. How would you ever create an algorithm for that, other than 'api, please press a button that says "fine by me" or "no way hell", right next to the image in question'?
Consider the problem of one time pads. If I have two messages the same length, one made of 'good data' and the other consisting of 'bad data' and I encode them both with different one time pads, then it is possible for the resulting ciphertext version of each message to be identical. Another way of putting this is that for any given ciphertext that has been properly encoded with a one time pad, the only information available about the plaintext is the length of the message (assuming you know already that a one time pad was used) and nothing else.
So not necessarily following any of the specifications of the system in the article.
I read his specification to mean that users are anonymous, they can post data and it can not be tracked to them. I do not see this necessarily requiring the data be filtered in a encrypted state only that it can not be tracked back to a submitter who took reasonable precautions.
Though I do not study cryptograph professionally that would be my current guess.
That it is paradoxical does not necessarily make it impossible, though. The goals are certainly contrary but I am not certain that they are contradictory.
If you think about community-based censorship, this could probably be arranged even in an anonymity community, as long as it had active-enough participation. A popular search engine like Google can have tremendous ability to censor others even on a network like Tor where people cannot easily be censored.
The chief problem is that «api» faces is that his/her aspirations are too individualistic and unimaginative. You could always put the to-be-censored material in an encrypted archive and distribute the link to the material with the password to it -- this sometimes happens with BitTorrent (and then you'd have to click on ads to get the password and it becomes a nightmare). Then nodes cannot inspect the content. So what are you going to do, limit content-types? This was done by Napster, where only MP3s would be shared -- but a piece of software quickly came out called Wrapster which "wrapped" other files in MP3s. There exist JPEG steganography tools as well, both hiding files within the least-significant bits of the image data as well as in parts of the JPEG which do not get interpreted by a normal JPEG reader (e.g. appending a RAR archive to the end of the JPEG image).
I say "too individualistic" as well because any sort of relay net where the nodes themselves inspect the content that they trade is going to expose itself to a possibility of systematic censorship. "I know that you know what you were sending me" is a horrible way to start your cryptosystem.
Nonetheless, there might be hope for a sort of global data-store which the nodes collectively take responsibility for, which nodes collectively trade and where nodes can vote to "veto" certain indexed files. The idea would be that you can't take down the data store by taking down individual nodes, you can't prove which node "uploaded" a file, and you can't necessarily fault the nodes for failing to down-vote a file tracked by the community since hosting the file is a collective decision, not an individual one. It would have to use central aspects of the design of BitCoin alongside central aspects of anonymity networks, but I don't see why it would be impossible.