5 ms·

Oh, certainly -- they still have to comply with takedowns, just as normal. But they don't have the ability to be forced to broadly remove content, and they hav

Oh, certainly -- they still have to comply with takedowns, just as normal. But they don't have the ability to be forced to broadly remove content, and they have (arguably) plausible deniability about knowing that it's there. They got caught, big time, last time over the fact that they were doing de-duplication on upload of content, and then when they received a DMCA for only one of the URLs, only taking /that/ one down -- even though they know it's actually also available in a bunch of other places.

oh_sigh 11y ago
Does manufactured plausible deniability provide as much protection? They could obtain all the keys used to decrypt files with a single logging statement, if they so chose.
- SixSigma 11y ago
  No they can't Notice the format of the URL example.com/fileA#encryption-key All MEGA has logged is: example.com/fileA encryption-key is generated client side and only sent to recipients, not the provider.
  - oh_sigh 11y ago
    That's why I said one logging statement could grab the key. Just log the fragment to a service that you run somewhere, and all of the sudden you have the key.
    - SixSigma 11y ago
      who is "you"? The fragment is only ever transmitted by the uploaded to the recipient. I'm not familiar with Mega but presumably this transmission is also encrypted. So your chance of getting it is low. And certainly Mega can deny ever receiving it.
      - oh_sigh 11y ago
        "You" being the people who wrote the client side script. Yes, the fragment is not normally transmitted to the server, but since the user is running code on their browser which was provided to them by mega, all mega needs to do is log the fragment back to their servers with a simple ajax call. The point wasn't that mega can deny ever getting the key - the point was that this "security" system in place is very obviously designed to workaround the problem of mega knowing what files they were trading. This would probably be viewed as willful blindness and not actually protect them in court: see: https://news.ycombinator.com/item?id=10415535 https://news.ycombinator.com/item?id=10415535
- AgentME 11y ago
  Not if the site used the service worker feature to pin secure versions of the site javascript on first connection.
  - Tepix 11y ago
    Got a good guide for that?
    - girvo 11y ago
      From when I looked last, it's super experimental and not quite there yet. This link[0] explained it reasonably well to me, though I'm still not sure on the security implications of pinning JS through it. [0] https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md https://github.com/slightlyoff/ServiceWorker/blob/master/exp...
- gerard 11y ago
  Having no cleartext to hand over in individual cases is one form of plausable deniability. Cleverly, it also appears to offer plausable deniability of your service's "primary purpose", since there are few conclusions that can be drawn from the encrypted data in aggregate. So some protection, yes, but there are certainly other ways to get yourself indicted, or your customers blocked, under such general tests. The example in the article shows the decryption key as a URL fragment, which never hits the wire. A subpoena on Mega's own servers is one thing, but a court compelling them to collect keys from client machines? I would hope not.
  - granos 11y ago
    It feels likely they could claim that any court order to transmit and log the keys would be "unduly burdensome" and would in fact fly in the face of their carefully considered business practices.
  - DanBC 11y ago
    We've seen court orders that caused Hushmail to create malformed Java apps which were then silenty delivered to target machines in order to break encryption. http://www.wired.com/2007/11/hushmail-to-war/ http://www.wired.com/2007/11/hushmail-to-war/ People pretty much have no option but to comply with court orders. Most people are not going to go to jail so that other people can continue distributing stuff. This should be a worry with Mega and its current owners.
    - amatix 11y ago
      They were talking about making offline & alternative OSS clients (via an open API) so that if they were legally forced to change the Javascript (which currently does the encryption) that it wouldn't affect the integrity of the service for those users.
- gojomo 11y ago
  Courts may not look kindly on such 'willful blindness': https://en.m.wikipedia.org/wiki/Willful_blindness https://en.m.wikipedia.org/wiki/Willful_blindness
  - oh_sigh 11y ago
    This seems pretty relevant from your link: > A famous example of such a defense being denied occurred in In re Aimster Copyright Litigation, 334 F.3d 643 (7th Cir. 2003), in which the defendants argued that the file-swapping technology was designed in such a way that they had no way of monitoring the content of swapped files. They suggested that their inability to monitor the activities of users meant that they could not be contributing to copyright infringement by the users. The court held that this was willful blindness on the defendant's part and would not constitute a defense to a claim of contributory infringement.
- Tepix 11y ago
  They could easily grab the key with a little bit of JavaScript, however it would be detectable on the client side.

oh_sigh 11y ago

Does manufactured plausible deniability provide as much protection? They could obtain all the keys used to decrypt files with a single logging statement, if they so chose.

SixSigma 11y ago
No they can't Notice the format of the URL example.com/fileA#encryption-key All MEGA has logged is: example.com/fileA encryption-key is generated client side and only sent to recipients, not the provider.
- oh_sigh 11y ago
  That's why I said one logging statement could grab the key. Just log the fragment to a service that you run somewhere, and all of the sudden you have the key.
  - SixSigma 11y ago
    who is "you"? The fragment is only ever transmitted by the uploaded to the recipient. I'm not familiar with Mega but presumably this transmission is also encrypted. So your chance of getting it is low. And certainly Mega can deny ever receiving it.
    - oh_sigh 11y ago
      "You" being the people who wrote the client side script. Yes, the fragment is not normally transmitted to the server, but since the user is running code on their browser which was provided to them by mega, all mega needs to do is log the fragment back to their servers with a simple ajax call. The point wasn't that mega can deny ever getting the key - the point was that this "security" system in place is very obviously designed to workaround the problem of mega knowing what files they were trading. This would probably be viewed as willful blindness and not actually protect them in court: see: https://news.ycombinator.com/item?id=10415535 https://news.ycombinator.com/item?id=10415535
AgentME 11y ago
Not if the site used the service worker feature to pin secure versions of the site javascript on first connection.
- Tepix 11y ago
  Got a good guide for that?
  - girvo 11y ago
    From when I looked last, it's super experimental and not quite there yet. This link[0] explained it reasonably well to me, though I'm still not sure on the security implications of pinning JS through it. [0] https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md https://github.com/slightlyoff/ServiceWorker/blob/master/exp...
gerard 11y ago
Having no cleartext to hand over in individual cases is one form of plausable deniability. Cleverly, it also appears to offer plausable deniability of your service's "primary purpose", since there are few conclusions that can be drawn from the encrypted data in aggregate. So some protection, yes, but there are certainly other ways to get yourself indicted, or your customers blocked, under such general tests. The example in the article shows the decryption key as a URL fragment, which never hits the wire. A subpoena on Mega's own servers is one thing, but a court compelling them to collect keys from client machines? I would hope not.
- granos 11y ago
  It feels likely they could claim that any court order to transmit and log the keys would be "unduly burdensome" and would in fact fly in the face of their carefully considered business practices.
- DanBC 11y ago
  We've seen court orders that caused Hushmail to create malformed Java apps which were then silenty delivered to target machines in order to break encryption. http://www.wired.com/2007/11/hushmail-to-war/ http://www.wired.com/2007/11/hushmail-to-war/ People pretty much have no option but to comply with court orders. Most people are not going to go to jail so that other people can continue distributing stuff. This should be a worry with Mega and its current owners.
  - amatix 11y ago
    They were talking about making offline & alternative OSS clients (via an open API) so that if they were legally forced to change the Javascript (which currently does the encryption) that it wouldn't affect the integrity of the service for those users.
gojomo 11y ago
Courts may not look kindly on such 'willful blindness': https://en.m.wikipedia.org/wiki/Willful_blindness https://en.m.wikipedia.org/wiki/Willful_blindness
- oh_sigh 11y ago
  This seems pretty relevant from your link: > A famous example of such a defense being denied occurred in In re Aimster Copyright Litigation, 334 F.3d 643 (7th Cir. 2003), in which the defendants argued that the file-swapping technology was designed in such a way that they had no way of monitoring the content of swapped files. They suggested that their inability to monitor the activities of users meant that they could not be contributing to copyright infringement by the users. The court held that this was willful blindness on the defendant's part and would not constitute a defense to a claim of contributory infringement.
Tepix 11y ago
They could easily grab the key with a little bit of JavaScript, however it would be detectable on the client side.