The 0.4 release of CoyIM is just around the corner. As you might have seen in other posts, this release will come with a lot of important improvements. And as we are talking about all these changes, we decided that it’s important to tell the story of why CoyIM was created. We didn’t just sit down and think that another messenger would be good. There were specific reasons which made us feel like this was a hole in the ecosystem. In this and following articles, we would like to detail some of these reasons for you.
For us, the triggering factor really came from two different perspectives. The first one relates to training non-technical people to use better operational security practices. The second comes from an observation about what some people in the high-security community was using. At the time, the STRIKE team (one of the precursor groups to CAD) had just been formed, and these two factors lead to the decision to create several different components that would eventually pave the way for CoyIM.
So let’s get back to these two triggers. At the time, and during several years before, members of the team had regularly been going around the world, meeting with people at risk and helping them in various ways. Most often this help took the form of practical workshops, looking at various things these people could do to improve their operational security immediately. Among the most important aspects was to strengthen their communication practices. Teaching them how to use XMPP and OTR was the main method for this. The main idea is that XMPP accounts are easy to get, you can distribute the accounts to many different servers, it’s a normal protocol used by millions around the world for various purposes, so it doesn’t look weird to network attackers. At the same time, OTR have some security properties that make it significantly better than encrypted email, for example. Most importantly, it rotates keys regularly, making sure that even if keys are compromised at some point, that can’t be used to decrypt previous messages - and neither to decrypt future messages, unless the attack continues. At the same time, OTR provides deniability, which means that for people in the most risky situations, even a conversation partner can’t prove that someone else said something. For certain kinds of situations, this kind of prudent approach to security is necessary. Having a one-stop solution for this using OTR and XMPP was extremely powerful. On top of all this, we used to add Tor to the mix, making sure that attackers couldn’t trace communication back to real IP addresses. If you combined these basics with some advice on compartmentalization and how to generate anononymous XMPP accounts, you could get a situation where even non-technical people could communicate in an extremely secure way. And since most people needing advice were non-technical, this was extremely important. Of course, the fact that this setup was natively supported by Tails made it even easier to show how to manage secure communications.
But the second part of this story is a bit more sad. Specifically, in order to teach this basic combination of protocols, we had to use an existing XMPP client with support for OTR. Because of the landscape at the time, most of the time this ended up being Pidgin - especially since Tails used Pidgin to start with. But this means that for teaching people how to use this correctly, there were a number of steps they would have to take. First, they would have to install Pidgin. They would have to install Tor. They would have to configure Pidgin to use Tor. Then they would have to install the OTR plugin. Then they would have to configure the OTR plugin correctly. And then there were a bunch more smaller things they would have to configure to improve the security of their situation - for example, if they had more than one account configured, they would have to remember to set the SOCKS5 username and password for Tor to something random, in order to force different Tor circuits for each account. They would have to remember to put something random looking in the resource part. And then, if their server used onion services, they would have to remember how to configure this correctly. And of course, the people they talked to would have to do the same.
At the end of this whole process, they would have a reasonably secure way of communicating. If you assume that Pidgin, the OTR plugin and the OTR library were bug-free. Since these components were all written in C, almost any kind of bug could potentially be used to exploit and attack the application remotely. And since Pidgin is a very large application, with support for many different protocols and lots of different types of complexity, there were many possibilities for these kinds of bugs. In general, the amount of bugs in an application is proportional to the lines of code it has. And with something written in C, this can be catastrophic. Pidgin regularly had security critical bugs reported during this time frame. All of us working in this field of giving security advice were looking for alternatives that would be better. But for several reasons, this Pidgin setup was still considered the most secure alternative at the time. So we were stuck, promoting and teaching it, even though we knew the potential risks with it.
During this same time period, several people in the high security community started using a different solution. This was
based on an application called xmpp-client. It was written in Golang, a memory safe language, and contained its own
implementation of OTR. The really good part of this program was that OTR was embedded directly into the application, and
the source code was minimal enough that it was easy to review it and understand everything it was doing. And since it was
written in a safer language, the risk of bugs were lower - even if bugs existed, they were less likely to lead to
catastrophic security outcomes. However, there was one big negative to this application. It was a command line
application that you communicated to using text commands. No windows, no graphics. Only text. For technically minded
people this can often be a nice experience, but it’s not something we can ever expect most non-technical people to
use. Worse, it required knowledge and discipline to manage securely. Once again, something that works for a small subset
of the population, but not something that can ever expect to have larger uptake. So that’s where we were stuck. Teaching
one suboptimal solution to the people we wanted to help, while using another solution for ourselves, since we didn’t
expect to ever be able to distribute it widely.
This is where things stood when the STRIKE team was formed in Quito, Ecuador. And for this exact reason, one of the
first project this team decided to work on was to create a complete implementation of OTR for the Golang programming
language. The OTR implementation used in xmpp-client was good, but it lacked several important features. Most
importantly, support for version 3 of the OTR protocol. So the team decided to add support for all the version 3
features. But it soon became apparent that it was better to simply rewrite the library while taking inspiration from the
xmpp-client implementation. This also allowed us to test the implementation from the ground up, ensuring that every
single piece of it worked as we expected it to work.
A few iterations later, the team took on the task of adding a graphical user interface to xmpp-client. To begin with,
it retained a lot of the basic code from xmpp-client. But with the graphical user interface, support for multiple
accounts and integrating the new OTR library, we had enough functionality to release it as its own product, called
CoyIM. Since then, a lot of functionality has been added. The code has been refactored many times and cleaned up in the
process. These days, very little remains of xmpp-client inside CoyIM, except for the historical perspective.
In the next few posts we will describe some of the most important reasons why we felt that it was necessary to create a new application instead of working with an existing one. The three most important ones are the programming language, security by default, and minimizing features.
We are very proud of the upcoming 0.4 release. It continues the path that started long ago described in this post. We believe it is by far the most important release of CoyIM yet. Continue reading about why CoyIM exists, and then try it out!