1. XMPP
Der Messenger Conversations wird seit Anfang 2014 von Daniel Gultsch ausschließlich für die Android-Welt entwickelt. Stand September 2020 verzeichnet der Messenger über 100.000 Installationen über den Google Play Store (2,29 €). Aktuelle Nutzerzahlen lassen sich allerdings schwierig schätzen, da viele Nutzer Conversations über den datenschutzfreundlichen F-Droid Store beziehen.
Im Gegensatz zu vielen anderen Messengern bringt Conversations kein eigenes Protokoll zum Nachrichtenaustausch mit, sondern setzt auf dem Extensible Messaging and Presence Protocol (XMPP) auf. XMPP ist ein Urgestein, dessen Anfänge bis zum Jahr 1998 zurückreichen und als (Kommunikations-)Protokoll, für den Austausch von Informationen bzw. Daten, entwickelt wurde.
Conversations bzw. die XMPP-Welt gestattet es Menschen, miteinander in den Austausch zu treten bzw. ein Kommunikationsnetzwerk zu betreiben, ohne von zentralen Anbietern in irgendeiner Form abhängig zu sein. Insbesondere für Personen oder Institutionen mit hohem Autonomiebedürfnis dürfte dies ein großer Pluspunkt sein.
- Die verrückte Welt der Messenger – Messenger Teil1
- Threema: Instant-Messaging-Dienst aus der Schweiz – Messenger Teil2
- Telegram: »Sicherheit« gibt es nur auf Anfrage – Messenger Teil3
- Wire: Vertrauen verspielt – Messenger Teil4
- Delta Chat: Messaging über die E-Mail-Infrastruktur – Messenger Teil5
- Conversations: Messaging über das XMPP-Protokoll – Messenger Teil6
- Element: Messaging über die Matrix – Messenger Teil7
- Briar: Anonymität und Sicherheit gehen vor – Messenger Teil8
- Signal: Hohe Sicherheit und Zero-Knowledge-Prinzip – Messenger Teil9
2. Verschlüsselung | Kryptografie
Zur Gewährleistung einer »abhörsicheren« Kommunikation setzt Conversations auf die Ende-zu-Ende-Verschlüsselung (E2EE) der Nachrichteninhalte. Dazu nutzt der Messenger die XMPP-Erweiterung OMEMO (Alternativ OpenPGP), die auf dem Double-Ratchet-Algorithmus und PEP (XEP-0163) basiert. Ursprünglich wurde Double Ratchet für den Messenger Signal entwickelt, dann aber von weiteren Messengern (bspw. Wire) adaptiert und an die eigene Umgebung angepasst. Wie auch das Signal-Protokoll unterstützt OMEMO die glaubhafte Abstreitbarkeit und Folgenlosigkeit (engl. Perfect Forward Secrecy (PFS)).
Sofern alle Teilnehmer Conversations nutzen, werden die Kommunikationsinhalte (Nachrichten, Dateien etc.) standardmäßig E2E verschlüsselt – sowohl im Einzel- als auch privaten Gruppenchat. Eine Ausnahme sind öffentliche Gruppenchats. Nutzer von Conversations sollten allerdings nicht davon ausgehen, dass eine Kommunikation mit einem Chatpartner immer standardmäßig E2EE eingeleitet wird bzw. überhaupt verschlüsselt möglich ist. In der XMPP-Welt ist Conversations lediglich ein Client von vielen, der eine (verschlüsselte) Kommunikation unter den Teilnehmern ermöglicht. Letztendlich ist es von verschiedenen Faktoren abhängig, ob eine Kommunikation E2EE erfolgen kann – unterstützt ein XMPP-Client OMEMO ist schon mal ein wichtiger Grundstein gelegt. Aufgrund der Fragmentierung der XMPP-Welt müssen Nutzer stets selbst darauf achten, ob die Kommunikation nun E2EE oder womöglich unverschlüsselt erfolgt. Neben der Fragmentierungsproblematik gibt es weitere Nachteile, die sich negativ auf die vertrauliche Kommunikation auswirken können:
- iOS: Leider existiert für die iOS-Welt kein XMPP-Client, mit dem ein vollständiger und fehlerfreier Nachrichtenaustausch in MUCs (privaten oder öffentlichen Gruppenchats) via OMEMO möglich ist. Davon abgesehen existiert für nahezu jedes System ein OMEMO-fähiger Client.
- OMEMO: Aktuell ist die OMEMO-Implementierung für MUCs allgemein als problematisch zu bezeichnen (Issue #3262, Issue #3081) und von einigen wird OMEMO sogar generell kritisch gesehen: Future of OMEMO.
Fairerweise muss man erwähnen, dass die Ursache für die aufgezeigten Probleme wenig mit Conversations selbst zu tun haben, sondern hauptsächlich mit der Offenheit und auch trägen Fortentwicklung von XMPP. Im Gegensatz zu geschlossenen (Messenger-)Systemen benötigt die Weiterentwicklung eines offenen Standards deutlich mehr Manpower und Zeit – was allerdings aufgrund der chronischen Unterfinanzierung nur schwer zu stemmen ist.
Hilf mit die Spendenziele zu erreichen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Authentifikation
Wer eine Authentifizierung seines Gegenübers nicht durchführt, kann nie wirklich sicher sein, ob er tatsächlich mit dem gewünschten Kommunikationspartner Nachrichten austauscht oder womöglich mit einem unbekannten Dritten. Zu diesem Zweck bietet Conversations eine Authentifizierung auf Basis eines Fingerprints (Zeichenfolge):
Anhand des Schloss-Symbols kann man erkennen, ob die empfangene Nachricht verschlüsselt wurde. Bevor man etwas tippt, bekommt man auch nochmal visuelles Feedback, ob die Nachricht OMEMO-verschlüsselt versendet wird.
3. Zentral | Föderiert | Dezentral
Anders als bei den meisten Messengern erfolgt die Kommunikation bzw. der Nachrichtenaustausch nicht über zentrale Server. Um mit jemandem chatten zu können, muss ein XMPP-Konto bei einem Server vorhanden sein oder neu angelegt werden. Ihr könnt euch ein XMPP-Konto wie eine Art E-Mail-Adresse vorstellen, die einmalig vergeben wird. Wie bei einem E-Mail-Provider benötigt ihr also zunächst ein neues (XMPP-)Konto bei einem Anbieter eurer Wahl.
Der Nutzer ist also vollkommen frei in seiner Entscheidung, bei welchem XMPP-Server bzw. Anbieter er ein Konto eröffnet, um es dann mit einem beliebigen XMPP-Client zu verwenden. Anders als bei einem zentralisierten Dienst wie WhatsApp, Telegram und Co. bestimmt also nicht ein Anbieter allein die Spielregeln. Die Architektur bzw. das Prinzip der Föderation verfolgt einen offenen Ansatz der kollektiven Vernetzung, bei dem niemand ausgeschlossen wird.
Für Anfänger ist der Einstieg in die XMPP-Welt etwas gewöhnungsbedürftig – das liegt insbesondere an der verteilten Serverinfrastruktur (Föderation), wie wir sie aus der E-Mail-Welt kennen. Um den Einstieg in Conversations / XMPP etwas zu erleichtern, gibt es eine hervorragende Anleitung. Etwas ausführlicher: Das Conversations Kompendium.
4. Metadaten
Eines der größten Stärken von XMPP ist gleichzeitig auch seine größte Schwäche: Die Föderalität. Sobald ein XMPP-Server mit anderen föderiert, ist er Teil eines großen Ganzen. Leider werden einige XMPP-Server nicht mit der Sorgfalt und Verantwortung betrieben, die bei föderierten Protokollen eigentlich eine Selbstverständlichkeit sein sollten. In der Praxis treten daher immer mal wieder Probleme wie Nachrichtenverlust oder fehlgeschlagene Verbindungen auf, weil etliche Server veraltet sind und bspw. keine aktuellen OpenSSL-Cipher-Suiten unterstützen.
Insgesamt ist dies ärgerlich, lässt sich aber mit der Wahl eines zuverlässigen und versierten Serverbetreibers wieder wettmachen. Die eigentliche Problematik liegt woanders: XMPP selbst. Das Protokoll ist historisch gewachsen und wurde ursprünglich nicht mit dem Fokus auf Vermeidung bzw. Schutz von Metadaten entwickelt. Das macht sich an diversen Stellen bemerkbar:
- Server-Logfiles: Über die Logfiles bzw. die serverseitige Datenbank hat ein XMPP-Server-Admin theoretisch Zugriff auf eine Menge (sensibler) Metadaten. Das Missbrauchspotenzial ist als hoch einzustufen:
- Auslesen des verwendeten Login-Passworts eures XMPP-Kontos
- Zugriff auf die Liste der gespeicherten Kontakte / vCards
- Zugriff auf zwischengespeicherte Offline-Nachrichten (sofern unverschlüsselt abgelegt, auch einsehbar)
- Zugriff auf das Archiv bzw. den Nachrichtenverlauf
- Einsehen aller aktuell verbundenen Nutzer inkl. IP-Adresse, Port usw.
- Einsehen aller Gruppenchats bzw. MUCs inkl. der MUC-Optionen und Mitglieder (Admin, Moderator, Teilnehmer)
- […]
- Server-Sicherheit: Das OMEMO-Protokoll ermöglicht eine Ende-zu-Ende-Verschlüsselung, so dass niemand außer den Teilnehmern einer Diskussion die Inhalte mitlesen kann. Allerdings ist das OMEMO-Protokoll für sich allein betrachtet noch lange kein schlüssiges Sicherheitskonzept, sondern lediglich ein Puzzleteil. Insbesondere auf XMPP-Serverseite muss der Betreiber Sorge tragen, dass der Server gegen Angriffe gut geschützt ist, damit die (Meta-)Daten der Nutzer nicht unautorisiert abgefischt werden:
- Härtung des Systems bzw. Reduktion auf das Wesentliche
- Regelmäßiges Einspielen von (Sicherheits-)Updates
- Nutzung von aktuellen OpenSSL-Bibliotheken
- Verwendung gültiger TLS-Zertifikate (bspw. Let’s Encrypt)
- Verschlüsselte Verbindungen zwischen den XMPP-Servern forcieren
Die Vermeidung von Metadaten ist demnach keine Stärke von XMPP und damit auch nicht von Conversations. OMEMO kann die Teilnehmer zwar vor dem Auslesen der Inhaltsdaten (bzw. Nachrichten) schützen – am Ende bleiben allerdings dann noch einige Metadaten (bspw. Kontaktliste) und die Zugriffsmöglichkeit auf euer Passwort. Es ist also eine Menge an Vertrauen notwendig, wenn ihr euch ein Konto auf einem XMPP-Server erstellt. Abgesehen von der Erhebung und Speicherung dieser Metadaten kann ein XMPP-Server-Admin die Datenerhebung über gewisse Serverparameter zumindest einschränken. Über die Minimierung des Loggings ist es bspw. möglich, die IP-Adresse, den Zeitpunkt der Anmeldung bzw. Nutzung des XMPP-Servers zu verwerfen. Überprüfbar ist dies allerdings nicht.
Mit der Registrierung eines XMPP-Kontos geht ein Nutzer also unweigerlich eine enge Vertrauensbeziehung zum Server-Admin bzw. Betreiber ein. Wer dies aus den oben genannten Gründen nicht möchte, der hat die Möglichkeit, seinen eigenen XMPP-Server, bspw. auf Basis von Prosody oder ejabberd, zu betreiben – das ist allerdings kein »Zuckerschlecken«, wie der Beitrag »ejabberd: Installation und Betrieb eines XMPP-Servers« aufzeigt.
5. Identifier
Als Identifier nutzt Conversations eine XMPP-ID, die vom Aufbau einer E-Mail-Adresse ähnelt. Meine XMPP-ID bzw. Adresse lautet bspw.:
kuketzblog@dismail.de
Der erste Teil kuketzblog ist mein gewählter Nickname des Kontos, der auf dem XMPP-Server dismail.de liegt.
Standardmäßig übermittelt Conversations keine Adressbuchdaten (wie Telefonnummer) an externe Server, wie es bspw. bei Messengern wie WhatsApp und Co. der Fall ist. Im Gegensatz zu vielen anderen Messengern ermöglicht Conversations also einen Identifier, der nicht an die Telefonnummer gebunden ist. Optional bietet Conversations eine Adressbuchintegration an.
Hinweis
Der Conversations-Ableger Quicksy wird ebenfalls von Daniel Gultsch entwickelt. Anders als bei Conversations besteht bei Quicksy die Möglichkeit, die Telefonnummer als Nutzernamen zu wählen. Dies soll eine Kontaktsuche anderer XMPP-Nutzer über die App bzw. das Telefonbuch ermöglichen und insgesamt die Einstiegshürde in die XMPP-Welt verringern.6. Quelloffenheit | Transparenz
Der Quelltext von Conversations ist offen (GPLv3-Lizenz) und damit für jeden einsehbar. Dadurch ist eine unabhängige Überprüfung der Sicherheit grundsätzlich möglich. Diese Offenheit ist ein essenzieller Schritt zu mehr Transparenz der Anwendung und sorgt damit für Vertrauen.
Der letzte Sicherheitsaudit von OMEMO (und Conversations) geht auf das Jahr 2016 zurück, bei dem einige Schwachstellen aufgedeckt wurden. Der wohl größte Schnitzer ist die Anfälligkeit für einen Man-in-the-Middle-Angriff, da im OMEMO-Protokoll keine Authentifikation der Nachrichten vorgesehen ist:
One cannot expect messages to remain confidential when one of the participating devices is malicious. However, a user might suspect at least that the integrity of messages sent by an honest device is guaranteed by the protocol. After all, a secure Signal session with that honest device has been set up. However, the Signal session only protects the random key. A malicious device has access to that key and can thus re-encrypt and re-authenticate any payload with that key, without the receiving party being able to detect it. This is illustrated in Figure 3. The displayed attack only shows the attack in one direction: Eve is able to modify and read anything sent by Alice. Eve needs to apply the same attack to Bob in order to setup up a bidirectional man in the middle attack. Note that Eve needs to strip of her own <key/> element from the list of keys in every message in order to remain undetected from Bob.
Two careful users will not be susceptible to this attack, because neither of them will ever accept an unvalidated key. However, no matter how careful Bob is with validating the identity key of the sending device, he must assume that Alice has never made a mistake and none of the devices were compromised in order to be guaranteed the authenticity of messages that come from any of her devices. This trust in the other party is not necessary, if the messages were authenticated inside the Signal session. Also, Bob could make it less likely for Alice to accept a malicious device by creating a cryptographic link between devices.
Allgemein gilt bei solchen Audits zu bedenken, dass diese immer versionsgebunden sind und für neue Versionen erneut durchgeführt werden müssten. Damit kann der Audit keine Aussage über das Sicherheitsniveau der geprüften Systeme / Software für die Zukunft ableiten – das ist allerdings ein generelles Problem, das Audits im Allgemeinen betrifft. Aufgrund der fortwährenden Weiterentwicklung von Conversations und auch OMEMO bzw. weiteren XEPs wäre ein erneuter Audit sicherlich sinnvoll.
7. Wissenswertes
Nachfolgend sind noch einige wissenswerte Punkte zusammengefasst, die Conversations bietet:
- Multiclient: Benutzer können ihre Chats über mehrere Geräte synchronisieren (Multiclient), da XMPP generell multiclient-fähig ist. Für den Desktop stehen mit Gajim (Windows, macOS und GNU/Linux) oder Dino (GNU/Linux) entsprechende XMPP-Clients zur Verfügung.
- Ohne Google-Abhängigkeit: Über F-Droid kann Conversations vollkommen losgelöst vom Google Play Store bezogen werden. Damit nicht genug: Es funktioniert auch komplett ohne proprietäre Google-Bibliotheken bzw. Firebase Cloud Messaging. Standardmäßig baut der Client eine (dauerhafte) TCP-Verbindung zum XMPP-Server auf, die auch beim Netzwerkwechsel (WLAN, mobil) oder Verbindungsproblemen für ungefähr 5 Minuten aufrechterhalten wird. Anstatt also immer eine neue Verbindung zu initiieren baut Conversations eine TCP-Verbindung auf, die dann über einen längeren Zeitraum für den Versand und Empfang von Nachrichten bzw. Push-Nachrichten benutzt wird.
- Sprach- und Videoanrufe: Conversations bietet ebenfalls die Möglichkeit, verschlüsselte Sprach- bzw. Videoanrufe mit einem Kontakt zu führen. Die Übertragung verläuft über WebRTC und wird mit DTLS und SRTP geschützt.
- OpenStreetMap: Der eigene Standort lässt sich innerhalb der App teilen und ist anschließend über das OpenStreetMap-Kartenmaterial für die Teilnehmer einsehbar.
8. Conversations: Vor- und Nachteile auf einen Blick
Positiv:
- Der Client ist quelloffen und der Quellcode damit einsehbar
- Mehrere Geräte können sich ein XMPP-Konto teilen – damit kann bspw. auch am Desktop gechattet werden
- Standardmäßig ist die Ende-zu-Ende-Verschlüsselung für Chats und auch private Gruppen-Chats aktiv (sofern die Teilnehmer Conversations nutzen)
- Conversations ist ohne die Verknüpfung einer Telefonnummer nutzbar – Identifier ist die XMPP-ID
- Auch auf googlefreien Smartphones nutzbar
- Nutzt nicht die Google-Infrastruktur zur Push-Benachrichtigung
- Keine (User-)Tracker integriert – Übermittlung von Absturzberichten optional
- Verschlüsselte Sprach- und Videoanrufe möglich
- Lokale Backups möglich – leider nicht durch Verschlüsselung geschützt
- Kein zentraler Server, sondern föderale Infrastruktur
Negativ:
- XMPP-Unterbau ist nicht für die Vermeidung bzw. Schutz von Metadaten konzipiert
- Fragmentierung in der XMPP-Welt sorgt oft für Probleme, die sich negativ auf Sicherheit und Datenschutz auswirken können
- Letzter Security-Audit (2016) liegt Jahre zurück
- Datenschutzerklärung äußerst knapp und lediglich in englischer Sprache verfügbar
- Der Mulitclient-Support von XMPP kann bei falscher Handhabung (bspw. ausbleibende Geräte-Verifikation) die Sicherheit der Kommunikation gefährden
9. Fazit
Betrachtet man Conversations als eine eigene Insel, dann könnte man sich dort durchaus wohl fühlen und »sicher« mit den anderen Teilnehmern kommunizieren. Sobald allerdings weitere Inselstaaten (andere XMPP-Clients und Server) hinzukommen, wird der Flickenteppich sichtbar, mit der die XMPP-Welt zu kämpfen hat. Die Effekte können sein:
- keine standardmäßige Einleitung einer Ende-zu-Ende-verschlüsselten Kommunikation
- (private) Gruppenchats, die eine Verschlüsselung auf Basis von OMEMO nicht zulassen, da ein Client das Protokoll nicht oder nur unvollständig implementiert hat
- Untergrabung der Sicherheit, da bei OMEMO das Konzept der Multi-Client-Verifikation konzeptionelle Schwächen hat
- […]
Neben der Fragmentierung ist das notwendige Vertrauen, das Nutzer einem XMPP-Serverbetreiber entgegenbringen müssen, die wohl größte Kröte, die es zu schlucken gilt. XMPP wurde ursprünglich nicht mit dem Ziel entwickelt, die Metadaten, die bei der Nutzung und Kommunikation anfallen, vor neugierigen Betreibern zu schützen bzw. erst gar nicht anfallen zu lassen. Dieser Wermutstropfen wird von vielen XMPP-Nutzern zu Recht als bitterer Beigeschmack empfunden.
Davon abgesehen – bzw. von der XMPP-Welt isoliert betrachtet – ist Conversations ein grundsolider Messenger, der über die Jahre stetig verbessert und um neue Funktionen (jüngst Audio- und Videoanrufe) erweitert wurde. Erst das unermüdliche Engagement von Daniel Gultsch hat überhaupt zur Entwicklung von OMEMO und weiteren XEP-Erweiterungen geführt, die heute die XMPP-Welt prägen. Trotz der aufgezeigten Schwächen und Probleme, die insbesondere auf die XMPP-Welt zurückzuführen sind, halte ich Conversations insgesamt für einen prima Messenger, der Nutzer ansprechen dürfte, die ein hohes Autonomiebedürfnis haben. Die Kombination aus einem eigenen XMPP-Server und Conversations dürfte gemessen an anderen Messengern eine Lösung sein, die eine größtmögliche Freiheit und Unabhängigkeit ermöglicht.
Tl;dr: XMPP (und damit Conversations) war und ist nicht der Heilsbringer für die Messenger-Welt. XMPP ist aber eine Lösung, die es Menschen gestattet, miteinander in den Austausch zu treten bzw. ein Kommunikationsnetzwerk zu betreiben, ohne von zentralen Anbietern in irgendeiner Form abhängig zu sein. Den Schwächen von XMPP sollte man sich dennoch bewusst sein.
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Conversations: Sicherer Android Messenger
Messenger: XMPP ist nicht der Heilsbringer – aber eine Lösung
Datenschutzfreundliche und sichere WhatsApp-Alternativen
ejabberd: Installation und Betrieb eines XMPP-Servers
Die verrückte Welt der Messenger – Messenger Teil1
12 Ergänzungen zu “Conversations: Messaging über das XMPP-Protokoll – Messenger Teil6”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Schöner Bericht, danke!
Kleine Anmerkung: Abschnitt 8., Positiv-Liste:
Die PlayStore-Version benutzt sehr wohl FCM für Push-Benachrichtigungen. Du erwähnst das zwar indirekt in Abschnitt 7, aber in der abschließenden Liste würde ich es besser nochmal ganz deutlich machen.
XMPP ist nicht nur ein förderiertes Netzwerk, es ist standardisiert. Und das ist die Grundvoraussetzung für ein vertrauenswürdiges Messenger-System.
Wenn Usern bestimmte Entscheidungen nicht gefallen, die die Entwickler einer App/Implementierung getroffen haben, können sie einfach die App/Implementierung wechseln. Bei zentralisierten Apps ist das nicht so, man muss das ganze Netzwerk verlassen und damit alle seine Kontakte. Dies hindet den Nutzer, effektiv Kontrolle über die Software auszuüben.
Standardisierte Protokolle sind wichtig, weil unkonventionelle Betriebssysteme supportet werden können.
Am Fall Signal sieht man ganz deutlich, warum das so wichtig ist: Third-Party Apps werden abgelehnt, es gibt aber nur offizielle Versionen für Android, iOS, Windows, MacOS und Linux.
Also keine *BSD Versionen, welche für Ubuntu Touch oder PostmarketOS.
Kürzlich hat der Hauptentwickler Folgendes getweetet: https://nitter.net/moxie/status/1299824747744653312#m
Hier schreibt er, dass Electron es ihm ermöglicht, nur 3 Apps zu maintainen, ohne eine Vierte bauen zu müssen. Das ist interessant, weil er damit wahrscheinlich nur Windows, MacOS, Android und iOS meint. Nicht Linux.
Man kann natürlich inoffizielle Apps bauen, aber ich sehe das für Zeitverschwendung an (siehe die Sache mit LibreSignal).
Und wenn man nicht einmal Linux supporten würde, zeigt das, wie ernst man es mit Informationeller Selbstbestimmung sieht!
Die Signal-Entwickler/Vermarkter sagen, dass die App „Open Source“ ist. Das ist ein Marketing-Begriff, mit dem sich von den Idealen der freien Software abgegrenz wird. Leider schreibt auch Conversations, dass die App „Open Source“ ist.
Bitte beim Thema bleiben: Conversations bzw. XMPP.
Signal läuft übrigens problemlos unter GNU/Linux. Es gibt für diverse Derivate fertige Pakete – unter anderem auch für Debian.
Weiterer Vorteil ist, dass man den Verkehr ganz simple über Tor leiten kann. Ist mit einem Klick getan, ohne das man dafür groß Scripte einbinden muss.
Ja – man kann jeglichen Traffic über Tor leiten. Würde ich aber eher nicht machen, da die Onion-Adresse nur für xmpp.provider.tld. gilt. Für URLs wie share.provider.tld muss man darauf vertrauen, dass der Tor Exit Node nicht sslstrip o.ä. ausführt. Würde ich also eher von abraten.
Ein toller Artikel, den ich definitiv teilen werde!
Als aufmerksamer Leser des Blogs gab es für mich natürlich nur wenig Wissenszuwachs, dennoch habe ich schon seit längerem eine Frage zu Conversations:
Wie ist es denn bezüglich der Sicherheit zu bewerten, dass der Herr Gultsch anscheinend allein an dieser App arbeitet? Ich frage das, weil ja auf dem Blog von z.B. Firefox-Forks abgeraten wird, wenn diese nur wenige Maintainer haben.
Grundsätzlich ist es natürlich wünschenswert und meist auch von Vorteil, wenn ein Projekt von mehreren Entwicklern betreut wird. Bei Conversations ist das nicht der Fall. Hier liegt es unter anderem auch an der Community Bugs zu melden, damit diese gefixt werden können.
Sollte Daniel Gultsch die Entwicklung eventuell mal einstellen, steht zumindest der Quellcode offen und kann weitergeführt werden.
Was ist mit iOS? Mike schreibt hier, dass es dafür keinen XMPP Client gibt. Dabei wurde doch auch hier beim Kuketz-Blog darauf darauf aufmerksam gemacht, dass es für iOS „ChatSecure“ gibt. Nach deren Angaben auch OpenScource.
https://www.kuketz-blog.de/chatsecure-ios-messenger-bekommt-omemo-support/
Wer sagt denn, dass es keinen XMPP-Client für iOS gibt? Wenn man den Text nur überfliegt, könnte man natürlich zu diesem Urteil kommen. Ich zitiere:
Es gibt unter anderem ChatSecure oder Siskin.
Ok, mein Fehler, habe den Abschnitt tatsächlich nicht ganz zu Ende gelesen.
Schade, dass es für die iOS Welt keinen client für vernünftigen Nachrichtenaustausch in MUCs gibt.
Danke für den Hinweis.
Hallo Mike, könntest du bitte näher ausführen inwieweit ChatSecure unvollständig und fehlerhaft ist was den Nachrichtenaustausch in MUCs angeht? Ist teste das gerade mit einem Prosody Server und konnte bisher noch keine Probleme feststellen (privater Gruppenchat mit OMEMO Verschlüsselung). Ein Link auf die Quelle deiner Ausführungen würde genügen.
Besten Dank für die tolle Arbeit hier,
Timo
Das sind Erfahrungswerte von Nutzern, die im geschlossenen Gruppenchat (für Moderatoren) unterwegs sind. Sobald bspw. ein neuer Nutzer in die Gruppe eingeladen wird, von dem der OMEMO-Key noch nicht für alle Teilnehmer bekannt ist, sorgt das bei den ChatSecure-Clients für Probleme. Es gibt aber noch weitere Seiteneffekte die auftreten können. Daran erinnere ich mich allerdings nicht mehr im Detail. Du kannst vielleicht auch mal auf der GitHub-Seite des Projekts unter Issues schauen.