Threema, Textsecure or Telegram are just a few new so called WhatsApp competitor nowadays. But before we go out and look for alternatives, we must understand what’s the problem with WhatsApp and Facebook. And before we consider that, we must understand why Zuckerberg payed 19 billion dollar for WhatsApp. I intentionally do not say that WhatsApp is worth that much money. It’s only that much worth for Facebook. The big deal shows us what really matters in the information age. Surprise, it’s information itself. Facebook itself is free, so where comes all the money? Facebook can afford buying WhatsApp, despite Facebook has not a single paying user. This tells us that information is very important and also very expensive. Important for advertising, marketing research or insurance companies. Or intelligence agencies. Information about us. Companies make billions of dollars by selling information they know about us!

The bad thing about this is, that we only understand why this can be a problem when it’s too late. When knowledge about us is used against us and we suddendly recognize it. Before that, we all agree using our personal information. And that’s bad.

So we note that information is important and we must take care of it.

For example by not giving a single company that much information. But there is more. It’s power. Facebook not only has our personal information, it has the power of more than one billion users. And there is almost no business competition.

So we note that using one centralized service supports monopolism and helps aggregating information.

So far, we’ve learned about the disadvantages of an information collecting centralized service. Now let’s have a look at why WhatsApp has so many users despite there are a lot of alternatives. When we read about apps having the potential to compete with WhatsApp, we always stumble upon the word usability. One of the main reason why WhatsApp is so successful, is because everyone can use it. You do not even have to register (explicitly). Registering is done almost instantly and implicitly

So we note that providing a real alternative to people, we must make the barrier of using our product very, very low by optimizing its usability. Features like group-chats or the ability to send multimedia files would increase the acceptance too. Platform support is also very important.

Let’s recap that. A chat system should protect our information. This can be done partially by using the right encryption. Partially, because meta data can be very difficult to encrypt. That means, data between two chatters can be strongly encrypted, but it’s hard to encrypt the information about who talks to each other (meta data). If we store the whole meta information collection at a single place (or company), we can hide what we are talking but not when, to who, where, how often and so on. For the latter, we must take a look at network topologies first. All communication in WhatsApp or Facebook end up at one server or server-cluster (see figure 1). A better alternative is using multiple independent servers. A decentralized system (see figure 2).

Figure 1: Centralized network topology.

Here, each server can be owned by another person or company. Communication is still possible between them because the Internet is designed that way. Think about email for example. Here we have the freedom of choice which provider we want to use. On top of that, we could use TOR (a network for the anonymization of connection data) to disguise even more of our meta data.

Figure 2: Decentralized network topology.

Another network topology we consider is the peer-to-peer architecture (see figure 3). Skype used to have this before Microsoft took it over. But Skype also fails somewhere else. At first, meta data is centralized. Second, it is owned by is a network for the anonymization of connection data one company (Microsoft). Third, it fails on it’s closed source nature. We cannot control or see what’s going on inside the system.
So we note that using an open source decentralized system is good. Also note that this is where most of the recently discussed alternatives fail completely.

Figure 3: Peer-to-peer network topology.

Another problem with closed source is the denial of choice. For example the choice of crypto algorithms. In an open system, we can use any end-to-end encryption we want. And we want that choice because weak encryption is not considerable for us. We also want encryption that guarantees us deniability and perfect forward secrecy. Deniability means that nobody can proof that your conversation actually took place. Perfect forward secrecy means that if someone comes into possession of your password or encryption keys, your conversation cannot be decrypted afterwards. So we note that we need a system that allows us to use our own clients and our own encryption. Let’s summarize this. Our chat system must be decentralized, support any client and any end-to-end encryption,
be easy to use and support all available platforms. To make it short here, it already exists. It’s called XMPP and was developed in 1999.

E-Mail ist alt und kaputt. Es gehört durch modernere Kommunikationsarten ersetzt. Warum? Was erwarten wir von Kommunikation über das Internet?

• Confidentiality, Integrity, Authentication
• Perfect Forward Secrecy (PFS)
• Plausible Deniability (PD)
• Asynchrone und synchrone Kommunikationsmöglichkeit
• Gruppenkommunikation
• Kollaboration
• Multimediale Kommunikation
• Dezentrale Struktur

Wenn wir von Verschlüsselung sprechen, dann ist damit Ende-zu-Ende-Verschlüsselung gemeint und nicht die Verschlüsselung der Transportwege. Das Gleiche gilt für Integrity und Authentication.

Wir können E-Mails verschlüsseln und digital signieren (z. B. durch Verwendung von OpenPGP). Leider kann dann für immer und von jedem bewiesen werden, dass wir diese Nachricht geschrieben haben. Ein weiteres Problem entsteht, wenn einer der Keys in falsche Hände gerät. Dann sind sämtliche bisher für ihn verschlüsselten Daten kompromittiert.

E-Mail ist langsam und immer asynchron. E-Mail-Verkehr kostet unnötig Zeit.[0]

E-Mail ist nicht kollaborativ.

E-Mail-Anhänge ermöglichen zwar die Übertragung multimedialer Inhalte, sind aber unglaublich ineffizient und ressourcenfressend.

Was gibt es also für Alternativen? Wie kann besser kommuniziert werden?

Soziale Netzwerke sind Privacy-Desaster.

Instant Messaging erfüllt die meisten Zwecke. Bei vielen Protokollen ist sowohl asynchrone als auch synchrone Kommunikation möglich. Confidentiality, Integrity, Authentication, Perfect Forward Secrecy und Plausible Deniability wird durch Verwendung von OTR[1] erreicht (allerdings nur bei Kommunikation mit einem Partner). Einige Protokolle erlauben Gruppenkommunikation durch Chaträume oder multimediale Kommunikation, wie das Übertragen von Dateien oder Video-/Audio-Telefonie.

Warum reichen bestehende Instant-Messaging-Systeme nicht aus? Was fehlt uns?

• Unterhaltungen in Echtzeit
• Flexibles Hinzufügen von Teilnehmern zur Gruppenkommunikation
• Verbessertes Sharing und Darstellung von Multimediainhalten
• Verschlüsselte, möglicherweise asynchrone, Gruppenkommunikation
  (mit PD und PFS)

Die ersten drei Punkte kann Googles Wave[2,3]. Das Problem der verschlüsselten Gruppenkommunikation mit den beschriebenen Bedingungen ist leider darin bisher nicht gelöst worden. Zudem existieren keine zufriedenstellenden Clients für Wave.

Wir wollen, dass die Infrastruktur nicht von einem einzigen Knotenpunkt abhängig ist. Dezentrale Struktur wird von den Protokollen, die E-Mail bzw. Wave zugrunde liegen, unterstützt. Fast alle IM-Dienste erlauben diese nicht.

Die Lösung

Wir sehen mehrere Lösungsansätze.

Komplett neues Protokoll mit Implementierung und Infrastruktur

Auch bekannt als: „Das Rad neu erfinden“. Machen wir nicht. Das Rad gibt es schon. Dieser Ansatz wäre sehr aufwändig und würde sich schwer etablieren.

Verwendung bestehender Protokolle

Bedingung ist, dass das Protokoll offen und leicht erweiterbar ist. Hier halten wir nur XMPP für sinnvoll. Der Vorteil dieser Lösung ist, dass genau die gewünschten Features implementiert werden können und keine Kompromisse notwendig sind. Voraussichtlich wird bereits bestehende Infrastruktur verwendet werden können.

Erweiterung von Wave

Wave hat bereits die meisten Features, welche wir uns wünschen. Verschlüsselung fehlt aber und es existieren keine guten Clients.

Der Plan

Wir evaluieren die letzten beiden Lösungsansätze und implementieren dann die sinnvollste Lösung. Dazu müssen wir zunächst XMPP und das Google Wave Federation Protocol verstehen.

Auf jeden Fall werden wir einen Client schreiben, der im Vergleich zu bestehenden Clients besser bedienbar ist und unsere beschriebenen Anforderungen erfüllt. Für Legacy-Clients ist eine (teilweise) Umsetzung der Features, beispielsweise durch Plugins, denkbar.

Die Unzufriedenheit mit vorhandenen Kommunikationsmöglichkeiten und die Idee diese zu verbessern schlummert schon seit einiger Zeit in uns. Hiermit möchten wir die Sache ins Rollen bringen. Stay tuned!

–nico, phil, matou

[0] http://www.heise.de/newsticker/meldung/Unternehmen-will-Mitarbeitern-die-E-Mail-abgewoehnen-1184596.html
[1] http://www.cypherpunks.ca/otr/
[2] http://wave.google.com/
[3] http://www.waveprotocol.org/

Neulich hatten wir während eines solchen Chats die Idee, dass wir doch unseren WG-Server am Chat teilnehmen lassen könnten, damit dieser uns z.B. mit Zitaten aus Fernsehsendungen unterhält oder wir über ihn die Musik in der Wohnung steuern können. Seit wir begonnen haben den ersten MUC-Bot zu implementieren, kommen immer wieder neue Ideen auf, was ein Bot so alles tun könnte. Zum Beispiel als Wörterbuch fungieren oder Kochrezepte fürs Abendessen vorschlagen.

Damit grundlegende Funktionalität nicht für jeden Bot neu geschrieben werden muss, habe ich begonnen ein kleines Framework zu entwickeln, dass sich um den XMPP-Teil des Bots kümmert und häufig benötigte Funktionen realisiert. Das Framework ist in python geschrieben.

Im Folgenden beschreibe ich die Mucbot-Klasse, die einen einfachen Bot darstellt. Um den Eintrag übersichtlich zu halten lasse ich einige Dinge weg, die nicht wesentlich sind. Daher wird der hier gepostete Code nicht lauffähig sein. Für die komplette Version schaut einfach auf github vorbei.

# Der Bot verwendet xmpppy (<http://xmpppy.sourceforge.net/>) um mit einem 
# Jabber-Server zu kommunizieren.
import xmpp

# Wir brauchen Regular Expressions um in empfangenen Nachrichten nach Keywords 
# zu suchen, auf die reagiert werden soll.
import re

# Das time Modul wird verwendet um Verzögerungen einzubauen. Z.B. falls der Bot
# nach einer bestimmten Zeit etwas sagen soll.
import time

# Der Bot erbt von Thread. Er kann also im Hintergrund gestartet werden, während
# das Programm noch etwas anderes tut.
from threading import Thread

class Mucbot(Thread):

# Es ist einiges an Initialisierung notwendig. Der Bot braucht eine Jabber-ID und
# ein dazu gehörendes Passwort, um sich damit am Server anmelden zu können. Da
# es ja ein MUC-Bot ist, braucht er außerdem einen Raum, dem er sich anschließen
# wird. Optional kann man ihm noch einen Namen geben, eine Liste von Zitaten,
# die er gelegentlich zitiert und ein Dictionary mit Keywords auf die er
# reagieren soll mit dazugehörenden Reaktionen. Die Keywords sind dabei als
# Reguläre Ausdrücke gegeben.
    def __init__(self, jid, pwd, room, botname='', roompwd='', quotes=[],
            minwait=-1, maxwait=-1, reactions={}, delay=3):

        # Kein expliziter Botname? -> Verwende die Node der Jabber-ID
        if botname == '':
            botname = jid.getNode()

        # […]
        # hier werden alle übergebenen Parameter in der Mucbot-Instanz
        # gespeichert, um diese später noch verwenden zu können

        # Um Nachrichten schnell nach Schlüsselwörtern durchsuchen zu können
        # werden alle Regulären Ausdrücke compiliert.
        for key in self.reactions.keys():
            self.reactions[re.compile(key)] = self.reactions.pop(key)

        # Jetzt kommt die Verbindung zum Server. Zuerst erstellen wir ein
        # xmpp.Client Objekt und verbinden uns mit dem angegebenen Server.
        self.client = xmpp.Client(jid.getDomain(), debug=[])
        self.client.connect()

        # Um auf ankommende Nachrichten reagieren zu können, müssen wir 
        # entsprechende Handler registrieren.
        self.client.RegisterHandler('message', self.msg_rcv)
        self.client.RegisterHandler('presence', self.pres_rcv)

        # Die Authentifizierung am Server:
        self.client.auth(jid.getNode(), pwd, resource=jid.getResource())

        # Und schlussendlich das Betreten des Raums:
        p = xmpp.Presence(to='%s/%s' % (room, botname))
        p.setTag('x', namespace=xmpp.NS_MUC).setTagData('password', roompwd)
        p.getTag('x').addChild('history', {'maxchars':'0', 'maxstanzas':'0'})
        self.client.send(p)

# Möchte der Bot etwas sagen, wird vom xmpp-Modul die xmpp Stanza zusammengebaut
# und an den Chatraum gesendet. 
    def say(self, msg):
        m = xmpp.Message(to=self.room, body=msg, typ='groupchat')
        self.client.send(m)

# Wenn der Bot eine Nachricht empfängt, wird folgende Methode aufgerufen:
    def msg_rcv(self, sess, msg):

        # Wir ignorieren Nachrichten, die wir selbst verschickt haben.
        sender = str(msg.getFrom())
        if len(sender.split('/')) > 1:
            sender = sender.split('/')[1]
        if sender.lower().find(self.botname) >= 0:
            return

        self.react(msg.getBody())

# In der folgenden Methode wird für jedes Keyword, dass wir gespeichert haben 
# geschaut, ob dieses in der empfangenen Nachricht gefunden werden kann. Falls 
# ja, antwortet der Bot mit einer zufällig ausgewählten Antwort aus der Menge
# aller passenden Antworten.
    def react(self, msg):
        time.sleep(self.delay)
        for pattern in self.reactions.keys():
            print "trying to find %s in %s" % (pattern, msg)
            if pattern.search(msg):
                self.say(self.reactions[pattern]
                        [randint(0,len(self.reactions[pattern])-1)])
                return

# Die folgende Endlosschleife wird aufgerufen, wenn der Bot im Chat bleiben und
# auf ankommende Nachrichten warten soll.
    def processing(self):
        while True:
            self.client.Process(1)

# Wenn der Bot gestartet wird, beginnt er mit dem Warten auf Nachrichten. Falls
# er bei der Initialisierung eine Liste von Zitaten übergeben bekommen hat,
# zitiert er aus dieser Liste in zufälligen Abständen zufällige Zitate.
    def run(self):
        processor = Thread()
        processor.run = self.processing
        processor.start()
        if self.minwait==-1 or self.maxwait==-1:
            return
        while True:
            r = randint(self.minwait, self.maxwait)
            time.sleep(r)
            self.say(self.quotes[randint(0,len(self.quotes)-1)])

Das mucbot-Projekt ist frei auf github verfügbar. Es steht unter einer GNU General Public License. Eigentlich bin ich eher ein Fan von BSD und ähnlichen Lizenzen, aber die Verwendung von xmpppy macht dies notwendig.

Vielleicht kann ja der eine oder andere Teile des Mucbots verwenden oder findet hier Anregungen für neue Projekte. Ich grüße mit diesem meinem ersten Blogeintrag alle Leser von IOException.de und freue mich schon darauf bald weitere spannende Dinge mit der Welt zu teilen.