Herzlich willkommen zu meinem Talk, den ich mal ganz optimistisch beenden, wie den Krieg der Instant Messenger genannt haben. Erstmal kurz über mich. Ich bin der Entwickler von Conversations am XMPP Client und

ich bin außerdem Mitglied in der XMPP Standards Foundation, was das beides jeweils ist. Werdet ihr im Verlauf des Talks dann erfahren, falls ihr es noch nicht wisst. Mehr Informationen über mich gibt es auf meiner Webseite gult.de, da gibt es dann auch irgendwie Links, aber das werfe ich am Ende des Vortrags auch nochmal auf die Leinwand.

Instant Messenger gibt es ziemlich, ziemlich viele. Wer hier benutzt denn mehr als zwei Instant Messenger im Alltag? Wir benutzen mehr als drei. Irgendjemand von euch benutzt schon XMPP?

Okay, auch schon ein großer Anteil. Ja, normalerweise würde man ja denken, dass Konkurrenz das Geschäft belebt. Und im Falle von Instant Messaging haben wir allerdings keine wirkliche Wahl.

Also wir können uns den Instant Messenger nicht aussuchen nach irgendwie gefällt er mir von der Bedienung her, hat er eine schöne Farbe, wie sieht es da irgendwie mit den Privacy Policies des Herstellers aus, sondern ich werde in der Regel immer durch irgendwelche externen Umstände dazu gezwungen diesen bestimmten Instant Messenger zu benutzen.

Also hätte ich wieder mal von meinem Freundeskreis genau diesen Instant Messenger benutzt. Oder weil wir das auf der Arbeit zum Projektmanagement benutzen. Und dieses Problem ist im Instant Messenger Umfeld ziemlich alleine.

Also das haben wir in keinem anderen Feld, weil zum Beispiel bei Texteditoren habe ich die freie Wahl, was für einen Texteditor ich benutzen kann. Also ich kann irgendwie VI benutzen und mein Kumpel Emacs und wir können trotzdem irgendwie Daten austauschen. Also es funktioniert halt.

Und ja, die meisten dieser Instant Messenger sind halt zentralisierte Dienste. Und ja, auch die Privacy-Probleme, die da mit zum Beispiel WhatsApp oder sowas aufkommen, brauche ich ja eigentlich nicht mehr großartig eingehen. Die waren ja auch jetzt verstärkt in den Mainstream-Medien. Also selbst die haben mir jetzt darüber berichtet, dass sie jetzt auf einmal

Telefonnummern speichern und die irgendwie an Facebook weitergeben und so weiter und so weiter. Und ja, alle diese Dienste speichern ja auch die Metadaten an einem einzigen Ort ab. Auch wenn sie jetzt nicht unbedingt sehen, was ich genau rede, weil die meisten dieser

Dienste mittlerweile dann doch Ende zu Ende verschlüsseln, sehen sie immerhin, mit wem ich rede. Und alleine in der Tatsache daran, dass selbst Facebook und WhatsApp jetzt eine zu Ende Verschlüsselung angemacht haben, sieht man ja, dass sie eigentlich gar nicht daran interessiert sind, was wir reden, sondern mehr mit wem wir reden.

Ein weiteres Problem von zumindest einem Großteil dieser zentralisierten Dienste ist, dass sie mich mehr oder minder dazu zwingen, mich mit einer Telefonnummer da anzumelden oder dass die Telefonnummer auch mein Identifier ist in diesem Netzwerk. Und das mag manchmal in manchen Situationen relativ praktisch sein, weil ich

dann sofort sehe, wer aus meinem Kontaktbuch oder so auch diesen Messenger benutzt. Aber das ist halt definitiv nicht immer erwünscht. Also wenn ich jetzt zum Beispiel irgendwie einen neuen Job annehme, ich möchte nicht unbedingt allen 50 Arbeitskollegen so voll meine private Handynummer geben. Und es ist halt auch einfach nicht praktikabel.

Also ich komme in einen neuen Fußballverein oder sowas. Da sind irgendwie 100 Leute drin oder sowas. Soll ich ihnen jetzt alle meine Telefonnummer geben? Ein weiteres großes Problem ist, dass man diese zentralisierten Dienste mehr oder minder einfach abschalten kann als staatliches Organ oder auch als Firma,

die jetzt nicht will, dass ihre Mitarbeiter während der Arbeitszeit WhatsApp benutzen. Das sieht man zum Beispiel daran, dass irgendwie Brasilien im Rechtsstreit mit WhatsApp lag und dann haben die das einfach mal irgendwie so für drei Tage dichtgemacht.

Und das weiteres großes Problem, was ich persönlich auch sehe, ist, dass diese zentralisierten Dienste oder monopolistische Systeme im Allgemeinen immer recht vergänglich sind. Also wir benutzen heutzutage noch ICQ zum Beispiel.

Und auch der Entwickler von Signal, Moxie Malensbeig, hat auch mal in einem Interview gesagt, dass der Signal gar nicht irgendwie so als eigentlichen Instant-Messenger sieht oder als Instinger mit Zukunft sieht, sondern das eigentlich nur so mehr oder minder als Tech-Demo für die Verschlüsselung sieht. Und dessen Ziel ist, dass diese Verschlüsselung irgendwie in WhatsApp und anderen Diensten eingebaut wird,

was aber dann ja auch wiederum heißt, dass für Signal selber nicht mehr unbedingt irgendwie eine Zukunft gegeben ist. Warum einigen sich eigentlich diese ganzen Dienste, Wire, Signal, WhatsApp nicht einfach auf ein Standard?

Und wenn man sich damit mal so ein bisschen mit beschäftigt, warum die das eigentlich nicht machen, ist, dass sich in den letzten Jahren die Finanzierung von Apps oder Programmen im Allgemeinen oder Software und Dienstleistungen im Internet verändert hat.

Also noch vor einigen Jahren, zum Beispiel bei E-Mail, waren wir bereit für unseren E-Mail-Client Geld auszugeben. Outlook hat Geld gekostet. Es gab relativ viele Shareware-Clients für E-Mail, die Geld gekostet haben, zumindest nach einer Testperiode oder sowas. Und es gab auch E-Mail-Anbieter, die auch Geld gekostet haben. Also gmx und web.de, wenn ihr euch noch erinnert, haben halt früher einfach Geld gekostet.

Oder okay, die hatten kostenlose Demo-Versionen oder sowas, die mit starken Einschränkungen gelebt haben. Aber es waren ansonsten Dienste, für dessen Dienstleistung man halt Geld bezahlt hat. Und ja, mit dem Aufkommen von Apps hat sich das halt gewandelt.

Der Nutzer möchte nicht mehr dafür bezahlen, beziehungsweise zumindest nicht mehr mit normalem Geld, sondern irgendwie, dass er Werbung in Kauf nimmt oder irgendwas anderes. Und so haben diese Dienste halt alle umgestellt auf andere Geschäftsmodelle und versuchen jetzt halt zum einen irgendwie mit Metadaten und mit dem Verkauf von Metadaten oder mit Werbung Geld zu machen.

Beziehungsweise was auch zu beobachten ist, dass diese Dienste nicht direkt Geld tatsächlich mit Werbung machen, sondern mit der Hoffnung eventuell irgendwann mal Geld zu machen, Investoren anlocken. Und diese Investoren sind natürlich auf eine Sache aus, Wachstum.

Wachstum in jedem Preis. Und Wachstum funktioniert halt am besten, indem man die Leute in ihren Dienst einsperrt und somit halt immer mehr Leute dazu zwingt, diesen Dienst zu benutzen. Ja, wenn es die großen Anbieter nicht wollen, können wir das nicht irgendwie selber machen.

Gibt es da nicht irgendwie einen Standard, den wir benutzen können für das Instant Messaging? Und tatsächlich, den gibt es. Den gibt es auch schon seit 16 Jahren oder sowas. Und der heißt XMPP. XMPP ist ein XML-basiertes Protokoll, das zum einen die Server-zu-Server-Kommunikation

und die Klein-zu-Server-Kommunikation spezifiziert. Es ist ein föderiertes Protokoll, das heißt Nutzer werden nicht irgendwie über nur den Benutzernamen oder nur die Telefonnummer identifiziert, wie das in diesen ganzen zentralisierten Diensten ist,

sondern sie werden über username.at. Domain identifiziert, wie man das von E-Mail her zum Beispiel kennt. Und diese föderalisierte Infrastruktur ist im Grunde ein Kompromiss aus zentralisierten Diensten und Peer-to-Peer-Diensten, wie zum Beispiel der Instant Messenger Talks, die man auch kennt,

wo jeder Client sozusagen selbstberechtigt ist. Der Vorteil von föderalisierten Systemen ist, dass hier der normale Handyclient oder so nicht so viel Last hat oder nicht so viel Arbeit hat, weil der normale Handyclient nur eine Verbindung aufhalten muss zu seinem eigenen Heim-Server

und nicht Dutzende Verbindungen zu den jeweils anderen Peers in diesem Peer-Netzwerk aufbauen muss. Natürlich könnte man föderalisierte Dienste im Extremfalle auch als Art Peer-to-Peer-Netz betreiben, in dem jeder Benutzer wirklich seinen eigenen Server hätte. Man hat sozusagen also die Wahl.

Zum grundsätzlichen Aufbau von XMPP. Das ist wie schon gesagt ein XML-basiertes Protokoll. Das heißt, es wird ein großes XML-Dokument sozusagen, ein großer XML-Strom jeweils zwischen einem Client und einem Server und zwischen den einzelnen Servern ausgetauscht.

In diesem XML sind drei Grundelemente spezifiziert. Messages, IQ und Presences. Messages ist relativ eindeutig, sind normale Nachrichten. IQ steht für Info-Query. Das sind sozusagen Nachrichten oder Pakete, die immer eine definierte Antwort verlangen.

Und Presence sind halt flüchtige Information, Status-Information. Also bin ich online oder bin ich gerade abwesend. Und auf diesen drei Grundpaketen wird der ganze Rest über Erweiterungen definiert. Also wenn ich jetzt zum Beispiel mitteilen möchte, dass ich gerade am tippen bin oder gerade aufgehört habe zu tippen,

dann gibt es eine Erweiterung, die eine Metanachricht verschickt, in der das halt drin steht. Ich habe gerade angefangen zu tippen. Der eigentliche Kern ist ein IETF-Standard. Und die Erweiterungen werden von der XMPP Standards Foundation herausgeschrieben.

Also irgendwie schreiben die nicht selber, sondern sind quasi nur wie ein Verlag das Qualitätskonsortium, was darüber guckt, ob die Erweiterungen formell korrekt sind. Und dann gibt es halt so ein paar Erweiterungen.

Wie ich eben schon sagte, XMPP ist so 16 Jahre alt oder so. Das kommt etwa aus dem Jahr 2000. Und die Anforderungen verändern sich natürlich in 16 Jahren. Also vor 16 Jahren hatten wir halt noch keine Handys in dem Sinne oder keine Smartphones. Und dann kommen halt Erweiterungen dazu, die es zum Beispiel ermöglichen,

dass die Verbindung abgebrochen werden kann und dann hinterher wieder aufgenommen werden kann. Also früher im Desktop-Rechner hat man sich einmal eingebunden und dann konnte eine TCP-Verbindung bestehen bleiben, bis man den Rechner wieder ausgeschaltet hat. Und jetzt auf Handys hat man ja immer diesen Wechsel zwischen irgendwie WLAN oder dem mobilen Netzwerk.

Oder dann ist man mal in einem Tunnel irgendwie für eine Minute oder so was. Und da kommt halt diese Erweiterung Stream Management zum Einsatz, die es erlaubt, dass ein Client sich beim Wiederverbinden nicht nur komplett eine neue Sitzung aufmacht mit dem Server, sondern sagt, hey, ich möchte diese eine Sitzung hier weiterführen. Eine weitere Erweiterung, die jetzt in den letzten paar Jahren relevant geworden ist, ist CSI.

Das steht für Client State Indication. Und damit kann ein Gerät, was batteriebetrieben ist, wie zum Beispiel ein Smartphone, dem Client sagen, hey, ich bin gerade im Hintergrund und die App wird sowieso gerade nicht angezeigt. Und ich muss in diesem Moment jetzt nicht wissen, wer gerade online ist,

weil ich sehe es jetzt, der Nutzer kann jetzt sowieso nicht draufgucken und sieht es nicht. Und dann müssen diese Pakete in diesem Moment nicht geschickt werden. Und das hilft dann natürlich, Batterie zu sparen, weil halt keine aktive Netzwerkverbindung dafür bestehen muss. Vor ein paar Jahren war es auch noch nicht so, dass man zwischen mehreren Geräten Naglos hin und her wechseln wollte,

weil da hatte man halt quasi nur einen Desktop-Rechner und jetzt möchte man von seinem Desktop-Rechner auf sein Handy und zurück wechseln. Da gibt es dann zwei weitere Erweiterungen, Message Carbons und Message Archive Management, die dafür sorgen, dass Nachrichten zwischen mehreren Geräten synchronisiert werden können.

Message Carbons ist dann so ein bisschen das, was live Nachrichten, also wenn zwei Clients wirklich gleichzeitig eingeloggt sind, dann sorgen Message Carbons dafür, dass alle Geräte diese Nachricht erhalten. Oder auch, dass wenn ich von meinem Desktop-Rechner gerade eine Nachricht geschrieben habe, dass die Kopie meiner eigenen Nachricht dann auf dem Handy erscheint.

Und Message Archive Management ist das gleiche dann für historische Daten. Also wenn mein Handy irgendwie zwei Wochen lang ausgeschaltet war, dann verbinde ich mich und dann kriege ich halt den Backlog von den letzten zwei Wochen. Ja, dann gibt es irgendwie noch so mehrere Erweiterungen für Ende-zu-Ende-Verschlüsselung.

Bevor wir darüber reden, nochmal die Erinnerung, dass die Server-zu-Server-Kommunikation und die kleinste Server-Kommunikation grundsätzlich TLS verschlüsselt ist. Wenn ich also meinen eigenen Server benutze und mein Kontakt auch entweder den gleichen Server benutzt

oder auch seinen eigenen Server benutzt, brauche ich noch nicht mal unbedingt Ende-zu-Ende-Verschlüsselung, weil ja wir vertrauen unseren beiden Servern, weil die halt von uns sind und die Kommunikation zum Server ist halt sicher. Wenn man jetzt aber doch irgendwie öffentliche Server benutzt oder zu einem Anbieter geht und das nicht selber hosten möchte oder kann oder so, dann gibt es dann doch Ende-zu-Ende-Verschlüsselung, wie man das auch so kennt.

Und da gibt es dann zum einen etwas, was oben PGP-basiert ist, also die Verschlüsselung, die man auch aus E-Mail kennt, Public-Private-Key-Verschlüsselung und die etwas neuere OMIMO-Verschlüsselung, die so im Kern so ein bisschen darauf aufbaut, was auch Signal benutzt

und Wire und so was benutzen mittlerweile auch den gleichen Algorithmus. Und der Hauptunterschied zwischen diesen beiden Verschlüsselungen ist, dass OMIMO Dinge wie Deniability und Forward Secrecy macht. Das heißt, also Forward Secrecy heißt im Grunde genommen,

wenn eine Nachricht einmal entschlüsselt worden ist, kann sie nicht noch ein weiteres Mal entschlüsselt werden, weil wir das Key-Material dann wegwerfen. Was, wenn irgendwas mal kompromontiert wird oder so was, den Vorteil hat, dass jemand im Nachhinein nicht die Nachrichten entschlüsseln kann, aber ich kann sie halt auch selber nicht wieder entschlüsseln. Das heißt, wenn ich irgendwie mal mein Device resette oder irgendwie sowas,

oder Neues bekomme, komme ich an meine eigenen per OMIMO verschlüsselten Nachrichten nicht wieder ran. Das mag manchmal akzeptabel sein, manchmal nicht. Manche Leute haben halt gerne den Backlog von jahrelanger Kommunikation

und das ist dann halt diese Abwägung. Also braucht man irgendwie, ist man paranoid genug, um diese Forward Secrecy und so weiter zu haben, dann kann man OMIMO benutzen. Möchte man lieber dieses Server-Seitige Archiv haben, kann man halt OpenPGP benutzen.

Beide kommen ohne Probleme halt mit mehreren Geräten klar und stellen auch diese Synchronisationen sicher und sind einigermaßen robust. In der Vergangenheit wurde in der XMPP-Welt auch mal dieses OTR benutzt, was ja Protokoll-Ignostik ist, was man also theoretisch über ICQ oder ISC sprechen könnte oder sowas. Das wurde immer noch so ein kleines bisschen benutzt,

aber es sollte halt zumindest nicht mehr benutzt werden, weil es halt einfach nicht robust genug ist in diesem Umfeld, wo man halt ab und zu mal Verbindungen aufbaut, wieder abbaut und so weiter. Ja, ein Vorwurf, was man irgendwie XMPP im speziellen oder offenen Standards im Allgemeinen immer vorwirft,

ist die Fragmentierung. Also das heißt, dass verschiedene Clients unterschiedliche Erweiterungen implementieren und dann nicht mehr kompatibel miteinander sind. Also wenn halt zum Beispiel vor X Jahren oder sowas eine Erweiterung aufkam,

die das Austauschen von Bildern ermöglicht und ich benutze einen Client, der aus einer Zeit kam, bevor diese Erweiterung eingeführt worden ist, dann klappt das natürlich nicht.

Oder auf der anderen Seite, wenn mein Client zum Beispiel diese Erweiterungen wie Stream Management oder Client State Indication, die ich eben erwähnt habe, die dafür sorgen, dass es auf dem Mobiltelefon auch rund läuft, wenn der Server diese Erweiterungen dann nicht kann, dann kann mein Client die natürlich auch nicht benutzen.

Ja, gegen dieses Client-Problem kann man auch relativ wenig machen. Also wenn Clients irgendwie vor 10 Jahren mal entwickelt worden sind und dann sind die Entwickler verschwunden und da steckt niemand mehr Arbeit rein, dann macht man dagegen auch nichts. Also es sei denn, man setzt sich da selber ran und fixt es,

dann wird sich an dieser Situation auch nichts ändern. Aber man ist ja auch nicht auf einen Client gezwungen. Der Vorteil von diesem Standard ist halt, dass man auch immer auf alternative Clients wechseln kann.

Bei der Server Software sieht das eigentlich ganz in Ordnung aus. Da haben wir den Fall, dass eigentlich alle großen drei Server die meisten Standards mitmachen, aber die Installations-Base da draußen schwankt da teilweise sehr stark.

Da haben wir den Fall, dass irgendein Anbieter sich vor 10 Jahren als XMPP schon mal irgendwie so mehr oder minder populär war in der ICQ-Site, gedacht haben, oh, komm wir richten mal hier diesen XMPP-Server ein und dann haben die da allerdings nichts mehr dran gemacht. Also dann haben die vielleicht noch mit ein bisschen Glück die Sicherheitsupdates

des Betriebssystems eingestellt, aber dann passiert da halt einfach nichts mehr. Und da gibt es halt immer noch so eine relativ breite Basis, wenn man nach XMPP-Servern im Internet guckt, die da einfach relativ alt und unmaintained sind. Also zum Beispiel um ein populäres Beispiel zu nennen, so hat die Search Engine DuckDuckGo irgendwann mal so einen XMPP-Server aufgebaut

und der ist halt einfach furchtbar, also da ist seit 10 Jahren nichts mehr passiert. Aber wenn man jetzt als Endnutzer auf der Suche nach so einem Serveranbieter ist, ist es von außen nicht immer sofort ersichtlich,

welche Server denn jetzt irgendwie gut sind oder welche, die aktuellen Erweiterungen unterstützen. Und vor einem halben Jahr habe ich mal versucht, dieses Problem irgendwie sichtbar zu machen und einen Compliance Tester geschrieben, der sich einfach zu diesen Servern verbindet

und dann einfach mal nachguckt, welche Erweiterungen die denn unterstützen. Und damit habe ich dann zumindest 90 Prozent der großen Anbieter abgetestet und das Ergebnis in eine Tabelle geschrieben.

Die werde ich am Ende des Vortrags dann auch nochmal verlinken. Also wenn ihr auf der Suche nach einem Anbieter seid, schaut vorher definitiv mal in diese Tabelle. Oder wenn ihr schon einen Anbieter habt, redet doch einfach mal mit dem und bittet ihn einfach, diese Erweiterungen anzuschalten. Weil ich habe nämlich die Erfahrung selber gemacht,

dass zumindest ein gewisser Teil dieser Anbieter diese Erweiterungen nicht mutwillig anmachen, sondern halt einfach nichts davon wissen oder so. Ich meine, das kann man den Leuten ja auch nicht verübeln. Die sind ja jetzt nicht so tief in der Materie drin. Das sind diese beiden Optionen, also entweder den Serveranbieter wechseln oder den eigenen Anbieter mal anschreiben.

Client-mäßig sieht es eigentlich ganz in Ordnung aus. Da gibt es für jede Plattform natürlich auch Clients, die ein bisschen veraltet sind, aber auch definitiv Clients, die relativ aktuell sind. Auf Android kann ich meinen eigenen Client Conversations empfehlen.

Auf Windows und Linux geht die aktuelle Empfehlung in Richtung Gadget. Der ist jetzt vielleicht nicht der aller, aller hübscheste, aber er tut wenigstens ganz in Ordnung. Allerdings muss man für manche Features, zum Beispiel damit der Bildversand vernünftig funktioniert

und damit auch Previews intern angezeigt werden und so ein paar Plugins installieren. Das kann man aber alles aus dem Programm heraus selber machen. Also da muss man jetzt nicht auf externe Webseiten gehen oder sowas. Auf iOS sah die Situation lange Zeit nicht so rosig aus,

weil Programme, die über den iTunes-Store vertrieben werden, und das ist ja nun mal ein Großteil der Apps für iOS, denen obliegt eine Limitierung, dass sie keine TCP-Connection im Hintergrund aufhalten können. Und XMPP benötigt halt nun mal eine TCP-Verbindung, weil darüber ja die Nachrichten zugestellt werden.

Und da hat es auf iOS lange Zeit Probleme gegeben, aber das Problem ist mittlerweile auch gelöst. Und im Moment sind die Chat-Secure-Leute fleißig dabei, um MIMO, also diese neue Verschlüsselung, einzubauen. Und falls dann jemand doch iOS benutzt, lohnt sich da definitiv einen Blick.

Zur Server-Auswahl, da muss man natürlich unterscheiden, möchte ich das selber hosten, möchte ich das in meinem Club oder in meinem Verein hosten, oder möchte ich einen öffentlichen Server benutzen. Wenn ich selber hosten möchte, dann gibt es zwei Server, die sich da anbieten,

eJabber, die und Prosidi. Prosidi hat so ein bisschen den Ruf, ein bisschen einfacher zu sein. Da muss man nicht so viel an der Config rumschrauben. Also da läuft mehr oder minder out of the box. Man muss leider ein paar externe Module einschalten, aber das ist jetzt eigentlich kein größerer Akt.

eJabber, die ist ein bisschen weniger zugänglich. Da ist die Config dann doch so ein bisschen länger. Zum Glück haben die vor einiger Zeit von einer sehr merkwürdigen Erlang-Config auf eine Jaml-Config gewechselt, was jetzt zumindest bedeutet, dass da weniger Klammern in der Config sind.

Aber aus meiner Sicht ist eJabber, die so ein bisschen der erwachsenere Client. Also wenn man sich dann doch irgendwie mal, wenn man sowieso Server-Administrator von Beruf ist und sich da mal ein paar Stunden reinfuchsen will und das jetzt nicht sofort laufen will und wenn man den Server nicht unbedingt jetzt für sich selber,

sondern für seinen kompletten Verein oder sowas betreibt, dann lohnt sich definitiv auch nochmal ein Blick in eJabber, die. Von der Performance-Test ist übrigens kein Problem. Es ist einfach nur das eJabber, die so ein bisschen ausgereifter ist. Wenn man sich damit nicht beschäftigen möchte, sondern einen öffentlichen Server benutzen möchte,

lohnt sich definitiv ein Blick in den Compliance-Tester. Das kann ich gleich mal zeigen. Das ist eine Tabelle, wo grün markiert wird, wenn ein Server ein Feature hat und rot markiert wird, wenn ein Server dieses Feature nicht hat.

Und man möchte einfach einen Server benutzen, der relativ viel grün hat. Ich habe diesen Talk bewusst so ein bisschen oberflächlich gehalten, weil komplett in die Details, wie jetzt diese einzelnen Erweiterungen funktionieren, das würde total diesen Rahmen hier sprengen.

Ich habe da allerdings in der Vergangenheit mal Artikel drüber geschrieben, die so ein bisschen detaillierter erzählen, wie diese Erweiterungen funktionieren, wenn man sich dafür aus technischer Sicht interessiert. Das heißt dann die State of Mobile XMPP in 2016, das von meiner Webseite aus verlinkt. Und vor zwei, drei Wochen habe ich für das Online-Magazin Golem

einen Artikel über die OMIMO-Verschlüsselung geschrieben, die auch auf relativ vielen Seiten dann noch mal so ein bisschen detailliert erklärt, wie OMIMO funktioniert, sowohl wie die Kryptopromittiven darunter arbeiten und wie das auf XMPP-Ebene aussieht.

Das ist alles von meiner Webseite aus verlinkt. Ja, gibt es Fragen. Ja, danke Daniel für den Vortrag. Ich gehe jetzt einfach rum mit dem Mikro, sodass immer die Fragen auch für alle verständlich sind.

Eine Frage hätte ich, wann funktioniert ein Dateiversand über verschiedene Clients hinweg? Ja, das ist ja wie gesagt das Problem, wenn Clients sich nicht mehr in der Entwicklung befinden,

dann kann man da halt nichts machen, es sei denn, man macht das selber. Meinst du über verschiedene Clients im Sinne von verschiedenen Herstellern oder auf mehreren Endgeräten? Na, eigentlich verschiedene Hersteller. Das heißt quasi von Conversation to Conversation ist absolut kein Problem. Das funktioniert auch von Pitch-in zu Pitch-in funktioniert.

Aber ich habe halt schon diverse Kombinationen mit Pitch-in, Garge-in, Conversations und einigen anderen ausprobiert und innerhalb eines kleinen Typs funktioniert es einfach frei, aber sobald man versucht von einem Klein auf einen anders gearteten Klein zu versenden, es gibt verschiedene Symptome des Nicht-Funktionierens, aber es hat bis jetzt noch nie eine Datei auf die andere Seite geschafft.

Ja, das sind natürlich Symptome dieser Fragmentierung, die ich eben angesprochen habe. Grundsätzlich sollte es eigentlich zum Beispiel von halbwegs aktuellen Clients, wie zum Beispiel Garge-in auf dem Desktop, deshalb empfehle ich dem auch immer, und Conversations zwischen den beiden sollte es funktionieren.

Und idealerweise dann auch über die Erweiterung namens HTTP-Upload. Da machst du keinen Peer-to-Peer-File Transfer, wie das herkömmlich in der XMPP-Welt so war, wo zwei Clients sich über Firewalls hinaus verständigen und dann die Datei direkt austauschen,

sondern da wird die Datei zuerst zu deinem Server hochgeladen, optional verschlüsselt selbstverständlich, und dann wird quasi nur ein Link ausgetauscht. Und wenn dein Server dieses HTTP-Upload kann, Garge-in kann es auch, Conversations kann es auch, ChatSecure soll es bald können oder Monal auf ein anderer iOS-Client könnte das auch.

Also wenn du da Probleme hast, ich würde mir definitiv mal dieses HTTP-Upload angucken, dann sollte das eigentlich funktionieren. Pidgin ist halt nicht mehr weiterentwickelt, also die machen halt an XMPP nichts mehr. Also da musst du dir ehrlich gesagt keine Hoffnung machen, es sei denn, du baust es selber ein.

Zwei prominentere Beispiele, die mir gerade einfallen, zum einen Google Chat, als es noch lebte, oder Facebook, zu Anfangszeiten waren ja auch XMPP-basiert, der Chat. Und wenn ich mir nicht alles täusche, dann lage ich mich auch noch nicht fest, war Facebook sogar so weit offen, dass ich mit Nutzern von anderen Domänen sprechen konnte. Irgendwann sind die weggegangen davon. Ich vermute, es lag an Gruppenchats, was dann immer so eine herrliche Sache in der XMPP-Welt ist.

Natürlich, ich vermute mal nicht, dass du bei Facebook arbeitest und dann mehr zu weißt, warum die da weggegangen sind und irgendwann ihren eigenen proprietary Kram aufgezogen haben. Aber hast du vielleicht irgendeine Ahnung, was denn die typischen Probleme sind? Warum man irgendwann XMPP nicht mehr machen möchte an der Stelle? Oder vielleicht hätten sie es doch machen sollen und waren einfach zu blöd, zu faul dazu? Ja, lässt sich natürlich nur drüber spekulieren.

Ich habe ja am Anfang meines Vortrages so zumindest die Theorie aufgestellt, oder was meine Meinung so ein bisschen ist, dass es hauptsächlich so ein Monetarisierungsproblem war. Also dass in einem offenen System es schwieriger ist, Einnahmen zu generieren oder Investoren anzulocken.

Ob es da jetzt großartige technische Probleme gab? Eigentlich nicht. Also man hätte XMPP auch einfach weiterentwickeln können. Also selbst wenn man quasi zu diesem Zeitpunkt XMPP benutzt hat und dann sagt, oh, aber das und das fehlt in XMPP, dann baut man sich halt einfach eine Erweiterung dazu. Ich meine zum Beispiel, Google hat das ja tatsächlich sogar gemacht. Also Google hat ja diese Jingle-Erweiterung gemacht, die quasi für die Art der Echtzeitkommunikation,

also zum Beispiel für Voice-Over-AP oder auch für den Dateiversand oder sowas, diese Erweiterung kommt ja ursprünglich von Google. Und auch dieses Klein-State-Indication, was mobile Clients oder batteriebetriebene Clients benutzen,

um halt Strom zu sparen, das kommt ursprünglich auch aus dieser Google-Talk-Welt. Also dazu hat sich ein bisschen im Syntax geändert, aber diese Grundidee von, oh, wir signalisieren im Server, wo wir im Vordergrund oder im Hintergrund sind, kommt von Google. Sie haben es dann halt allerdings nicht der XMPP Standards Foundation zur Standardisierung vorgeschlagen,

sondern weiter ihr eigenes Typchen gekocht. Und ja, warum das ist, darüber kann man wirklich noch spekulieren. Hi. Ich möchte dir zuerst gerne mal danken für deinen konstanten Einsatz für offene Protokolle.

Ich habe eine Frage, die ein bisschen in die Zukunft geht. Ich bin der Meinung, dass das, was Facebook und WhatsApp großgemacht hat, ist die Entdeckung von Kontakten. Facebook löst das dadurch, dass ich von meinen Freunden die Freunde sehen kann und mich mit denen verbinden kann.

Und WhatsApp löst das darüber, dass man seine Handynummern gibt und dass die Kontakte im Telefon durchsucht. Das mag man nicht mögen, wahrscheinlich hier die allerwenigsten, führt aber dazu, dass in meinem Umfeld ungefähr 9,6 von 10 Personen diese beiden Sachen nutzen.

Und kaum jemand jabber, außer meine Nerdfreunde. Deshalb ist meine Frage, gibt es in der XMPP Community Ideen oder hast du Ideen, wie man das einfacher machen kann, diesen Schritt von, ich habe die App auf meinem Handy und ich möchte mich gerne mit meinen Freunden verbinden,

die ich vielleicht schon in anderen sozialen Netzwerken habe oder die ich irgendwie, ich will nicht mit jedem einzelnen reden, hast du Jabber und wie ist dein Kanal? Das ist, glaube ich, super wichtig, um so etwas zu verbreiten. Also ja, ich habe da tatsächlich Ideen zu, das könnte man ja auch appunabhängig machen.

Also das Einzige, was man ja kreieren müsste, wäre ein Mapping von Telefonnummern zu XMPP-Adressen. Das wäre mehr oder weniger der einzige Schritt. Und dann die lokalen Telefonnummern nachgucken, ist ja kein Hexenwerk.

Und das könnte man ja theoretisch auch als eigentlich händige App bauen oder irgendwie sowas, weil die könnte ja quasi einfach nur das Telefonbuch durchsuchen, diese Telefonnummern alle zu einem zentralen Dienst schicken, der dann als Antwort darauf die XMPP-Adresse liefert. Und das könnte ja dann quasi einfach nur z.B. Conversations oder beliebige andere XMPP-Clients

dann launchen sozusagen, dass man dann quasi so den Startbefehl an Conversations mit der dazugehörigen Adresse gibt. Ja, das wäre die Idee. Warum ich mich damit persönlich jetzt noch nicht beschäftigt habe, ist zum einen, dass du die Telefonnummer verifizieren musst.

Also du kannst ja nicht beliebige Leute quasi das zuspammen lassen und sagen hier die Telefonnummer, die und die XMPP-Adresse. Das muss ja quasi verlässlich sein. Du musst die XMPP-Adresse und die Telefonnummer verifizieren. Und eine Telefonnummer in Verifikation kostet halt wirklich hartes Geld. Also ich habe mir das tatsächlich mal angeguckt oder sowas. Ich glaube so das günstigste, was du machen kannst oder sowas,

ist irgendwie so 29 Cent pro SMS oder irgendwie sowas. Und wenn du da was anderes hast, können wir weltweit, können wir später mal reden oder so. Aber das ist das, was mich bisher so ein bisschen davon abgehalten hat. Und bei mir persönlich jetzt auch ein bisschen so mangelndes Interesse, ehrlich gesagt.

Also weil ich dieses Problem in meinem privaten Umfeld nicht habe, weil ob ich jetzt jemanden, den ich neu kennenlerne, frage nach seiner Telefonnummer, die irgendwie eine 10-stellige zufällige Zahl ist oder nach seiner XMPP-Adresse, die ich mir gegebenenfalls noch auswendig merken kann, bin ich da persönlich lieber der, der die XMPP-Adresse nimmt.

Weil ich meine, die sind halt aussprechbar. Ich weiß von fünf meinen Freunden irgendwie die XMPP-Adressen auswendig. Ich weiß von keinem einzigen Freund noch nicht mal von mir selber die Telefonnummer auswendig. Aber ja, also Ideen ja. Persönliches Interesse gerade aus diesen Gründen jetzt nicht so hoch.

Vielen Dank für den Vortrag. Ich habe eine Frage zu Multiprotokoll-Clients. Also das Problem, was angesprochen wurde, ist ja, dass ein Teil des Freundeskreises nicht XMPP nutzt und wahrscheinlich WhatsApp. Und wie stellt man die Brücke her? Also man könnte jetzt eine WhatsApp-App installieren, aber es gibt wohl auch andere Apps. Ich nutze selber eine, allerdings auf Firefox OS,

die mehrere Protokolle unterstützen, unter anderem XMPP. Kennst du noch mehr? Kannst du sowas empfehlen oder kann man da eine Entwicklung in die Richtung empfehlen? Ja, natürlich, also diese Multiprotokoll-Messenger gibt es ja einige von. Also wie du sagst, hier auf Firefox OS oder Pidgin ist der große Vertreter auf dem Desktop,

beziehungsweise Adium, quasi Pidgin für iOS. Oder früher gab es auch dieses Trillion. Ich glaube, die gibt es sogar theoretisch immer noch. Meine persönliche Meinung zu diesen Multiprotokoll-Dingern ist halt, dass sie vieles, aber wenig richtig machen. Also weil XMPP halt schon dann doch so ein bisschen komplexeres Protokoll ist,

mit dem man sich dann doch so ein bisschen beschäftigen muss. Und so Leute, die irgendwie, weiß ich nicht, in ihren Client irgendwie so 10, 20 Protokolle reinstecken, die können sich dann gegebenenfalls nicht immer so auf XMPP konzentrieren, wie man das gerne hätte. Also im Fall von Pidgin sieht man es ja auch, die haben, wie gesagt, seit fünf Jahren oder so nichts mehr an XMPP gemacht.

Also ich will das jetzt absolut nicht verallgemeinern. Es kann zumindest theoretisch total gute Multiprotokoll-Clients geben. Ich kenne halt keinen. Was du allerdings natürlich auch machen könntest, was mal mehr, mal weniger schlecht gibt, es gibt in XMPP dieses Konzept von Transports,

das dein Server quasi zwischen mehreren Netzen vermittelt. Also dass dein Server halt eine Verbindung ins WhatsApp-Netzwerk herstellt oder ins Skype-Netzwerk oder sowas. Also gibt es tatsächlich Ansätze für,

ich persönlich habe damit ehrlich gesagt aufgehört, weil die so ein bisschen dann doch so ein bisschen zu buggy waren, aber zumindest aus technischer Sicht geht das, ja. Ja, vielleicht noch eine Frage. Ich denke, vielleicht ist noch ein missing feature dieses Konzept,

dass ich auch irgendwie telefonieren oder Videotelefonie machen kann oder sowas. Soweit ich weiß, ist Jitsi da die einzige Anwendung, die das halbwegs vernünftig über XMPP hinkriegt, also über diese Jingle-Erweiterung und so weiter. Du hast glaube ich irgendwann mal geschrieben, du findest das zumindest interessant und hast dich vielleicht da mal mit beschäftigt.

Ist sowas vielleicht irgendwie in der langen Zukunft mal interessant für Conversations oder sagst du prinzipiell, das ist nicht in deinem Scope irgendwie oder? Ja, also du weißt es wahrscheinlich, aber nur für alle nochmal. Also es gibt eine XMPP-Erweiterung für Video- und Sprachtelefonie. Also das ist halt nur, es gibt diesen Standard dafür.

Also XMPP kann das an sich, es sind halt nur die Kleinst, die es gegebenenfalls nicht immer unterstützen. Jetzt war da eine Frage, ob Conversations das mal können wird. Es ist unheimlich viel Aufwand. Ich finde es aus einer technischen Sicht spannend, wie man da quasi auch durch die Firewalls durchbricht

beziehungsweise wie man halt irgendwie die richtigen Proxys zur richtigen Zeit benutzt und sowas. Aber ich sehe jetzt nicht, dass ich irgendwie in näherer Zukunft die Zeit dafür finde. Also sei denn es gibt auch irgendwie, also Conversations wird ja auch teilweise von Firmen oder von Securityfirmen benutzt oder sowas,

die das halt auf ihren Android-Telefon oder sowas einsetzen wollen und von denen haben ein paar Leute gesagt, dass sie potenziell gerne mal Voice-over-IP hätten. Und wenn die das quasi bezahlen, dann würde es natürlich auch in Mainline-Conversations gebenfalls einfließen. Aber das ist reine Spekulation.

Also kann ich quasi jetzt nichts Konkretes dazu sagen. Hallo. Mich würde interessieren, das Protokoll, inwiefern ist das vielleicht auch geeignet, um so anonym zu kommunizieren in Richtung Tor oder Tor Hidden Services? Also ist das dafür verwendbar, irgendwie ausbaubar?

Ja. Ich weiß nicht, ob du pseudonym oder anonym meinst. Du kannst natürlich dich über das Tor-Netzwerk, also das Tor-Netzwerk einfach ganz normal als Proxy benutzen und dich da rüber zu einem XMPP-Server verbinden. Einige XMPP-Server haben auch direkt Onion-Adressen.

Die Jabba-Adresse ist zwar nicht auf Punkt Onion, aber du kannst als Zieladresse, also dahin, wo sich der Kleine verbindet, direkt eine Onion-Adresse angeben. Dann sparst du dir quasi den letzten Haupt durchs offene Internet. Und dann kannst du dir einen Account anlegen, der irgendwie halt pseudonym ist.

Wenn das deine Definition von anonym entspricht, kannst du damit anonym checken, ja. Aber ich könnte sozusagen nicht selber, also ich kann ja Adressen so vergeben, dann auf meinem eigenen Server. Also ich kann nicht beides haben, die Kontrolle über den Server und anonyme Adressen sozusagen.

Wahrscheinlich, oder? Also du als Serverbetreiber siehst ja gegebenenfalls quasi nur den NIC und die Herkunftsadresse, also die Herkunfts-IP. Und wenn die Herkunfts-IP verschleiert ist, weil du Alt-Tor benutzt, und dann hast du ja quasi nur den NIC,

und mit nur dem NIC kannst du ja in der Regel quasi nichts anfangen. Okay, und du hast die Kontaktliste des jeweiligen, die quasi dann aus anderen NICs besteht, mit denen du irgendwie nichts anfangen kannst. Das kannst du machen. Aber es ist jetzt kein Tox oder so, wo jeder Endpunkt irgendwie quasi ein Tor-Node ist oder so.

Gibt es noch Fragen, die ich vielleicht übersehen habe? Alles klar. Dann Dankeschön, Daniel, für den Vortrag. Und euch noch viel Spaß auf den Datenspuren. Danke.