Introducing ProtonMail Contacts
protonmail.com
protonmail.com
I mainly have two problems: 1. The mobile client logs out spontaneously (or crashes and logs out) every once in a while and I have to reenter both the password and the TOTP code. Cumbersome, and really inconvenient if I'm on the go and for example my plane ticket is in ProtonMail. (I don't know my password and keep it in a password manager, inaccessible from my mobile), 2. The web client logs out whenever the browser is restarted. The web browser at least remembers the password, but I need to interact with my phone to get the TOTP code in. This means that I end up in a state where I don't get notifications for new mails, and I have to go and deal with it proactively. They recently released the "bridge", which runs as a daemon and lets me access the mail via IMAP. This alleviates the problem, but it is unfortunately still unavailable for Linux.
Are there any other happy or unhappy ProtonMail users out there? Am I alone in these frustrations?
In the end I'm not really using it though, simply because none of my contacts uses it. In that case ProtonMail is simply begging the question when it comes to privacy and security:
You can set an expiry for emails to non-Protonmail recipients, meaning they just receive a link to the contents of the email. Obviously you must also password protect it (otherwise gmail / outlook will just follow the link). Now the point is: how do you safely communicate the password?
Either you know how to safely communicate a password; in that case why not send the message without ProtonMail? Or you do not know how to safely communicate a password; what security does ProtonMail offer then?
Especially if it's not life-or-death, but you'd just "rather not appear in the data set, if avoidable." To each their own :)
Personally, I'm not fond of storing TOTP within a password manager. Then again, I also don't like webmail (because the JavaScript code can differ per session and we cannot audit notice any difference). Bridge is interesting.
1. https://github.com/WhisperSystems/Flock 2. https://signal.org/blog/flock/
"The private key is generated on the client side". Does this mean it gets generated with Javascript sent from the server? What if the server gets hacked?
It's still possible for a sophisticated MITM to replace the JS code so that is DOES send the key somewhere.
It is however going to be hard to prevent a malicious active attacker from stealing the passphrase.
The webcrypto api is still pretty cool though. I've been hoping for an excuse to use it sometime.
The webservice would assert that the resources it's sending now are the same resources it will continue to send in the future. The browser is in a prime position to enforce this.
In the event the resources ever change, then the browser should refuse to allow the changed resources to run and notifies the user what has happened in a way that is at least as scary as broken TLS. If it's a legit deployment (say, because the service has updated the backend), then this should be independently verifiable out of band e.g. via a blog post, a public changelog, etc. The process to accept the new deployment would need to be opt-in. If the user choices not to opt-in, the browser may continue using the old resources that were being served up in the past.
Without some mechanism like this, verification of the claims that services like ProtonMail makes remains intractable.
For the record one can already do it if all resources would use Subresource Integrity. Hashes of leaf resources would be embedded in parent resources up to the root document that you could announce out-of-band (e.g. https://example.com on 23rd of November 2017 has hash 1234566...). Then you'd have a cryptographic proof (like a Merkle tree) that nothing in the page changed.
If you think that taking something that's 80% there and filling in the last 20% for yourself counts as something that's "already" possible, then nothing is new and everything is already possible.
> Hashes of leaf resources would be embedded in parent resources up to the root document that you could announce out-of-band (e.g. https://example.com on 23rd of November 2017 has hash 1234566...)
This is really janky and not at all what I'm talking about. What I'm talking about is as simple as what happens now, e.g., "GitLab/Mastodon/Whatever XX.x Released".
And there will never be especially for web apps because there are no parties interested in this. Look at what happened with HPKP. It looked good on the surface but it turned out that extreme security is a little bit too extreme.
> If you think that taking something that's 80% there and filling in the last 20% for yourself counts as something that's "already" possible, then nothing is new and everything is already possible.
I'm just pointing out that you can already construct a scheme with the same security properties as what you described. If you'd rather wait for some hypothetical standard and implementation that will probably never happen then that's your decision.
> This is really janky and not at all what I'm talking about. What I'm talking about is as simple as what happens now, e.g., "GitLab/Mastodon/Whatever XX.x Released".
Perfect is the enemy of good and "GitLab/Mastodon/Whatever XX.x Released" seems to be just good enough. For paranoid people OpenPGP is there to verify build artifacts.
Are you an authority on this? Or just trying your hand at being pundit with an endless supply of unsubstantiated stop energy?
> I'm just pointing out that you can already construct a scheme with the same security properties as what you described.
No, you can't. You're writing as if the "you" here is the party in control of the service backend—the developer. That's not what this is about. This is about how you—the user—can trust that out of the n times you visited the site it didn't serve up tampered assets to backdoor the process. If this were about developers, we wouldn't be having this discussion; the developer doesn't need to request proof that he or she hasn't done any tampering to covertly introduce a backdoor.
> "GitLab/Mastodon/Whatever XX.x Released" seems to be just good enough.
I'm convinced at this point that either you're just responding without actually giving any consideration to the words coming from either one of us, or I'm having a frustrating exchange with a chatbot.
I'm the one who wrote that a release announcement on the project blog suffices to verify out-of-band that the user should expect the resources to change. You're the one who wrote this:
> Hashes of leaf resources would be embedded in parent resources up to the root document that you could announce out-of-band
So why are you now trying to explain to me that a release announcement blog post is "good enough"? Clearly if I didn't think so, I wouldn't have argued for it.
I won't be returning to this thread.
Yes, but virtually nothing protects against proxying requests. Non-exportable keys protect against using them when the device is powered off.
> Also, if the server is malicious on the first connection, then the server could just not use the webcrypto api to begin with, and just make use a key that the server knows instead.
Agreed, but it's kind of like Trust On First Use. I guess it depends on one's trust model if they consider it a good trade-off.
"Your ProtonMail private key is stored encrypted on your browser using your mailbox password. It is sent to our servers in the encrypted form. The only time it is decrypted is when you correctly enter your mailbox password." [1]
[1] https://protonmail.com/support/knowledge-base/how-is-the-pri...
Are there plans to have the protonmail service provisionally add contact info for the user, then have the user accept this by signing it with their private key?