[idontgetproton]

I don't understand this. Let's say I receive a newsletter from some website.

That newsletter is not PGP-encrypted, so at some point the Proton Mail servers must be able to see a plaintext version of it. That means I have to trust that they never store that plaintext version.

In addition, even if they immediately encrypt it and store the encrypted version, how can they do so such that only I can read it? Is the key generated from my password? How come it's possible to reset my password with a recovery email address then? Surely they must be storing the key somewhere, in which case storing encrypted messages is pointless.

EDIT: apparently my second point is incorrect, forgetting your passphrase will indeed leave your emails permanently encrypted. The first point still stands though, it's not zero-knowledge at all if they receive the plaintext of my private emails in the first place and I have to trust that they don't store it.

[kijin]

In asymmetric encryption, the key for encryption is different from the key for decryption. You can encrypt something without being able to decrypt it, or vice versa.

You can encrypt your "master" key with another key derived from your password. When you change your password, you just decrypt and re-encrypt the master key so that it doesn't have to change.

The combination of these two techniques in one form or another is responsible for much of modern computer security, including the encryption used on this very website.

[rurban]

Sure they see the plaintext version in flight from the router. That's where a warrant would install the TAP. Before it arrives the protonmail server, where it is encrypted and stored.

Outgoing mail similar, but there it can be encrypted, so the TAP would be directly at the server, before it is encrypted.

In contrast to gmail TAP's are installed by a warrant ordered by a judge and per customer only. With gmail warrants are not needed, data is just handed over, and search interfaces are available to any agency which wants it.

[icebraining]

From what I understand, there are two passwords; the Mailbox passwords, used for encrypting and signing emails, is in fact unrecoverable, and you'll lose your emails if you forget it: https://protonmail.com/support/knowledge-base/resetting-mail...

[blfr]

Yes. But you enter the second password into the Proton webapp if you use it so it's not exactly beyond their reach.

[matthewaveryusa]

You are correct in your assessment, but this statement holds true for any application. You must read the source before executing it -- and en suite you need to trust the hardware that's executing said code.

As it stands you don't send your password to proton -- they send you an encrypted private key that the password you type decrypts (at email creation time you generated that private key in your browser via openppg.js ) They most certainly could change their API to send the password to the server once it's typed in the UI. This isn't unheard of and there is large suspicion that law enforcement made hushmail modify their API for certain users of interest in order to decrypt their mail.

[pfg]

The lack of code signing in web apps and the added attack surface of having your web and application server (which are in control of the code that users run) exposed to the internet matter a lot in this context.

Attacks on build systems of native applications aren't unheard of (CCleaner, that Ukrainian tax software, etc.), but it's far more involved and more likely to be detected, whereas web app backdoors can easily be delivered exclusively to the target and only for as long as needed to pull off the attack.

[twiss]

I've been working on adding code signing to web apps, using Service Workers: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...

The main blocker is https://github.com/w3c/ServiceWorker/issues/1208 (which would fix the non-critical but less-than-ideal issue described under "Service Worker lifecycle" in the blog post).

[blfr]

It's true for applications delivered live (mostly webapps). For vast majority of apps, I expect that at least the package maintainer at least glanced at the changes before building a new version. This is hardly foolproof but there is another layer of verification.

[dannyw]

The key is indeed generated from your password - to be pedantic, the key is encrypted by your password with a hardening function.

I believe a copy of the key is sent to the recovery email. Not completely sure, I haven’t entered one.

[tony101]

The key is not sent anywhere. Your recovery mail allows you to recover access to your account, but not access to your keys. So if you ever lose your password you will also lose the ability to decrypt your mail.

[tony101]

They use your public key to encrypt and you use your private key to decrypt. Your private key is stored encrypted with your passphrase.