bartbutler

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.

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.