Kim Dotcom resigns as Mega director | Hacker News Reader

Kim Dotcom resigns as Mega director

couriermail.com.au

64 pointsayers37 comments

What a shame to have to surrender your baby to fight a group of bad actors causing a bureaucratic nightmare on the other side of the world.

Given that the guy himself has a track record of massive bad-actorness, it's not exactly a shame.

Assume that every single thing he does has the end goal of defrauding someone for his personal gain, and you won't be disappointed.

If you believe in equal protection under the law the fact that he's an asshole is irrelevant.

Yep, feels like one of those cases where you want everyone to lose somehow.

Syria!

Would quite like the civilians to win there...

Clearly like he says, he is only resigning to focus on a political career, and with dotcom's recent moves, that is unsurprising. IMO he will still be prodding the company forward. (Or whoever the idea person is behind MEGA)

Kimble's going into politics? That's going to be fun, he's predestined for a job where he can bullshit as much as possible.

How's mega doing anyway? I haven't heard of it since the heavily hyped launch.

It is doing pretty well. Heard that at its current growth rate, it will reach 1 billion files uploaded by december.

Sync apps on android is already launched. iOS and desktop client coming soon. They have launched an SDK which helps developers build apps based on Mega storage layer.

except for a couple of days ago when MegaPWN[1] came to light

[1] http://nzkoz.github.io/MegaPWN/

They replied to that. Basically: "this was already in our FAQ, use the chrome plugin" https://mega.co.nz/#blog_21

I think by now everybody's already convinced that any javascript-based crypto is a joke.

It's only a joke if you don't trust the js script. Just like any encryption or software is a joke if it is untrustworthy. Unless you have the source code, it is verified and you compiled yourself, then there is always a point of weakness there. You could say the same about SSL certs and HTTPS on any website, you are blindly trusting VeriSign (or cert authority).

But with SSL your root certificates change rarely and you can control them, as well as freeze certificates for specific websites. With Javascript code you don't have that kind of control and if you did it would require a massive change in the approach of creating a webapp in order to be managable.

It's not an insurmountable problem though, I would like to see an attempt at solving it (a browser extension would be required, but arguably you could have much greater transparency in updates than even most package managed apps if you used readable JS).

Fair point, and a browser extension that would detect changes in he script would be easy enough to build. The point is, for the vast majority of users, freezing certs and such is not common (I didn't know you could do that for example) and they would rely on the site to specify the cert to use.

This is called certificate pinning (a.k.a. Trust On First Use or TOFU). If you use Firefox, just install Certificate Patrol.

If you are interested in the rationale, and how you can use technologies like DANE to make it even better, read the paper by Gabor Toth and Tjebbe Vlieg (http://staff.science.uva.nl/~delaat/rp/2012-2013/p56/report....).

It's not just a matter of trust. If you verified the JS, you could trust it. The issue is that it's very easy to inject things into an HTML page on the fly. It would be like trying to say that you could trust GnuPG, but you download it from the internet and install it every single time that you use it. That's a huge attack surface.

With a small caveat for HTML5 apps where you can install a verified version of specific code you trust in your browser or your phone. And Node.js applications which run on the server side in a controllable version.

But above is just a nuance. I agree on the basic idea when it comes to Javascript you run in the browser, it is a lost battle - unless I get a SHA256 of every version of every javascript library and compare to that, and disallow other unreadable (random emscripten junk) scripts on random pages you visit while browsing. That is why I have NoScript installed, and only allow handpicked sites to run javascript in the browser.

If only we would have had the declarative approach (I still am a little grumpy that the browser makers abandoned W3C and the far better designed declarative technology XHTML2 + XForms to pursue what is now HTML5).

Oh come one. The issue was with the developer using the environment that browsers present incorrectly and it wasn't an inherent flaw of the language.

A stupid/malicious designer will always exploit features of a language to reduce/eliminate the security of the entire system.

Don't be hating on js for the sake of hating on js!

It's not js that's the issue, it's the fact that the server can change the code at any time without the user being notified. So mega can backdoor its own encryption code at any time to retrieve your keys.

It's broken by design, it's not a flaw of js per se.

Your mobile & desktop OSes etc all have a silent automatic update mechanism. Installed programs can start services silently and download executable code in the background and use it as they want. And governments take advantage of these facts regularly.

That's why they created the browser extension. It might even come signed. At least you can read the source in plain text, unlike a compiled binary.

Which mobile & desktop OSes do that? The only software that automatically installs updates on my Apple gadgetry seems to be Google Chrome.

Google play services is one example. Any app can download executable code in the background without you realizing what is happening. Apple has some mechanisms of their own coded in if necessary.

Do you have more information on Apple's mechanisms? I can't find anything (and I'd like to turn them off :)).

You can't turn them off without jailbreaking, then you can download tweaks to turn them off. One I remember from years ago was the 'app blacklist' disabler.

It's not hating on JS for for the sake of it though.

Some environments are very hard for cryptography. Javascript in the browser is inherently tricky for cryptography.

I'm just gonna leave this here...

http://www.matasano.com/articles/javascript-cryptography/

This is a matter of phishing. Once somebody gets physical access, no matters what, security can be compromised. Mega offers security at server side while all other competitors facilitate spying through programs such as PRISM. Mega as a platform is very secure model. It is just that browser based physical access is prone to attacks. It a very know fact. Nothing to do with Mega's encryption or achitecture.

"To use this website, cookies must be enabled in your browser. To enable cookies, follow the instructions for your browser below." -couriermail.com.au

All the news corp (rupert murdoch owned) web sites in Australia do this now. That's one reason I don't visit them!

They are forced to do that by law.

Australian website, there's nothing forcing them to do anything.

Aren't Australia and Great Britain "connected" by that Commonwealth stuff? I'm not an expert in international politics, but in case that Australia is bound to that cookie law in GB, that'd explain it.

We are, but their privacy laws have absolutely no bearing on Australia. At the moment the only control the queen has is the ability to indirectly act through a Govener General who can disband the current government at will. That's never happened and probably never will though.

The whole cookie thing is just people flying off the handle anyway. One person put a warning so now everybody else does too.

Maybe the servers are in EU?

Nope, Sydney.

    person:         News Limited
    country:        AU

Reply on news.ycombinator.com