"Secure" anything is a myth, it's about what levels of risk you are willing to accept.

The bottom line is that yes, this sort of setup would be worse than PGP email, but it would still be better than traditional web mail which the vast majority of people use.

On an interesting aside: You don't have to audit the code every single time. On first execution of the code, it can store itself in the browser's application cache indefinitely, and manage upgrades in the same style as traditional software. This is fairly new ground though :)

> store itself in the browser's application cache

That may solve some of the distribution problems, but no browser-based software can ever be truly secure for a different reason: you have to run the crypto in the same process as the network and parsing code. All browsers have a history of security issues and other bugs in these areas. We should be minimizing attack surface, but browser designers instead decided to add more features that inevitably lead to more bugs.

The browser is an incredible "weird machine"[1], and relying on them for security requires believing that nobody will figure out how to program that "weird machine". The solution is something in the style of the "agent" programs[2] for ssh/gpg. The crypto - especially the private keys - must be done in an isolated process, so buffer-overflows and parser bugs at worst leak only the current data. If the crypto is handled in the browser itself, there is always risk that a bug will allow the keys to be leaked.

[1] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...

[2] ssh-agent(1), gpg-agent(1)

True, browser is more and more looking like a regular OS which executes untrusted programs. As far as security is concerned though I am hoping Servo will solve most of the issues.

I'd argue it's not significantly better than any existing product that uses transport-level security without E2E crypto. Both systems are likely to be broken if there's a server-side breach, though I'd admit there's a bit more effort involved for an attacker (planting a backdoor and collecting keys as opposed to just dumping the whole data set).

Definitely. I think that's why companies that do this (like SpiderOak and Keybase) implement client-side web crypto for convenience use but provide a pretty visible warning about the potential pitfalls compared to the desktop app, so users can make an informed choice.

A lot of people are researching solutions like the app-cache approach to try and fix this, fortunately it's getting better!

>this sort of setup would be worse than PGP email

Why not use PGP then? It's not hard.

I've read this several times, and while some of the points are correct it still feels like a marketing piece from Moxie.

gpg isn't difficult to use, hell my grandmother could do it. Concepts like private keys (this is the key you keep private) and public keys (this is the... well, public key) are trivial to understand.

You don't need to understand the technical details of encrypting and signing messages either, you just paste in the message and the pubkey key and encrypt.

It's by far the best email encryption solution we have right now, and I seriously doubt we'll be seeing anything better any time soon.

> gpg isn't difficult to use

Yet any research we have shows that people, even technical people, make simple but critical errors.

how would you stop a script crafted to overwrite the stored code without letting you know? You still have to audit every time to know that something like this wasn't introduced

Serious request, what do you think about unhosted client side crypto?

https://youtube.com/watch?v=WTPimUSIWbI

I think something like the self-hosted version (file:///) of this is getting close to something I'd consider safe enough. The backdoor problem from my previous post obviously isn't exclusive to web apps - a large chunk of software we use day to day performs updates automatically, and no one's going to reverse-engineer everything after each update.

That being said, the average native app implementing E2E crypto is probably still safer as of today for a number of reasons:

Binaries are typically signed by the developer, which isn't something you usually see in a web app using Web Crypto. Signing keys are easier to protect from unauthorized access, compared to your entire web stack.

With native apps, you tend to have far more control over code changes. You can chose your own update schedule and review new software versions for any critical component. A typical web app could change the code on every request. Web apps also make it a lot easier to pull off a targeted attack.

There's also simply a larger attack surface in general. Anything from XSS to phishing is much easier to pull off in a web app (though, as iMessage showed us, it's not quite that simple). Just think about how much effort browser plugins for password managers have to go through to prevent users from accidentally entering their master passphrase in some phishing form.

@chrisfosterelli mentioned the app cache approach of circumventing this - I guess we'll end up with some kind of trusted zone for crypto-related code in browsers, maybe with code signing and what not, sooner or later, and that might get us fairly close to the security of native apps. I don't think we're quite there yet.

PS: Thanks for writing acme-tiny!

Thanks for bringing the unhosted trend to my attention. I haven't heard of it. I'm a bit skeptical about the graphic in the front page given applications often need to perform computations on the data itself. There's probably something in the site that addresses that. I'll read it in a few days and then maybe look at your tool.

Btw, you need to correct the WebCryptoAPI link in "Security and Philosophy" part of this page:

https://github.com/diafygi/byoFS

Clicking it gives me nothing. Copy-and-pasting the link results that resembles spyware. I think it's just missing a colon after http is all.

I've actually looked at the code Mega uses (mainly for downloading without a browser) and the key is not stored on the server but actually part of the URL fragment, which isn't necessary to be sent to Mega, and decryption happens on the client:

https://gist.github.com/KenMacD/6431823

http://julien-marchand.fr/blog/using-the-mega-api-how-to-dow...

I haven't looked at the upload side but that's an interesting datapoint. Not sure how secure AES128-CTR is.

That would avoid transmitting the key to the server, but in the scenario I mentioned, it would still be accessible to the backdoor via window.location.hash.

I meant the key to decrypt the user's own folder. That has to be stored on the server so you can access your files from anywhere. But yes, share files/folders keep the key in the window hash, but that's not what I was talking about.

That isn't entirely true. You could easily develop a web extension that validated the hash of the scripts being sent down the wire. Then you'd have an equivalent security guarantee to a normal desktop client.

Or you just inject your own payload and pad the payload until it has a hash collision with the original. At 128M hashes per second you can probably find a payload that works within a day. Since the hashes are published, usually, you know your target so it's just a matter of time.

You do know how hard it would be to find a SHA-256 collision? We haven't even found /one/. Sure, if you used MD5, you could expect a collision, but SHA256?

I've seen them. Just recently I had a short burst of collisions. It happens. Don't underestimate the resolve of someone who wants to grind an axe.

Lol, no. You have not seen a SHA256 collision. One has never been found, by anyone, ever.

Thanks for calling me a liar. I see the quality of people on this thread has suddenly dropped. So, stick with respectful discourse or keep it to yourself. You are clearly not in the industry, just another useless troll.