HearSay: Anonymous and Confidential P2P File Sharing
gist.github.com
gist.github.com
"one who distributes a device with the object of promoting its use to infringe copyright, as shown by clear expression or other affirmative steps taken to foster infringement, is liable for the resulting acts of infringement by third parties." (MGM Studios, Inc. v. Grokster Ltd)
vs
"The HearSay P2P File Sharer; a response to The Copyright Alert System, as well as several other internet regulation attempts. "
If you don't think this is enough, you haven't seen recent rulings on inducement.
I remember reading on 4chan (possibly fake, but still interesting) where a guy was called up by his ISP who said that someone on his network downloaded some movie (actually probably didn't). The guy asks the ISP employee for his name and "kindly tells him to fuck off" using his words. He also threatened to leave AT&T so the employee was forced to entice him with a better deal.
Long story short, the guy liked the alert system.
First, when you create a TOR like system to disguise senders and receivers through blind intermediaries the system is 1/n efficient where n is the number of intermediaries. This kinda sucks when we're talking large media flies.
Second, it really just takes a bit of legal argument to label any participants as 'making available' infringing files.
Really the best solution is mega upload's nonsense where you can theoretically argue you're a common carrier just storing encrypted blobs. However, a Hearsay like tool could be useful for storing references to said megauploaded files - though a TOR site might work better.
Still, this begs the question: how do I challenge a takedown request if MEGA has never seen / can never see the original? What if the takedown request is in error?
On the other hand, if there are protections against that, people could just use something like this:
Protocol for "Deniability" while using SERVICE
Step 0: encrypt some payload, generate x other blobs of random data of roughly equal size (say x = 9)
Step 1: upload the 10 blobs to SERVICE
Step 2: instruct others to download these blobs
Step 3: wait a week, then remove these blobs from SERVICE
Step 4: instruct others to decrypt the blob with hash X using key Y
Note: Deniability is only assured if the monitor, EVE, is unlikely to download and store every random blob offered, "just in case" it may later turn out to be offending. If there are lots of uploaders using this strategy, with downloaders that tend to only be interested in the tastes of one provider, while EVE is interested in EVERY provider, then it scales unfavorably for EVE, and EVE could set herself up for a certain type of denial of service attack.
Of course, EVE could always go after key distribution, but keys are tiny, therefore easier to mirror, so that strikes me as harder.
Disclaimer: This is all just from information theoretic interest. Don't steal movies, don't do drugs.
So the question isn't solely theoretical. The protocol has to be simple enough to gain a sizable user base as its safety net, but also sophisticated enough to withstand certain level of attack. That sweet spot is hard to hit.
It only looks difficult and obscure because I (stupidly) wrote it as a protocol.
I could/should have just said that users could shuffle what they have on a given service faster than takedown requests come in. They might do this naturally, as a consequence of overzealous takedowns against encrypted blobs on MEGA.
More to your point, Usenet and XDCC have maintained vibrant communities, despite being difficult to use, but on an even more popular level, Bittorrent has incredible popularity and surprising staying power. Sophistication of an underlying protocol isn't really strongly connected to ultimate ease of use.
It's good to see people thinking of ways around a very serious impending problem if something like CISPA passes shortly.
We didn't focus on candy security only (hard on the outside, soft on the inside). Even if you are trusted, and inside a cluster, you're still limited to active attacks only--that is, refusing to relay messages you don't like (but not editing them!). You still have no idea (hopefully/usually) who has requested a file, who has offered the file, and you usually won't even know what the file was unless you've already obtained a copy of the torrent file.