[pencilo]

Since I'm the first security person here I might as well just start off the anti-javascript crypto thread:

Their claim "Zero Access to User Data" is completely untrustable. There is no realistic way to be confident that this time you logged in you didn't get served backdoored javascript that sends that 'local browser only' password up to the server. This already happened in the past with Hushmail so you should keep this attack in mind.

Any system that is based on crypto code that you get in this way is inherently silly and doesn't buy you anything if the server is malicious, which is all this feature is billed as. At best you gain nothing, at worst you gain false confidence in your security.

The Swiss bit sounds interesting, but I know nothing about Swiss law and I don't see how that would stop active exploitation by an outside state actor from breaking into their service and exploiting the fact that the crypto code is sent down every time you page fetch(after a login even, how nice for targeting!). That's one of the NSA's major roles, I doubt they'd have much issue pulling it off if they wanted/needed to.

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

[tmalsburg2]

> The Swiss bit sounds interesting, but I know nothing about Swiss law ...

Switzerland has already famously succumbed to US law enforcement: http://www.forbes.com/sites/irswatch/2014/02/03/swiss-bank-s...

See also this earlier discussion on Reddit: https://pay.reddit.com/r/privacy/comments/25x80h/harvard_and...