This could be very interesting, but like most P2P and File sharing protocols you can make them and secure as you like, but the weakest link in any encryption is people. All it takes is for someone from the RIAA, MPAA, etc to infiltrate said private network and easily be able to catch people out sharing copyrighted material easily.
It's good to see people thinking of ways around a very serious impending problem if something like CISPA passes shortly.
The weakest link in this system is only the actual sharing of torrent files.
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.
As this software is in response to the "The Copyright Alert System" used by the largest ISPs in the USA, I would like to know what the impact of this program has been so far. I haven't seen many reports online of users getting notifications. Does anyone have any insight into how this program is effecting average users? Is it scaring some people away from torrenting?
Remember: the ISPs are only the messengers; the IP holders are the only ones sending messages.
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.
The difficulty of attacking policy problems with coffee script are two-fold:
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.
Distribution of references still facilitates takedown requests.
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.
You can invent all the protocols you want, but the more difficult and obscure the protocol is, the less usability and availability it will achieve, then less users, less traction, and less anonymity.
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.
> but the more difficult and obscure the protocol is
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.
Fantastic proof of concept. The big question is, whether or not these kind of distributed networks survive depends entirely on whether the legal argument that any given user of the network can be implicated in enabling software piracy holds any water. If it doesn't, then eventually decentralized, encrypted, and routed networks will deal the final blow to copyright censorship.
Welp, too bad they may have made themselves liable for inducement just by the first sentence of the introductory text:
"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.
14 comments
[ 4.6 ms ] story [ 28.6 ms ] threadIt'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.
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.
"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.