Hacker News Reader

Comment by doublec | Hacker News Reader

This JS code needs to be run on the MEGA domain, right? That's why it's a bookmarklet. Other sites don't have access to the local storage required to extract the key. It does mean that MEGA can get the key and send it back to the site if MEGA was compromised but ultimately the client code needs to get the key to decrypt the MEGA content.

Some way of pinning or signing JavaScript verified by a third party or browser would be useful here. If it could also note what percentage of users was using a particular JS version you'd be more likely to notice if a targeted malicious JS was being sent.

View on HN

Isn't the issue more that Mega portray that they CAN'T see what files you're storing (plausible deniability regarding pirated content) while this proves that they actually could see your file contents if they wanted to?

Which in turn really means it's no more secure than, say, DropBox.

At least that's the impression I have regarding why this is somewhat important.

This didn't need proving. They send you JavaScript code, which you trust to encrypt your files. Without a built-in, well-audited, static browser mechanism no web service can ever be trusted with confidential data.

If the Feds decide to raid MEGA again they can simply modify their server side script to recognise your IP and serve you bad JavaScript from the MEGA domain, revealing your keys the next time you login. Nobody would be any the wiser.

Personally I'm waiting for JS crypto to take off big time and idiots to start using it from a CDN.

Sure, but don't you think it's important that they make this clear?

So far they market heavily on the fact that it's secure when this is simply not true.

If you read their security page, they do say you shouldn't use it if you don't trust them. But that's about it for any warning that you're basically sitting there naked.

I know no security system is entirely secure, but they aren't generally targeting security minded folks, they're targeting the layman who reads what they say and then thinks they're secure due to their weasel worded security page.

Meh. Should every site using HTTPS make it clear that hundreds of CAs whom you've never heard of have the capability to perform a MITM?

At least with MEGA you know the security framework is something they've engineered themselves, so you know you have to trust them. With SSL/TLS you're deferring to authority simply because it's convenient.

You still have to trust SSL, in the case of MEGA, COMODO is their CA, and they appear to use 128bit RC4.

Of course, if you've not cleaned your trusted certificates, someone like CNic can just MTIM you.

The article isn't proving anything, it's an example of how a known problem affects MEGA. It's saying encrypt your files first, because trusting MEGA (or anyone who uses that kind of encryption) is not enough.

You're right, this just highlights the nature of the site in a very effective way. The message here is nobody should be surprised.

> Without a built-in, well-audited, static browser mechanism no web service can ever be trusted with confidential data

That's why mega has a separate app: https://mega.co.nz/#chrome

It's more secure than DropBox in that someone seizing MEGA's data can't read it. A MEGA employee can't read your data. To read your data they need to capture the private key. This is possible by virtue of the fact that they're sending you the code to use the private key.

Reply on news.ycombinator.com