
MEGA is genius - hlieberman
https://blog.setec.io/articles/2015/10/18/mega.html
======
bentpins
Note that MEGA is compromised: The NZ govt now owns a controlling portion of
shares. Kim issued a statement saying not to use it, and to look out for an
open source not for profit MEGA 3.0 when his non-compete expires late this
year

[http://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-
me...](http://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-mega-3)

~~~
adventured
"those shares were then seized by the New Zealand government -- Dotcom
alleges"

Massive emphasis on _alleges_. If a person is thrown out of their own company,
why would it be surprising if they then try to burn its reputation to the
ground accordingly by claiming it's fully compromised. Not to mention Kim is
planning a competing product, which casts further doubt on his credibility
about the MEGA claim. His word is not good enough on this, more proof is
necessary for such dramatic allegations.

And:

"In addition Hollywood has seized all the Megashares in the family trust that
was setup for my children"

Uh what? Hollywood seized the shares? None of what he's claiming makes any
sense.

------
aidenn0
It seems like given a public link including the decryption key, they could
still be given a takedown request, since as soon as a rights holder sends them
the link, they are no longer blind to the content. It does, however, preempt a
Content ID like system.

~~~
TheDong
It also makes it terribly un-fun wackamole for the rights holder.

If they had the files unencrypted, the rights holder could demand that every
copy of file `foo` be removed. With this design, multiple uploads of the same
file are not identifiably the same by MEGA, so that case can't happen.

It's interesting that they decided the benefit of encryption (lessened
responsibility, marketing) outweighed the cost of wasted storage space for
dedupe-able content.

~~~
geogriffin
MEGA could have made byte-identical content de-dupable yet still unreadable to
MEGA.. which would save storage space but might still retain the whack-a-mole
quality: if your upload gets taken down, you may simply change any one byte in
the file and re-upload. does MEGA do this? and if not, I wonder why not?

~~~
hlieberman
Probably not. That's one of the things that had Megaupload jammed up. I think,
in this case, disk space is cheaper than the lawyers' fees.

~~~
geogriffin
ah so they weren't even asked to ID content in a smarter way, like YouTube
does? if their goal was really to enable piracy, did they think pirates would
really give up without finding out that they could simply insert random bytes
to evade takedown? Though I guess that would end up killing their de-duping
rate anyway..

------
fho
Regarding the discussion about deduplication ability (deduplibility?): Would
it be possible to do some cryptography tricks to allow MEGA access to the data
while still preserving deniability? I am thinking about the Dual_EC_DRBG
backdoor [1] or the weak-key-generation in Debian [2].

Edit: I should clarify. I mean a purposeful installed vulnerability at the
point MEGA was build, not something that can be used after the fact.

[1]([https://en.wikipedia.org/wiki/Dual_EC_DRBG](https://en.wikipedia.org/wiki/Dual_EC_DRBG))
[2]([https://en.wikipedia.org/wiki/Random_number_generator_attack](https://en.wikipedia.org/wiki/Random_number_generator_attack))

~~~
anonbanker
not only is it possible, but Dotcom has alluded to exactly those things in his
slashdot interview.

------
codexon
I don't see how this is genius.

Having hosts not know the contents they perform services for has been desired
for a very long time. Research on homomorphic encryption predates mega by
quite a while. And I am sure there must be backup services that already
encrypted client-side long before mega.

The only reason why there wasn't something exactly like mega earlier was
because browsers didn't have the capability. And it seems mostly like revenge
for having megaupload shutdown. The profits aren't very good when you can't
de-duplicate files (because the content is encrypted) or do anything else
clever with the data. You just become a dumb provider of hard drive space and
bandwidth. Anyone can clone client-side encryption.

------
zamalek
Avoiding spam could be made less frustrating for users (report = frustration):
require proof-of-work. The server presents some nonce and the client is
expected to perform the old "hash until X zero bytes" POW and then add some
extra entropy. This makes spamming computationally expensive.

In addition, because there may be multiple possible solutions for the problem,
if the POW+entropy key is used with AES CTR, this could provide an additional
layer of plausible deniability.

------
sametmax
This is what services like 0bin.net and zerobin.net do for pastebin.

------
DennisP
Freenet has a similar model, in a p2p context. Anyone with a link can access
the file, but the person hosting it plausibly isn't aware of its contents.

