The rocky road to OMEMO by default

Why it took us more than two years to enable End-to-End encryption by default: The first in a series of essays leading up to the release of Conversations 2.0

When Andreas Straub first introduced OMEMO into Conversations he was trying to make it work with existing server infrastructure by utilizing a general purpose storage mechanism called PEP to store the public key material. PEP, at that point, was primarily being used to distribute the user’s avatar. At least on paper it was also capable of storing group chat bookmarks and all kind of other information. By default only the contacts of a user are allowed to access the information stored in PEP. This default is perfectly reasonable for avatars and still gets you a long way when trying to use OMEMO - After all, most of the time you will be chatting with your contacts. Most of the time, but not always… There are two primary exceptions to that rule: Group chats, and the first few messages you exchange before adding each other to your contact lists. This was a big hurdle we had to overcome before being able to make OMEMO default for all outgoing messages. Unfortunately, efficiently changing the access model of a PEP node was, despite being standardized, not implemented in any of the major servers. Ejabberd, one of the major XMPP servers, got support for that in its 17.12 release. Prosody, another widely used XMPP server, is still working on that feature, but has a module called omemo_all_access that essentially disables access control for all OMEMO nodes and thus achieves the same effect.