5 ms·

Distribution of references still facilitates takedown requests. Still, this begs the question: how do I challenge a takedown request if MEGA has never seen / c

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.

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.