Why CoyIM was created - Too Many Features in Other Applications

Feb 11, 2022

We are very close to release version 0.4 of CoyIM. In fact, at the time of writing this article, we are scheduled to release this version two weeks from now. And as we have detailed in many different articles, the release contains a huge number of improvements, new features and fixes. And while we are extremely proud of all this work, it is also important to look back at the origins of CoyIM to understand why it exists and why we have made some unconventional choices, both in this release and in previous versions. Specifically, we are very proud of all these improvements and new features. But we are also very proud of the features we have not added.

That might sound weird. The general paradigm out there is that you measure your worth based on the amount of features you have. And if that is your measure, CoyIM will absolutely disappoint. If you compare CoyIM to other similar applications, basically all of them have a huge number of features that CoyIM lacks. As a small example, when considering how to add file and directory transfer for this release, we wanted to evaluate the options in order to minimize the amount of features we added. To implement it we decided to use a part of XMPP called Stream Inititation. And if you have read the article describing what’s new in CoyIM with a focus on file transfer, you might remember that we could have added file transfer in two ways - either using Stream Initiation, or using something called Jingle. Most other applications would likely have chosen to implement Jingle, since that is the newer standard. And in fact, most XMPP applications out there do implement Jingle. They also implement Stream Initiation. Because why not? Better to have both implemented, right? Well. We as the developers of CoyIM believe this is the wrong way of thinking. And more specifically, it is a problematic approach when dealing with high security situations. So, in this case, we chose to implement the older standard and not the newer standard. The logic was quite simple. The older standard is smaller, and easier to implement in a consice way that doesn’t add a lot of complexity. The Jingle standard contains many more moving elements, meaning that the implementation would have been larger - and the attack surface would have increased as well. So when choosing between the two, the older standard came with a lower risk for our users. And implementing both of them would have meant even more complexity, for no real benefit to our users. The more code, the more risk. The more complexity, the more risk. And the more things that can interact in different ways, the larger the attack surface.

As we described in the post about how CoyIM came about, one of the main alternatives for secure messaging at that time was Pidgin. But one of the reasons we felt quite uncomfortable with Pidgin was exactly that it contained a large amount of functionality. In fact, Pidgin supports many different communication protocols, not just XMPP. It supports a huge range of standards. It supports all kinds of media types, including emojis. In fact, it is so complicated that it has a complete plugin system which allows users to install custom functionality of various kinds. Now, complexity is not only about each individual piece of functionality but also about how they can interact with each other. It’s the combinatorial explosion that leads to a huge increase in attack surface. And the way Pidgin is built leads to exactly this.

In CoyIM, we decided early that we would only implement whatever was absolutely necessary. This means that the basic communication is done only in text. We don’t support more fancy communication methods. We don’t allow users to highlight text or change the font or anything along those lines. And we only support XMPP as a communication protocol and OTR as an end-to-end encryption protocol. This is to minimize the risk of combinations leading to unexpected interactions and more possibilities of attack. This is why we do not want to add other encryption protocols - since that would mean a multiplication of interactions.

In the same manner, we do not implement all the different extensions to XMPP that are available. In some cases, we decided against them because they reveal information about the user. In other cases, we felt that implementing them was not worth it, compared to the extra functionality for the user. We also do not support plugins for extra functionality. Of course, all of these things have value for the user, but they also bring complexity, making it less likely that we can protect you well. This is incidentally related to our decision to make CoyIM a completely separate application using GTK for drawing the windows. These days, most applications of this type are done using different kinds of web technology. Sometimes, they run directly in the browser, and sometimes they make their own windows but under the covers still use the browser. But a browser comes with a huge amount of functionality, and an attack surface that is hard to control. For this reason, we made the choice to not use this kind of technology for CoyIM, in an effort to try to reduce and manage the risk for our users.

In summary. CoyIM will never have some features that you might find in other chat applications. CoyIM might not look as fancy as some others. We will not support sending emojis or inlines images. We will never support other communication protocols. Fundamentally, this is done to reduce the complexity of the application and minimize the attack surface. CoyIM v0.4 has many improvements, but that’s nothing compared to everything we decided not to do. We will continue making decisions this way - we believe it’s the only responsible way to manage a security-focused application.