Some bad signs: 1. Hosted in Switzerland is advertised as a security feature. The point of e2e is that the servers are untrusted. If you need a "good jurisdiction" for your servers, it means they must be trusted. That's a problem, because sadly there are no good jurisdictions in today's world, and your jurisdiction doesn't help you if your servers are hacked. 2. It's webmail. That means the security of whatever e2e t…
1. While historically advertising a hosting location was a bit of a red flag for snake oil, the Snowden disclosures changed things for SaaS providers. Jurisdictional arbitrage is indeed a security feature of the service. I think you're missing the point a bit in that it goes much beyond the physical servers. Simply locating servers in Switzerland doesn't provide much protection for users if you're an American company with US bank accounts. For example, choosing to run on German or Irish AWS servers doesn't really buy you much. But, ProtonMail not only has all of its servers located in Swiss datacenters, it also: 1) Is a Swiss corporation fully under the jurisdiction of Swiss law (which also means it operates under strict customer data anti-retention requirements) 2) Holds its funds in a Swiss bank 3) Has corporate officers that reside in Switzerland 4) Offers .ch e-mail addresses and a .ch web interface that cannot be taken control of through US courts and that are resolved through Swiss DNS servers 5) Is using a non-US (Swiss) Certificate Authority (QuoVadis) for its certificates.
2. This is true. However, it's true about every web service. It is also true about any software that is either distributed over the web/TLS or has security updates distributed over the web/TLS. It also includes any software that runs on platforms that have patches distributed over TLS. That is nearly everything. It's no more difficult to insert malicious code into web apps than it is to insert it into mobile phone apps, desktop apps, or operating system patches when working with a compromised trusted TLS connection. While some may say that non-web apps have code signing or application signing keys, the fact is that most of either the signing or verification keys for those application code signature schemes are distributed over TLS. There are devices out there with trusted hardware and embedded keys and some groups are starting to make use of proper TPMs. But, high quality trusted platforms are beyond the reach of most consumers and developers. I know of no platform that would catch the insertion of malicious code by a determined third party with the ability compromise a TLS session in the release and/or development cycle. If webapps are faulted and everyone is using a webapp (github) to develop, well then, everyone is essentially equally compromised. The same goes for distributing updates or public keys for validation of code signatures.
3. The company did, in the early days, see Lavabit as a inspiration. But, our systems are very different. Our systems are "can't read your mail" not "promise not to read your mail". Proton has no need to avert its eyes. There is no "plaintext in and plaintext out". There is no transmission of the private key decryption passwords back to the server. I don't think your comparison holds. The way Proton works is that the encryption is done in the browser. A non-encrypted private key is not stored, or ever sent to, the Proton servers. An openPGP keypair is generated in the browser by the user. The public key is sent to servers and stored in a database. The private key is encrypted in the client's browser, with a passphrase the client enters, using the opensource openpgpjs library. That encrypted (with a password that is never sent back to the Proton servers) private key is sent to the Proton servers and stored in a database. When a user logs in, their encrypted openPGP key is sent down to their browser with their public key encrypted e-mail. Their web browser then decrypts their private key and uses it to decrypt their email on the local computer. We never have to avert our eyes from their passphrase because it never transverses our systems. The decryption is done locally. Obviously, it would be better for us not to store the private key (even though it's strongly encrypted). But, that's just not practical for a webmail application.
So, I'm sure everyone is wondering: What would a TLS based ProtonMail compromise look like? Well, modified code (nefarious javascript) would be injected into the TLS stream that would send the user's decrypted private key and/or private key pass phrase to a third party or otherwise expose it (as invalid packets, etc) in the stream. Or, carefully selected cryptographic primitives would be inserted into the software. I contend that these are the same vulnerabilities someone faces downloading GnuPG from it's distribution sites, downloading Firefox/Chrome/IE, or even applying Windows/Linux updates.
And, I'm also sure people are wondering: What would a US Government compromise of the ProtonMail servers look like? Well, I'll leave the details out on how the US Government might get their hands on Swiss domiciled servers... maybe something like the time they cut through a datacenter wall at MIT in the middle of the night to get the early PGP code. Let's just assume they have the servers. They'd first have to break the disk encryption. Once they broke the disk encryption, they'd have to break into the database. Once they did that, they'd basically have a bunch of AES encrypted keys that they'd have to run password guessing attacks on.
ProtonMail is trying to bring cryptography to the general population to protect the basic human right of privacy. We are doing webmail the best possible way webmail can be done because webmail is the primary method of communicating for the vast majority of people today. We are not going to get our grandmas to sit in Faraday cages and work on trusted platforms with one time pads that they exchanged at their church groups and yoga classes.
There is no security through obscurity in what we're doing. Honestly, I'd be honored if you took a look. We use Signal internally. I've read through the code and was very impressed. I couldn't find a single flaw that I could exploit. Perhaps, you'd even be willing to do a consulting engagement to audit us?