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
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