3 ms·

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

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.

brownbat 14y ago
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.
- xfs 14y ago
  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.
  - brownbat 14y ago
    > 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.

brownbat 14y ago

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.

xfs 14y ago
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.
- brownbat 14y ago
  > 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.