[nly]

The impact of state actors trying to do MITM for the purposes of JavaScript injection won't be so bad once all major browsers support HPKP[0]. It looks like they're already using HSTS.

I agree with everything you've said though, I've ranted about it on many occasions. The underlying problem is one of making changes noticeable (which is what HSTS and HPKP do for TLS). Ideally you want a way to isolate the sensitive components of the application (anything with access to plaintext or keys), and have them open sourced, vetted, and undersigned by respectable third parties. Unfortunately you can't do this in practice today even in the traditional desktop or mobile app software models, which mostly sign only to prove authorship. In the browser it's hard to see how it would be even be possible... an in-browser app/plug-in model like Chrome Store wouldn't really help without a delayed update channel that gave any third party canary systems time to review and sign-off any changes. And ultimately you're still going to be gluing your secure box to your insecure form controls.

Perhaps what we need is a system like Moxies Convergence or the EFFs SSL Observatory but for HTML and JS, because I don't see "JavaScript and HTML pinning" really cutting it.

I don't think any of these challenges make ProtonMail a mistake though. It's certainly always going to be better than GMail, which depends on access to your message plaintext for advertising, and therefore can never provide privacy.

[0] https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21

[pencilo]

Sorry I wasn't clear, I wasn't talking about someone MiTM but someone actively compromising their servers.

It would be nice to have a corpus of javascript and HTML from these sorts of sites so that someone could go and look for these kinds of attacks but I doubt you can do anything proactively without destroying the ability to launch features/do experiments. Certs change rarely so pinning works, content not so much.

They don't make ProtonMail worse per se but I'm a little worried when people bill bad security ideas as core security features, it makes me cautious about anything else that could be problematic.

>I don't think any of these challenges make ProtonMail a mistake though. It's certainly always going to be better than GMail, which depends on access to your message plaintext for advertising, and therefore can never provide privacy.

No email provider whose main interface is a browser ever can provider you with those promises of privacy though, at least GMail doesn't claim it when they can't really promise it.