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.
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.
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.
Not that I don't want more alternatives to Gmail, but Google's End-to-End extension seems to have more trustworthy security design than this, and I'd rather wait for that to appear. ProtonMail or other email providers could, in theory, use that extension, too, though.
As a side node, the above is something I wouldn't have been able to say if Google wouldn't have started working on an end-to-end solution, and I would probably be much more interested in starting to use another email provider that did (this as a response to people who have been saying here before that "Google shouldn't use end-to-end security because it would hurt their business" - not doing so would hurt their business in the long term, is like how I like to look at it).
Why do you dislike Huawei in particular? I could hazard some guesses but most of the reasons I would guess are present in every other manufacturer I can think of. I'm truly interested in why that's a problem for you.
Apparently they signed up Huawei with a contract where they warranted there were no backdoors in the hardware. Guarantees nothing of course but props for the chutzpah to demand such an outrageous clause in the contract.
For a secure email service provider, they are very vague about the details. For example, they say there is a second password with which the messages are encrypted and this is only under user's control. Questions:
- So how does the receiver decrypts the message?
- If user wants to change / rotate their password, does it go back and update the old messages?
- Does this second password encrypt your meta data as well?
This is another interesting and massive PHP project aimed at user data security and privacy. Looks so impressive and it's a promising mail app by CERN engineers.
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.