Moving away from the cloud Part IV - JabberSat 06 July 2013 by Javex
This is the fourth part of the series of how to pull your data out of the cloud. You can find the introduction together with a list of currently published articles here.
Well, it has been some time since my last post since I was kind of involved with work and university. However, now I am back and today I present to you another part in taking back control: Jabber, or generally speaking, instant messaging communication.
A lot of this article doesn't focus so much on the own server part and more on the general idea of moving to a better, open protocol: XMPP. But let's start from the beginning:
Several years ago, I decided to try out jabber. Back then, I used the CCC Jabber Server just to get a feel for the protocol. One of the major reasons to even think about switching back then was the availability of ICQ transports. Since I was using ICQ for a large part of my communication back then, I needed that functionality. But once I imported my ICQ contacts, everyone was back to numbers instead of names. The manual naming would have been horrible.
Fast forwards several years: Now only very few people I communicate with use ICQ. So the previous issue should not exist anymore. Furthermore, I now run my own server, so I could just as well run my own Jabber service. So let's try to get started:
Deciding upon a server was not easy. And the long list at xmpp.org made things even harder besides being an awesome resource. Who has the time to test each and every server on that list?
So to narrow my choices I first defined my requirements for a server: I want it to be open source, easy to configure, secure and have good documentation. An additional bonus is to have some extensions (transports, file proxies, etc.). Furthermore, I am on ArchLinux and it would be a big bonus if it was in the official repositories. So I checked the ArchWiki on XMPP to see what was available.
There, three servers are presented:
ejabberd is in the official repository and will thus receive automatic updates. It's under GPL2 so it also fulfills the open source requirement. However, it is not easy to configure: I had an issue with the second command I issued, that is creating an admin account. After googling did not turn up anything on this issue and the documentation didn't help either, I just gave up and moved on.
So I cannot really say if ejabberd would have been good for me of if it would have fulfilled my requirements afterwards. I just left and looked at the remaining alternatives. First I wanted to try jabberd2, but that is only in AUR and so I looked at Prosody.
Prosody is amazing. It is configured (and written) in LUA and as such I can apply my skills from configuring awesome and understand directly how it works. Furthermore it is really easy to set up: I issued some commands, created a self-signed certificates and it just worked with the help of the default documentation. I then fine-tuned it so it fits my needs and there it is: The server requires users to have ssl and also supports server-to-server encryption (though I already blacklisted gmail.com because apparently they don't support s2s encryption).
With the server set up, let's turn to the client. As noted in the introduction, this isn't purely about making the server. It still fits the scope of the articles since here my goal is to get away from ICQ and Skype.
Again, first we need to know what we search. I need clients for Linux and Android where the latter will only be used on rare occasions. So let's focus on Linux. There are a lot of possbilities here. I decided to go into the direction of GUI based applications because I like a basic form of eye-candy.
First of all, I already have Pidgin installed, so obviously this is my first go. Login works and I can send messages to my Google Talk account so everything seems fine. However, once I try audio/video the limits of Pidgin become apparent: Due to its nature as a multi-protocol IM client, it is not focussed on audio & video, especially with Jabber. Thus, let's look for other opportunities.
Since we search a native Jabber client (to avoid the problems above) the ArchWiki can help again with a small list of Jabber clients. From there, I just open up every GUI client and look at documentation, their homepage and especially screenshots: It shouldn't be too ugly.
Furthermore, the German Wikipedia has a good overview on XMPP clients that is superior to the English version. The matrix gives a good overview of the clients capabilities and helps narrow the search.
I will make it short: The screenshots and their homepage repel me. I don't want to hate my IM client every time I look at it.
Psi looks okay and the homepage is clear and detailed about available features. However, one point I haven't mentioned so for (and that will be detailed at the end of the article) is that I want OTR support.
And the German Wiki lists that as unofficial. I sense problems and so I decide to switch to another client (even though Psi might actually be pretty cool).
At the first look of Psi+'s Wiki you get hit by a mix of russian and english. Even though everything is translated on the first page, my experience so far with software that is not documented primarly in english is that at some point you come across problems and only find search results in a foreign language. I want to avoid that and so I skip Psi+ as well.
I hit their page and am already lost. No thank you.
Another application I came across was Jitsi. It is written in Java and seems to have been developed with video and audio in mind. That is not very surprising if you look at their history: The software started out as a SIP client called SIP Communicator. So that seems to be a big plus: One of the major advantages of Skype is the ease of voice & video communication and if Jitsi aims to be some kind of "open-source Skype" then it may be the right thing for me.
However, I quickly hit the first roadbump: Compilation from AUR fails with over 600 warnings and one error that I cannot find anything on. Compiling on my laptop works perfectly. This is kind of confusing as it is almost identical to my desktop system. Probably a missing package or library or something. I install Jitsi on the laptop and also transfer the package over to my desktop system where installation and startup now work fine.
However, their beautiful homepage and screenshots promise more than you get on Linux: The UI is typical Java-ugly and is also somewhat buggy (this is not their fault but it's kind of hard for me to use if you cannot click the menus etc.). This may be related to my awesome WM.
Furthermore, while supporting OTR, I did not find any options on choosing the authentication method and was stuck with having to type fingerprints (which additionally are case-sensitive! Come on guys, a lower case hex 0xd is the same thing as an upper case 0xD).
While being kind of promising, I still turn it of and turn to my last option:
The reason I looked at Gajim last is really stupid: I seem to have mixed it with Digsby which had some issues some years ago which are partly explained in this German Blog. I download Gajim and am amazed: It is easy to configure and it is written in Python!
On using it, I come a across a few bugs (like at one point not being able to click anywhere). This is very annoying but since it is Python, maybe I can fix some of those issues?
Also, while only having an OTR plugin, this seems to be native and can be installed directly from their repsoitory without much of a hassle. Great job guys! It supports all methods of authentication that Pidgin does and so it wins here to.
Furthermore, voice communication is easy to use (though kind of hacky to set up) and I guess video will be easy as well (didn't try that yet).
Gajim is a full Jabber-only client and can only use other protocols through transports. That's fine with me. Should I really want ICQ here, I will just install the transport and it's done.
I will make this brief: I chose Xabber because it is open source, supports everything I need and is very easy to use. It is my client of choice here.
OTR is an awesome cryptographic protocol for having secure end-to-end communication. The reason for that is that it is tailored specifically to the needs of spontaneous communication that should only be valid for the duration of the conversation. This means that it encrypts the communication, authenticates the chat partner during the communication but also allows modification after the conversation to achieve deniability. Lastly, it offers perfect forward secrecy as a bonus.
From the clients above, all could have done OTR and some natively (or almost natively). From the available clients I would say Pidgin has the best implementation, mostly because here it is the most visible if OTR is not (or partially) active. Gajim only puts a small question mark on the shield if the session is not authenticated - I would want a bigger warning when the session is not fully secured.
This time it was not so much about building something on the server - that is actually easy & quick but more about switching to a new infrastructure that achieves more privacy and security and gives us back some more control.
It should be fairly obvious that this can be seen in the light of PRISM and Tempora and the fact that we all have to realize that our communication is not private if we do not rely on end-to-end encryption & authentication. It does not matter if we trust the server or a government or whatever. The only way to keep your communication between you and your partner is by ensuring that you are the only people on this planet that have the cryptographic keys to it.
And finally, I have a small note: Currently my contact list is empty and I will have to inform my contacts that I switched to jabber. Many of them can then give me their Jabber names as they already are on Jabber. Some might switch because of me. And some might get lost. For ICQ I might install a transport to keep the communication alive. But for Skype you are now out of luck: Once the transition is over, I will not be available via Skype for you (except maybe if I turn it on just for a quick phone call).