"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 :)
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.
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!
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.
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
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 :)