That's not a bad idea, I'll see what people think. Note that clicking on the unsubscribe link will unsubscribe you to whatever comms preference was specified in the sending and tell you what it was.
Hey, Proton CTO here. There was a bug, and we fucked up. Support should have reported it up the chain and acknowledged this. Things happen, especially at scale, but we take comms consent seriously and will fix it.
This is Bart, Proton CTO here. For clarity, the issue mentioned here only impacts Proton Mail Bridge, our desktop IMAP/SMTP gateway to Proton Mail encrypted email.
The fact that Bridge and its client can become desynchronized sporadically for some users is a high priority issue we have been working on. Bridge is open source, and as a result relies upon open-source components, and the root cause is an architectural issue in a library that Bridge uses to implement IMAP. When there are network issues, this library returns errors to email clients.
Unfortunately, there are hundreds of email clients, and some email clients don’t handle errors properly, and this leads to desynchronization.
Our error tracking shows this does not happen often (1-2% of Bridge users) and the symptom is usually incorrect display of messages or read/unread status which is fixed with an inbox resynchronization. There are cases where a combination of a desynchronized mailbox and a specific series of user actions can lead to accidental email deletion, but this is far rarer than desynchronization. Our implementation tries as hard as possible to avoid this. If you find you are missing an email, our implementation works around the issue by placing it in a users’ All Mail folder.
As Bridge is open source, updates on this issue have always been publicly posted on GitHub. Addressing this issue at the source requires replacing the core IMAP library. Unfortunately, there are no FOSS IMAP libraries that are sufficiently well maintained. Therefore, the solution is to build our own IMAP library called Gluon, which we have been focusing on since this issue was reported to us. You can follow the progress of this open-source project here: https://github.com/ProtonMail/gluon
We are not refusing to fix the problem. The only possible solution is writing a new open-source IMAP library which we can maintain ourselves to ensure this class of errors cannot occur again. We have doubled the size of the team working on this this year so it is a priority for us.
We’re confident that this addresses the main sources of desynchronization and will be available in the beta version of Bridge by the end of the year.
UI refresh, SSO/persistent sessions, and because this crowd might care, the whole app was rewritten from scratch to transition from Angular v1 to React, which simply had to be done and retired an enormous amount of technical debt.
We are aware of the the issues brought up in [0] and [1]. As suggested in [2], we are already considering to switch to an implementation in WebAssembly to mitigate the possibility of timing attacks on the web platform.
In our mobile and desktop apps, where timing attack resistance is easier to achieve, the X25519 implementation is already constant-time.
Once they are generated, keys are controlled by our users and not easily updated, so we wanted to make our choice of default curve as future-proof as we could while balancing speed and interoperability.
It's not a small use case for corporate users where the internal mail is all encrypted. We also have full PGP support and the bridge is fully integrated with this, so we hope the garden aspect will decrease with time, though we expect PGP volume to remain small. You are also heavily discounting the overhead of having users manage their own keys locally in your preferred solution.
We (ProtonMail) don't provide a server-side IMAP/SMTP interface because we don't want to see your cleartext mail. And if you are doing the encryption and key management yourself locally, then you can literally use any email provider you want. The Bridge sidesteps this issue by exposing a local IMAP/SMTP interface and handling the encryption/decryption locally, but there are very good reasons we built it the way we did.
1. ProtonMail implements the OpenPGP standard and is fully interoperable with other OpenPGP email systems.
2. The web app is a single page application so it does not reload on every request.
That said, you are correct that the web app is not appropriate when the threat model includes ProtonMail itself (though you can run the web app locally and thus sidestep the problem). The native clients are better suited in that case.
I also think exploiting it would be extremely difficult. IIRC, it was NIST ECC curves which are hard to make constant time and do not have WebCrypto primitives. We are still going to see what we can do to address this.
You are confusing crypto primitives with a high-level spec like OpenPGP. OpenPGPjs used WebCrypto and node crypto libraries when available for primitives. You still need a library for the OpenPGP stuff.