Der Unternehmenssitz der heinekingmedia GmbH ist in Hannover (Niedersachsen), wo auch die Polizei und Schulen zu den Nutzern zählen. Darüber hinaus wird Stashcat u.a. auch bei der CDU in Niedersachsen als “parteiinterner Messenger” angeboten (es wird argumentiert, daß dies auch eine „Wirtschaftsförderung“ sei). Stashcat ist auch die Basis für „schul.cloud“ (nicht zu verwechseln mit der „Schul-Cloud“ des Hasso-Plattner-Instituts!)
Stashcat ist ein Inselsystem und setzt auf ein technisches “Abschotten” des Systems zur Absicherung, wodurch Mißbrauch vermieden werden soll. Es wird kein standardisiertes Protokoll (und auch nicht ein abgewandeltes XMPP) verwendet - sondern eine firmeninterne Entwicklung, in die keine Einsicht gewährt wird.
Jeder Benutzer erhält einen eigenen Account in der schul.cloud Plattform, der den Vor- und Nachnamen des Nutzers in Klartext umfasst
Seitens des Herstellers wird zwar bei Nachfrage auf externe Prüfungen („Audits“) verwiesen …
Wie bei allen Computerprogrammen kann es dennoch auch bei „closed source“ Produkten Sicherheitsschwachstellen geben. Eine eigene Recherche zu Stashcat im Internet hat ergeben, daß die Sicherheitsfirma CIPHRON im Jahr 2017 einige Schwachstellen in kryptographischen und sicherheitsgebenden Funktionen des Instant Messengers StashCat gefunden hat. Diese wurden dokumentiert und dem Hersteller bekannt gemacht, damit dieser entsprechend reagieren kann.
Die zahlreichen aufgeführten Schwachstellen seien alle behoben, die damit verknüpften Angriffspunkte beseitigt worden, versichert die hinter Stashcat stehende Firma.
Das „kostenlose“ Angebot der „schul.cloud“ ist der Aufhänger, um kostenpflichtige Dienste (schul-cloud-pro) zu verkaufen.
Auf der Seite “schul.cloud” wurde damit geworben: “So sicher, dass es auch die Polizei erlaubt! Mehr zum Polizeimessenger.”
Der Werbespruch wurde Stand 03.03.2019 von der Seite entfernt - wird aber weiterhin noch auf der Seite der Fa. heinekingmedia verwendet.
Interessanterweise warb/wirbt die Firma heinekingmedia GmbH mit Argumenten für Stashcat, die exakt auch für Jabber(XMPP) sowie Matrix zutreffen:
“kostet Sie nichts” und “Vertrag zur Datenverarbeitung im Auftrag ist nicht erforderlich”. Letzteres stimmt nicht, da eine Schule, sobald das nicht Einzelpersonen “just for fun” nutzen, sondern die Schule das verpflichtend als Kommunikationsmedium einsetzt, eben ganz klar einen solchen Vertrag mit dem Dienstleister abschließen muss! Das wiederum geht nur mit der Pro-Variante von schul.cloud.
Im Februar 2019 wurden dem Hersteller verschiedene Fragen gestellt und wie folgt beantwortet:
3. Verschlüsselung
\
a) Ist der Quellcode zum Signierungsalgorithmus einsehbar und überprüfbar?
Auf der Seite findet sich u.a. eine Information zum “Signierungsalgorithmus (SHA256withRSA)”. Ist der Quellcode diesbezüglich einsehbar und überprüfbar?
Heinekingmedia:
Es handelt sich um eine Closed Source Lösung, die wir inhouse eigenständig entwickeln. Der Quellcode ist daher nicht öffentlich einsehbar, wurde aber im Rahmen des Polizei-Rollouts von stashcat®, der Basistechnologie, überprüft und freigegeben.
b) Spezial-/Fachbegriffe
Was ist unter
- “Perfect Forward Secrecy”
- “automatische Patches der SSL Endpoints”,
- “Downgrade Attack Prevention” und
- “Secure Renegotiation”
zu verstehen?
Anregung:
Wenn Fachbegriffe aufgeführt werden, sollten diese - für die Endbenutzer verständlich - erläutert werden.
Heinekingmedia:
Alle Informationen zum Datenschutz und zur Sicherheit in der schul.cloud werden auf unserer Website www.schul.cloud im Bereich Datenschutz aufgeführt. Wir planen demnächst eine generelle Umgestaltung der Datenschutz-Unterseite für alle Messenger-Websites. Im Zuge dieser Umgestaltung planen wir generell, die Begrifflichkeiten für die verschiedenen Empfängergruppen entsprechend verständlicher zu gestalten. Daher vielen Dank für das Feedback.
c) Perfekte, in die Zukunft gerichtete Sicherheit
“Perfect Forward Secrecy zum Schutz der Daten vor nachträglicher Entschlüsselung der Kommunikation”
- Wie wird dies in der Praxis gehandhabt bzw. wie läuft das für den Benutzer ab?
- Werden Nachrichten (Messenger) und Daten (Dateisystem) verschlüsselt?
- Wann/wie oft muß ein Schlüssel eingegeben werden?
Heinekingmedia:
Mit jedem Nutzer-Account ist ein Private Key gekoppelt. Hierzu muss zusätzlich zum Account-Passwort ein Verschlüsselungskennwort vom Nutzer vergeben werden. Dieses Verschlüsselungskennwort wird bei jedem Login in die schul.cloud® vom Nutzer eingegeben.
</div>
4. Protokoll: Welches Protokoll kommt zum Einsatz (öffentlicher Standard oder Eigenentwicklung)?
_Heinekingmedia:\
Es handelt sich hierbei um eine Eigenentwicklung._
5. Kommunikation
* Ist eine Kommunikation zu anderen Schulen (andere schul.cloud-Nutzer) möglich?
* Ist eine Öffnung des Messengers gemäß der Forderung der Bundesinnenministerin zur Öffnung von WhatsApp geplant?
_Heinekingmedia:\
Die schul.cloud ist eine geschlossene Plattform. Für jede Schule wir eine eigene Umgebung erstellt. Zusätzlich ist es in der schul.cloud pro möglich, Mandantenübergreifend zu kommunizieren, sodass mehrere Schul-Umgebungen miteinander verbunden werden können. Die Verbindung funktioniert immer bewusst über einen Administrator._
6. Schnittstellen
* Welche Daten können extrahiert/exportiert werden?
* Gibt es standardisierte Datenaustauschschnittstellen, wie z.B. Export als Excel, CSV, XML?
* Gibt es APIs um mit eigenen Systemen auf die Daten und Vorgänge zuzugreifen, wie REST, WebServices oder XML-RPC?
* Können / wie können Drittsysteme (z.B. Nextcloud) eingebunden werden?
_Heinekingmedia:\
In der schul.cloud können grundsätzlich alle Dateiformate geteilt und ausgetauscht werden. Für einzelne Funktionen besteht die Möglichkeit zu einem Excel-Export. Die Anbindung von Drittsystemen ist in der schul.cloud nicht vorgesehen._
7. Benutzeradministration
* Welche Benutzerrollen gibt es?
* Gibt eine Benutzerhierarchie bzw. Benutzergruppen?
* Was wird bei identischen Namen verfahren?
_Heinekingmedia:\
In der schul.cloud gibt es die Benutzerrollen Schüler, Lehrer und Eltern. In der schul.cloud pro kann jede Schule individuelle Benutzerrollen definieren. Zudem können Kontaktgruppen definiert werden. Da sich jeder Nutzer anhand eines Einladungsschlüssels selbstständig registriert, gibt es keine Probleme bei identischen Namen._
8. Externe Prüfung: Wann und von wem wurde schul.cloud zuletzt auditiert/geprüft?
_Heinekingmedia:\
Die Basistechnologie wurde im Rahmen des Polizei-Rollouts wie oben beschrieben geprüft._
9. Praxisfragen
* Auf welchen Betriebssystemen kann schul.cloud betrieben werden?
* Ist es möglich Dateien lokal zu speichern/wo?
* Können Dokumente direkt aus der Anwendung heraus geöffnet und gespeichert werden (z.B. Textverarbeitung, Tabellenkalkulation, ...)?
_Heinekingmedia:\
schul.cloud kann als Desktop-Client auf Windows- und Mac-Systemen betrieben werden. Zudem existieren native Apps für Android und iOS. In Form des Web-Clients kann die schul.cloud zudem auf beliebigen weiteren Systemen verwendet werden. Dateien können direkt aus der Dateiablage auf das lokale Gerät gespeichert werden. Dokumente können als Vorschau in der Anwendung geöffnet werden. Zum Bearbeiten müssen sie heruntergeladen werden._
10. Sonstiges
* Kann auch ein anderer Subunternehmer zur Verarbeitung der Daten gewählt werden? Wie sind hier die Abhängigkeiten?
* Wie würden Sie den Mehrwert beschreiben, den das System gegenüber einer einfachen Dateiablage hat?
* Gibt es eine Roadmap für die Weiterentwicklung von Funktionen als/in Richtung eLearning-Plattform?
* Gibt es eine Featureliste?
* Gibt es eine Demo-Version, um die Funktionalität zu testen?
_Heinekingmedia:\
Nein, die schul.cloud wird in einem gesicherten Rechenzentrum in München bereitgestellt. In der schul.cloud pro ist eine on Premise Installation grundsätzlich möglich. Gegenüber einer normalen Dateiablage bietet die schul.cloud Kommunikationsmöglichkeiten, den direkten Austausch von Informationen und Dateien. Somit kann die komplette Schulkommunikation und Unterrichtsorganisation über die schul.cloud abgedeckt werden. Die schul.cloud als Kommunikationsplattform wird ständig am Bedarf der Praxis weiterentwickelt. Für die Einsicht der Funktionen der schul.cloud besuchen Sie gerne unsere Website. Schulen können sich - ebenfalls über unsere Website - selbstständig für die Nutzung der schul.cloud kostenfrei registrieren. Bei einer Erst-Registrierung prüfen wir die Schulzugehörigkeit._
Das Marketing der Fa. heinkingmedia GmbH ist super und arbeitet sehr professionell. Auch der Internetauftritt ist richtig gut gemacht. Kleiner Wehrmutstropfen hier ist das Ergebnis bei Webbkoll (extern) …
Webbkoll
Quelle: https://webbkoll.dataskydd.net/de/results?url=http%3A%2F%2Fschul.cloud (extern)
Aktueller Stand
Die o.g. Informationen sind Stand 30.04.2021 immer noch aktuell. Der Fa. heinekingmedia sind die Inhalte dieser Seite bekannt; es gab hierzu einen Austausch per E-Mail.
Am 24.08.2020 kam noch folgende Anfrage: „Ist es noch möglich Ihnen Input zu geben? Falls ja würde ich mich darum kümmern …“
Trotz positiver Beantwortung am 30.08.2020 („Ja - ich würde Ihre Infos dann bei der nächsten Aktualisierung der Seite mit berücksichtigen.“) ist bis April 2022 keine diesbezügliche Nachricht eingegangen.
Fazit
Eine weitere Insellösung bedeutet für den Nutzer letztendlich jedoch erneut eine weitere (dritte, vierte, fünfte?) inkompatible Messenger-App. Selbst die Bundesjustizministerin fordert eine Öffnung der Messengerdienste (insbesondere von WhatsApp).
- Lesezeit: 1 Minute / ganze Rubrik: 9 Minuten - |
Psssst: Geheimnisse und Sicherheitslücken
Daten dürfen nicht pauschal an WhatsApp/Facebook übertragen werden. Wer Daten von Dritten ohne Zustimmung weitergibt, handelt rechtswidrig.
Schlicht: Man macht sich strafbar.
Sensible Bereiche / Geheimnisträger
Geheimnummern / „interne“ Telefonnummern
Privatsphäre
Querverweis: WhatsApp für Überwachungszwecke nutzen
Empfehlung: |
Bei der privaten Nutzung von WhatsApp sollten Berufsgeheimnisträgern ein separates berufliches Smartphone - ohne installiertes WhatsApp verwenden. |
„Freie Messenger“ in sensiblen Bereichen / für Geheimnisträger
In vielen Bereichen des alltäglichen Lebens gibt es Geheimnisträger/Berufsgeheimnisträger, die das besondere Vertrauen ihrer Kontakte haben.
Hierzu gehören:
Bereich |
Geheimnisträger |
Kontakte |
Bildung |
Lehrer, Dozenten, Referenten, … |
Kollegium, Schüler, Studenten, … |
Justiz |
Polizei, Richter, Rechtsanwälte, Mediatoren … |
Kollegen, Straftäter, Mandanten … |
BOS |
Behörden und Organisationen mit Sicherheitsaufgaben: Polizei, Feuerwehr, Rettungsdienst, Technische Hilfe, Bergwacht, Forst, … |
Patienten, Geschädigte, Verursacher, interne Stellen, … |
Gesundheit |
Ärzte, Psychologen, Psychiater, Apotheker, … |
Patienten, Kunden, Liferanten … |
Kirche |
geistliche Würdenträger |
alle Kontakte |
Politik |
sämtliche Mandatsträger |
Mitglieder, Kontaktpersonen, Vertrauenspersonen, Lobby, Presse, … |
Presse |
Journalisten, Redakteure, Fotografen, … |
Vertrauensleute, Bürger in Krisengebieten, … |
Soziales |
Frauenhäuser, Sozialdienste, … |
alle Kontakte |
Wirtschaft |
Geschäftsführer, leitendes Personal, Bevollmächtigte, Mitarbeiter, Aushilfen, … |
Lieferanten, Kunden, Geschäftspartner, Entwicklungspartner, … |
Bei all diesen Berufsgruppen ist nicht davon auszugehen, dass von allen Kontakten eine Einverständniserklärung vorliegt.
Empfehlung: |
Berufsgeheimnisträger sollten E-Mail mit Verschlüsselung und/oder einen freien Messenger nutzen. |
Chat auf der Basis des internationalen Protokolls XMPP kann und darf(!) überall dort legal eingesetzt werden, wo E-Mail auch genutzt wird. |
Auf dem Infoblatt (PDF) ist dazu alles Wesentliche zusammengefasst.
Berufliche Sofortnachrichten auf privaten Geräten
Ist legales Chatten möglich?
In der Berufswelt und auch an Bildungsträgern stellt sich oft die Frage, ob man einen Messenger auf einem privaten Gerät für berufliche Inhalte überhaupt nutzen darf. Hierzu ist es hilfreich sich darüber im Klaren zu sein, was Texten/Chatten eigentlich ist.
Grundsätzlich ist anzumerken, dass Chatten (=Plaudern) den Charakter von persönlichem „Gespräch“ hat - das wird oft übersehen! Chatten liegt somit näher an der Telefonie wie am Versenden von Briefen/E-Mail - an die ein ganz anderer Maßstab (z.B. auch Archivierungspflicht) anzulegen ist.
Berufliche oder schulische Dokumente sollten deshalb auch nicht mittels eines Chatprogramms übermittelt werden, das auf einem privaten Gerät installiert ist.
Technische Restriktionen
Manche (Insel-)Lösungen versuchen ein Weiterleiten oder Kopieren von Inhalten technisch zu verhindern oder ermöglichen ein „Löschen“ von Nachrichten. Dadurch wird jedoch lediglich Rechtssicherheit suggeriert aber nicht erreicht (Pseudosicherheit). Eine technische Beschränkung ist diesbezüglich ein falscher(?) Grundgedanke bzw. Lösungsansatz, denn unerlaubtes Weitergeben oder Kopieren kann technisch nicht verhindert werden! Einmal empfangene/angezeigte Inhalte können immer unerlaubt kopiert, fotografiert oder weitergeleitet werden. So kann beispielsweise auch nicht verhindert werden, ein Gerät nach dem Empfang aber vor dem Lesen einer Nachricht auf „offline“ zu schalten.
Grundsatzproblem
Das Problem betrifft alle Kommunikationsformen: Ein Telefonat ist möglich unabhängig davon, was gesprochen wird; ein Briefversand ist unabhängig vom Inhalt möglich; bei einem Kopierer wird (außer Geldscheinen) alles kopiert, was ein-/aufgelegt wird. Die Entscheidung für was die Technik genutzt wird, trifft immer der Nutzer.
Beispiel:
Ein dienstliches Telefonat zwischen einem Privathandy und einem privaten Festnetzanschluß wird i.d.R. kein Problem darstellen - dienstrechtlich/strafrechtlich kann es jedoch sehr wohl bedeutend sein, was gesprochen wird.
Deshalb ist Aufklärung wichtig, wie die zur Verfügung stehende Technik sicher und rechtskonform genutzt wird! Analog der privaten Nutzung von dienstlichen Geräten sollte deshalb ein Arbeitgeber/Dienstherr die dienstliche Nutzung von privaten Geräten regeln - heißt: zulassen oder verbieten.
Ja, legales Chatten ist möglich. |
Alle Lösungen, die sich an die geltende Rechtslage halten (z.B. kein unerlaubtes Hochladen von Daten) sind auch legal nutzbar. Die Problematik ist also nicht ob - sondern wie und für was Messenger genutzt werden können, um sich letztendlich rechtskonform zu verhalten. |
Überall dort, wo E-Mail verwendet wird, kann und darf ein auf standardbasierten Protokollen basierender Chat legal genutzt werden (der einzige Unterschied ist der zusätzliche Online-Status)! |
Externer Verweis
In der Zeitschrift „Deutsche Polizei“ wird im Artikel „Sichere Messenger bei der Polizei“ auf Freie Messenger eingegangen und der Einsatz empfohlen.
Interne und private „Geheimnummern“
Oft gibt es Telefonnummern, die nur bestimmten Personen/Personenkreisen vorbehalten sind.
Beispiele für Geheimnummern sind:
- Notfallnummern
- Privatnummern im Geschäftsbereich
- wichtige Telefonnummern im Rettungswesen/Katastrophenschutz
- Zweitnummern, die nicht in öffentlichen Verzeichnissen stehen sollen
- …
Aber auch bei technischen Anlagen gibt es unzählige Beispiele:
- Alarmanlagen
- Türe und Tore mit entsprechender Steuerung
- elektrische Poller, die „per Anruf“ versenkt werden können
- Hausautomation
- …
Da manche Messenger das komplette Adressbuchs des Nutzers ohne dessen aktiver
Zustimmung auf ihren zentralen Server laden (z.B. WhatsApp), verstößt dies nicht
nur gegen den Datenschutz und ist ein Vertrauensbruch - sondern ist auch eine
Sicherheitslücke.
Wichtig: |
Private als auch geschäftliche „Geheimnummern“ müssen tatsächlich geheim bleiben und dürfen auch keine Rückschlüsse auf persönliche Verbindungen geben. |
Denkfehler!
Viele Messenger sind zentral organisiert. Das bedeutet, dass selbst ohne das Kennen der verschlüsselten Inhalte ein sehr detailliertes Wissen über die Nutzer und der Beziehungen untereinander gesammelt und (im Firmeninteresse) genutzt wird:
- Wer kennt wen?
- wer kommuniziert?
- mit wem?
- wann?
- wie lange?
aber auch:
- in welchen Zeiträumen wird nicht kommuniziert?
- …
Die Informationen kommen nicht aus den eigentlichen Inhalt der Nachrichten, sondern aus der Übertragung an sich.
Viele Anbieter preisen die „vollständige Ende-zu-Ende-Verschlüsselung“ an.
Dabei ist es in diesem Zusammenhang jedoch unerheblich, ob die Kommunikation verschlüsselt ist oder nicht.
Das unbegrenzte Sammeln, Aufbewahren und Auswerten der Übertragungsdaten wird verschwiegen/verharmlost.
Das wird oft übersehen.
Durch das Abgleichen von Datenbanken und dem Anwenden von mathematischen und analytischen Verfahren lassen sich sehr schnell und einfach wesentliche Hintergründe
- zum persönlichen und beruflichen Umfeld
- zum sozialen Umgang
- zum gesundheitlichen Zustand
- zur wirschaftlichen Situation oder auch
- zur politischen Gesinnung
- …
ermitteln. Dabei haben diese Informationen eine sehr hohe Trefferwahrscheinlichkeit, weshalb sie dann auch für viel Geld gehandelt werden.
Dieses Sammeln, Anreichern und Auswerten von Informationen ist Realität und entpricht der täglichen Praxis.
Beispiele
Konkrete Beispiele, die sich aus dem Adressbuch und den (inhaltlich verschlüsselten) Übertragungsdaten ableiten bzw. eindeutig ermitteln lassen:
- Geschlecht
- Ungefähres Alter
- Nationalität
- Wohnort
- Kaufkraft
- Bonität
- Eigentumsverhältnisse
- Familienstand
- soziales Umfeld
- politische Gesinnung
- berufstätig ja/nein
- sozial engagiert ja/nein
sowie
- Änderungen:
- Verhaltensänderungen
- Beziehungsänderungen
- Änderungen/Entwicklung bei den anderen vorgenannten Merkmalen
- …
Artikel zum Thema
Gefährdete Privatsphäre (2020)
In einer kollaborativen Zusammenarbeit der TU Darmstadt, der TU Graz und der Universität Würzburg wird gezeigt, dass aktuell verwendete Verfahren zur mobilen Kontaktermittlung die Privatsphäre von Nutzern massiv bedrohen.
Unter anderem heißt es:\
… Die Übertragung quasi aller persönlichen Kontakte an einen Dienstanbieter stellt ein signifikantes Risiko für die Privatsphäre und auch eine rechtliche Herausforderung dar …
Quelle: https://contact-discovery.github.io/de (extern) |
Hier eine kleine beispielhafte Übersicht, welche Konzerne welche Daten sammeln:

Quelle: https://web.archive.org/web/20191115234907/https://securitybaron.com/blog/the-data-big-tech-companies-have-on-you-or-at-least-what-they-admit-to/amp/ (extern)
Weitere externe Beispiele sind >> hier << zu finden.
Gedankenspiel zur Privatsphäre
Bei „freie-messenger.de“ werden Daten nicht „gesammelt“, „angereichert“ und „verkauft“.
- Würden Sie mir trotzdem einfach alle ihre Kontakte zur Verfügung stellen und mitteilen, wann Sie mit wem kommunizieren?
- … oder ihren Freunden?
-> Warum dann einer gewinnorientierten Firma, die ein zentrales System betreibt?
Privatsphäre betrifft jeden und ist wichtig:
Nicht ohne Grund gibt es Vorhänge für die Fenster oder Wohnungs- und Haustüren, die ein äußeres Zeichen der Privatsphäre sind. Sie schützen vor neugierigen Blicken oder dem Zutritt Fremder in das eigene Leben.
Privatsphäre <-> Bequemlichkeit |
Jeder muss für sich entscheiden, welchen Stellenwert die Privatsphäre hat und wann diese der Bequemlichkeit geopfert wird. |
“Metadaten oder Metainformationen sind strukturierte Daten, die Informationen über Merkmale anderer Daten enthalten.
Bei den durch Metadaten beschriebenen Daten handelt es sich oft um größere Datensammlungen wie Dokumente, Bücher, Datenbanken oder Dateien. So werden auch Angaben von Eigenschaften eines einzelnen Objektes (beispielsweise „Personenname“) als dessen Metadaten bezeichnet.
Anwendern von Computern ist oft nicht bewusst, dass Daten über nicht unmittelbar erkennbare Metadaten verfügen und dass diese unter Umständen einen größeren Nutzen für Computerkriminelle oder Behörden haben als die Daten selber.”
Quelle: Wikipedia
- Lesezeit: 3 Minuten / ganze Rubrik: 7 Minuten - |
Freie Messenger an Schulen / Bildungseinrichtungen
Um im Bereich des Datenschutzes nicht bevormundet zu werden, ist eine grundlegende Kommunikationskompetenz erforderlich. Es ist wichtig, die Bedeutung von freier Software - und hier insbesondere von freien Messengern - frühzeitig schon an Bildungseinrichtungen zu vermitteln. Unabhängige und selbstbestimmte Entscheidungen sind nur dann möglich, wenn man einen Überblick über die verschiedenen Systeme und Hintergründe hat.
Exkurs: WhatsApp an Schulen ist verboten
Exkurs: Lehrkräfte sind Berufsgeheimnisträger
Wenn man in das Thema „Alternativen zu WhatsApp / Freie Messenger“ einsteigen möchte, ist es wichtig, den Verantwortlichen an einem Praxisbeispiel zu vermitteln, welche Möglichkeiten es tatsächlich gibt und dass viele Inhalte mit wenig Aufwand im Unterricht vermittelt werden können. Die Messengerkompetenz muß also gezielt gefördert werden, denn die Erkenntnis „Ach sowas geht? Ich dachte das geht nur mit WhatsApp?“ ist extrem wichtig. Eine Vorführung/Demonstration der Funktionalitäten sowie das Aufzeigen eines möglichen Einführungsszenarios ist deshalb sinnvoll. Das kann anhand der beispielhaften Checkliste für die Einführung gemacht werden.
Das ist auch wichtig, wenn das Thema nicht nur in einer Klasse sondern an einer gesamten Schule vermittelt werden soll. Für einen Erfolg ist es dann Voraussetzung, dass die Schulleitung tatsächlich positiv dazu steht. Also muß auch hier erst Wissen vermittelt werden, damit die notwendige Messengerkompetenz vorhanden ist. Wie intensiv sich die jeweilige Schule/Lehrkraft dann mit dem Thema auseinandersetzen will, sollte selbstbestimmt sein. Oft entwickelt sich das auch aus einer Eigendynamik heraus.
Die Einführung von freien Messengern an Schulen kann in verschiedene Themenbereiche unterteilt werden, die aufeinander aufbauen. Bei allen sollte eine entsprechende Planungs- und Einführungsphase stattfinden. Der Zeitaufwand für das Thema kann und muß in allen Phasen klein gehalten werden.
AlekSIS
Mit AlekSIS (extern) gibt es sogar ein Komplettpaket zur Organisation und Verwaltung für Schulen, das ausschließlich auf freier Software basiert:
“Mache einen Job, und mache ihn richtig” – das ist ein grundlegendes Prinzip der Softwareentwicklung, das AlekSIS® verfolgt. Daher konzentriert sich AlekSIS selbst auf alles, was mit Organisation und Verwaltung zusammenhängt. Es ist als zentrale Stelle für Stammdaten wie Personen, Lerngruppen, Stundenpläne, und alles, was die Arbeitsweise der Schule ausmacht, gedacht.
Für alle Einsatzgebiete, die nicht direkt mit Verwaltung zusammenhängen – wie Lernplattformen, Videokonferenzen, und vieles mehr – integriert sich AlekSIS mit anderen offenen Plattformen und auch mit proprietären Lösungen.
AlekSIS kann u.a. auch mit einem Matrix-Server interagieren, indem die organisatorischen Daten repliziert werden, um automatisch Matrix-Spaces und -Räume für die gesamte Schule zu verwalten. Selbstverständlich auch mit LDAP- und OAuth-/OpenID-Unterstützung.
Aber:
Matrix ist ein tolle Teammessengerlösung - allerdings sollte Matrix als isolierte Instanz bei Schulen und Bildungseinrichtugnen betrieben werden, da es systembedingt datenschutzrechtliche Bedenken gibt. Allenfalls eine Brücke und die Nutzung einer Schnittstelle zum internationalen Standard XMPP wäre evtl. denkbar.
Exkurs: Mehrheitlich sind jedoch unfreie Messenger/Lösungen für Schulen und Bildungseinrichtungen vorherrschend.
Öffentlicher Chat
Oft wird großer sozialer Druck ausgeübt, trotz offiziellem Verbot einen bestimmten Messenger zu nutzen. Auch wird Bequemlichkeit über alles andere gestellt und sachliche Argumente zählen nicht. Um einen gegenseitigen Erfahrungsaustauch zum Thema “Freie Messenger an Schulen” zu unterstützen, gibt es deshalb eine öffentliche Chatgruppe (Jabber/XMPP): schulen@conference.jabber.de (Direktverknüpfung zum sofortigen Einstieg: xmpp:schulen@conference.jabber.de?join)
Hier können sich Lehrkräfte, Schüler und Eltern über Probleme zu geschlossenen (unfreien) Messengern und/oder über Erfolge zu freien Messengern austauschen.
Referenzschule/-einrichtung
Für Bildungseinrichtungen sollen weitere Unterrichtsmaterialien, Checklisten und Anleitungen erstellt und zum Herunterladen bereitgestellt werden.
Die „Schönbein Realschule Metzingen“ (extern) ist Referenzschule und bindet das Thema erstmals im aktuellen Schuljahr aktiv im Unterricht ein. weitere “Referenzschulen”, die sich aktiv einbringen und beteiligen möchten, sind willkommen.
Weitere interessierte Einrichtungen (alle Schularten) im deutschsprachigen Raum können sich gerne melden >> Kontakt <<. Auch wenn bereits anbieterunabhängiger Chat / freie Messenger aktiv eingesetzt werden, würde mich eine kurze Information freuen.
Weitere Verknüpfungen auf Seiten zum Thema:
https://zefanjas.de/5-grossartige-open-source-programme-die-wir-in-unserer-schule-einsetzen/ (extern)
https://matthias-andrasch.de/2018/liebe-hochschulen-und-schulen-ermoeglicht-bitte-endlich-die-digitale-vielfalt-entwurf/ (extern)
Checkliste zur Einführung
1. Freie Messenger in der Praxis
Bei der Einführung von freien Messengern an Schulen ist es wichtig, in allen Phasen praktisch zu vermitteln, was im Vergleich zu WhatsApp geht und was nicht (kein System ist perfekt). Deshalb hier eine kurze Übersicht der wesentlichen Punkte.
Was geht?
- Einzelgespräche (chats)
- Gruppen
- öffentliche Räume/Gruppen
- persönliche Nachrichten innerhalb Gruppen
- Verschlüsselung
- Texte
- Bilder/Fotos
- Sprachnachrichten
- Dateiversand
- Standortweitergabe
- A/V-Telefonie
- mehrere Geräte
- mehrere Konten
- freie Wahl des Benutzernamens (Pseudonym/Alias)
- freie Serverwahl
- ggfs. eigener Server für Spezialisten
- mit oder ohne SIM-Karte nutzbar; auch nur am PC oder Tablet
Was geht nicht?
- z.B. Videokonferenzen: Hierfür werden BigBlueButton (BBB) oder “Jitsi Meet” empfohlen!
Es hat sich bewährt, die Funktionalität auf zwei eigenen Geräten (z.B. Smartphone und Tablet) im „Livebetrieb“ zu demonstrieren. Hier kann in bereits bestehende Einzel- und Gruppenchats geschaut werden („Oh, das sieht aus wie bei WhatsApp“) und aufkommende Fragen direkt geklärt werden.
2. Mögliche Umsetzung
- Entscheidung Jabber (XMPP) oder nicht (Mail-Chat nur bei zusätzlichem Interesse)
- Einrichtung auf persönlichem Gerät - oder mehreren Geräten der Verantwortlichen und Interessierten
- persönliches Konto / zusätzlich pseudonymisiertes Konto anlegen
- App installieren
- evtl. Einstellungen zeigen
- öffentlicher Raum für “Schulen”
- Erste, grobe Inhalts-/Themenformulierung
- Messengerkompetenz
- Messengernutzung
- ggfs. später technischer Betrieb
- Information und Einbeziehung Fachkonferenz Medienbildung / Kollegium
- Besprechung in Fachkonferenz Medienbildung / Kollegium
- welche Fächer - welche Themen
- welche Klassenstufen
- welche Inhalte, zeitlicher Aufwand
- zeitliche Abstimmung fachübergreifend
- Informationen/Veranstaltungen (Information/Nutzung)
- Elternbrief für Minderjährige
- stille Einführung in Klassen oder große Vorstellung?
- Wissensvermittlung / Nutzung
Der Aufwand und die Tiefe ist von/durch die Schule steuerbar!
3. Entscheidung ob / weitere Vorgehensweise
Sobald der/die Verantwortliche hinter der Sache steht, kann dann die weitere Vorgehensweise besprochen werden.
Die Einführung von freien Messengern an Schulen kann in verschiedene Themenbereiche unterteilt werden, die aufeinander aufbauen. Bei allen Bausteinen sollte eine entsprechende Planungs- und Einführungsphase stattfinden:
1) “Messengerkompetenz”
Hierunter fällt alles, was mit der Information und Aufklärung im Rahmen des Unterrichts zusammenhängt.
Theoretische Inhalte:
- Was ist Kommunikation?
- Was macht WhatsApp? / Was sind freie Messenger?
- Was ist Interoperabilität und warum sind internationale Standards überall so wichtig?
- Was bedeutet Datenschutz und Privatsphäre?
- Was versteht man unter Metadaten? Warum sind diese für Firmen so interessant?
- Was ist Verschlüsselung und wie funktioniert diese prinzipiell?
- Auf welchen Geräten kann getextet werden?
- Mobbing, Datensicherheit, …
Praktische Inhalte:
- Anlage und Nutzen von Chat-Konten auf Smartphones und PC
- Verschlüsselung
- Datensicherung
- Netzwerkstrukturen, …
Generell gilt:
Im Vorfeld ist zu entscheiden (zu planen), welche Inhalte in welchen Fächern/Bereichen vermittelt werden sollen. Ob die Themen bereits aufbereitet präsentiert - oder im Unterricht selbst erarbeitet werden, liegt in der Eigenkompetenz der jeweiligen Lehrkraft.
2) “Messengernutzung”
Aktive Nutzung von freien Alternativen. Ziel sollte sein, unabhängig von der Nutzung von WhatsApp oder sonstigen zentralen Lösungen zusätzlich über einen freien Messenger erreichbar zu sein.
Mögliche Nutzergruppen:
- Schüler
- Klassengruppen
- Lerngemeinschaften
- Lehrkräfte (privat)
- Kollegium (Nutzung muß genehmigt werden)
3) “Technischer Betrieb”
Je nach fachlicher Kompetenz an der Schule - und Interesse seitens der Schüler - kann auch ein eigener Schulserver eingerichtet und betrieben werden. Als „Steigerung“ und Alternative für mögliche technische Lösungen könnte auch die quelloffene Socialmedia-Plattform „Movim“ (XMPP) (extern) oder eine quelloffene Team-Software wie „Mattermost“ (extern) in Frage kommen.
Für den Unterricht
>> Hier werden noch Inhalte und Dokumente beispielsweise zu „Privatsphäre vs. Datenschutz“, „Freie Software“ oder „Verschlüsselung“ gesucht. <<
Für Bildungseinrichtungen
Unterrichtseinheit |
Unterlagen |
Vorlage/Muster für Information „virtuelles Klassenzimmer“ (Information über freie und anbieterunabhängige Messenger-/Videokonferenz-Systeme) |
Information (.PDF) (Druckversion 04/2020) Information (.ODT) (Libre-Office-Datei; Version 04/2020) |
>> Hier werden noch weitere Inhalte und Dokumente wie z.B. „Administratives“, „Arbeitsanweisungen“, „Leitfäden“ oder „Schulregeln“ gesucht <<
Allgemein
Faltblatt
… zum Thema „Schulischer Datenschutz“:
Das Faltblatt kann in der aktuellen Version als Druckdatei direkt heruntergeladen und frei weitergegeben werden: Schulischer Datenschutz (extern) (PDF-Datei)
Quelle: Landesbeauftragter für den Datenschutz und die Informationsfreiheit Rheinland-Pfalz
Fragwürdige Empfehlungen im Faltblatt
In der aktuellen Version (Stand November 2019) ist formuliert:
„Sofern eine Lehrkraft es als notwendig erachtet, über Messenger mit Eltern, Schülerinnen und Schülern zu kommunizieren, kommen nur europäische Anbieter, die eine Ende-zu-EndeVerschlüsselung anbieten, in Betracht (z. B. Wire, Hoccer, Pidgin/OTR, Chiffry oder Threema).“
Warum explizit gerade diese Systeme als Beispiele genannt werden ist fragwürdig, denn …
- Wire hat den Hauptsitz in die USA verlegt,
- Hoccer ist nicht für Kinder/Jugendliche zu empfehlen (und hat den Betrieb im Mai 2020 eingestellt),
- Pidgin ist nur eine App und kein Anbieter/kein Messengersystem,
- Chiffry ist nur in einer sehr eingeschränkten Basisversion kostenlos und
- Threema ist ebenfalls nicht kostenlos.
- Zudem sind die meisten aufgeführten Systeme nicht quelloffen.
Alternativ zu „nur europäische Anbieter …“ könnte neutral formuliert werden:
„Im Geltungsbereich der DSGVO + Ende-zu-Ende-Verschlüsselung + open source von Server und Client“.
Dies wurde dem Landesbeauftragtern für den Datenschutz und die Informationsfreiheit Rheinland-Pfalz am 31.12.2019 mitgeteilt - bisher noch ohne Reaktion bzw. Änderung des Leitfadens.
Ergänzend wird an dieser Stelle auf die Forderungen der Politik und die Empfehlungen von diversen Datenschutzbeauftragten sowie die Informationen bei „Warum nicht?“ hingewiesen.
Exkurs: Unfreie Messenger
Am Markt gibt es verschiedene Anbieter, die kommerzielle Produkte für Schulen / Bildungseinrichtungen anbieten oder planen. Eine schöne Sammlung zu „Schulische Plattformen (Kommunikation)
als Alternativen zu WhatsApp“ von Mr. Tee gibt es >> hier << (extern). In diesem Padlet ist auch „schul.cloud“ aufgeführt …
schul.cloud / Stashcat
„schul.cloud“ mit Punkt (heinekingmedia) ist nicht mit “Schul-Cloud” mit Bindestrich und groß geschrieben (Hasso-Plattner-Institut) gleichzusetzten/zu verwechseln!
Hinter der schul.cloud (mit Punkt) verbirgt sich “Stashcat” der Fa. heinekingmedia: https://schul.cloud/sicherheit/technologie (extern)
Was evtl. gegen schul.cloud (stashcat) spricht: >> hier <<
IServ
Von der Firma IServ liegt folgende Information vom 19.11.2018 vor:
„Der [geplante] Messenger ist für die schulinterne Kommunikation gedacht. Er läuft auf den jeweiligen Servern der Schulen, wir selbst betreiben die Infrastruktur nicht. Er ist nicht für die private Kommunikation gedacht, wir treten damit nicht in den Wettbewerb mit Diensten wie Whatsapp. Eine Verbreitung über die jeweilige Schule hinaus ist also auch nicht unser Ziel. Selbst wenn wir in Zukunft die Möglichkeit implementieren würden, den Dienst nach außen hin zu öffnen, bleibt das in jedem Fall eine Entscheidung der Serverbetreiber, ob diese das tatsächlich möchten. Damit geht ja nicht nur Positives einher.“
Anmerkung: Weitere Anbieter/Produkte bitte >> hier << melden.
Gemeinsamkeiten
Allen Lösungen gemeinsam ist, daß der Benutzer für die Nutzung wieder eine neue, inkompatible Messenger-App installieren muß. Auch haben diese keine offenen Schnittstellen, die das Bundesjustizministerium fordert (Offenes WhatsApp) und der Quellcode ist nicht einsehbar.
Interessant in diesem Zusammenhang ist auch das Thema, ob/wie berufliche Nachrichten auf privaten Geräten erlaubt sind.
- Lesezeit ganze Rubrik: 48 Minuten - |
Anbieterabhängige, unfreie Messenger wie WhatsApp haben in unserem Rechtsstaat als Wirtschaftsfaktor eine legitime - wenn auch zu Recht umstrittene - Rolle. Dennoch ist eine freie und anbieterunabhängige Kommunikation beim Chatten gesellschaftlich erstrebenswert, so wie das bei E-Mail, Telefon oder Mobilfunk schon immer selbstverständlich ist. Abhängigkeiten von zentralen Instanzen können hier fatale Folgen haben.
Auf Grund der aktuellen Dominanz von WhatsApp (zumindest in Europa) kann sich freier Chat nur weiterentwickeln und etablieren, wenn jeder einzelne die Bereitschaft zeigt, seinen Kontakten zumindest 1 freie Chatmöglichkeit als Kommunikationskanal anzubieten.
Paradoxerweise führt die Nutzung von geschlossenen WhatsApp-Alternativen als Ergänzung zu WhatsApp nicht zu einer Schwächung der marktbeherrschenden Situation - sondern der Platzhirsch wird dadurch gestärkt.
Auch ist es in der Regel so, dass die Mehrzahl der Privatnutzer in Europa (99% ?) WhatsApp aktuell nicht löschen wollen/können. Es wird nicht tatsächlich nach einer “Alternative” und Ersatz gesucht - sondern nach einer unabhängigen und/oder datenschutzfreundlichen Ergänzung, die die Privatsphäre respektiert.
Um frei zu Chatten muss man Messenger nicht wie Briefmarken sammeln. Auch wenn es heutzutage leicht fällt, mal eben noch diese oder jene App zu installieren, so bedeutet jede zusätzliche Installation doch einen gewissen Ressourcenverbrauch (Energie, Rohstoffe, Speicherplatz, Zeit). Deshalb habe ich für beide Gruppen jeweils eine Empfehlung:
WhatsApp-Ersatz
Ich schätze den Anteil in der Bevölkerung derer, die tatsächlich einen Ersatz für WhatsApp suchen (und WhatsApp löschen wollen) als extrem gering ein.
Für diese (kleine) Gruppe empfehle ich ausschließlich “anbieterunabhängigen, freien Chat” und nicht eine Insellösung wie Signal, Telegram, Threema, Viber usw.
Warum?
Alle diese selbsternannten Alternativen werden auf Grund ihrer zentralen Struktur nie die Erreichbarkeit wie WhatsApp (oder ein offenes Chatsystem) haben und man löst nicht das Problem der Abhängigkeit.
WhatsApp-Ergänzung
Alle Privatnutzer, die WhatsApp derzeit nicht löschen wollen oder nicht löschen können empfehle ich, neben WhatsApp keine X weiteren unfreien Lösungen zu installieren. Hier ist es besser, seinen Kontakten zumindest einen freien Messenger als Ergänzung anzubieten, um auch unabhängig und datenschutzfreundlicher erreichbar zu sein:
Empfehlung
Als echte Alternative zu WhatsApp mit dem größten Potential kann deshalb mit gutem Gewissen normaler „Chat” (normal = auf der Basis von internationalen Standards) empfohlen werden, da hierdurch die oft geforderte Interoperabilität ermöglicht wird.
Für Unternehmen oder Behörden bietet sich der Einsatz von Matrix als Teammessenger an, da hier eine Brücke zum Chatstandard möglich ist.
Natürlich gibt es zu jedem System neben Anhängern auch Kritiker, die einzelne Punkte bemängeln oder es als Ganzes ablehnen. Gründe hierfür können konzeptioneller Art sein, technische Rahmenbedingungen oder auch in der Privatsphäre oder dem Datenschutzes liegen. Jeder Nutzer hat eigene Anforderungen und eigene Maßstäbe an ein Messengersystem und wie so oft, kann man nicht alles gleichzeitig haben.
Kurz: Es gibt unterschiedliche Meinungen und nicht den „besten“ Messenger.
Verwaltung / BOS / Medien
Vorwort
In der öffentlichen Verwaltung - aber auch bei Behörden und Organisationen mit Sicherheitsaufgaben (BOS / BORS) - wird am Einsatz von Messengern gearbeitet oder es sind teilweise bereits unterschiedliche Lösungen im Einsatz. Allen gemeinsam ist der nachvollziehbare Wunsch, einfach und sicher Informationen auszutauschen.
Leider ist es bei „Chat“ so, dass es zwar öffentlich zugängliche und herstellerunabhängige Systeme gibt - so wie das bei E-Mail, Telefon oder Mobilfunk selbstverständlich ist - allerdings steht hier keine Firma mit entsprechendem Werbebudget im Hintergrund.
Das bedeutet wiederum, dass auf Grund von fehlendem Wissen auf glitzernde (Werbe-)Aussagen von Firmen vertraut und viel Geld doppelt oder gar mehrfach für Spezialentwicklungen ausgegeben, die nicht der Öffentlichkeit zu Gute kommen, sondern Firmeneigentum und nur gegen Bezahlung nutzbar sind. Der Markt wird dadurch sehr lukrativ.
In der Folge gibt es gerade in diesem wichtigen Bereich viele verschiedene Projekte, die jedoch untereinander nicht föderieren bzw. nicht kompatibel sind. Auch ist (mir) nicht bekannt, ob mit Nutzern des jeweiligen Systems auch außerhalb der Verwaltungseinheit kommuniziert werden kann. Hier bin ich um jede Information dankbar!
Um die Vielfalt bzw. das Durcheinander zu veranschaulichen, folgt eine Übersicht der mir derzeit bekannten, im Einsatz befindlichen oder geplanten Messengern in öffentlichen Verwaltungen und „BOS“. Allein hier sind schon über 10 verschiedene Systeme aufgeführt!
In der Öffentlichkeit (und in der Verwaltung) wird noch zu wenig zwischen unfreien, zentralen Systemen auf der einen Seite und freien, dezentralen Systemen auf der anderen Seite unterschieden. Deshalb ist das nachfolgend entsprechend mit vermerkt …
Deutschland
Bundesweit
Bundespolizei: „MOKA“ („Jabber(XMPP)“) - quelloffen, frei, zentral
„Bei der Bundespolizei befindet sich derzeit ein auf dem offenen Protokollstandard XMPP (Extensible Messaging and Presence Protocol) basierender Messengerdienst im Probebetrieb. Dieser Standard ermöglicht auch die Kopplung verschiedener Messengerdienste (vergleichbar wie bei E-Mail, Stichwort: Föderationsfähigkeit), so dass von Seiten der Bundespolizei kein Bedarf für die Einführung eines behördenübergreifenden Messengerdienstes gesehen wird. Stattdessen könnte eine verbindliche Festlegung auf einen Protokollstandard wie XMPP erfolgen, so dass eine behördenübergreifende Messengerkommunikation mit (ggf.) unterschiedlichen Messengerlösungen möglich wird (vergleichbar wie im Bereich der E-Mail-Kommunikation). Die Bundesregierung wird diese Einschätzungen der Bundespolizei mit Abschluss des Probebetriebs bewerten und gegebenenfalls weitere Maßnahmen prüfen.“
Quelle: Antwort der Bundesregierung zu Polizei im digitalen Zeitalter (extern) vom 14.11.2019
Vgl. auch: Antwort der Bundesregierung zu Digitalfunk und Einsatzkommunikation (extern) vom 11.09.2018
Zuletzt bei der Bundespolizei erwähnt im Jahresbericht 2020 (extern) auf Seite 48 vom 02.11.2021
Aber: Vermutlich ist keine Föderation mit anderen Servern möglich. Hier bitte ich um eine Information oder Korrekturmitteilung, falls das doch der Fall sein sollte.
Bundeskriminalamt: „SE-Netz“ (SE = Spezialeinheiten) - unfrei, zentral, Firmeneigentum
„Das BKA wurde durch den AK II mit der Bereitstellung eines zentralen Einsatzkommunikations- und Unterstützungssystems (EKUS) für die Spezialeinheiten der Polizeien des Bundes und der Länder beauftragt. Als Produkt wurde durch den AK II die Software „SE-Netz“ des Fraunhofer-Instituts für Verkehr und Infrastruktur (Fh-IVI) festgelegt. Gegenwärtig erfolgt der Aufbau des Zentralsystems im BKA, die Datenanbindung der EKUS-Teilnehmer sowie die Ertüchtigung des Produkts im Hinblick auf Zentralsystemfunktionalitäten durch den Hersteller.“
Quelle: Antwort der Bundesregierung zu Polizei im digitalen Zeitalter (extern) vom 14.11.2019
Vgl. auch: Antwort der Bundesregierung zu Digitalfunk und Einsatzkommunikation (extern) vom 11.09.2018
Bundeswehr:
- „BwMessenger“ (Matrix-Protokoll - frei, zentral, quelloffen)
Quellen:
heise.de (extern) vom 24.12.2019
bwi.de (extern) vom 18.11.2020
Aber: Wird nur Bundeswehr-intern genutzt; keine Interoperabilität; keine Föderation mit anderen Servern; kein Einsatz von Brücken zu anderen Systemen. Hier bitte ich um eine Information oder Korrekturmitteilung, falls das doch der Fall sein sollte.
- „Facebook“ (zentral, unfrei) als Marketing-Instrument
Quelle: team-hr.de (extern) von 2019
Diverse Ministerien: „Wire“ für VS-NfD (?)
- Ausgehend vom Kanzleramt nutzen mehr als 30 Ministerien und Behörden den Messenger Wire für Verschlußsachen, Informationen Nur für den Dienstgebrauch (VS-NfD)
Quelle: BSI Magazin - Ausgabe 2020 / 02 - vom 15.12.2020 (extern, PDF-Datei ca. 9 MB, auf Seite 10)
Im Papier heißt es u.a.:
„_Die Auswahl reduziert sich jedoch drastisch, wenn neben Benutzerfreundlichkeit auch Aspekte wie IT-Sicherheit oder Datenschutz eine Rolle spielen und Informationen ausgetauscht werden sollen, die nach der VSA „VS - Nur für den Dienstgebrauch“ eingestuft sind. Für eine sichere Kommunikation zwischen Teilnehmerinnen und Teilnehmern innerhalb der Netze des Bundes (NdB) und dem offenen Netz bleibt schließlich keine der modernen Lösungen übrig._“
Die Behauptung „es bleibt schließlich keine moderne Lösung übrig“ scheint von Lobbyisten zu stammen, denn sie stimmt nicht. Seit Jahren gibt es bewährte Systeme und internationale Standards hierfür.
Auch ist es nicht so, daß Wire zugelassen wäre, sondern es ist (wie andere Produkte) auch nur innerhalb des für VS-NfD zugelassenen Netzes erlaubt. Sollte es ein tatsächliches Zulassungsdokument geben, würde mich dieses sehr interessieren. >> Kontakt <<
Querverweise: Empfehlung (s.u.), Schnellübersicht Messengersysteme
BundesMessenger
Souveränität und Sicherheit und Freiheit. Freier Messenger für die öffentliche Hand.
Der BundesMessenger ist eine sichere Messaging-Lösung für die Öffentliche Verwaltung. Von der BWI für die Behörden in Deutschland. Die Beta Phase ist aktiv.
In den häufig gestellten Fragen (HGF/FAQ) findet sich der Hinweis, daß hierfür Matrix verwendet wird bzw. der Messenger der Bundeswehr (BwMessenger) als Vorlage genommen wurde.
Da der Bundeswehr-Messenger ausschließlich für Angehörige der Bundeswehr ist, kann davon ausgegangen werden, daß der BundesMessenger ebenfalls keine interoperable Lösung ist und ebenfalls ausschließlich für bestimmte Verwaltungseinheiten und vermutlich nicht für die Kmmunikation auch mit den Bürgern ist. Schade. So wie es aussieht, wird es wieder keinerlei standardisierte Schnittstelle “nach außen” geben.
Es wird ausdrücklich darauf hingewiesen, daß es sich das Projekt noch in der Beta-Phase befindet. Trotzdem wäre etwas mehr Information gut. Antworten auf Fragen wie z.B. …
- Wann hat die Betaphase begonnen/bis wann geht diese?
- Wer ist beteiligt?
- Gibt/gab es eine Ausschreibung?
- Was sind/waren die Vorgaben/Rahmenbedingungen?
- Sprechen evtl. Datenschutzgründe gegen eine generelle Öffnung? Welche konkret?
- Wichtig: Ist / wie ist eine offene Kommmunikation von Bürgern und Verwaltung geplant?
- Ergänzende Informationen zur Interoperabilität bzw. zur Nutzung von internationalen Standards/Brücken?
… wären interessant zu wissen.
Es bleibt zu hoffen, daß im Rahmen der Betaphase eine funktionierende und zuverlässige Brücke zum Chatstandard (XMPP) entwickelt/sichergestellt wird, denn eine weitere rein verwaltungsinterne Messengerinsel wäre nicht wirklich “für alle” bzw. Interoperabilität nur auf dem Papier und schönes Marketing.
Es wird also spannend, ob am Ende der Betaphase auch die Interoperabilität durch Nutzung von internationalen Standards nach vorne gebracht wird.
“Souveränität und Sicherheit und Freiheit. Freier Messenger für die öffentliche Hand”
ist gut.
“Souveränität und Sicherheit und Freiheit. Freie Messenger für alle (auch die Bürger)”
wäre besser.
Quelle: https://messenger.bwi.de/bundesmessenger (extern; 22.12.2022)
Bundesländer
Baden-Württemberg: Threema (unfrei, zentral, Firmeneigentum)
Mit dem Pilotprojekt Messenger testet das Kultusministerium den pädagogischen Einsatz des Instant Messengers „Threema“ für die Schulen in Baden-Württemberg. Insgesamt nehmen 13 Schulen am Projekt teil. „Wir wollen die digitale Kommunikationsform dort einsetzen, wo sie pädagogisch und organisatorisch sinnvoll ist“
Quelle: km-bw.de (extern) vom 22.11.2019
Bayern:
- „TeamWire“ (unfrei, zentral, Firmeneigentum)
Quelle: stmi.bayern.de (extern) vom 16.05.2017
Quelle: heise.de (extern) von 05/2017
- „ByCS-Messenger“ (frei, zentral, basiert auf Element/Matrix, keine Interoperabilität, keine Matrix-interne Föderation)
Eine verpflichtende Nutzung für Schüler gibt es nicht - ggf. gilt für Lehrkräfte eine Verpflichtung für die dienstliche Kommunikation.
Aus den Nutzungsbedingungen: „Eine Nutzung für private Zwecke ist nicht zulässig.“
Quelle: bycs.de (extern) vom 04.02.2024
Aber: Keine Interoperabilität und vermutlich ist auch hier wie bei den anderen ‘großen’ Matrix-Instanzen keine Föderation (Kommunikation zwischen Nutzern verschiedener Matrix-Instanzen) aktiviert und somit unterbunden. Hier bitte ich um eine Information oder Korrekturmitteilung, falls das doch der Fall sein sollte.
Rheinlandpfalz: „poMMes“ (unfrei, zentral, Firmeneigentum)
Kurz für polizeilicher Multimedia Messenger – ist ein vom Polizeipräsidium für Einsatz, Logistik und Technik (PP ELT) in Mainz entwickelter Messenger
Quelle: e-recht24.de (extern) vom 31.05.2019
Niedersachsen: „NIMes“ (unfrei, zentral, Firmeneigentum; Basis: „Stashcat“)
Quelle: polizei.niedersachsen.de (PDF-Datei; extern) proPolizei Heft 04/2018
Nordrhein-Westfalen: „Logineo“ (frei, zentral, basiert auf Element/Matrix, keine Interoperabilität, keine Matrix-interne Föderation)
In NRW können Schulen Matrix über Server des Landes nutzen (Logineo NRW Messenger) mit gekoppeltem Jitsi.
Quelle: Schulministerium NRW (extern)
Aber: Förderation gibt es dabei jedoch nicht; die Instanzen sind abgeschottet. Es soll Überlegungen geben, die Instanzen soweit zu öffnen, dass zumindest eine Kommunikation zwischen Lehrkräften verschiedener Schulen möglich ist. Ob das jedoch tatsächlich kommt, muß abgewartet werden. Die Instanzen sind auch sonst stark eingeschränkt: Lehrer können Klassenchats öffnen; Schüler haben keine Möglichkeit, unabhängig davon untereinander zu kommunizieren.
Schleswig-Holstein und Hamburg: „Element Matrix“ (frei, zentral, basiert auf Element/Matrix, keine Interoperabilität, keine Matrix-interne Föderation)
„Similarly Dataport, a major IT service provider for public administration in Germany, will shortly begin to deploy a Matrix-based solution offering open source collaboration to 500k users across public offices and education throughout Schleswig-Holstein and Hamburg. The deployment, aimed at improving the region’s digital sovereignty, includes secondary schools and further education establishments in time for the September term. So far as we know, 500K users makes this the biggest single messaging and collaboration implementation in the world.“
Quelle: element.io (extern)
Aber: Keine Interoperabilität und vermutlich ist auch hier wie bei den anderen ‘großen’ Matrix-Instanzen keine Föderation (Kommunikation zwischen Nutzern verschiedener Matrix-Instanzen) aktiviert und somit unterbunden. Hier bitte ich um eine Information oder Korrekturmitteilung, falls das doch der Fall sein sollte.
Hessen: „HePolChat“ (unfrei, zentral, Firmeneigentum; Basis: „Stashcat“)
Lokal und Regional
Rathäuser, Landkreise, TV- und Radiosender, Presse u.ä. verwenden oft
- „WhatsApp“ (!) (unfrei, Firmeneigentum) und manchmal
- „Telegram“ (unfrei, Firmeneigentum).
Auch auch hier wäre zumindest die ergänzende Nutzung von öffentlichen Chat-Standards in der Kommunikation angebracht.
Schweiz
- „IMP“ (Instant Messenger Police) bei fast allen Polizeikorps (Code ist Firmengeheimnis; kostenpflichtig)
Quelle: Herstellerseite „abraxas“ (extern) Stand 01/2020
- „Threema“ bei der Verwaltung (Bundesamt für Informatik (BIT)) (kostenpflichtige Variante, Code ist Firmengeheimnis)
Quelle: golem.de (extern) vom 14.02.2019
Frankreich
- „Tchap“ für Französische Regierung (Matrix-Protokoll) (frei, zentral)
Quelle: heise.de (extern) vom 21.04.2019
Aber: Keine Interoperabilität und vermutlich ist auch hier wie bei den anderen ‘großen’ Matrix-Instanzen keine Föderation (Kommunikation zwischen Nutzern verschiedener Matrix-Instanzen) aktiviert und somit unterbunden. Hier bitte ich um eine Information oder Korrekturmitteilung, falls das doch der Fall sein sollte.
Europa
Auf europäischer Ebene wird in der NATO zumindest der freie Chatstandard (XMPP) eingesetzt.
Aber: Auch hier ist vermutlich keine Föderation aktiviert.
Sonstige
Die bisher genannten Lösungen kommerzieller Anbieter sind nicht abschließend. Es gibt es noch weitere wie z.B. govchat (extern) (unfrei).
Empfehlungen für freien Chat
Von verschiedensten Stellen wird auf allenen Ebenen freie Software (=freier Chat) gefordert oder empfohlen:
Bundesjustizministerium (BMJV)
Forderung für Öffnung und Dezentralisierung der Messengerdienste.
Bundesdatenschutzbeauftragter
„Behörden und Unternehmen, die meiner Aufsicht unterstehen, rate ich regelmäßig davon ab, WhatsApp zur internen Kommunikation zu nutzen. Aus meiner Sicht sollten die Bundesbehörden einen eigenen datenschutzfreundlichen Messenger entwickeln bzw. sich an der Weiterentwicklung eines freien Messengers beteiligen, der dann schrittweise auch für die Kommunikation mit den Bürgern geöffnet werden könnte. Hierbei bietet sich die Entwicklung auf Open-Source-Basis natürlich in besonderem Maße an.“
Quelle: Pers. Schreiben vom 29.10.2019
Datenschutzbeauftragte aus anderen Bereichen
Aber auch Datenschutzbeauftragte aus der Wirtschaft oder den Kirchen empfehlen freien Chat. Hier ein Beispiel der Kirche:
„Die Entwicklung sowie der Einsatz und Betrieb eines eigenen Messenger-Dienstes in Kirche und Diakonie auf Basis von etablierten und frei zugänglichen Protokollen auf föderalen Servern wäre aus Sicht des
Beauftragten für den Datenschutz der EKD die beste Lösung und wird daher empfohlen.“
Quellen:
Parteien stehen zu offenem Quellcode
Fast alle Parteien sind sich einig, dass „public money - public code“ (extern) ein wichtiger Bestandteil bei IT-Entscheidungen sein sollte. Mit öffentlichen Geldern entwickelte Software soll als Freie Software allen Zugute kommen. Nun hat sich sogar die CDU angeschlossen und das in ihrem Parteitagsbeschluß im November 2019 in das Programm mit aufgenommen:
„Die offenen und gemeinsam entwickelten Standards des Internets und die offenen Schnittstellen sind die Prinzipien, die wir für die Digitalisierung Deutschlands heranziehen. Nur durch Offenheit entsteht Wettbewerb, nur durch Offenheit können neue Akteure im Wettbewerb die Platzhirsche herausfordern. Deshalb gilt künftig für alle (öffentlichen) Digitalisierungsprojekte in Deutschland: Auftragsvergabe und Förderung sind an die Einhaltung der Prinzipien Open-Source und offene Standards gebunden. Durch öffentliche Mittel finanzierte Software soll allen Bürgern dienen. Zusätzlich sollen freie und offene APIs den Zugang für unabhängige Entwicklungen erleichtern.“
Bundesregierung
Wenige Tage nach dem Parteitagsbeschluß unterstreicht Bundeskanzlerin Merkel die Forderung in der Generaldebatte im Bundestag:
”… Das bedeutet aber als erstes mal, dass ich alles digitalisiert vorhanden habe, dass ich weiß, was ich habe. Wir sind dafür und ich kucke gerade Nadine Schön an, dass wir das auch möglichst im offenen, im ‘Open-Data’-Bereich machen - als ‘Open Source’ - dass das durchschaubar ist. Aber meine Damen und Herren, dass man daraus neue Produkte machen kann, dafür brauchen wir noch einen Kulturwandel in Deutschland der versteht, dass das dringlich ist. Und ich habe den Eindruck, dass wir da viel, viel zu langsam sind. Und dass wir sozusagen als Abgeordnete die Botschafter sein sollten ‘verschlaft diese Zeit nicht’, sonst werden Wertschöpfungsmodelle an uns vorbeigehen und wir werden zur verlängerten Werkbank - das ist meine ganz große Sorge aber ich glaube als Bundesregierung sind wir jetzt auf dem richtigen Weg. …”
Quelle: Video von invidio.us (extern)
Bildungswesen
Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Rheinland-Pfalz hat ein Faltblatt zum schulischen Datenschutz veröffentlicht. Hier heißt es u.a.:
„Zur schulischen Kommunikation zwischen Lehrkräften und Schülerinnen und Schülern steht den Schulen u. a. eine landeseigene, kostenfreie, auf Moodle basierende Lernplattform zur Verfügung: http://lernenonline.bildung-rp.de (extern) Diese gewährleistet die Datensicherheit durch die Verwendung eines landeseigenen Servers. Sofern eine Lehrkraft es als notwendig erachtet, über Messenger mit Eltern, Schülerinnen und Schülern zu kommunizieren, kommen nur europäische Anbieter, die eine Ende-zu-EndeVerschlüsselung anbieten, in Betracht (z. B. Wire, Hoccer, Pidgin/OTR, Chiffry oder Threema).“
Quelle: Faltblatt Stand Nov. 2019
Anmerkung:
Der Herausgeber wurde darauf hingewiesen, dass Wire den Hauptsitz in die USA verlegt hat, Hoccer nicht für Kinder zu empfehlen ist (Ergänzung: Hoccer hat den Dienst im Mai 2020 eingestellt!), Pidgin nur ein mögliches Programm eines freien Messengersystem ist, Chiffry nur in einer sehr eingeschränkten Basisversion kostenlos ist und Threema ebenfalls nicht kostenlos ist. Zudem sind die meisten nicht quelloffen. Des Weiteren wird formuliert “europäische Anbieter”. Das können
folglich auch Anbieter u.a. aus der Ukraine, Moldavien und Weißrussland sein.
Es wurde der Vorschlag gemacht, hier alternativ statt dessen eine neutrale Formulierung wie „Im Geltungsbereich der DSGVO + E2EE + Open source von Server und Client“ zu verwenden.
Mehr zu Messengern im Bildungswesen: >> hier <<
Krankenhäuser
In den „technischen Datenschutzanforderungen an Messenger-Dienste im Krankenhausbereich“ wird empfohlen:
„Es sollte zumindest optional der Einsatz offener Kommunikationsprotokolle (z.B. XMPP) möglich sein, um eine Kommunikation mit anderen Messenger-Diensten zu ermöglichen.“
Quelle: Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder vom 07.11.2019
Polizeiliches Umfeld
Im Umfeld von Berufsgeheimnisträgern wird verstärkt über freie (und sichere!) Lösungen berichtet. So zum Beispiel im ausführlichen Artikel „Sichere Messenger bei der Polizei“
Freie Messenger
Zusammenfassung
Durch eine solch unstrukturierte und gesamtgesellschaftlich unüberlegte (aus der Not heraus entstandene) Vorgehensweise mit verschiedensten Projekten gehen Millionen an Steuergeldern verloren. Außerdem begibt sich die öffentliche Hand ohne Notwendigkeit in eine kaum noch aufzulösende Abhängigkeit. Aus Sicht der zwingend einzuhaltenden Datenschutzbestimmungen müssen Systeme, bei deren Funktionen sich die Verwaltung blind auf die Aussagen kommerzieller Anbieter verlassen muss, ebenfalls als bedenklich eingeschätzt werden.
Wie bei E-Mail, Telefon oder Mobilfunk sollte eine freier Austausch auch beim Chat eine Selbstverständlichkeit sein - das ist möglich. Alle Funktionen der kommerziellen Produkte können auch auf Basis von standardisierten Protokollen realisiert werden. Hierzu muss sich die Messengerkompetenz bei Entscheidungsträgern verbessern und Lobbyisten in die Schranken verwiesen werden.
Bei allen Überlegungen sollte deshalb ein Grundgedanke über allem schweben: Steuergelder sollten nicht in Projekte gesteckt werden, die eine Abhängigkeit von Herstellern zur Folge haben. Besser formuliert:
Öffentliche Gelder -> öffentlicher Programmcode und öffentliche Daten |
Steuergelder sollten nur in Projekte gesteckt werden, die unabhängig von Herstellern sind. |
Empfehlung
Im Gegensatz zur privaten Nutzung, bei der eine klare Empfehlung ausgesprochen werden kann, ist das bei der öffentlichen Hand jedoch nicht so einfach.
Aktuell wird gerne auf Matrix gesetzt, da dieses für Ausfallsicherheit von Chaträumen optimal ist. Da jedoch bei aktivierter Föderation der komplette Chatverlauf auf alle Server der am Gespräch beteilgten Teilnehmer synchronisiert wird, ist das datenschutzrechtlich problematisch (Stichwort „Auftragsdatenverwaltung“). Deshalb bietet sich der Einsatz einer Brücke zum internationalen Standardprotokoll für Chat („XMPP“) nicht nur an, sondern ist auch sehr zu empfehlen.
Derzeit empfehle ich deshalb die Kombination der Protokolle XMPP und Matrix: “X[M]PP”.
Querverweis: Interoperabilität
Vorab
Zum Thema „Messenger“ gibt es schon reichlich Übersichten, die bei der Entscheidungsfindung helfen können: >> hier <<
Grundsätzlich gilt jedoch: Es gibt keinen „besten“ oder „sichersten“ Messenger”, jedes System hat Stärken und Schwächen. Hierzu ein sehr informativer Artikel:
https://www.kuketz-blog.de/kommentar-den-idealen-messenger-wird-es-nie-geben/ (extern)
Jeder Anbieter wird „sein“ Produkt, d.h. „seinen“ Messenger in Vergleichen immer positiv darstellen und es gibt kaum brauchbare Vergleiche und wenn, dann fehlen oft wichtige Merkmale.
Das war der Grund, eine eigene, unabhängige Übersicht von Messengersystemen zu erstellen.
Alle hier aufgeführten Systeme sind dezentral und frei. Dennoch gibt es auf Grund des unterschiedlichen, technischen Aufbaus (Protokolle) wesentliche Unterschiede. Das hat den Vorteil, dass man das für sich passende System wählen oder auch mehrere parallel nutzen kann - oder als Ergänzung zu seinem bisherigen Lieblingsmessenger.
In welchen Fällen ist Jabber(XMPP) die bessere Wahl?
Wenn der Onlinestatus übermittelt und angezeigt werden soll.
Wenn gleichzeitig mehrere unterschiedliche Konten genutzt werden sollen
(z.B. für persönliche, private, anonyme oder geschäftliche Kontakte).
Wenn Gruppen nur von bestimmten Personen administriert werden sollen.
Manche Teilnehmer nur Lesezugriff erhalten sollen.
In welchen Fällen ist ein E-Mail-Messenger die bessere Wahl?
Wenn „einfach jeder“ erreicht werden soll.
Mit einem E-Mail-Messenger sind deutlich mehr Empfänger bzw. Kontakte möglich als z.B. bei WhatsApp (weltweit alle E-Mail-Adressen - und über Mailinglisten auch sehr große Gruppen gleichzeitig).
Wenn formlose E-Mails ausgetauscht werden sollen.
Sicherheitshinweis:
Kommuniziert man mit jemanden, der keinen kompatiblen E-Mail-Chat-Messenger installiert hat, wird die Nachricht nicht (nur für die Empfänger lesbar) verschlüsselt, sondern unverschlüsselt gesendet. Im „schlimmsten Fall“ wird diese auch noch über E-Mail-Server zu Empfängern geleitet, die untereinander nicht (per TLS) verschlüsselt sprechen.
Das bedeutet, daß Nachrichten an klassische E-Mail-Kontakte evtl. als lesbare „Postkarte“ unterwegs sein können.
Wesentliche Unterschiede zw. Conversations (XMPP) und Delta Chat (IMAP)
Wesentliche Unterschiede |
Conversations (XMPP) |
Delta Chat (IMAP) |
Kommunikation möglich mit … |
Conversations und alle anderen Messenger auf XMPP-Basis (kleinere Nutzergruppe) |
Delta Chat und alle E-Mail-Programme (größtmögliche Nutzergruppe) |
Mehrere Konten im selben Messenger möglich |
ja |
nein |
Onlinestatus möglich |
ja |
nein |
Teilnehmerberechtigungen in Gruppen/Konferenzen |
Eigentümer, Administrator, Mitglied, Leser |
alle gleichberechtigt |
Öffentliche Gruppen |
ja |
nein |
Speicherort der Kontakte |
bei Serverbetreiber |
auf Endgerät |
Tabelle: Stand 05/2018
In welchen Fällen ist “Briar” die richtige Wahl?
Wenn eine anonyme und maximal (daten-)sichere Kommunikation erforderlich ist
(z.B. in sicherheitskritischen Bereichen; in Krisen- und Kriegsgebieten; sicherheitsaffine Anwender).
Wenn eine Kommunikation ohne Internetzugang möglich sein soll (z.B. in geschlossenen Arbeitsbereichen, Lebensgemeinschaften - oder auch bei zerstörter Infrastruktur).
Wenn auch lokal kein gemeinsamer Server vorhanden ist (die Geräte der Benutzer verbinden sich direkt über Bluetooth oder WLAN miteinander).
Wenn das Tor-Netzwerk genutzt werden soll (Voraussetzung hier: Internetzugang).
Ideal für Personen mit erhöhtem Sicherheitsbedürfnis wie Aktivisten und Journalisten.
Bewertungsreihenfolge
Für eine Entscheidung könnte man auch Systeme unter verschiedenen Gesichtspunkten „sortieren“:
Datenschutz, Privatsphäre & Sicherheit (von hoch nach niedrig)
Briar >> Jabber(XMPP) mit OMEMO >= Matrix mit Verschlüsselung >> Signal >> Telegram ~ Threema >> WhatsApp
Stromverbrauch (Mobilgerät - von gering nach hoch)
Jabber(XMPP), Signal >> Matrix >> Briar
Funktionsumfang (von viel nach wenig)
Matrix >> Jabber(XMPP), … >> Briar
Kompatibilität (vorhanden/nicht)
Jabber(XMPP) <-> Matrix (Telegram bedingt)
Es kommt also immer darauf an, worauf man Priorität legt. Für eine detailliertere und sachliche Bewertung bietet sich deshalb eine Nutzwertanalyse an.
In Firmen/Organisationen/Behörden ist es immer wieder Aufgabe der Abteilung „IT/EDV“ eine Übersicht von „sicheren“ Messengern zu erstellen, die dann als betriebsinterne Entscheidungsgrundlage dient.
Von der Erstellung einer neuen „Welche Messenger gibt es am Markt“-Übersicht kann nur abgeraten werden (es gibt hunderte Messenger!).
Statt dessen werden verschiedene Übersichten als Einstieg und Grundlage empfohlen: >> hier <<
Jede Firma, Behörde oder Organisation hat eigene Anforderungen an ihr IT-System, weshalb i.d.R. ein Pflichtenheft als Entscheidungsgrundlage erstellt wird. In diesem sind alle entscheidungsrelevanten Punkte und Kriterien aufgeführt.
Kriterien und Bewertung
Als Anregung für eine Kriteriumsübersicht wird hier auf die nach unterschiedlichen Bereichen sortierte Übersicht von „freie-messenger.de“ verwiesen. Diese darf frei verwendet und für eigene Zwecke geändert/ergänzt/angepasst werden. Um eine nachvollziehbare Entscheidung zu erhalten, die dann auch von allen Beteiligten akzeptiert wird, sollten die einzelnen Bereiche bzw. Kriterien in einer Nutzwertanalyse erst gewichtet und dann bewertet werden.
Wichtig ist, dass sich die beteiligten Stellen auf eine gemeinsame Vorgehensweise einigen und dann entsprechend die Kriterien bewerten.
Bei vielen Vergleichen ist das Kriterium „Sicherheit“ ist oft Augenwischerei von Firmen, die ihr Produkt verkaufen möchten und sollte deshalb bei einer Aufstellung von Kriterien genau definiert und vom Datenschutz abgegrenzt werden sollten. So z.B. AGB, Erhebung von Metadaten, Quelloffenheit, Serverkommunikation, Verschlüsselungstechnik, Identifikationskennzeichen, …
Eine sichere Ende-zu-Ende-Verschlüsselung wird überbewertet - Sie ist nicht der Maßstab sondern lediglich eine Grundvoraussetzung, die alle aktuellen Systeme/Messenger beherrschen sollten.
Bei der Entscheidung, welcher Messenger eingesetzt werden soll, spielt auch die Netzwerkstruktur eine Rolle. Neben diesen zugrundeliegenden, technischen Gegebenheiten ist es hilfreich, die hierauf aufbauenden Kommunikationsregeln („Protokolle“) von den Anwendungsprogrammen („Clients“) zu unterscheiden und auch hier eigene Anforderungen festzuhalten. Wichtige Fragen, an die man zunächst vielleicht nicht denkt können sein: Soll/muß das Protokoll z.B. überprüfbar, allgemeinverfügbar, erweiterbar sein? Gibt es Entwicklungmodell, das nicht zuletzt auch den Umgang mit entdeckten Fehlern („bugs“) berücksichtigt? …
Im Vorfeld können auch bestimmte Pflicht- oder k.o.-Kriterien benannt werden.
Mögliche Maßstäbe für die Punktevergabe sind sehr individuell:
- 5er-System mit neutraler „Mitte“:
- 5=Sehr wichtig / 4=wichtig / 3=neutral / 2=weniger wichtig / 1=unbedeutend
- 5=Perfekt / 4=gut / 3=neutral / 2=schlecht / 1=mangelhaft
- orientiert am Schulnotensystem: Note 1 = 6 Punkte, …, Note 6 = 1 Punkt
- feiner granuliert mit 1 bis 10 Punkten oder
- lediglich ja (1 Punkt) und nein (kein Punkt)
- …
Beispielhafter Auszug aus einer Nutzwertanalyse/Entscheidungsmatrix:

Vorteile
- Entscheidungen können transparent gefällt werden.
- Die Entscheidungsfindung liegt schriftlich vor und kann auch in der Zukunft nachvollzogen werden.
- Die Nutzwertanalyse kann gut im Team und/oder von verschiedenen Personen durchgeführt werden und als Diskussionsgrundlage dienen.
Nachteile
- Die Bewertung ist recht subjektiv.
- Die Festlegung der Gewichtung und die Vergabe von Punkte sind keine exakt messbaren Vorgänge.
- Bei sehr vielen Alternativen und/oder Bewertungskriterien wird die Methode schnell zeitaufwändig.
Vorlage
Als Basis für eine eigene Entscheidungsgrundlage kann hier die Tabelle heruntergeladen werden:
Allgemein
Das Berechtigungsmodell in Android ist alles andere als einfach oder durchgängig. Teilweise unterscheiden sich Berechtigungen von einer Android-Version zu nächsten oder es kommen andere dazu.
Im Zusammenhang mit Messengern wichtig und oft diskutiert ist jedoch generell der Zugriff auf das Adressbuch des Geräts.
Bei XMPP-Messengern (im folgenden Beispiel an Conversations verdeutlicht) wird zwar auch eine Berechtigung zum Zugriff auf die Kontaktdaten angefragt, diese Berechtigung ist jedoch nicht zwingend für die Funktionalität erforderlich. Selbst wenn die pauschale Android-Berechtigung “Kontakte” für den Messenger deaktiviert wird, kann auch ohne Zugriff auf das Adressbuch normal geplaudert/getextet werden. Wenn jedoch die pauschale Berechtigung “Kontakte” erteilt wird, können im Adressbuch vorhandene Jabber-IDs (Namen der XMPP-Konten) sowie Profilbilder ausgelesen und in Conversations genutzt werden.
Auf dem Gerät sollten die mindestens die Berechtigungen Kamera, Mikrofon, Speicher und Zwischenablage erlaubt werden.
Übersicht und Vergleich der einzelnen Android-Berechtigungen
Android-Berechtigung |
WhatsApp |
Conversations |
Delta Chat |
Anzahl der Berechtigungen |
Anzahl: 42! |
Anzahl: 20 |
Anzahl: 16 |
Geräte- & App-Verlauf |
|
|
|
Aktive Apps abrufen |
X |
|
|
Identität |
|
|
|
Konten auf dem Gerät finden |
X |
|
|
Konten hinzufügen oder entfernen |
X |
|
|
Eigene Kontaktkarte lesen |
X |
X |
|
Kontakte |
|
|
|
Konten auf dem Gerät finden |
X |
|
|
Kontakte lesen |
X |
X |
X |
Kontakte ändern |
X |
|
|
Standort |
|
|
|
Ungefährer Standort (netzwerkbasiert) |
X |
X |
X |
Genauer Standort (GPS- und netzwerkbasiert) |
X |
X |
X |
SMS |
|
|
|
SMS empfangen |
X |
|
|
SMS senden |
X |
|
|
Telefon |
|
|
|
Telefonstatus und Identität abrufen |
X |
|
|
Telefonnummern direkt anrufen |
X |
|
|
Anrufliste lesen |
X |
|
|
Fotos/Medien/Dateien |
|
|
|
USB-Speicherinhalte lesen |
X |
X |
X |
USB-Speicherinhalte ändern oder löschen |
X |
X |
X |
Speicher |
|
|
|
USB-Speicherinhalte lesen |
X |
X |
X |
USB-Speicherinhalte ändern oder löschen |
X |
X |
X |
Kamera |
|
|
|
Bilder und Videos aufnehmen |
X |
X |
X |
Mikrofon |
|
|
|
Audio aufnehmen |
X |
X |
X |
Fingerabdruckhardware |
|
|
|
Fingerabdruckhardware verwenden |
|
|
|
WLAN-Verbindungsinformationen |
|
|
|
WLAN-Verbindungen abrufen |
X |
X |
X |
Geräte-ID & Anrufinformationen |
|
|
|
Telefonstatus und Identität abrufen |
X |
|
|
Sonstige |
|
|
|
Synchronisierungsstatistiken lesen |
X |
|
|
Daten aus dem Internet abrufen |
X |
X |
|
Netzwerkverbindungen abrufen |
X |
X |
X |
Netzwerkverbindungen ändern |
X |
|
|
Konten erstellen und Passwörter festlegen |
X |
|
|
mit Bluetooth-Geräten koppeln |
X |
X |
|
Dauerhaften Broadcast senden |
X |
|
|
WLAN-Verbindungen herstellen und trennen |
X |
|
|
Zugriff auf alle Netzwerke |
X |
X |
X |
Audio-Einstellungen ändern |
X |
X |
X |
Nahfeldkommunikation steuern |
X |
|
|
Synchronisierungseinstellungen lesen |
X |
|
|
Beim Start ausführen |
X |
X |
X |
Konten auf dem Gerät verwenden |
X |
|
|
Über anderen Apps einblenden |
|
X |
|
Vibrationsalarm steuern |
X |
X |
X |
Ruhezustand deaktivieren |
X |
X |
X |
Systemeinstellungen ändern |
|
|
|
Synchronisierung aktivieren oder deaktivieren |
X |
|
|
Verknüpfungen installieren |
X |
|
|
Verknüpfungen deinstallieren |
X |
|
|
Google-Servicekonfiguration lesen |
X |
|
|
Tabelle: Stand 07/2020
Hinweise zur Anzeige von Berechtigungen
Android organisiert die einzelnen Berechtigungen in Gruppen (die sich zudem von Android-Version zu Android-Version leicht unterscheiden können). Die Einzelberechtigungen können sowohl in F-Droid als auch im Play-Store unter „Berechtigungen“ bei der jeweiligen App eingesehen werden. In den App-Einstellungen dagegen sind nur die Berechtigungsgruppen zu sehen.
Die Berechtigungen sind sowohl bei der F-Droid- als auch der Playstore-Version identisch!
Aber es gibt es einen Unterschied bei der Anzeige von gerätespezifischen Berechtigungen, die herstellerbezogen sind:
- Im Playstore werden nur die „Android-Berechtigungen“ (ohne die gerätebezogenen) angezeigt.
- In der F-Droid-App werden zusätzlich zu den Android-Berechtigungen auch die je nach Gerätehersteller erforderlichen Berechtigungen angezeigt.
- Über die Homepage von F-Droid werden wirklich alle Berechtigungen der Apps angezeigt (auch die gerätebezogenen).
Bei der Installation gilt das Prinzip „alles oder nichts“ - d.h. mann muss allen Berechtigungen zustimmen oder man kann das Programm nicht installieren und nutzen.
Generell gilt: |
Ein Programm (eine App) soll lediglich die Berechtigungen anfordern, die es zur Nutzung tatsächlich auch benötigt! |
App-Bezugsquellen (Android)
Unterschiedliche Bezugsquellen für Android-Apps
Oft kann ein und das selbe Programm für Android über mehrere Quellen installiert werden. Das hat seinen Grund entweder im Datenschutz (Google-Abhängigkeit) oder in der Aktualität bzw. eventuellen Sonder- oder Testversionen.
F-Droid (extern)
Alle Anwendungen, die über F-Droid bezogen werden können, sind frei und quelloffen. „F-Droid“ bedeutet sozusagen “Freie Android”-Apps; der Dienst ist spendenfinanziert. Ausführliche Hintergrundinformation hierzu gibt es auf den Seiten von „mobilsicher.de“ (extern) und im ZDF-Interview vom 22./24.12.2018.
Anmerkung:
Manchmal kann es sein, dass Anwendungen erst ein paar Tage nach der Veröffentlichung im Google Play Store in F-Droid erscheinen. Dies liegt an der Prüfung des Quellcodes, der vor jeder Veröffentlichung durchgeführt wird.
- F-Droid - App
Hier werden Aktualisierungen automatisch heruntergeladen und diese Quelle ist unabhängig von Google.
Verknüpfung zum direkten Herunterladen der APK-Datei: >> hier << (extern)
Schritt-für-Schritt-Anleitung (extern) zum Installieren von F-Droid von mobilsicher.
- über Internetseite
Programme können über „F-Droid.org“ (extern) oder alternativ auch „Fossdroid.com“ (extern) (englischsprachig) ohne eine Anmeldung direkt heruntergeladen werden.
- Von anderem Gerät
Innerhalb der F-Droid-App können Apps per Bluetooth direkt an andere Geräte gesendet werden, die kein F-Droid installiert haben.
Google Play Store (extern)\
Bequeme Quelle, über die Aktualisierungen i.d.R. komplett automatisch im Hintergrund ablaufen. Der Benutzer kann jedoch auch wählen, dass ihm neuere Versionen vor der Installation erst angezeigt werden.
Kommt für Google-freie Geräte natürlich nicht in Frage.
Direkt vom Entwickler
… oder direkt über die Projektseite bzw. Entwicklungsplattform (Bitbucket, GitHub, Gitlab, SourceForge, …)
-> Hier steht oft die neueste, meist tagesaktuelle Version zur Verfügung.
Hinweis:
Beim direkten Herunterladen von Programmen/Apps müssen diese vom Benutzer selbst installiert und eigenverantwortlich auf dem aktuellen Stand gehalten werden. Ein Hilfsprogramm hierfür ist wiederum „APKTrack“ (extern), das auch über F-Droid erhältlich ist.
Unbekannte Quellen
In den Android-Einstellungen kann bei einer Installation die Option „Installation aus unbekannten Quellen“ einmalig oder dauerhaft aktiviert werden. Dies ist jedoch kein zusätzliches Sicherheitsproblem - auch im Google-Play-Store ist genügend Schadsoftware oder Software mit Trackern und Werbung zu finden. Deshalb sollte vor jeder Installation kritisch hinterfragt werden, ob die angeforderten Berechtigungen vom Programm tatsächlich auch benötigt werden und ob dem Herausgeber vertraut wird. Statt „unbekannte Quellen“ wäre eigentlich bezeichnender: „Installation aus Google-unabhängigen Quellen“.
Mehr Informationen hierzu bei mobilsicher.de (gefördert vom Bundesministerium der Justiz und für Verbraucherschutz):
https://mobilsicher.de/hintergrund/keine-angst-vor-unbekannten-quellen (extern)
Tipp: Überprüfung auf ‘Tracker’
Bei der (englischsprachigen) Seite „Exodus-privacy“ (extern) können Programme/Apps auf enthaltene Tracker (ggfs. unerwünschte Programmteile zur Verhaltensanalyse) geprüft werden.
Auch wird hier die Anzahl und die Art der Berechtigungen angezeigt. Beispiel:

Im Notfall oder bei Katastrophen steht oft kein Internet zur Verfügung und in diesen Fällen sind klassische Messenger nutzlos. Es gibt jedoch besondere Messenger, die auch ohne Internet funktionieren und eine lokale Kommunikation zwischen Geräten per Bluetooth oder WLAN möglich ist. Das kann auch bei Ausfall der Notrufnummern im Fest- oder Mobilfunknetz hilfreich sein.
Auf Grund der Systemarchitektur und den Unterschieden zwischen Android und iOS ist es sehr aufwändig, übergreifende Systeme zu entwickeln. Eine unabhängige App/Lösung für beide Betriebssysteme zwar sehr wünschenswert, ist derzeit (Okt/2023) nicht bekannt. Da in vielen Haushalten sowohl Android- als auch iOS-Geräte genutzt werden, sind Haushalte mit ausschließlicher i-OS-Nutzung hier im Nachteil.
Messenger-Apps für den Notfall
Meshenger
Einsatzzweck: Spontannetzwerk, Notfallsituation
- auch Sprach- und Videoanrufe
- Kontakte sind vorab z.B. per QR-Code gegenseitig hinzuzufügen
- nur Android; nicht für iOS
Vorteil gegenüber Briar: Einfachere Benutzeroberfläche
Mehr Infos: >> hier <<
Projektseite/Quellcode: https://github.com/meshenger-app/meshenger-android (extern)
Briar
Einsatzzweck: Krisengebiete, Journalisten, Aktivisten, Notfallsituation
- Kontakte sind vorab z.B. per QR-Code gegenseitig hinzuzufügen
- Postfachfunktion (zur Zwischenspeicherung von Offlinenachrichten) bei Nutzung von separatem Server möglich
- nur Android; nicht für iOS
Vorteil gegenüber Meshenger: Kontakt auch über Internetverbindung möglich, Postfachfunktion möglich
Mehr Infos: >> hier <<
Projektseite: https://briarproject.org (extern)
Unfreie Messenger
Für beide Smartphone-OS (Android und iOS) gibt es z.B. „bridgefy“ - allerdings ist das nicht quelloffen und fällt hier als Empfehlung hier wegen der Anbieterabhängigkeit raus. Wenn die Firma „den Hahnen zudreht“, übernommen wird oder z.B. Konkurs macht, kann schnell Ende sein.
Weitere Apps für den Notfall
WiFi Walkie Talkie
Neben Meshenger und Briar kommt noch die App „WiFi Walkie Talkie“ (ebenfalls nur Android; ebenfalls in F-Droid (extern) verfügbar) in Frage. Die App hat den Vorteil, daß Sprachkommunikation ohne vorheriges Hinzufügen von Kontakten funktioniert - Textnachrichten sind hier jedoch nicht möglich.
Quelle: F-Droid (extern)
Trail Sense
Eine sehr gute Unterstützung und Möglichkeit, in abgelegenen Gebieten Hilfe zu rufen ist noch die App „Trail Sense“, die ebenfalls quelloffen und über F-Droid (extern) erhältlich ist.
Hier sind als Werkzeuge u.a. eine Taschenlampen- und Trillerpfeifen-Funktion vorhanden! Damit kann man SOS-Signale, Hilfe oder auch individuell Signale geben. Also eine absolute Empfehlung für diesen Fall.
Quelle: F-Droid (extern)
Weitere Möglichkeiten
Keine Messenger-Apps, aber dennoch wichtig …
Funk für den Notfall
Hier kann auf die sehr gute Seite https://deutschland-funkt.de (extern) verwiesen werden. Bei dieser Aktion können alle mitmachen, die ein Jedermannfunkgerät (CB-Funk) oder der Amateurfunkgerät haben. Im Notfunk-Wiki (extern) der Initiative sind viele Infos dazu zu finden.
Manuelle Signalgebung
Das kann beispielsweise durch Klopfen an Rohre oder gemauerte Wände geschehen.
Sonstiges
SOS-Signal = dreimal kurz / dreimal lang / dreimal kurz = dit dit dit / dah dah dah / dit dit dit (… — …)
Gibt es Regeln/Handreichungen, wie oft bzw. in welchen zeitlichen Abständen in Notfällen nach Hilfe gesucht/gerufen werden soll? Für mehr Infos gerne Kontaktieren!
Es gibt Probleme, die bei allen Messengern und unabhängig vom verwendeten Betriebssystem auftreten können. Diese können technischer Natur sein - oder auch durch menschliches Fehlverhalten hervorgerufen werden.
Systembedingte Beendigung von Apps
Bei Smartphones ist eine lange Akkulaufzeit wichtig. Dabei werden von zahlreichen Herstellern jedoch problematische Stromsparmaßnahmen ergriffen – mit teils unerfreulichen Nebeneffekten. Nicht vom Hersteller freigegebene Apps werden bei vermeintlicher Inaktivität oder nach einer gewissen Zeit einfach gestoppt um Strom zu sparen:
- Zu Android-Systemen gibt es eine sehr gute (englischsprachige) Seite, die genau das aufzeigt und (zu Recht) anprangert: Don’t Kill My App (extern)
„Don’t kill my app“ bedeutet soviel wie „Beende meine App nicht!“.
Es gibt auch eine App hierzu:
- Apple ist bei iOS jedoch noch restriktiver bei der Beendigung von im Hintergrund laufenden Apps!
- Gute Informationen zur Problembehebung bei Benachrichtigungen findet man auch auf der Seite von Signal. Die Schritte zur Problembehebung sind je nach Telefonmodel und Betriebssystem unterschiedlich - und nicht nur für Signal-Nutzer hilfreich:
Menschliches Fehlverhalten
Gruppendruck und Medienstress
Nicht nur WhatsApp kann Gruppendruck und sozialen Zwang erzeugen. Gerade Jugendliche möchten nichts verpassen, beliebt und „in“ sein. Da fällt es schwer sich auszuklinken, das Handy abzuschalten oder sich die Blöße zu geben, nicht immer sofort auf Nachrichten zu reagieren. Man ist ständig verfügbar und hat das Gefühl, auf jede Nachricht sofort reagieren zu müssen.
Bestenfalls reguliert sich der Medienstress nach einer Phase intensiver Nutzung von selbst, wenn junge Nutzer merken, wie viel Zeit über das Smartphone verbraucht wird. Gemeinsam vereinbarte Regeln und Einschränkungen für die Handy-Nutzung unterstützen dabei. Auch kann ein gemeinsamer Elternabend zu dem Thema weiterhelfen, um die Problematik in ihrer Tragweite für Klassen und Gruppen zu erfassen und gemeinsam Lösungen zu finden.
Kettenbriefe
Leider verbreiten sich Kettenbriefe mit oft ernsten Inhalten (Betrugsversuche, Einschüchterungen, Drohungen oder sogar Todesprognosen) über Messenger rasch, verunsichern und ängstigen. Wer Kettenbriefe -egal welcher Art- erhält, sollte deshalb diese Dreier-Regel beherzigen:
- Nicht weiterschicken,
- löschen,
- jemandem davon erzählen!
Kettenbrief-Roboter
Es ist wichtig, hier Bescheid zu wissen und auch bei Bedarf Hilfe zu erhalten. Saferinternet.at bietet hier einen automatisierten Service um Kinder vom psychischen Druck, der von solchen Inhalten ausgeht, zu entlasten. Auf der Seite besteht die Möglichkeit, Texte einzugeben und dann vom Kettenbrief-Roboter entsprechend hilfreiche Antworten zu bekommen. Das geht auch per WhatsApp-Nachricht an eine Telefonnummer - was jedoch aus Sicht der zentralen Metadatenauswertung von Facebook nicht optimal ist - gerade bei solch sensiblen Themen.
Zur Seite: https://www.saferinternet.at/projekte/der-kettenbrief-chatbot/ (extern)
Mobbing
Insbesondere in den Gruppenchats kommt es zu Beleidigungen, Übergriffen und Mobbingattacken. Die Gruppenkommunikation belastet Opfer besonders, wenn Anfeindungen und Attacken in der Gruppe systematisch gegen eine Person gehen. Selbst „Hass-Gruppen“ werden gegründet, deren Zweck darin besteht andere fertig zu machen.
Gemobbte sollten gar nicht erst antworten, solche Gruppen verlassen, zur Blockierfunktion (s.u. „Kontakte blockieren“) greifen und sich jemandem anvertrauen. Es hilft, wenn Eltern sich für die Freundeskreise und Gruppen interessieren, in denen ihre Kinder aktiv sind. Ein guter Kontakt zu den Eltern macht es jugendlichen Mobbing-Opfern leichter, ihnen von Anfeindungen zu erzählen.
Um Mobbing zur Anzeige zu bringen, sollten Beweise gesichert werden, z.B. per Weiterleitung (s.u. „Inhalte weiterleiten“) oder Bildschirmkopien erstellt werden (screenshots).
Quelle:
https://www.internet-abc.de/eltern/familie-medien/kommunikation-handy-whatsapp-facebook/whatsapp/whatsapp-fuer-kinder-und-jugendliche/ (extern)
Beschwerdestelle
Sollten über das Medium Messenger jugendschutzgefährdende oder strafbare Inhalte - z.B. in öffentlichen oder auch privat organisierten Chaträumen - festgestellt werden, können diese Vorfälle der „Internet-Beschwerdestelle.de“ als Beschwerde (extern) gemeldet werden. Diese ist ein gemeinsames Projekt von eco - Verband der Internetwirtschaft e. V. und der Freiwilligen Selbstkontrolle Multimedia-Diensteanbieter e.V. (FSM).
Über „Internet-Beschwerdestelle.de“ eingehende Beschwerden werden zunächst juristisch geprüft. Wenn der gemeldete Inhalt gegen die einschlägigen Jugendmedienschutzgesetze bzw. einschlägigen Strafgesetze verstößt, können die Betreiber von „Internet-Beschwerdestelle.de“ weitere Schritte einleiten: Der Inhalte-Anbieter wird direkt aufgefordert, den Inhalt abzuändern bzw. der Host-Provider gebeten, die Entfernung des Inhaltes zu veranlassen. In gravierenden Fällen kann die Beschwerde in anonymisierter Form auch direkt an die zuständige staatliche Stelle weitergeleitet werden.
Nach dem Jugendmedienschutz-Staatsvertrag (JMStV) werden demnach Beschwerden mit folgenden Inhalten bearbeitet:
- Missbrauchsdarstellungen von Kindern und Jugendlichen (auch virtuell)
- frei zugängliche Tier- bzw. Gewaltpornografie
- Darstellungen von Kindern und Jugendlichen in unnatürlich geschlechtsbetonter Körperhaltung
- verherrlichende, verharmlosende oder menschenunwürdige Gewaltdarstellungen
- volksverhetzende und kriegsverherrlichende Darstellungen, Propagandamittel verfassungswidriger Organisationen
- indizierte Darstellungen
- sonstige jugendgefährdende Inhalte, die frei zugänglich sind, und Inhalte, die nach dem Jugendmedienschutz-Staatsvertrag (JMStV) unzulässig sind
- Verstöße gegen die anerkannten journalistischen Grundsätze durch Mitglieder der FSM
- Verstoß gegen die Pflichten zur Anbieterkennzeichnung durch Mitglieder der FSM
Anmerkung:
Neben Beschwerden zu „Chat“ können auch Vorfälle zu Internetseiten, E-Mail, Tauschbörsen, Newsgroups, Diskussionsforen oder sonstige Inhalte gemeldet werden.
Quelle: https://www.internet-beschwerdestelle.de.html (extern)
Messengerhype
Das Thema Messenger sollte nicht überbewertet werden. Auch hat diese Art der Kommunikation echte Nachteile - im Privatbereich besteht unbestritten sogar echte Suchtgefahr. Auf meine Frage, auf welchem Kommunikationsweg ein Bekannter seine priorisierten (wichtigen) Nachrichten mitteilt, habe ich folgende Antwort bekommen, die ich voll unterstütze:
Frage: Wie teilst du priorisierte Nachrichten mit?
Da habe ich verschiedene Methoden:
Ganz altmodisch per Telefon. Wenn es dringend ist, rufe ich an. Wenn keiner ran geht, schicke ich eine SMS oder eine E-Mail hinterher - oder beides. Bei manchen Leuten weiß ich auch, dass sie z. B. auf Arbeit nicht telefonieren, aber Messenger-Nachrichten beantworten. Da nutze ich dann [Messenger XY] oder SMS.
Andersherum hilft auch ein Anruf, wenn eine wichtige E-Mail ein paar Tage unbeantwortet bleibt.
Und ich helfe dem Leser beim selbst priorisieren indem ich einen Betreff wähle, der den Inhalt zusammenfasst. Wenn es wirklich dringend/wichtig ist, kann auch ein “Dringend” an den Anfang der Betreffzeile. Manche komplexen Anfragen können auch in mehrere E-Mails mit verschiedenen Themen geteilt werden. Dann kann mein Gegenüber auch wieder frei entscheiden, die Mail mit der kurzen Info sofort zu beantworten und das kompliziertere Thema später, wenn es ruhiger ist.
Und vermutlich der zweitwichtigste Aspekt - ich verschicke nicht so viele irrelevante Nachrichten. Ich bekam öfter mal das Feedback von Freunden, dass meine Facebook-Posts gelesen wurden - denn ich würde ja nur so selten etwas posten.
In Gruppenchats dagegen treibe ich mich kaum noch herum. Die nerven, sind voll mit Babyfotos, Memos, Kettenbriefen und nicht zum Thema passenden Petitionen - wichtige Termine [Inhalte] sind irgendwo dazwischen verschollen.
Der wichtigste Aspekt ist das Recht auf Nichterreichbarkeit und Ruhe. Ich muss nicht immer erreichbar sein und meine Kommunikationspartner müssen das auch nicht. Meiner Erfahrung nach sind die meisten Dinge gar nicht so dringend, dass sie sofort beantwortet werden müssen oder nicht bis zum nächsten Tag oder Treffen Zeit hätten. Und nebenbei führt ein nicht ständig piependes Telefon zu weniger Stress. Und wenn es doch dringend ist, siehe oben.
Zusammengefasst heißt das: Ich denke vorher nach, ob und für wen meine Nachricht wichtig und/oder dringend ist und wähle dann den passenden Kommunikationskanal.
Auch ist es wichtig, die richtigen Empfänger zu wählen und seine Nachrichten nicht unnötig breit zu streuen.
Gedanken zu „Alternativen zu WhatsApp“
Vorwort
Immer wieder werden bekannte Messengersysteme wie beispielsweise Signal oder Threema als Alternativen zu WhatsApp empfohlen, denn die sind doch super „sicher“!?
Das mag sein, aber was ist „Sicherheit“ überhaupt, gibt es „Pseudosicherheit“ und ist Sicherheit für jeden dasselbe!? Gibt es neben Sicherheit nicht auch noch andere Dinge wie beispielsweise Freiheit, Privatsphäre, Datenschutz oder Nachhaltigkeit? Leider werden diese Begriffe oft nur als Schlagwörter (buzzwords) benutzt oder sogar gegeneinander ausgespielt, ohne die tatsächliche Bedeutung und Wichtigkeit zu erkennen.
Eines der bekanntesten Zitate (extern) von Benjamin Franklin (1706-1790) lautet:
“Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren”.
Warum nicht Alternative XY
Zentrale und voneinander abgeschottete Dienste wie Signal & Co. helfen nicht dabei, die Grundproblematik zu lösen, sondern stärken letztendlich dadurch sogar die Position und Marktmacht von WhatsApp. Denn allen gemeinsam ist, daß diese wie WhatsApp auch Insellösungen sind und man daher von einer zentralen Stelle abhängig ist:
Es fehlt die Interoperabilität. Es ist also nicht möglich, Nachrichten anbieterübergreifend auszutauschen, so wie das z.B. bei E-Mail, Telefon oder dem Mobilfunk ganz normal ist.
Mehr Informationen, warum solche Systeme tatsächlich nicht die Heilsbringer sind, findet man: >>hier<<
Es wird also keinem dieser Anbieter gelingen, gegen das „Quasimonopol“ anzukommen - Warum sich also Gedanken machen? …
Die Lösung
… Weil die Lösung bereits auf dem Tisch liegt, und das Beste daran ist, daß sie keiner Firma gehört: „Chat“.
Eine rhetorische Frage: Wer nutzt Telefon und E-Mail? Alle? Dann kennen alle sicherlich auch die Vorteile dieser Systeme: Unabhängigkeit durch freie Wahl der Anbieter, was durch
- Zusammenarbeit der Anbieter (=Föderation) und
- standardisierte, internationale Protokolle
ermöglicht wird (=Interoperabilität). Genau dasselbe gilt und gibt es auch für „Chat“!
Je mehr Leute per normalem Chat erreichbar sind, desto besser. Unter „normal“ sind in diesem Fall Messenger zu verstehen, die internationale Standards einhalten. Beispielsweise ist es bei dem ebenfalls offenen (aber nicht standardisierten) Protokoll „Matrix“ so, daß es eine Brücke zu standardisiertem Chat („XMPP“) gibt.
Solche Brücken/Tansportwege für normale Nachrichten sind vielleicht nicht perfekt, aber dennoch hilfreich und sehr vorbildlich. Sie machen auch die Wichtigkeit von international einzuhaltenden Regeln (Standards) deutlich, denn diese sind -wie in vielen anderen Bereichen auch- der Garant für Innovation und Zukunftssicherheit. Bei anbieterunabhängigem Chat werden internationale Standards eingehalten und man hat mehr Möglichkeiten und Freiheiten, als man zunächst vielleicht annimmt …
Einladung
Oft gibt es nur Halbwissen oder teils auch veraltete Informationen - Deshalb hier die Bitte, unabhängigen Chat selbst einmal persönlich zu testen und eigene Erfahrungen zu machen, denn hierfür braucht man kein Expertenwissen!
Alle, die schon anbieterunabhängig erreichbar sind, können diesen Einladungs-Link verwenden, um ihre Kontakte darüber zu informieren:
https://www.freie-messenger.de/i/#meinname@chatadresse.de
(natürlich muß die jeweils eigene Chatadresse statt dem Platzhalter ab ‘#’ eingetragen werden.)
Aber kann es überhaupt gelingen, die Allgemeinheit zur sicherer Chat-Kommunikation zu bewegen?
Ja! Wobei die Frage ist, was „sicher“ bedeutet und ob „anbieterunabhängige und sichere Kommunikation“ nicht eine treffendere Formulierung wäre.
Es hilft auch nicht, auf mangelnden Datenschutz oder die Auswertung von Metadaten bei WhatsApp & Co. zu verweisen, denn die Probleme kennt heute wahrscheinlich jeder und ignoriert sie fleißig, da das sehr bequem ist. Treffenderweise wurde der Konzern Facebook in „Meta“ umbenannt, was gedanklich sehr nah bei „Metadaten“ liegt …
Vorteile
Oft ist es einfach besser, auf die technischen Vorteile aufmerksam zu machen und darauf hinzuweisen, daß man selbst auf diesem Weg erreichbar ist. Ausschlaggebend sind dann vor allem praktische Dinge wie:
- mehrere Chatkonten (Beruf, Privat, Sonstiges)
- synchrone Nutzung an mehreren Geräten (Smartphone, PC, Tablet)
- Nutzung mit und ohne SIM-Karte möglich
- kein Mindestalter (wegen der Kinder)
- automatisch dabei: Privatsphäre+Datenschutz
Es gibt aber noch mehr Gründe, die für die unabhängigen Chat sprechen - man muß WhatsApp ja nicht sofort löschen, sondern kann das parallel nutzen. Einige Vorteile von freiem Chat auf der Basis des (flexibel erweiterbaren) Standardprotokolls:
Grundsätzliche Vorteile
- öffentlicher (internationaler) Standard statt oft geheimem Firmeneigentum
- Unterstützung von „öffentliche Gelder -> öffentlicher Code“
- Unabhängigkeit von einem externen (zentralen) Anbieter mit zentraler Systemarchitektur: Die Gefahr und Abhängigkeit, die bei der Nutzung von zentralen Diensten besteht, zeigen aktuelle Beispiele des SWR (Sperrung WhatsApp-Chatkonto) sowie die temporäre Beendigung des Messengerdienstes Ginlo (2019 bzw. 2020)
Ein föderales System (analog anderen Kommunikationsformen wie z.B. E-Mail) macht unabhängig und ist vor allem zukunftssicher.
Technische Vorteile
- Es sind getrennte (und mehrere) Chatkonten möglich
- gleichzeitige Nutzung von Mobilgeräten und PC/Laptops mit Nachrichtensynchronisation über mehrere Endgeräte
- Chatten mit oder ganz ohne Smartphone
- Chat-Clients für Windows/Linux/Mac/Android/iOS/…
- keine personenbezogene System-Identifikations-Nummer
- nicht nur geschlossene Chatgruppen, sondern auch öffentliche Chaträume sind möglich
- Es sind mehrere Ende-zu-Ende-Verschlüsselungen möglich (unterschiedliche Arten)
- Es können eigene Chatserver betrieben werden (Eigenhosting)
Organisatorische Vorteile
- Bei selbst betriebenen Chatservern können die Daten in einem Sicherungskonzept berücksichtigt werden.
- Anbindung an Nutzerverwaltungssysteme ist möglich
- Einfache Anpassung an die Aufbau- und Ablauforganisation
- interne und externe Kommunikation möglich
Finanzielle Vorteile (Kosten)
- keine Mehrfachinvestitionen in Inselsysteme
- Gelder können individuell für Programmieraufträge zur Verbesserung des Codes vergeben werden
- IT-Unternehmen können mit Dienstleistungen und Beratung Geld verdienen
- Programmcode von Clients und Serversoftware ist oft quelloffen und darf daher einfach verwendet, individuell angepasst und weiterentwickelt werden
Vorurteile
Vorurteil #1: „Kennt niemand“
Doch - sogar die Verbraucherzentrale (extern), das ZDF (extern; wenn auch mit inhaltlichen Fehlern) oder der Nachrichtendienst ‘heise’ (extern) berücksichtigen diese - und nicht zu vergessen das Bundeskartellamt (extern) - wie oben schon angesprochen.
Vorurteil #2: „Nutzt niemand“
Wirklich?
Potentielle Kommunikationspartner
Der Hauptnutzen in der Kommunikation ist die Anzahl an potentiell verfügbaren Kommunikationspartnern (Netzwerkökonomie). Jedoch wird die Anzahl der Nutzer und potentiellen Kommunikationspartner bei anbieterunabhängigem Chat leider oft unterschätzt. Da weder Telefonnummer noch Smartphone verpflichtend ist, sind alle Internetnutzer potentielle Kommunikationspartner - denn Chatten ist auch rein im Browser möglich.
Eine optimale Netzwerkökonomie ist somit gegeben.
Konkrete Nutzerzahlen
Anbieterunabhängiger Chat auf der Basis des international standardisierten Protokolls „XMPP“ ist zumindest so verbreitet wie Threema - was fehlt, ist lediglich ein zentrales Marketing.
Allein die offiziellen Nutzer-/Downloadzahlen verschiedener (untereinander interoperabler!) Messenger-Apps sind in der Summe beeindruckend - hier verschiedene Zahlen zu den Installation aus dem Playstore:
- zwischen 1.000.000 und 5.000.000 bei Xabber
- zwischen 100.000 und 500.000 bei Conversations (deutscher Entwickler)
- zwischen 100.000 und 500.000 bei Yaxim (deutscher Entwickler)
- zwischen 10.000 - 50.000 bei blabber.im/Pix-Art (deutscher Entwickler)
- weitere Apps vorhanden
Über die Suchseite „Shodan“ werden ca. 300.000 Server gefunden (ohne Nutzerzahlen).
Unbekannte Nutzerzahlen
Zu den Zahlen aus dem PlayStore kommen noch die Installationen des bekannten Appstores „F-Droid“ (extern), in dem nur quelloffene Apps zur Verfügung gestellt werden. Hier werden die Downloadzahlen jedoch nicht veröffentlicht.
Darüber hinaus gibt es auch noch verschiedene Apps aus der Apple-Welt wie …
- Monal,
- Siskin und
- ChatSecure (ehemals führend; wird jedoch nicht mehr aktiv weiterentwickelt)
… sowie auch Desktop-Clients für Windows und Linux wie z.B.
- Gajim,
- Pidgin,
- Dino,
- Kaidan
Allen Apps/Programmen gemeinsam ist, daß leider keine Downloadzahlen verfügbar sind.
Eigentlich sollte keine Argumentation auf Nutzerzahlen abzielen, denn dann müssten alle bei WhatsApp bleiben - aber es handelt sich ja auch nur um ein Vorurteil.
Vorurteil #3: „Kompliziert“
Bitte? Jeder, der ein E-Mail-Konto oder ein Konto bei Facebook, Instagram, Apple, Microsoft & Co. einrichten kann, ist in der Lage, auch ein Chatkonto einzurichten!
Allerdings müssen die gebotenen Freiheiten und Möglichkeiten natürlich erst kennen- und schätzengelernt werden - aber das haben wir bei der Papierpost, Telefon und E-Mail ja auch geschafft.
Schnelleinstieg
Alle, die bisher WhatsApp nutzen, dürften mit der Telefonnummer als Teil der Chatadresse kein Problem haben. Somit wäre für 75%-80% der Nutzer von Smartphones (ca. Anteil Android) die kostenfreie App Quicksy der einfachste Einstieg in unabhängiges Chatten. Das ist eine Einfachversion der Chat-App Conversations, bei der lediglich ein Chatkonto verwendet wird. Beide Apps sind vom selben Entwickler.
Wer tatsächlich auf die Telefonnummer als Teil der Chatadresse verzichten will oder ein iOS-Gerät nutzt, kann auf andere ebenfalls sehr gute Apps für „Chat“ zurückgreifen - bei denen dann sogar mehrere Chatkonten gleichzeitig nutzbar sind. Das ist beispielsweise gut, um Privates von Beruflichem zu trennen.
WhatsApp-Wechsler
Oft wird vom „Umstieg“ oder „Wechsel“ weg von WhatsApp geredet. Allerdings werden die wenigsten Leute WhatsApp tatsächlich von Ihrem Gerät löschen. Dazu sind noch zu viele Kontakte hier gebunden und abhängig.
Solange WhatsApp noch keine offizielle Brücke nach außen ermöglicht, ist es sinnvoll, ergänzend zu WhatsApp anbieterunabhängigen Chat zu nutzen und seinen Kontakten zumindest anzubieten.
Leider werden Messenger-Apps oft wie Briefmarken gesammelt, aber kein einziges von diesen dann halbherzig genutzten Systemen hält öffentliche Standards ein oder unterstützt diese.
Die Mehrzahl der „WhatsApp-Wechsler“ sind somit eigentlich eher „Nach-Alternativen-Suchende“, die je nach Motivation technische Sicherheit, Datenschutz/Privatsphäre oder einfach Unabhängigkeit wollen - aber gleichzeitig die Bequemlichkeit nicht aufgeben wollen.
Verschlüsselung
Wie sieht das mit der Verschlüsselung aus und ist standardisierter Chat eine zukunftssichere Alternative?
Ja natürlich, denn die Verschlüsselung wird einfach „oben drauf“ gesetzt, so wie man sie benötigt. Neue Entwicklungen und Techniken können dadurch einfach ergänzt und integriert werden.
Neben der heutzutage normalen Transportverschlüsselung wie sie im Bereich Browser durch „HTTPS“ Standard ist, kann man Chatinhalte zusätzlich noch per Ende-zu-Ende-Verschlüsselung (E2EE) absichern. Hier gibt es sogar mehrere Möglichkeiten:
- OMEMO (entspricht der einfach zu bedienenden Singnal-Technik)
- PGP (Pretty Good Privacy, wie man das auch von E-Mail kennt)
- MLS (Message Layer Security - eine aktuell neu in Entwicklung befindliche Verschlüsselung)
Beispiel
Die von WhatsApp bekannte und ursprünglich von Signal entwickelte Technik (AXOLOTL) wird heutzutage bei vielen Systemen eingesetzt und ist Stand der Technik. Wer möchte, kann bei freiem Chat (hier OMEMO genannt) seinem Gegenüber quasi automatisiert einfach „blind vertrauen“ (in der Fachsprache „BTBV“ / blind trust bevore verification) - oder bei gesteigertem Sicherheitsbedürfnis durch manuelles Gegenprüfen sicherstellen, daß niemand auf dem Transportweg mitliest oder später durch weitere Geräte Sicherheitslücken entstehen.
Zusammenfassung/Fazit
Anstatt von „Alternativen zu WhatsApp“ sollte man besser von „der Alternative zu geschlossenen Systemen“ sprechen, denn die Nutzung von verschiedenen geschlossenen Systemen wie Threema, Signal, Telegram, Viper & Co. festigt lediglich die Marktmacht von WhatApp.
Die Nutzung von internationalen Standards ist auch beim Chatten extrem wichtig, muß wieder entdeckt und gelernt werden, denn:
Anerkannte Standards sind der Garant für Innovation und Zukunftssicherheit! |
Analogie zu anderen Kommunikationsformen:
Das Browsen im Internet ist nicht nur mit einem einzigen Browser möglich - genauso wie jeder Nutzer die Freiheit in der Wahl des Geräts und der Software fürs Telefonieren oder für E-Mail hat.
Eine Öffnung bzw. Verhaltensänderung geht umso schneller, wenn z.B. bei Kontaktdaten auf Internetseiten oder auf Visitenkarten neben der Postadresse, der Telefonnummer und E-Mail-Adresse auch noch die „Chatadresse“ steht.
Dann hat man die wahre Alternative zu WhatsApp und die Lösung des Problems „Interoperabilität“ nicht nur entdeckt, sondern ist auch tatsächlich unabhängig: „Chat“
Ergänzende Informationen:
Datum: 14.06.2024
Rechte: CC BY-SA
Autoren: Diverse (Initiative Freie Messenger)
Alle Artikel/Gedanken rund um das Thema Messenger:
- Lesezeit: 6 Minuten / ganze Rubrik: 52 Minuten - |
Hier geht es um die grundsätzliche Gegenüberstellung und Merkmale von Messengersystemen sowie ergänzenden Informationen.
Das ist etwas anderes als Funktionsvergleiche von Messenger-Apps/-Programmen! Solche Vergleiche von einzelnen Messengern, bei denen Funktionen gegenübergestellt und teilweise auch (oft subjektiv) bewertet werden, gibt es viele. Zur (tatsächlich) einmaligen „Übersicht von Vergleichen“ geht es >> hier <<.
Schnellübersicht
Auf dieser kompakten Seite werden Fragen beantwortet wie:
- Ist man von einem Anbieter abhängig?
- Welches System hat einen frei einsehbaren Quellcode und bei welchem ein Firmengeheimnis?
- Ist das für die von Nutzern verwendete Software (z.B. “Messenger-App”) und die Serversoftware gleich oder nicht?
- Wie ist die Netzwerkstruktur und ist man hier als Nutzer unabhängig?
- Ist die Möglichkeit einer Ende-zu-Ende-Verschlüsselung vorhanden?
Die Schnellübersicht ist so optimiert, daß sie auch bei Schwarz-/Weiß-Ansicht und -Drucken lesbar und aussagekräftig bleibt (PDF-Dateien ca 0,5 MB):
Weiterführende spanische Informationen: https://niboe.info/whatsapp-telegram-signal-privacidad (extern)
Zeitlicher Verlauf
Messenger kommen und gehen. Hier eine Grafik, wo man sieht, wann welche Messenger eingeführt wurde. Nachträglich farblich hervorgehoben wurden der Chatstandard XMPP (Jabber) sowie Matrix:
Quelle: https://mov.im/?blog/debacle%40movim.eu/76bf90a4-5f59-4962-92db-6cd859f42ec9
Vergleich von WhatsApp mit freien, dezentralen Systemen
WhatsApp ist mit Abstand der beliebteste Messenger mit der größten Verbreitung in Europa. Er hat einen tollen Funktionsumfang, ist einfach zu bedienen und sehr bequemen bezüglich der Kontaktverwaltung. Aber …
Anregung und Bitte: |
Es gibt keine Notwendigkeit, ausschließlich nur einen Messenger (meist WhatsApp) installiert zu haben. Neben dem bisher geschätzten, zentralen Messenger (das kann auch Signal, Threema, Telegram, usw. sein) kann zusätzlich ein freier Messenger genutzt und zumindest als Kontaktmöglichkeit angeboten werden. |
Zwischen den beiden anbieterunabhängigen Systemen Jabber (XMPP) und Matrix (Matrix-Protokoll) gibt es große konzeptionelle Unterschiede - dennoch können diese in der nachfolgenden Übersicht zusammen betrachtet werden.
Merkmale |
WhatsApp (chatd/funXMPP) |
Chatstandard (XMPP) / Matrix (Matrix) |
E-Mail (IMAP) |
Briar |
Grundsätzliches |
|
|
|
|
Inselsystem ("walled garden" [^1]) |
ja |
nein |
nein |
nein |
Freie Nutzung (keine "AGB", kein Mindestalter, keine geografischen Einschränkungen, keine Begrenzung auf Zeitraum usw.) |
nein |
ja |
ja |
ja |
Offener Quellcode von Messenger-Programm(en) ("open source") - Code kann überprüft werden |
nein |
ja |
ja |
ja |
Offener Quellcode von Server-Programm(en) ("open source") |
nein |
ja |
ja |
kein Server |
öffentliches Verschlüsselungsprotokoll |
nein |
ja |
ja |
ja |
Kostenlose Nutzung |
ja |
ja |
ja |
ja |
Selber Messenger für Kommunikation erforderlich |
ja |
nein |
nein |
ja |
Allgemeine Geschäftsbedingungen |
ja |
keine |
keine |
keine |
Mindestalter für Nutzung |
16 |
ohne |
ohne |
ohne |
Anmeldung und Nutzung |
|
|
|
|
Mehrere Konten möglich |
nein |
ja |
ja |
nein |
Anonymer Namen möglich |
nein |
ja |
bedingt [^2] |
bedingt [^3] |
Auf mehreren Geräten gleichzeitig nutzbar (Multi-Client-Synchronisation) |
nein |
ja |
ja |
nein |
Gruppen/Konferenzen |
|
|
|
|
Maximale Teilnehmeranzahl in Gruppen |
256 |
unbegrenzt |
unbegrenzt |
unbegrenzt |
Berechtigungen in Gruppen/Konferenzen |
wenige |
diverse |
nein |
diverse |
- Eigentümer |
nein |
ja |
alle gleich |
nein |
- Administrator |
ja |
ja |
alle gleich |
ja |
- Mitglied |
ja |
ja |
alle gleich |
ja |
- Teilnehmer/Leser |
nein |
ja |
nein |
nein |
Öffentliche Räume/Gruppen |
nein |
ja |
nein |
nein |
Datenschutz/Privatsphäre |
|
|
|
|
Unabhängig von Telefonnummer |
nein |
ja |
ja |
ja |
Zentrales Sammeln und Auswerten von Metadaten |
ja |
nein |
nein |
nein |
Ohne Adressbuchabgleich vollständig nutzbar |
nein |
ja |
ja |
ja |
Auf Android-Geräten ohne Google-Konto nutzbar |
ja |
ja |
ja |
ja |
Ohne Google Cloud Messaging (GCM) bei Android nutzbar |
ja |
ja |
ja |
ja |
Online-/Offlinestatus möglich |
ja |
ja |
nein |
nein |
Online-/Offlinestatus abschaltbar |
ja |
ja |
kein Status |
kein Status |
Zentrale Erfassung Online-/Offlinestatus |
ja |
nein |
kein Status |
kein Status |
Lese- und Empfangsbestätigung abschaltbar |
teilweise |
ja |
ja |
ja |
Tipp-Benachrichtigung abschaltbar |
? |
ja |
ja |
ja |
Sicherheit |
|
|
|
|
Ende-zu-EndeVerschlüsselung ("e2e") |
ja |
ja |
ja |
ja |
"e2e"-Verschlüsselung in Gruppen |
ja |
ja |
ja |
ja |
"e2e"-Verschlüsselung automatisch / zwingend aktiviert |
ja |
ja [^4] |
ja [^4] |
ja |
Technik |
|
|
|
|
Infrastruktur |
zentral |
dezentrale, föderale Server |
dezentrale, föderale Server |
dezentral, direkt (p2p [^5]) |
Auswahl zwischen verschiedenen Messengern (Client-Software) möglich |
nein |
ja |
ja |
ja |
Speicherort der Kontakte |
zentraler Server |
bei Server-betreiber |
auf Endgerät |
auf Endgerät |
Archivierbar (z.B. bei Firmen) |
? |
ja |
ja |
nein |
Eigener Server möglich (z.B. für Firmen) |
nein |
ja |
ja |
nein |
Sonstiges |
|
|
|
|
Finanzierungsmodell |
Handel mit Daten / Werbung |
XMPP: Spenden Matrix: Investments |
Spenden |
Spenden |
Sonderfunktion "Telefonieren/Videotelefonie" |
ja |
ja |
nein |
nein |
Sonderfunktion "Gruppen-Anruf" (verschlüsselt) |
nein |
nein |
nein |
nein |
Direkte Kommunikation ohne Internet (LAN/WLAN/Bluetooth – p2p [^5]) |
nein |
nein |
nein |
ja |
Im Browser aufrufbar |
ja |
ja |
ja |
nein |
|
[^1]: Walled garden = „ummauerte Gärten“ = Bewußt abgegrenzte Systeme, mit denen durch das Anbieten von kostenlosen/günstigen Diensten Geld verdient wird, das in anderen Bereichen z.B. durch den Verkauf von Daten oder Werbung erwirtschaftet wird. |
[^2]: Einschränkung: Anonyme E-Mail-Konten (ohne Angabe von pers. Daten) sind nur selten möglich |
[^3]: Ein direkter Kontakt kennt die Identität - Aus der Perspektive anderer Personen kann man bei eigenen Blog-/Forum-Einträgen anonym bleiben. |
[^4]: e2e = Ende zu Ende-Verschlüsselung ist möglich, jedoch nicht bei allen Messenger-Programmen verfügbar. Hier muss bei der Entscheidung welches Programm genutzt werden soll entsprechend gewählt werden. |
[^5]: p2p = peer to peer = Direktverbindung der Klienten („clients“), d.h. den Programmen der Nutzer. |
Tabelle: Stand 07/2022 (blau markierte Texte = Änderungen seit 07/2020)
Die Tabelle kann als Druckdatei heruntergeladen werden: Systemvergleich (PDF-Datei)
Zum Vergleich von Jabber (XMPP) und Matrix (Matrix-Protokoll): >> hier <<
Natürlich gibt es auch viele andere Vergleiche von Messengern: >> hier <<
Vergleich Stiftung Warentest
- Lesezeit: 2 Minuten / insgesamt: 17 Minuten - |
Messengertest
22.02.2022 / Quelle: stiftungwarentest.de
Die Stiftung Warentest hat am 22.02.2022 einen Messengervergleich (extern) veröffentlicht. Dieser wurden in einigen dortigen Kommentaren kritisiert. U.a. auch von Freie Messenger.
Kommentar von Freie Messenger
22.02.2022 / 13:44 Uhr: Fehler im Test/Vergleich vom 22.02.22
Kommentar der Stiftung Warentest
22.02.2022 / 14:17 Uhr:
„… wo die offensichtlichen Tabellenfehler liegen, sollte nicht einfach behauptet werden, ohne konkret zu werden.“
„Wir haben nur Apps getestet, und so heißt ja auch der Test.“
>> Zum gesamten Text <<
Konkretisierung der Punkte
24.02.2022
Der expliziten Aufforderung, die genannten Punkte nochmals zu konkretisieren wird nachgekommen: >> hier <<
… und eine entsprechende Übersicht/Liste zur Verfügung gestellt: >> hier <<
Freie Messenger zum Test vom 22.02.2022
Fehler im Test/Vergleich vom 22.02.22
Leider werden 15 “Messengerdienste” mit einer App verglichen - “Standardisierter Chat” (auf Basis des internationalen Protokolls XMPP) sowie das offene Protokoll Matrix fehlen.
Zur Übersicht von Systemen hier eine “Schnellübersicht Messengersysteme”: https://www.freie-messenger.de/systemvergleich
Auch wird die wichtige “Ende-zu-Ende-Verschlüsselung” leider mit “Sicherheit” quasi gleichgesetzt:
https://www.freie-messenger.de/begriffe/kryptografie/gedanken
https://www.freie-messenger.de/begriffe/pseudosicherheit
“Threema verlangt als einzige App [richtig: Anbieter] keine E-Mail-Adresse oder Telefonnummer beim Registrieren.” Das geht auch bei anbieterunabhängigem Chat.
Conversations ist eine App und kein System - für standardisierten Chat gibt es viele Apps/Programme und viele Anbieter/Serverbetreiber!
Fehlt/vielen wichtig: Gibt es Unterschiede für den Dateiversand bezüglich der maximalen Dateigröße?
Mehrere offensichtliche Fehler in der Tabelle/Bewertung.
Fazit: Schade.
Quelle: https://www.test.de/Messenger-Apps-im-Vergleich-4884453-0#comments-area / 13:44
Anmerkungen
- Es handelt sich um die Kopie eines externen, öffentlich verfügbaren Textes.
Stiftung Warentest zu verschiedenen Kommentaren
Liebe Leserinnen und Leser,
vielen Dank für die Kommentare. Es gibt einige Einwände von Ihnen, die wir nicht so stehen lassen möchten:
Intransparenz: Die Testtabelle zeigt, dass die Gesamtnote sich aus 16 Einzelbewertungen zusammensetzt, und unter „So testet die Stiftung Warentest“ zeigen wir, dass diese Noten meist in vielen einzelnen Untersuchungen ermittelt wurden. Auch wenn wir nicht jedes Detail aufschlüsseln können, macht unsere Darstellung doch deutlich (transparent), was wir hier untersucht und bewertet haben. Beispiel “Schutz der Privatsphäre” Wir haben auf Verstöße gegen die Rechtslage geprüft sowie Vorkehrungen und Möglichkeiten in den Apps bewertet (siehe Methodik). Wie sich Mängel beim Datenschutz auswirken auf die Menschen, das ist natürlich ein weites Feld. Wir haben zum Thema umfangreich berichtet in vielen Reports unter test.de/datenschutz.
Objektivität: Der Test ist nicht weniger objektiv, weil der Titel nicht alles beinhaltet, was den Test ausmacht. Natürlich sind bei Apps der Funktionsumfang und Komfort wichtig und gehören in den Test. WhatsApp erreichte nur ein „befriedigend“ insgesamt, der Schutz der Privatsphäre ist bei keinem besser bewertet, als mit einem knappen „befriedigend 3,5“.
„Schuster bleib bei Deinen Leisten“ und „offensichtliche Fehler in der Tabelle“: Warum das Ganze nichts taugen soll und wo die offensichtlichen Tabellenfehler liegen, sollte nicht einfach behauptet werden, ohne konkret zu werden.
Messenger-Dienste leider nur als App getestet: Wir haben nur Apps getestet, und so heißt ja auch der Test.
Quelle: https://www.test.de/Messenger-Apps-im-Vergleich-4884453-0#comments-area / 14:17
Anmerkungen
- Es handelt sich um die Kopie eines externen, öffentlich verfügbaren Textes.
Konkrete Kritikpunkte vom 24.02.2022
Die Stiftung Warentest hat um eine weitere Konkretisierung bezüglich der Kritik zum Messengervergleich vom 22.02.2022 gebeten. Hier die detailliertere Übersicht von verschiedenen Punkten (die Liste erhebt jedoch keinen Anspruch auf Vollständigkeit):
A) Grundsätzlich
Der Einstieg ist: „WhatsApp, der Testsieger Signal und sechs weitere Chat-Dienste überzeugen beim Thema Verschlüsselung. Andere Apps lassen Lücken.“
Wenn es primär um „Sicherheit“ oder „Datenschutz“ geht, sollten die Kriterien auch entsprechend gewählt und gewichtet werden. Jeder Vergleich hat einen Schwerpunkt und kann nicht alles abdecken (s.u.).
Man sollte „App“ nicht mit „Messengerdiensten“ gleichsetzen. Im Textteil des Test wird beides gleichwertig verwendet. Gleich am Anfang steht „… hat sich auf Messengerdienste verlagert …“ und „… haben wir im Test von 16 Messenger-Diensten für Android und iOS geprüft“ oder „15 der 16 Dienste haben essenzielle Mängel“.
Da muss man bei der Formulierung bewusst unterscheiden, denn App als Synonym für ein Messengersystem passt eben nur bei geschlossenen, firmeneigenen Messenger(systemen/-diensten).
Übertragen auf E-Mail ist es, wie wenn man Thunderbird mit GMX vergleichen würde.
Wenn wie behauptet angeblich nur „Apps“ verglichen würden, dann dürfte z.B. die Datenschutzerklärung (die die Serverbetreiber betrifft) nicht Bestandteil des Tests sein. Die DSGVO gilt nicht für Apps sondern für Betreiber - und nur mit Betreibern können z.B. von Einrichtungen „Aufträge zur Datenverabeitung“ geschlossen werden.
Die Ganze Rubrik „Schutz der Privatsphäre“ wird abgewertet aufgrund formaler Mängel bezüglich „Datenschutzerklärung“. Die Aussagekraft der gemachten Bewertung ist dadurch zu hinterfragen.
https://threema.ch/de/blog/posts/messenger-vergleich-stiftung-warentest (extern)
Nicht falsch aber für die Zielgruppe des Tests (D) ebenfalls zu hinterfragen:
Warum ein Vergleich mit Diensten (WeChat, Lime), die hauptsächlich im asiatischen Raum und Hierzulande kaum verwendet werden?
Reicht es aus, daß eine „Ende-zu-Ende-Verschlüsselung zur Verfügung steht“ (und als vertrauenswürdig anzusehen), wenn keine Einsicht in den Quellcode möglich ist?
In diesen Fällen kann weder die Qualität noch die tatsächliche Verfügbarkeit geprüft werden. Dies sollte durch unabhängige Sicherheitsaudits überprüft werden oder unabhängige Audits sollten positiv in die Bewertung einfließen. Auch wäre eine Frage, worauf sich E2EE bezieht (Nachrichten, Statusmeldungen, Metadaten)?
Auf das bei der Ende-zu-Ende-Verschüsselung (E2EE) elementare Thema der gegenseitigen Verifizierung (Überprüfung) wird nicht eingegangen, ohne die eine E2EE nicht wirklich vor Angriffen und dem Mitlesen schützt. Eine Anleitung hierfür wäre zielgerichteter, als eine Anleitung zum Umzug auf Signal.
„Telefonie“ ist in der Tabelle einmal bei „Funktionen“ und einmal bei „Einrichtung und Nutzung“ aufgeführt. Hier steht „Nutzung der Telefonie“ - was jedoch etwas anderes bedeutet als „Qualität der Telefonie“ („Wir bewerteten die Qualität der Ton-/Bildübertragung …“). Das kann verwirrend wirken.
„Datensendeverhalten: Wir entschlüsselten den Datenstrom und prüften, ob er für die Funktion der App nicht notwendige Datenarten enthält.“
Wurde die Transport- oder Ende-zu-Ende-Verschlüsselung entschlüsselt? Oder wurden die Zieladressen für Datenpakete analysiert, mit denen man herausfinden kann, ob eine App unbemerkt „nach Hause telefoniert“ - also Daten an den Anbieter sendet?
B) Vergleich mit der App(!) Conversations
Conversations ist lediglich eine App und kein Messengerdienst. Wenn überhaupt, dann würde eher die Conversations-Variante „Quicksy“ mit zugehörigem Server als Testkandidat quasi als „interoperabler Messengerdienst“ in Frage kommen. Augenscheinlich wurde diesbezüglich zu wenig recherchiert/getestet.
Conversations ist nicht an einen Serverbetreiber (conversations.im) gebunden, sondern man kann frei wählen! Mehrere andere Apps basieren auf Conversations (sog. „forks“), die eine andere Benutzeroberfläche haben und/oder ergänzende Funktionen. Genauso wie das Original sind auch diese (meist) anbieterunabhängig nutzbar.
Wenn Mängel in der Datenschutzerklärung bei WhatsApp genauso negativ bewertet werden, wie der Mangel des Fehlens einer Datenschutzerklärung bei einer App(!) werden Äpfel mit Birnen verglichen. Die Qualität der WhatsApp Datenschutzerklärung wird als gleich schlecht gewertet wie eine App die überhaupt keinen Server beinhaltet (Analogie E-Mail: E-Mail-Programme sind auch unabhängig von Anbietern).
Kosten: Conversations ist zumindest in F-Droid dauerhaft kostenlos, im Playstore nur bei Aktionen. Ein Konto bei dem Betreiber conversations.im hat zusätzliche Kosten, die mit keinem Wort erwähnt wurden (12€/Jahr). Wenn man schon die App mit dem vorgeschlagenen Anbieter nimmt sollten die Daten vollständig sein; Die Einfachversion Quicksy ist überall kostenlos (sowohl im Playstore als auch in F-Droid). Darüber hinaus gibt es mehrere frei verfügbare und ebenfalls kostenlos nutzbare Abspaltungen („forks“) mit anderem Namen.
Nachrichten: Audionachrichten (Sprachnachrichten) sind möglich - bei anderen wird das positiv erwähnt, hier in der Beurteilung als negativ aufgeführt.
Die textliche Beurteilung von „Telefonie und Gruppen sehr gut.“ bei Conversations passt nicht ganz zur Schulnote 3,6 bis 4,5 bei „Nutzung“ in der Tabelle.
„Conversations ist nur für Android verfügbar“ - klar stimmt das, aber es gibt einige andere Apps/Programme (auf allen möglichen Betriebssystemen) mit denen Conversations interoperabel ist. Nur weil der Name nicht mit dem Serverbetreiber gleichgesetzt werden kann ist das negativ zu bewerten? (Conversations ist interoperabel mit z.B. Monal für Mac und iOS oder mit Gajim/Dino für Windows und Linux oder Movim für den Browser; da XMPP ein freies Protokoll ist, ist die Liste eigentlich noch deutlich länger)
Durch die Ungebundenheit kann man (nicht nur) Conversations auf mehreren Geräten installieren und z.B. auf dem Tablet und dem Smartphone parallel nutzen (Mehrgerätefähigkeit). Oder die Möglichkeit mehrerer Chatkonten z.B. für Beruf, Privat und Sonstige. Man benötigt keine SIM-Karte für die Nutzung und es ist sogar nicht einmal eine Telefonnummer erforderlich, wenn man das nicht möchte. Alles technische Vorteile, der in einem Test nicht erwähnt werden sollten?
Folglich stimmen beispielsweise auch die Einträge in der Vergleichstabelle nicht oder sind irreführend:
- Mängel in der Datenschutzerklärung: „deutlich“
- Anmeldung und Installation: Bei Facebook besser?
- Technische Vielseitigkeit: nur ein „+“?
- Authentifizierung und Privatsphäre: nur ein befriedigend?
- Browsernutzung / kein Webclient von Conversations - achso in der Fußnote dann doch - trotzdem keine positive Bewertung („web.conversations.im“ IST die der Webseite der App).
Bei WhatsApp wird das als positiv bewertet aber: Warum steht hier nicht ebenfalls „Nicht über Anbieterseite möglich, aber über andere Website: web.whatsapp.com“?
C) Sonstige Fehler/Fragen
Keine E-Mail-Adresse oder Telefonnummer beim Registrieren - das wird nur bei Threema wird im Text als positiv hervorgestellt. Genau das ist jedoch auch ein wesentliches Merkmal von anbieterunabhängigem Chat. „Threema ist die einzige App“ stimmt nicht.
„Conversations kann die IP-Adresse verschleiern.“ Das stimmt nicht. Ganz abgesehen davon: Wie soll eine Verschleierung der eigenen IP-Adresse dazu beitragen, die Identität vor den Anbietern zu schützen?
Datenschutz („Datenschutzerklärung“) ist nicht mit Privatsphäre („Neben der Verschlüsselung können auch andere Elemente zum Schutz der Privatsphäre beitragen …“) oder Anonymität („Zusatzschutz durch Anonymität“) gleichzusetzen. Durch die Vermischung geht der Fokus des Vergleichs verloren. Auch technische Sicherheit (Verschlüsselung) ist eine andere Baustelle - aber das passt zumindest zur Überschrift „Wo niemand mitliest“.
Im Text erwähnt aber zu unwichtig für die Vergleichstabelle: Maximale Dateigröße beim Teilen von Dateien (es lohnt sich, selbst mal danach zu schauen (Testsieger Signal nur 200 MB?) / siehe auch letzte Zeilen bei https://www.freie-messenger.de/xmpp/server/#empfehlenswerte-server ).
Was sind „Fremdprotokolle“?! Treffend wäre: „Einsatz von internationalen Standards/Protokollen“
Warum gibt es so große Bewertungsunterschiede bei „Nachrichten: Text/Bild“ zwischen den Kandidaten, wenn Textnachrichten und Bilder versendet werden können (z.B. iMessage mit „(+/o)“, Conversations und Threema mit „+/+“ - neun andere mit „++/++“?
Auch kein Fehler aber zu hinterfragen: Warum ist gerade die Funktion „Emoji-Suche“ so elementar? Abgesehen davon wird die Tastatur (samt Emojis) des verwendeten Betriebssystems genutzt, falls eine App keine eigene Emoji-Funktionalität zusätzlich mitliefert. Es gäbe noch so viele andere Funktionen - wie war nochmal die Überschrift des Tests?
Zurückziehen von Nachrichten nach dem Versand wird in der Tablle als „Sicherheits-“merkmal gesehen und bewertet - das sollte jedoch aus bekannten Gründen auch kritisch gesehen werden. Je nach Standpunkt kann eine solche „Sicherheits-“funktion nicht nur positiv sondern auch negativ bewertet werden, da nur Pseudosicherheit suggeriert wird. (vgl. Kommentar vom 22.02.) Im Text selbst steht sogar extra hervorgehoben: „Was einmal online ist, lässt sich nicht wieder einfangen.“
Anregungen:
- Eine Unterscheidung zwischen geschlossenen und freien (anbieterunabhängigen) Systemen oder ein weiteres Bewertungskriterium (z.B. „anbieterunabhängig“) würde helfen.
- Vielleicht wäre es hilfreich, eine Gewichtung der einzelnen Kriterien einzuführen.
- Detailliertere Information zu den Kriterien (und deren Gewichtung) auf der 2. Ebene würde für deutlich mehr Transparenz sorgen.
- Auch schön (nur bei Onlinetabellen) sind Vergleiche, bei denen Nutzer selbst diese Gewichtung anpassen können. Eine solche ist z.B. in der „Übersicht von Messengervergleichen“ zu finden.
D) Fazit
Aus der Sicht vieler WhatsApp-Nutzer wird die Bedeutung eines gefüllten Adressbuchs für eine Kommunikationslösung mindestens so stark gewichtet sein wie alle anderen Kriterien zusammen. Es ist also richtig, darüber aufzuklären, Alternativen vorzustellen und zu vergleichen.
Wie so oft zeigt es sich jedoch auch beim Vergleich der Stiftung Warentest, dass das Erstellen eines allemeinen oder umfassenden und trotzdem übersichtlichen Messengervergleichs immer sehr schwierig bzw. fast unmöglich ist.
Ziel darf es nun nicht sein, einzelne der oben aufgeführten Punkte zu rechtfertigen oder zu widerlegen, denn es geht ums Grundsätzliche. Neben dem Hinweis auf Fehler wurde hier - wie auch schon im ursprünglichen Kommentar - konstruktive Kritik gegeben.
Wenn konstruktive Kritik nun genauso schnell und intensiv umgesetzt wird, wie die Reaktion auf die Kommentare, dann kann man sich (ernsthaft!) schon auf den nächsten Test von Messengersystemen freuen!
Autoren: Freie Messenger / Diverse
Aktueller Stand: 25.02.2022
Weitere Aktualisierung nicht ausgeschlossen
Freie Messenger vom 24.02.2022
Antwort auf angefragte Konkretisierung
Der Bitte/Aufforderung zur Konkretisierung der Kritikpunkte wurde entsprochen und der Test näher beleuchtet. Dabei herausgekommen sind ca. 30 Punkte - hier nur einer davon:
- App und/oder Messengerdienst: Wenn man den gemachten Vergleich auf E-Mail übertragen würde, wäre das wie “Thunderbird mit GMX vergleichen”!
Eine vollständige Auflistung und detaillierte Beschreibung der konkreten Punkte sprengt den Rahmen eines Kommentars und geht der Stiftung Warentest deshalb per E-Mail zu. Die Informationen sind aber auch direkt online abrufbar:
https://www.freie-messenger.de/systemvergleich/stiftungwarentest/20220224_02
Gesammelte Kommentare dazu:
https://www.freie-messenger.de/systemvergleich/stiftungwarentest
PS:
Bereits 2021 wurde der Stiftung Warentest die damalige “Schnellübersicht Messengersysteme” zugesandt und um Aktualisierung der damaligen Ergebnisse (Stand 2015) gebeten. Insofern sind die jetzigen Testergebnisse zumindest ein Schritt in die richtige Richtung.
Quelle: https://www.test.de/Messenger-Apps-im-Vergleich-4884453-0#comments-area
Anmerkungen
- Es handelt sich um die Kopie eines externen, öffentlich verfügbaren Textes.
Vorwort
„XMPP oder Matrix“ - Was ist besser? Diese Frage ist so nicht zu beantworten, da jedes der beiden freien und anbieterunabhängigen Systeme seine Vor- und Nachteile hat. Die Systeme sind nicht besser oder schlechter, sondern unterschiedlich in der Konzeption und deshalb nicht perfekt für jeden Anwendungsfall. Die manchmal verwendete Formulierung „Matrix vs XMPP“ ist für beide Seiten kontraproduktiv, denn es geht nicht um ein „Gegeneinander“ sondern um das „Miteinander“.
Teilweise wird die Frage, welche App verwendet werden soll so beantwortet:
- WhatsApp => Conversations (XMPP; Android) u.a.
- Slack => Element (Matrix)
Das ist jedoch nur eine sehr grobe und subjektive Empfehlung.
Unterschiedliche Prioritäten
Je nachdem, aus welcher Position man schaut, gibt es mal mehr oder mal weniger große Unterschiede. Auch haben Privatpersonen, Firmen, Hoster oder politische Vertreter ganz individuelle Prioritäten und können Punkte ganz unterschiedlich bewerten und gewichten …
Private Nutzer
Aus dem Blickwinkel von privaten Nutzern ist WhatsApp der Maßstab - oder Datenschutz. Es geht nicht um Teamarbeit, die Serverauslastung und -performance ist nicht relevant und wie die Übertragung im Hintergrund funktioniert ist ebenso egal. Hautpsache die App/das Programm (der Client) funktioniert.
Merkmal |
Chatstandard (XMPP) |
Matrix |
Clients für alle Betriebssysteme |
ja |
ja |
Einheitliche Benutzeroberfläche bei verschiedenen Betriebssystemen (OS) |
nein |
ja |
Clients mit reiner Text Benutzeroberfläche (TUI) |
ja |
ja (alle im Beta-Status) (extern) |
Desktopclient ohne Electron |
ja |
ja, FluffyChat (Flutter) * |
„Halb-Anonymität“ / Anzeige der Chatadresse in öffentlichen Chaträumen (anderen Teilnehmern gegnüber) |
ja / wird nicht angezeigt, kann vom Raumadministrator aktiviert werden |
nein / Adressen sind immer öffentlich; eine Deaktivierung ist nicht möglich |
*) Andere Electron-freie Desktop-Clients sind nicht zu empfehlen, da diese sich noch im Entwicklungstatus (Alpha/Beta) befinden oder nicht weiterentwickelt werden.
Nutzerzahlen
Großanwender
Nutzer wie Unternehmen oder Behörden haben ganz andere Bedürfnisse wie Privatanwender. Hier sind Funktionen zur Gruppenarbeit sowie die Integration verschiedener Dienste wichtiger, weshalb „Teammessenger“ gefragt sind. Unterschiede der Protokolle:
Protokoll |
Chatstandard (XMPP) |
Matrix |
Ausfallsicherheit von Chaträumen über mehrere Server |
nein |
ja |
Verschlüsselung von Chaträumen |
aktivierbar und deaktivierbar |
aktivierbar |
Speicherort von Administrationsdaten |
auf jeweils 1 Server für alle Teilnehmer |
auf jeweils allen Servern der beteiligten Teilnehmer |
Speicherort von Gesprächsverläufen |
für eine einstellbare Vorhaltezeit und/oder bis zur Abholung durch den Nutzer auf dem Server bei dem der Chatraum eingerichtet ist / nach Abholung jeweils auf dem Server der Nutzer |
auf jeweils allen Servern der beteiligten Teilnehmer |
Datenspeicherung auf Server zur Verteilung von Nachrichten auf mehrere Geräte deaktivierbar |
ja, kann vom Raumadministrator deaktiviert werden; individuell vom Nutzer auch für jeden Chatraum und Kontakt |
nein, kann nicht deaktiviert werden |
Hoster/Serverbetreiber
Protokoll |
Chatstandard (XMPP) |
Matrix |
Konzeption |
Basis ergänzbar um jeweils einzelne Erweiterungen (XEP) |
monolithische Protokoll (alles in einem) |
Sprache |
XML (extern) Extensible Markup Language |
JSON (extern) JavaScript Object Notation |
Fokus auf |
Flexibilität und Erweiterbarkeit |
Ausfallsicherheit von Chats/Chaträumen |
Ressourcenverbrauch (CPU, RAM, Plattenspeicher) |
geringer als Matrix |
höher als Jabber(XMPP) |
Ort der Datenspeicherung (betrifft Ausfallsicherheit aber auch Datenschutz) |
nur auf dem Server, auf dem der Chatraum eingerichtet ist |
auf jedem Server aller beteiligten Teilnehmer |
Brücken zu anderen Systemen (viel per Web-API) |
ja |
ja |
Nachrichteneingang |
Direktempfang falls TCP-Verbindung offen ist (in die beide Seiten Daten ohne Aufforderung senden können), ansonsten Info über Nachricht per Push-Nachricht |
Immer erst Push-Nachricht über neue Nachricht an Client, der die Nachricht dann vom Server abholt (das regelmäßige, aktive Nachfragen („polling“) muß betrieben werden, da das Protokoll HTTP zustandslos („stateless“) ist) |
Vorteil |
„Grünere“ Nutzung der IT (weniger Ressourcenverbrauch) |
Bei Ausfall/Wartung eines Servers können Teilnehmer von anderen Servern ohne Unterbrechung weiterschreiben. |
Anmerkung zu „Push“:
Bei Apps aus dem F-Droid-Store wird auf Google FCM verzichtet. Deshalb gibt es hier kein “push” und man muss die App im Vordergrund halten, was wiederum einen größeren Strombedarf erfordert und dann wieder mit Matrix-Apps für Android vergleichbar ist. Für Gerätesteuerung (internet of things / IOT) besser geeignet.
Anmerkung zu „Pull“:
Durch oftmaliges Fragen nach neuen Nachrichten ist der Strombedarf tendenziell größer - außer man vergrößert den Abfrageintervall entsprechend (z.B. auf mehrere Sekunden), was dann ggfs. jedoch keiner „Sofortnachricht“ mehr entspricht. Für Gerätesteuerung (internet of things / IOT) weniger gut geeignet.
- für die Nutzer in der Praxis irrelevant
- für Ökologen und Theoretiker („Mehr Rechenleistung und mehr Speicherplatz <-> grüne IT“) relevant
- für Wirtschafter und Entscheider wichtig: Die in der Folge zu erwartenden Kosten je Nutzer/Endgerät
- für Serverbetreiber (Fremd-/Eigenhosting) sehr wichtig in Bezug auf Hardware zwecks Ressourcenbedarf und Fehlertoleranz
Beide Systeme können serverseitig für große Installationen skaliert werden:
Skalierung XMPP
Der Server “ejabberd” ist für seine Skalierbarkeit bekannt und kann über mehrere Instanzen geclustert werden. (Wikipedia (extern))
Bekanntestes Beispiel/Inselsystem: WhatsApp
Skalierung Matrix
Bekanntestes Beispiel/Inselsystem: Tchap (Französische Regierung)
Ressourcenbedarf
Es wird viel vom Speicherbedarf geredet, aber Zahlen aus der Praxis (die sich von den theoretischen Werten manchmal unterscheiden) sind nur wenige zu finden. Hier ein paar gesammelte Informationen zunächst aus der Praxis:
… und zum theoretisch Möglichen:
- process-one.net (extern): 2.000.000 Geräte auf einer XMPP-Instanz
- erlang-solutions.com (extern): XMPP-Server-Test “… And so it went, until we reached fifteen nodes, at over 1.2 million users and 22 thousand messages per second, no limit was in sight. …”
- ejabberd (extern): 1.500 Nutzer (XMPP) = 90 MB
- Zahlen zu Matrix fehlen hier noch -> gerne mitteilen!
Sonstige Praxiswerte:
Anmerkung: Quellen mit weiteren aktuellen Zahlen und gerne auch Korrekturen sind willkommen >> Kontakt <<
JSON und XML
XML steht für “Extensible Markup Language”, während JSON für “JavaScript Object Notation” steht.
JSON und XML sind beide für Webdienste geeignet -> es gibt kein wirkliches besser oder schlechter für den Anwendungszweck „Chat“.
Die Hauptunterschiede sind (zur Information):
- JSON ist eine Erweiterung von JavaScript, während XML eine Erweiterung von SGML ist.
- JSON ist datenorientiert, XML ist dokumentenorientiert
- JSON enthält keine Start- und End-Tags, während XML Start- und End-Tags hat
- JSON unterstützt Datentypen und Arrays, während XML keine expliziten Datentypen und keine Arrays unterstützt
- JSON unterstützt keine Namespaces, XML unterstützt Namespaces
- JSON ist für Konfigurationsdateien weniger geeignet, da es keine direkte Kommentarsyntax gibt
Weitere Gegenüberstellungen:
Protokoll/Politik
Ein Unterschied ist die Bestätigung des Protokolls durch eine internationale und unabhängige Standardisierungsgremium. In Fall des Internets und der Protokolle dafür ist hier die IETF in Verbindung mit der XMPP Standard Foundation (XSF) zuständig. So soll eine eine gewisse Qualität eines Standards erreicht und Unabhängigkeit gesichert werden. Beide Protokolle sind quelloffen. Heißt sie sind komplett einsehbar und überprüfbar:
Protokoll |
Chatstandard (XMPP) |
Matrix |
IETF-Standard |
ja |
nein |
Öffentliches Protokoll |
ja |
ja |
Wie wird die Unabhängigkeit des Protokolls nun in der Praxis sichergestellt bzw. wie sind die Regelungen zu den handelnden Personen/Organen, die über die Spezifikationen (das „Protokoll“) bestimmen und entscheiden können?
Protokoll |
Chatstandard (XMPP) |
Matrix |
Benennung von Führungspersonal (Formaler Prozess) |
Der Vorstand („board“) und die technische Arbeitsgruppe („council“) werden von den Mitgliedern frei gewählt |
Die vorhandenen Personen in der Führung entscheiden über Neubesetzungen und sollen dabei auf Neutralität achten. |
Kontrolle und Vertrauen: |
Die Kontrolle liegt bei den Mitgliedern, welche Vorstand und technischen Rat jährlich neu wählen. |
Es sollte „Neutralität zwischen Matrix.org Foundation und New Vector Ltd“ herrschen. „Die Community sollte ihnen trauen.“ |
Auskunftspflicht: |
Die Akteure müssen ihre Arbeitgeber/Interessen benennen |
? |
Sonstiges: |
Der personelle Anteil einer Körperschaft/Organisation im Führungsgrremium ist geregelt und begrenzt |
Personalunion von 2 Führungskräften in Spezifizierungsgremium (Matrix.org) und Dienstleistungsfirma (New Vector Inc.) |
Regelungen/Quellen: |
Bylaws (extern; Internetseite) |
Official Articles” (extern; PDF) und Rules (extern; PDF) bei „Legal Details“ |
Erläuterungen zu den Regeln bei XMPP
Quellen: Allgemeine Beschreibung der XSF (extern) und Regeln („Bylaws“) (extern) der XSF
Für die Mitglieder (Members) gilt, #2.1:
An applicant for membership may not be admitted if, at the time of application or consideration, fifteen percent (15%) of the Members of the Corporation are employed by or represent the same corporation or organization as that corporation or organization which employs the applicant or is represented by the applicant.
Deshalb müssen bei Anträgen zur Mitgliedschaft die relevanten Zugehörigkeiten angegeben werden!
Kontrollverlust an Dritte
Die Regelungen der IETF (IETF-RFCs) und der XSF (XSF-Bylaws) sollen zumindest klarstellen, dass eine „Übernahme“ nur feindlich-konfrontativ möglich ist und daher zumindest die Kosten eines Konflikts zu erwarten sind.
Erläuterungen zu den Regeln bei Matrix
Quellen: Official Articles” (extern; PDF) und Rules (extern; PDF)
Im ersten Dokument, #17.1 der “official articles of the Foundation”:
The Guardians shall appoint any individual who is eligible as a Guardian to fill a vacancy or (subject to the maximum number permitted by Article 16.1) as an additional Guardian, subject to any requirements set out in the Rules from time to time, and provided at least 75% of the current Guardians approve the appointment.
Für die Anforderungen wird auf das zweite Dokument #3.1.4 verwiesen:
The Founder Guardians shall be joined by additional Guardians (with the Founder Guardians forming a minority of the Board) to ensure there is continuity, but also neutrality, between the Foundation and New Vector Ltd.
Und weiter bei #3.1.5 und #3.1.6:
Guardians are typically independent of the commercial Matrix ecosystem and may not even be members of today’s Matrix community, but are deeply aligned with the mission of the project and Guiding Principles.
The Guardians are self-appointing […]. However, any Guardian appointed must be respected and trusted by the wider Matrix community to uphold the Guiding Principles and keep the other Guardians honest.
Noch klären / Fragen:
- Warum wird zwischen Gründungswächtern („founder guardians“) und normalen Wächtern („guardians“) unterschieden?
Kontrollverlust an Dritte
- Was wäre, wenn ein internationaler Konzern wie Goolge so bei Matrix einsteigt wie das früher auch schon mal bei XMPP der Fall war? Oder ein Großinvestor der das Protokoll für seine Zwecke ändern/erweitern will?
- Gibt es eine Regelung für einen solchen Fall oder wird dadurch eine Übernahme durch Dritte möglich/erleichtert? Muß man sich einfach darauf verlassen, daß die Foundation die Neutralität sicherstellt?
Andere Vergleiche
… wobei dort leider oft die Frage „Was ist besser?“ gestellt wird. Eigentlich halte ich jedoch die Frage „Was ist anders?“ für sinnvoller, denn unterschiedliche Anforderungen können zu unterschiedlichen (anderen) Lösungen führen.
Unterschied lt. Matrix
Matrix selbst findet den Unterschied relativ subjektiv und formuliert:
… The whole area of XMPP vs Matrix is quite subjective. Rather than fighting over which open interoperable communication standard works the best, we should just collaborate and bridge everything together. The more federation and interoperability the better.
Quelle: https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp? (extern; englisch)
… allerdings werden hier verschiedene Begriffe wie Brücken, Föderation und Interoperabilität in einem Satz verwendet. Da oft unterschiedliches Verständnis dazu vorhanden ist, sind deshalb ein paar Gedanken dazu angebracht.
Entscheidungskriterien
Jabber(XMPP) und Matrix unterscheiden sich grundsätzlich in ihrer Systemarchitektur. Auch bei den jeweils vorhandenen Clients gibt es Unterschiede: So herrscht auf der einen Seite eine große Vielfalt mit unterschiedlichen Funktionen - auf der anderen Seite gibt es einen Referenzclient, der für alle Betriebssysteme die selben Funktionen anbietet.
Was ist für eine Entscheidung nun wichtiger: Systemmerkmale oder Clientfunktionalität ?
Es gibt keine allgemeingültige Antwort:
Langfristig kann es besser sein, das für sich besser passende System zu wählen - unabhängig von der Betrachtung der Clients. Kurzfristig ist vielleicht eine allumfassende Clientlösung wichtig. Bei Körperschaften/Organisationen hilft hierbei vielleicht auch die Überlegung, in welchen Bereichen (Clientverbesserung/-Anpassung oder System-/Protokollverbesserung) investiert werden soll/kann.
Ideal wäre eine Kooperation von Matrix und dem Chatstandard (XMPP) durch funktionierende Brücken). So wäre ein standardisierter Austausch von Nachrichten mit Anderen möglich - und trotzdem können Unternehmen/Behörden intern die Vorteile von ausfallsicheren Chaträumen genießen. |
Inhalt
Diese Übersicht von Messengervergleichen ist in dieser Form einzigartig und in folgende Bereiche aufgeteilt:
Eine tagesaktuelle Übersicht aller Messenger mit genau den Kriterien, die einem selbst wichtig sind, wird man schwer finden, denn jeder Vergleich hat einen Schwerpunkt und ist aus einem bestimmten Blickwinkel heraus erstellt. Manchen Übersichten fehlen (bewußt?) bestimmte aber essentielle Messsenger, sind teilweise nicht vollständig oder enthalten Fehler. Deshalb am Besten immer mehrere Übersichten anschauen und Inhalte auch mal kritisch hinterfragen. Die hier aufgenommenen Messengervergleiche liegen in ihrer inhaltlichen Qualität zumindest im oberen Bereich.
Hinweis: Bessere Vergleiche/Informationen sehr gerne mitteilen! >> Kontakt <<
Querverweis: Systemvergleich
Querverweis: Andere externe Verweise und Verknüpfungen
Deutsche Vergleiche
Vorschau |
Beschreibung und Quelle |
|
Sicherheit und Nachhaltigkeit von Messengern, e-Mail, SMS & Co.
Auch mit klassischen Kommunikationskanälen (Brief, Telefon, Telefax, SMS) im Vergleich!
ABER: Stand November 2016, weshalb bei Jabber(XMPP) das aktuelle Verschlüsselungsprotokoll OMEMO fehlt und Matrix auch nicht aufgeführt ist.
Zur Quelle: Digitale Gesellschaft; Schweiz (extern) |
|
22 Messenger im Vergleich
Übersicht, bei der die verschiedenen Kriterien individuell mit Punkten bewertet werden können, so daß man eine „für sich passende“ Rangfolge erhält.
ABER: Das Kriterium ‘Selbstzerstörende Nachrichten’ wird leider nicht auch als Sicherheitsrisiko gesehen (-> Pseudosicherheit ) sondern positiv - und das Fehlen der Funktion wird als negativ bewertet. Besser wäre keine Bewertung dieses Kriteriums oder eine Einstellung, ob das Vorhandesein positiv oder negativ bewertet werden soll.
Zur Quelle: orcas.de (extern) |
|
Messenger-Matrix (deutsch und englisch)
Überblick, über die verschiedenen technischen Merkmale diverser Messenger.
Zur Quelle: Kuketz (extern)
Sehr empfehlenswert auch die Artikelserie „Die verrückte Welt der Messenger“ (extern) |
|
Messenger-Matrix mit Schwerpunkt Sicherheit
ABER: Nicht nur das Vorhandensein eines Sicherheitsaudits wird bewertet, sondern augenscheinlich auch das Datum (ohne ergänzende Hinweise bzw. ohne Bezug zur Programmversion).
Zur Quelle: Piratenpartei (extern) |
|
Vergleich der großen 7 (quelloffenen) Messengersysteme (deutsch und englisch)
ABER: Zumindest bezüglich OMEMO(XMPP) und Matrix nicht mehr aktuell, da Stand 2016.
PDF (ca. 11 MB!) zum Herunterladen: >> hier <<
Zur Originalquelle: goldbug (extern)
Englischer Auszug: wikibooks.org (extern) |
|
Alternativen zu WhatsApp und Threema
Zur Quelle: digitalcourage.de (extern) |
|
Quelloffene Messenger (GitHub)
Zur Quelle: GitHub (extern) |
|
Allgemeine Messenger-Liste
Zur Quelle: Wikipedia (extern) |
|
Messengerprotokolle im Detail
Zur Quelle: hashbang.dot (extern - aber Google-Docs!) |
Englische Vergleiche
https://privacyspreadsheet.com/messaging-apps
Vorschau |
Beschreibung und Quelle |
|
Vergleich der großen 7 (quelloffenen) Messengersysteme (deutsch und englisch)
ABER: Zumindest bezüglich OMEMO(XMPP) und Matrix nicht mehr aktuell, da Stand 2016.
PDF (ca. 11 MB!) zum Herunterladen: >> hier <<
Zur Originalquelle: goldbug (extern)
Englischer Auszug: wikibooks.org (extern) |
|
Messengervergleich (Comparison of Instant Messengers)
Sehr gelungene und aktuelle Übersicht. Gruppierung in …
-> offene & dezentrale,
-> offene & zentrale und
-> geschlossene Systeme.
Zur Quelle: eylenburg.github.io (extern) |
|
Privacy Spread Sheet
Sehr guter und detaillierter Vergleich mit dem Schwerpunkt Privatsphäre.
Zur Quelle: privacyspreadsheet.com (extern) |
|
Score Card for Mobile Crypto Chat Applications
Vergleich von Goldbug/Smoke mit anderen Systemen
Zur Quelle: Goldbug/Smoke (extern) |
|
Messengervergleich (Messenger Comparison Table)
Zur Quelle: divestos.org (extern) |
|
Instant Messenger
Zur Quelle: awiki.org (extern) |
|
Diverse Messenger mit Vor- und Nachteilen
Zur Quelle: fairphone.com (extern) |
<< VIDEO >> |
SimpleX vs Session
Zur Quelle: simplifiedprivacy.com (external)
Anmerkung: In manchen Punkten sind die dargestellten Informationen eigenartig. Session sei ein Ersatz für Telegram (die Erwähnung von ‘Blockchain’ darf nicht fehlen) wogegen SimpleX Signal ersetze. Zumindest das ist falsch, denn Session ist ein Signal-Fork mit Vermeidung von Metadaten durch ein - inzwischen - eigenes Onionnetz. |
|
Vergleich von Messengern (Secure messaging apps comparison)
Scheint nicht ganz aktuell zu sein (bei Matrix wird noch Riot statt Element aufgeführt; der Chatstandard XMPP fehlt komplett)
Wenn „sichere“ Messenger genannt werden, sollte immer hinterfragt werden, was denn konkret unter „Sicherheit“ verstanden wird.
Zur Quelle: securemessagingapps.com (extern) |
|
Vergleich von Messengern (Information on secure messaging apps)
Wenn „sichere“ Messenger genannt werden, sollte immer hinterfragt werden, was denn konkret unter „Sicherheit“ verstanden wird.
Lt. Internetseite wird die Übersicht nicht mehr gepflegt und dient nur noch zur Dokumentation.
Zur Quelle: securechatguide.org (extern) |
Weitere Vergleiche
Leistung
Ein Vergleich verschiedener Messaging-Anwendungen kann auch anhand der Leistung erfolgen. Andriy Utkin (extern) hat eine kleine Analyse von Messaging-Apps für Android (extern) in Bezug auf Stromverbrauch, Bandbreite und RAM-Nutzung durchgeführt. Seine Schlussfolgerungen:
- Conversations (XMPP) scheint in Bezug auf Akkulaufzeit, Datenverkehr und RAM am Besten abzuschneiden.
- Facebook Messenger und Element (Matrix) sind die schlechtesten der untersuchten Apps und verbrauchen bis zu 300x mehr Strom als Conversations, wenn die Batterieoptimierung deaktiviert ist. Ich schätze, dass die Akku-Optimierung für diese Apps aktiviert bleiben sollte. Wir brauchen mehr Daten, um mehr zu sehen.
- Element X (experimentelle Matrix-App) weist eine mehr als 100-fache Verringerung [Anmerkung: Vermutlich ist ‘weniger als 1%’ gemeint] des Energieverbrauchs auf im Vergleich zu Element und verbraucht nur 2x mehr Strom als Conversations.
- Ein paar weitere proprietäre Messenger wurden gemessen und liegen zwischen den oben genannten Extremen. Über sie lässt sich nur wenig sagen, außer dass die meisten von ihnen kontinuierlich eine beträchtliche Menge an Strom und Bandbreite verbrauchen, selbst wenn nicht mit ihnen interagiert wird.
Wie wurden die Daten gewonnen?
Die Messungen stammen von universellen Android-Tools, die einmal pro Minute über die adb-Shell aufgerufen werden. Die RAM-Nutzung wird von RSS aus ps ermittelt. Die Batterie- und WLAN-Nutzung stammt von dumpsys batterystats. Der letztgenannte Bericht liefert nur dann aktuelle Daten, wenn das Gerät nicht geladen wird. Daher muss die ADB-Verbindung mit adb tcpip in den TCP-Modus geändert werden, und das USB-Kabel darf nicht eingesteckt sein, außer zum regelmäßigen Laden.
Quelle: Messengers performance (extern) bei grafana.net
Sonstiges
Weitere Diskussionen/Vergleiche:
Hier werden verschiedene quelloffene Messenger beschrieben (aber nicht direkt miteinander verglichen):
Hinweis: Bessere Vergleiche/Informationen sehr gerne mitteilen! >> Kontakt <<
Vergleich Stiftung Warentest
- Lesezeit: 2 Minuten / insgesamt: 17 Minuten - |
Messengertest
22.02.2022 / Quelle: stiftungwarentest.de
Die Stiftung Warentest hat am 22.02.2022 einen Messengervergleich (extern) veröffentlicht. Dieser wurden in einigen dortigen Kommentaren kritisiert. U.a. auch von Freie Messenger.
Kommentar von Freie Messenger
22.02.2022 / 13:44 Uhr: Fehler im Test/Vergleich vom 22.02.22
Kommentar der Stiftung Warentest
22.02.2022 / 14:17 Uhr:
„… wo die offensichtlichen Tabellenfehler liegen, sollte nicht einfach behauptet werden, ohne konkret zu werden.“
„Wir haben nur Apps getestet, und so heißt ja auch der Test.“
>> Zum gesamten Text <<
Konkretisierung der Punkte
24.02.2022
Der expliziten Aufforderung, die genannten Punkte nochmals zu konkretisieren wird nachgekommen: >> hier <<
… und eine entsprechende Übersicht/Liste zur Verfügung gestellt: >> hier <<
… sind für Arbeitsgruppen gemacht („groupware“) und können als quelloffene Alternativen zu „Slack“ (“Slack ist dein digitales Büro - Revolutioniere deine Arbeitsweise mit einem zentralen Ort für alle und alles, was du für deine tägliche Arbeit brauchst.”) gesehen werden. Allen gemeinsam ist, daß Schnittstellen vorhanden sind, so daß andere Systeme mit in den internen Arbeitsablauf eingebunden werden können.
In der Regel existieren diese sowohl in einer Open-Source- als auch in einer kostenpflichtigen Enterprise-Variante mit professionellem Support. Die Geschäftskunden-Pakete bieten zusätzliche Funktionen an wie zum Beispiel Unterstützung für Hochverfügbarkeit.
Querverweis: Systemvergleich
… oder direkt zu den externen Vergleichen von quelloffenen Teammessengern.
Matrix
|
„An open network for secure, decentralized communication“
„Matrix is an open standard for interoperable, decentralised, real-timecommunication over IP.“
|
Chatten und Arbeiten per verteilter Datenbank (a lá Git). Aufgeteilt auf Matrix.org (Protokollentwicklung) und Element.io (Vertrieb und Hosting). Matrix vergleicht sich selbst (extern) nicht mit anderen Teammessengern, sondern mit IRC, XMPP, Trillian und Pidgin.
Beispiele für den Einsatz im Bildungsbereich: Uni Bochum (extern), TU Dortmund (extern), Uni Hannover (extern), Uni Insbruck (extern)
Weitere Beispiele: BWI (Bundeswehr) (extern), Französische Regierung (Tchap) (extern), Deutsches Gesundheitswesen (TI-Messenger) (extern), Handmade Seattle (extern)
Quelle: https://element.io/communities
- positiv: quelloffenes System
- positiv: viele andere Dienste können eingebunden werden
- positiv: Server mit Föderationsmöglichkeit
- positiv: Interoperabilität ist möglich über Brücke (falls aktiviert) zu internationalem Standard XMPP
- positiv: keine Tracker in der Android-App Element feststellbar (40 Berechtigungen): Exodus (extern)
- negativ: KEINE deutsche Projektseite
- negativ: lt. webbkoll (extern) 81 Drittanfragen (third-party) auf der Internetseite von matrix.org
- negativ: lt. webbkoll (extern) 9 Drittanfragen (third-party) auf der Internetseite von element.io
Preise:
Mehr Informationen zum Matrix-Protokoll: >> hier <<
Schnittstelle: https://spec.matrix.org/latest (extern)
Projektseite: http://matrix.org (extern; englisch)
Mattermost
|
„Make your work flow”
„Finally, an open source platform for developer collaboration. Secure, flexible, and integrated with the tools you love.“
„From creating AAA games to coordinating rescue missions, over 800 organizations around the globe trust Mattermost to ship better software, faster.“
|
Beispiele für den Einsatz im Bildungsbereich sind die Uni Kaiserslautern (extern) Uni Mainz (extern), FH Münster (extern), WWU Münster (extern), The University Of British Columbia (extern)
Weitere Beispiele (wie Bosch, DuckDuckGo, NASA, Nasdaq, Samsung, …) sind auf der Seite von Mattermost (extern) zu finden.
- positiv: quelloffenes System
- positiv: als Insellösung sehr gut
- positiv: Integration von BigBlueButton möglich (Beispiel Uni Mainz (extern))
- negativ: Server ohne Föderation / keine Interoperabilität
- negativ: KEINE deutsche Projektseite
- negativ: 1 Tracker (Google Firebase Analytics) in der Android-App (17 Berechtigungen): Exodus (extern)
- negativ: lt. webbkoll (extern) 1 Cookie von Dritten und 27 Drittanfragen (third-party) auf der Internetseite
Preise: https://mattermost.com/pricing (extern)
Schöne Anleitung: diebasis.wiki (extern; PDF)
Schnittstelle: https://api.mattermost.com (extern)
Projektseite: https://mattermost.com (extern)
Rocket.Chat
|
„Die größte Open-Source-Kommunikationsplattform der Welt. Besitzen Sie Ihre Daten, passen Sie alles an, integrieren Sie alles.“
„Über 12 Millionen Nutzer in mehr als 150 Ländern vertrauen auf uns.“
„Ihre Privatsphäre, unsere Priorität.“ / „Die Kommunikationsplattform für Unternehmen, bei denen ein vollständiger Schutz der Privatsphäre geschäftskritisch ist.“
„Die Open-Source-Alternative zu Slack, Zendesk for Service, Intercom und Sendbird. Alles in Einem.“
|
In der Dokumentation von Rocket.Chat steht zwar, das eine Föderation möglich sei, allerdings wird (Stand 06/2022) vom produktiven Einsatz abgeraten. Hier steht in den Konfigurationseinstellungen zur Föderation (Bildschirmkopie) der Warnhinweis:
„Federation support is a work in progress. Use on production system is not recommended at this time.“
Quelle (englisch): https://docs.rocket.chat/guides/administrator-guides/federation (extern)
Beispiele für den Einsatz: Uni Bremen (extern), Heinrich-Heine-Universität Düsseldorf (extern), Hochschule Koblenz (extern),
Uni Köln (extern), Uni Regensburg (extern)
Weitere Beispiele (wie DB, VW, Audi, …) sind auf der Seite von Rocket.Chat (extern) zu finden.
- positiv: quelloffenes System
- positiv: deutsche Internetseite
- positiv: eigene Server sind möglich (diese sind dann jedoch in sich geschlossene Systeme)
- positiv: Interoperabilität mit XMPP ist konkret in Planung (extern)
- positiv: Föderation mit Matrix sollte über Matrix-typescript library (external) möglich sein
Experimentelle Unterstützung der Matrix Föderation wurde am 25.05.2022 angekündigt (extern). Aber: Aktuell noch im Alphastatus (extern)!
- negativ: Server ohne empfohlene Föderation (s.o.) / keine Interoperabilität
- negativ: der Desktop-Client basiert auf Electron
- negativ: Mit der Version 4.0 wurde die automatische LDAP-Synchronisation von der freien in die Enterprise-Version verschoben
- negativ: 3 Tracker (Bugsnag, Google Firebase Analytics & CrashLytics) in der Android-App (19 Berechtigungen): Exodus (extern))
- negativ: lt. webbkoll (extern) 33 Cookies; 17 von Dritten; 96 Drittanfragen (third-party) u.a. an Facebook, Google, linkedin, Twitter, Zoom, … auf der Internetseite
Beispielnutzung: “Fairchat” (extern; nutzt Rocket.Chat)
Preisliste: https://de.rocket.chat/pricing (extern; englisch)
Projektseite: https://de.rocket.chat (extern)
Zulip
|
„Chat for distributed teams.“
„Zulip combines the immediacy of real-time chat with an email threading model. With Zulip, you can catch up on important conversations while ignoring irrelevant ones.“
„Mehr als 120 native Integrationen“
|
Auch dieser Teammessenger ist für die Arbeit in verteilten Gruppen und “Threads” gemacht. Zulip wirbt explizit damit, dass die kostenpflichtige Variante die Open-Source-Fassung finanziert. Andere Dienste wie z.B. Dropbox, E-Mail, GitHub, GitLab, GoogleCalender, Matrix, Youtube u.v.m. können eingebunden werden und es ist möglich, einen eigenen Zulip-Server zu betreiben. Beispiele für den Einsatz im Bildungsbereich sind die Universität München (extern) und die Universität San Diego (extern).
Im Vergleich zu den Open-Source-Konkurrenten Mattermost oder Rocket.Chat bietet Zulip neben der Möglichkeit des Eigenhostings auch das kostenlose Hosten auf Zulip-Servern an.
- positiv: quelloffenes System
- positiv: eigene Server sind möglich
- positiv: viele andere Dienste (über 120 verschiedene!) können eingebunden werden (https://zulip.com/integrations/) (extern)
- negativ: Server ohne Föderation / keine Interoperabilität
- negativ: KEINE deutsche Projektseite/Hilfe
- negativ: 1 Tracker (Google Firebase Analytics) in der Android-App (26 Berechtigungen): Exodus (extern)
- negativ: lt. webbkoll (extern) 30 Drittanfragen (third-party) auf der Internetseite
Kommentar zu Zulip:
The most important difference, in my opinion, between Zulip and most of the other popular chat systems is their conversation model. With most systems, like Slack, Matrix or even XMPP, conversations are separated into channels, rooms or chat rooms respectively. For some of the newer chat systems, threads have been added to conversations as an after thought, but in Zulip, threading was an initial design feature so the system was built to support threading, in a similar way to email.
Quelle: https://mailarchive.ietf.org/arch/msg/tools-discuss/WAvOx6dkPKu-UanUYtzeNhGjydg/ (extern)
Ausführlichere Beschreibung: blog.novatrend.ch (extern)
Quellcode: https://zulip.readthedocs.io/en/stable/production/install.html (extern)
Client (F-Droid): https://f-droid.org/de/packages/com.zulipmobile/ (extern)
Schnittstelle: https://zulip.com/api (extern)
Projektseite: https://zulipchat.com (extern; leider nur englisch)
Externe Vergleiche
= = = Serverbasiert = = =
- Lesezeit: 1 Minute / ganze Rubrik: 63 Minuten - |
Abgrenzung:
- Serverbasierte Messengersysteme („Bedingung“) benötigen für die Nutzung entsprechende Server - z.B. für die Kontakliste, Nachrichtenweiterleitung, Gruppen oder Chatraumverwaltung.
- Servergestützte Messengersysteme („Möglichkeit“) funktionieren grundsätzlich auch ohne Server - jedoch können für Spezialfunktionen (wie Zwischenspecherung von Nachrichten) Server in Anspruch genommen werden.
- Serverlose Messengersysteme („Verzicht“) sind komplett dezentral und ohne spezielle (weitere) Server organisiert.
Übersicht
- Lesezeit: 20 Minuten / ganze Rubrik: 108 Minuten - |
Anbieterunabhängiger Chat auf Basis des international standardisierten Protokolls ist eine Empfehlung in der Schnellübersicht!
Im Gegensatz zu anderen Messengern/Systemen kann und darf(!) Chat auf der Basis des Protokolls XMPP überall dort legal eingesetzt werden, wo E-Mail auch genutzt wird! |
Auf dem Infoblatt (PDF) ist dazu alles Wesentliche zusammengefasst.
Vorwort
Sollte jemand den Chatstandard unter dem Namen „Jabber“ kennen, so sollte beachtet werden, dass das System in den letzten Jahren große Veränderungen erfahren und sich den aktuellen Anforderungen an modernes “instant messaging” angepassst hat. Die Bezeichnung jedoch wird heute auch noch oft und gerne verwendet - interessant für Smartphone-Nutzer ist: Im normalen Adressbuch findet sich bei jedem Kontakt oft ein Feld „Chat“ in dem man die Chatadresse seiner Kontakte hinterlegen kann. Für standardisierten Chat hier als System also einfach „Jabber“ wählen.
Wesentliche Weiterentwicklungen:
- Nutzer müssen nicht gleichzeitig online sein
- Ende-zu-Ende-Verschlüsselung mit aktuellen Verschlüsselungsmethoden
- Audio-/Videotelefonie
- Sprachnachrichten
- Dateiaustausch unabhängig vom Format
Inhalt:
Vorteile & Nachteile
- positiv: Keine Abhängikeit von einer zentralen Stelle
- positiv: Interoperabilität durch Nutzung von Standards
- positiv: Freiheit in der Wahl der Software
- pos&neg: Unterschiedliche Benutzeroberflächen durch Vielfalt bei Clients; kein betriebssystemübergreifender Client (außer Browser)
- negativ: Man muß sich auf Empfehlungen für Clients und auf Empfehlungen für Serverbettreiber verlassen (es gibt nicht den einen Anbieter und nicht die eine App)
- negativ: Verschiedene Apps/Programme mit unterschiedlichem Funktionsumfang
- negativ: Android-Clients haben einen deutlichen Vorsprung vor iOS-Clients in Sachen Benutzerfreundlichkeit als auch Funktionsumfang
- negativ: Abseits der empfohlenen Apps/Programme gibt es auch solche, die z.B. keine OMEMO-Verschlüsselung implementiert haben (diese sind dann trotzdem für öffentliche Chaträume brauchbar)
- negativ: Durch Föderation fallen systembedingt Metadaten an; nicht zur Vermeidung von Metadaten designt, sondern für Interoperabilität
- negativ: Verifizierte OMEMO-Verschlüsselung ist bei der Nutzung von mehreren Geräten/Clients weniger empfehlenswert, da bei „totaler“ Sicherheit Nachrichten nicht auf neuen Geräten gelesen werden können und das in der täglichen Praxis so oft nicht gewollt ist. Abhilfe nur durch „Blindes Vertrauen vor der Verifikation“ (BTBV) - oder durch andere Verschlüsselung (PGP)
- negativ: Serverseitig bei ejabberd-Software: Mitglieder verlieren Verbindung, wenn Server neu startet; Server vergisst Mitgliederliste, wenn Server neu startet; Server zu Server Verbindungen sind nicht robust und gehen verloren, wenn Server IP wechselt
- negativ: Subjektive Info: Früher wurde immer wieder mal von Nachrichtenverlust berichtet, wenn Geräte offline waren
- negativ: Nicht durch das Protokoll bedingt aber eine Folge der „Föderation“: Öffentlich verfügbare Server garantieren selten eine bestimmte Ausfallsicherheit. Insbesondere bei privat betriebenen Servern können immer wieder längere Ausfälle die Folge sein. Manchmal werden solche Server auch nicht mehr aktiv betreut oder der Dienst ganz eingestellt. Man muß selbst nach zuverlässigen Servern schauen, sich auf Empfehlungen verlassen oder kann selbst hier aktiv beim Hosting werden.
- negativ: Es gibt manche Hoster, bei denen sehr viele Serverbetreiber Ihre Dienste laufen haben - fällt hier einer aus, wären viele unterschiedliche Instanzen betroffen. Dazu folgende Übersicht (extern).
Spezialfall „öffentliche Chaträume“:
- positiv: Möglichkeit zum Austausch, wie es z.B. WhatsApp nicht bietet
- negativ: Verlässt bei öffentlichen Chaträumen (in die jeder mit einem beliebigen Alias beitreten kann) ein Nutzer den Chatraum, kann ein anderer unter dem selben Spitznamen beitreten und weiterschreiben, ohne dass andere den Wechsel evtl. bemerken.
- negativ: Werden bereits versendete Nachrichten „korrigiert“ (nachträglich nochmals in einer geänderten Version versendet), werden diese je nach verwendetem Client bzw. Einstellung evtl. auch entsprechend oft angezeigt
Quellen, die ebenfalls kritische Punkte aufführen sind curius.de / Mai 2021 (extern), Privacy-Handbuch (extern), Kuketz-Blog / 18.02.2018 - Testzeitraum Okt. 2016 bis Nov. 2017 (extern) und Signal / 10.05.2016 (extern)
Grundsätzliches
Um Chatten zu können, muss ein Chatkonto bei einem Server vorhanden oder angelegt sein. Der Nachrichtenaustausch erfolgt dann mit einem XMPP-kompatiblen Programm freier Wahl.
Es gibt keinen genauen Nutzerzahlen - allerdings liegen diese im mehrstelligen Millionenbereich:
Normalfall: Internetnutzung
Server
XMPP ist ein föderales, dezentrales System genauso wie das auch bei E-Mail der Fall ist. Das bedeutet, dass im theoretischen Idealfall jeder Anwender seinen eigenen Server betreibt. Wenn man das selbst machen möchte, ist hierfür jedoch ein gewisses technisches Verständnis und Engagement erforderlich. Deshalb gibt es - wie bei E-Mail - zig verschiedene öffentliche Anbieter, auf deren Server dann die Verwaltung von Konten, Adressbüchern und Chatverläufe für ggfs. mehrere Geräte erfolgt.
Grafische Darstellung von Föderation und Serververnetzung anhand von wenigen Servern:
Normale Ansicht (WebGL) / Quelle (extern)
Komprimierte Ansicht (WebGL) / Quelle (extern)
Normale Ansicht / Quelle (extern)
Komprimierte Ansicht / Quelle (extern)
| | | |
Das Ganze gibt es auch noch in einer 3D-Verision (WebGL): https://xmppnetwork.goodbytes.im/3d.html (extern)
Es gibt also extrem viele Anbieter bzw. XMPP-Server und für einen Neueinsteiger scheint es schwer eine Wahl zu treffen.
Tipp zum xmppnetwork-Service:
Es ist möglich, gezielt nur die Verbindungen von einem einzigen Server anzeigen zu lassen. Dazu muss die Abfrage lediglich mit ?focus=server.tld
erweitert werden.
Welche Server bei diesem Dient aufgeführt werden bzw. wie diese ergänzt werden können, steht in den FAQ (extern)
Clients
Dank der Vorreiterrolle von „Conversations“ kann auf 80% der Smartphones mit einer modernen und intuitiven Benutzeroberfläche „getextet“ werden. Darüber hinaus gibt es jedoch noch weitere inteoperable freie Messenger für die verschiedensten Betriebssysteme und für Browser:
- Android: Conversations, monocles chat (extern), blabber.im (extern), aTalk (extern), Yaxim (ohne OMEMO) (extern), …
- iOS: Monal, Siskin, …
- Linux (Desktop): Gajim, Dino (extern), …
- Linux (Konsole): Profanity (extern), Poez.io (extern), mcabber (ohne OMEMO) (extern), …
- Windows: Gajim (extern), Pidgin * (extern), …
- Windows 10/UWP: UWPX (teilweise OMEMO) (extern)
- macOS: Beagle (extern), Monal (extern), Swift (ohne OMEMO) (extern), …
- Browser: JSXC (extern), Converse (extern), Candy (ohne OMEMO) (extern), …
* Der Multi-Messenger Pidgin ist nur eingeschränkt zu empfehlen (Stand 2021). Er ist zwar intuitiv nutzbar und unterstützt OMEMO - nicht jedoch die XMPP-Erweiterungen “MAM” (XEP-0313) und “Message Carbons” (XEP-0280): Diese sind erforderlich, damit die Chat-Historie und Nachrichten auch auf mehreren eigenen Geräten zuverlässig verteilt werden.
Genauso eingeschränkt zu empfehlen ist der Desktopclient „coy.im“, der ebenfalls nicht die Erweiterungen XEP-0313 und XEP-0280 unterstützt. Dieser Client hat sich auf OTR als Verschlüsselungsmethode festgelegt. coy.im lt. eigener Aussage nicht für den Austausch sensibler Inhalte geeignet: https://github.com/coyim/coyim#security-warning (extern)
Es ist sogar möglich selbst einen OMEMO-fähigen Jabber-Client mit Java zu schreiben, der keine 200 Zeilen Quellcode benötigt:
Eine schöne Übersicht verschiedener Clients gibt es bei xmpp24.de (extern), linkmauve.fr (extern; englisch) und bei xmppchat.eu (extern).
Egal, welcher Messenger jedoch gewählt wird - durch die gemeinsame Basis kann man kommunizieren ohne dass diese den selben Messenger installiert haben müssen. Wie bei anderen Programmen (z. B. Browsern, Dateimanagern, Bildbearbeitung, Musikprogrammen, …), kann der Benutzer das wählen, das ihm am Besten gefällt! Das „System“ funktioniert unabhängig hiervon.
Client-XEP-Übersicht
Das herausragende Merkmal (für manche ein Makel) von standardisiertem Chat ist, daß es durch Erweiterungen (Extensions/„XEPs“) an sich ändernde Anforderungen angepasst und modern gehalten werden kann. Nicht jeder Client benötigt jedoch jede Erweiterung und wenn Erweiterungen unterstützt werden sollen, ist eine entsprechende Programmierarbeit erforderlich. Einen Überblick dazu liefert folgende Übersicht:
| PDF-Datei (ca. 0,2 MB): >> hier <<
Freundlicherweise zur Verfügung gestellt von: ‘kikuchiyo’ / CC-BY-SA-4.0 |
Verschlüsselung
Zusätzlich zur grundsätzlich verwendeten Transportverschlüsselung gibt es mehrere Verschlüsselungsarten, die genutzt werden können:
- OMEMO
= Verschlüsselung pro Endstelle (Client); Nachrichten können nur auf den Geräten gelesen werden, für die sie auch verschlüsselt wurden.
Apps/Programme, die diese aktuelle Verschlüsselung unterstützen sind zu finden bei: https://omemo.top (extern)
Englischsprachige Hintergrundinformationen: https://conversations.im/omemo (extern)
- OpenPGP
= Verschlüsselung pro Nutzerkonto; Nachrichten können auch auf anderen Geräten gelesen werden.
- Nicht in Gruppen nutzbar: ‘OTR’ (nur wenn beide zum Zeitpunkt des Versands online sind)
- Nicht in Gruppen nutzbar: ‘PGP’ (alt)
Übersichtstabelle: https://wiki.xmpp.org/web/XMPP_E2E_Security#Comparative_Overview (extern)
Gedanken zur Ende-zu-Ende-Verschlüsselung
Chaträume
Neben klassischen Chats mit normalen Kontakten (2er Chats / „1:1“) gibt es auch noch private Chaträume („Gruppen“) und sogar öffentliche Chaträume. Für und in jedem Chatraum gibt es deshalb verschiedene …
… Einstellungen:
- privat (nur auf Einladung) oder öffentlich (jeder der die Adresse kennt darf rein)
- moderiert (ja/nein)
- Sichtbarkeit der Chatadressen für die Teilnehmer: (teil-)anonym oder für alle sichtbar
- in öffentlichen Verzeichnissen sichtbar (ja/nein)
- dauerhaft(persistent) oder flüchtig (besteht der Chatraum weiter, wenn der letzte Teilnehmer diesen verläßt)
- Standardsprache
- gesperrte/gebannte Chatadressen
- …
Nicht jeder Server bietet seinen Chatraum-Administratoren die selben Einstellungsmöglichkeiten; hier gibt es manchmal Unterschiede.
Rollen und Rechte von im Chat Anwesenden:
- Besucher (kein Schreibrecht bei „moderiert“)
- Teilnehmer (Schreibrecht auch bei „moderiert“)
- Moderator
Anmerkung:
Bein unmoderierten öffentlichen Chaträumen gibt es für Besucher und Teilnehmer keinen sichtbaren Unterschied - erst wenn z.B. auf Grund von Müllnachrichten („Spam“) auf „moderiert“ umgeschaltet wird, sind entsprechend Schreibrechte möglich bzw. nicht.
Zugehörigkeit:
- Besitzer
- Administrator
- Mitglied
- keine (besondere) Zugehörigkeit
- Ausgeschlossene
Mehr Informationen zu Rollen, Rechten und Zugehörigkeit: Wikipedia (extern)
Englischsprachige Quelle: XMPP.ORG (extern)
Brücken
Mit Brücken können Nachrichten von/zu anderen Systemen ausgetauscht werden. Eine Art Universalbrücke ist Matterbridge (extern). Eine Beispielnutzung ist hier (extern) beschrieben.
Allerdings sind Brücken immer mit Vorsicht zu genießen und nicht immer legal - besser ist es, standardisierte Schnittstellen zu nutzen.
Querverweis: Sind Brücken und deren Nutzung legal?
Nutzung im LAN: „Bonjour“
XMPP kann auch innerhalb eines eigenen Netzwerkes ohne Internetzugang genutzt werden. Die entsprechende Technik im Hintergrund nennt sich „Bonjour“. Ein sinnvolles Einsatzgebiet hierfür sind größere Nutzergruppen in einem geschlosssenen Netzwerk (LAN/WAN) wie zum Beispiel Arbeitsnetzwerke, Hörsäle, Wohnheime. Aber auch als Rückfallebene für die interne Firmenkommunikation, wenn durch Ausfälle/Wartungsarbeiten bei Telekommuniationsanbietern keine Internetverbindung besteht.
Empfehlungen
… Die Entwicklung sowie der Einsatz und Betrieb eines eigenen Messenger-Dienstes in Kirche und Diakonie auf Basis von etablierten und frei zugänglichen Protokollen auf föderalen Servern wäre aus Sicht des Beauftragten für den Datenschutz der EKD die beste Lösung und wird daher empfohlen.
Quelle: https://datenschutz.ekd.de/wp-content/uploads/2018/10/Ergänzende-Stellungnahm-Messgr-Dienste.pdf
vom 24.10.2018
Probleme/FAQ
AV-Telefonie
Frage: Warum funktionieren Anrufe in manchen Konstellationen nicht?
Problembeschreibung:
Befinde ich mich im gleichen WLAN mit meinem Kontakt, können wir über die App telefonieren - gehe ich über Mobilfunk online, funktioniert es nicht mehr. Es klingelt zwar beim Gegenüber, aber es kommt kein Gespräch zustande. Chatten funktioniert in jeglicher Kombination reibungslos.
Antwort:
Da für den externen Datenverkehr oft Sicherheitseinstellungen (von Firewalls oder NAT) greifen bzw. zwischen den beiden Gesprächspartnern entsprechende Hardware (z.B. Fritz!Box) ist, wird für den direkten Verbindungsaufbau ein weiterer Dienst (STUN-/TURN-Server) benötigt, der die für die direkte Übertragung (ohne die jeweilige Chatserver) erforderlichen, tatsächlichen IP-Adressen vermittelt. Sonst funktionieren Anrufe außerhalb des selben WLANS nur in manchen (seltenen) Fällen.
Ob der eigene Server die Hilfe von STUN-/TURN anbietet, kann hier eingesehen werden: https://compliance.conversations.im/test/turn (extern)
Oder direkt z.B. in Conversations in den Kontoeinstellungen über das Menü den Punkt “Serverdetails” aktivieren. Hier muß dann bei “XEP 0215 External Service Discovery” ein “ja” stehen.
Andere Ursachen könnten sein:
Es wird TOR genutzt oder eine gedrosselte Datengeschwindigkeit. So reichen 32/64kbit nach aufgebrauchten Datenvolumen zwar theoretisch aus - werden aber häufig gepulst gedrosselt. Sprich: Man bekommt nur alle paar Sekunden ordentlich Bandbreite für die Datenübertragung, hat dann aber lange Aussetzer womit A/V nicht funktioniert.
Interessantes Zusatzwissen
Geschichte und Abgrenzung
Unterschied “Jabber” / “Cisco Jabber”
Auch wenn beides den selben Ursprung hat, ist „Cisco Jabber” nicht identisch mit dem freien „Jabber (XMPP)“. „Cisco Jabber” ist eine Implementierung des XMP-Protokolls der Firma Cisco für Unternehmenskommunikation mit Cisco-Geräten. Es ist nicht quelloffen und hat von der Firma Cisco eigene Erweiterungen erhalten, die der Allgemeinheit nicht zugänglich sind.
Trotzdem ist es technisch möglich, Nachrichten auf Basis des „freien” Protokolls mit „Cisco Jabber” auszutauschen. Diese Föderation (offene Zusammenarbeit) funktioniert jedoch nur, wenn auf dem jeweils unternehmenseigenen Cisco-Server die entsprechenden Einstellungen/Freigaben einrichtet werden.
Ursprünglich wurde XMPP von Jabber, Inc. entwickelt. Dann an die XSF übergeben, und Jabber Inc wurde an Cisco verkauft.
Dossier zu XMPP
The State of XMPP in 2019 (extern) mit englischsprachigen Informationen zu:
- Open Source’ Community
- Commercial Usage
- Clients
The State of Mobile XMPP in 2016 (extern) mit englischsprachigen Informationen zu:
- Reliability (Zuverlässigkeit)
- Images and multiple devices (Bilder und mehrere Geräte)
- Mobile ready encryption (Verschlüsselung)
- An Excurse on Push (Informationen zum Funktionsweise von Push)
Versteckte Anwendergruppen
Oft ist überhaupt nicht ersichtlich, dass im Hintergrund XMPP als Basis eingesetzt wird. So gibt es richtig große Anwendungen mit vielen Millionen Nutzern wie z.B. bei Onlinespiele oder auch Messenger, die ein teils individuell abgewandeltes XMPP intern nutzen - aber nicht nach außen öffnen. Dazu gehören u.a.:
- Messenger
- WhatsApp: ~2 Milliarden Nutzer
- Kik Messenger: ~300 Millionen Nutzer
- Zoom: ~200 Millionen Nutzer
- Jitsi: ~20 Millionen Nutzer
- Moya App: ~6,5 Millionen Nutzer
- Grindr: ~4 Millionen Nutzer
- Mailfence: ~350.000 Nutzer
- IT-Systeme & Telekommunikationsanbieter
- Apple Push Notifications: ~500 Millionen Nutzer
- Facebook: Nutzeranzahl unbekannt
- Firebase Cloud Messaging : Nutzeranzahl unbekannt
- GitHub: Nutzeranzahl unbekannt
- GMX: Nutzeranzahl unbekannt
- Google Push Notifications: ~1.5 Milliarden Nutzer
- Google Cloud Print: Nutzeranzahl unbekannt
- Logitech Harmony Hub: Nutzeranzahl unbekannt
- Orange: Nutzeranzahl unbekannt
- Spiele
- Fortnite (extern): ~250 Millionen Nutzer
- Nintendo Switch (extern): ~34 Millionen Nutzer
- League of Legends (extern) (~27 Millionen Nutzer)
- EA Origin: ~40 Millionen Nutzer
- Neverwinter: ~16 Millionen Nutzer
- EVE (extern) (~1 Million Nutzer)
- Star Trek Online: ~900.000 Nutzer
- Champions Online: ~345.000 Nutzer
- Wirtschaft
Quellen:
Militärischer Einsatz
Isode (extern) ist ein Unternehmen, das kommerzielle Standardprodukte (Client- und Server-Software) für sichere Messaging- und Verzeichnissysteme für Regierungs-, Militär- und Luftfahrtbehördenkunden in über 150 Ländern entwickelt. Für die unternehmenskritischen Lösungen wird Wert auf die Nutzung internationaler Standards und offener Protokolle (IMAP, XMPP, LDAP) gelegt:
Grafische Darstellung militärischer Nutzung
Quelle für Grafik: https://www.isode.com/solutions/military-xmpp.html (extern) - wird weitergeleitet auf aktuelle Seite (extern; 10.12.2022)
Militärischer Einsatz (NATO)
Übersetzter Auszug aus dem (englischsprachigen) Papier „MAJIIC - Multisensor Aerospace-ground Joint ISR Interoperability Coalition“ der NATO:
„… In Bereichen wie z.B. Sofortnachrichten für die verteilte Zusammenarbeit von Einheiten wird das Projekt die weit verbreitete kommerzielle Standards für den potenziellen Einsatz bei gemeinschaftlichen Operationen bewerten - wie z.B. den XMPP-Standard des Jabber-Chat …“
Originaltext:
”… In areas where no STANAG is available, such as Instant Messaging tools for distributed operator collaboration, the project will assess widely used commercial standards for potential use in coalition operations, such as the XMPP standard used in the Jabber chat tool …”
Englischsprachige Quelle: https://www.nato.int/docu/update/2007/pdf/majic.pdf (extern)
Militärischer Einsatz (USA)
Englischsprachige Quelle: https://www.defencetalk.com/us-dod-selects-jabber-to-deliver-net-centric-collaboration-services-12613 (extern)
US-Geheimdienst NSA
Auch der US-Geheimdienst nutzt das Standardprotokoll.
Englischsprachige Quelle: https://www.vice.com/en/article/8qxdez/the-nsa-uses-the-same-chat-protocol-as-hackers-and-activists (extern)
Sonstiges
Open Source ist zwar an sich kostenfrei - allerdings können Firmen mit Entwicklungsaufträgen bedacht werden und das Ergebnis steht dann wiederum de Allgemeinheit zur Verfügung. Auch gibt es z.B. eine Jobbörse rund um XMPP: https://xmpp.work/ (extern)
Verweise auf externe Informationen:
Ausführliche externe Meinungen
Das System „XMPP“ gibt es schon seit ca. 20 Jahren. Dennoch bzw. gerade deshalb gibt es hierzu verschiedene Meinungen/Standpunkte:
Internationale Infoseiten
Französisch
Fazit
Im Gegensatz zu anderen Messengern/Systemen kann und darf(!) Chat auf der Basis des Protokolls XMPP überall dort eingesetzt werden, wo E-Mail auch genutzt wird! |
Ideal wäre eine Kooperation mit Matrix durch funktionierende Brücken. So könnten Unternehmen/Behörden intern die Vorteile von ausfallsicheren Chaträumen und Teamchatfunktionen genießen - und trotzdem wäre ein standardisierter Austausch von Nachrichten von/nach außen möglich. |
Zum Systemvergleich von standardisiertem Chat (XMPP) und Matrix: >> hier <<

Grundsätzliches
Was ist ein Chatkonto?
“Chatten” kommt vom englischen „to chat“, was soviel wie plaudern heißt. Ein Chatkonto ist die “Adresse” von der bzw. an die Nachrichten gesendet werden und funktioniert wie bei E-Mail. Die Chatadresse ist wie eine E-Mail-Adresse aufgebaut: „bezeichnung“ + „@“ + „servername“ + „topleveldomain“ (Beispiel: „max@mustermann.de“)
Warum braucht man ein Chatkonto?
Wenn man jemandem eine Nachricht senden will, muss dies auch bei dem richtigen Empfänger ankommen. Ein Chatkonto ist quasi die Postadresse für Sofortnachrichten. Um XMPP nutzen zu können, muss ein Chatkonto bei einem Server eingerichtet werden.
Erstellung
Freier Benutzername
Bei der Einrichtung eines Chat-Kontos ist lediglich ein frei zu wählender Benutzername sowie ein Passwort anzugeben. Sonstige personenbezogene Daten sind nicht erforderlich.
Als Benutzername bietet es sich an, seinen eigenen Namen (Vor- und/oder Nachname) mit zu verwenden. Dieses Konto sollte dann für Kontakte verwendet werden, die persönlich bekannt sind wie Familie, echte Freunde und Bekannte. Selbstverständlich kann man auch eine Telefonnummer verwenden wenn man das möchte, denn auch hierfür gibt es manchmal Gründe.
Beispiele für ein persönliches Chatkonto:
„max.muster@server.de“, „mustermann@server.de“, „max1999@server.de“, „musterfirma@server.de“ oder „+00123456789@server.de“
Neutrale Kontobezeichnungen geben dagegen keinen Rückschluß auf die Telefonnummer, den Namen, das Alter oder das Geschlecht. Mit solchen Chatkonten kann „unbedenklich“ und anonym in öffentlichen Räumen/Konferenzen geplaudert werden:
„fantasiename@server.de“, „zufallszahl@server.de“, „8fds9a0@server.de“, „tierfreund@server.de“, „blabla@server.de“
Vorhandener Benutzername (E-Mail-Adresse)
Bei folgenden deutschsprachigen E-Mail-Anbietern ist es möglich, die bereits eingerichtete E-Mail-Adresse zeitgleich auch als Chat-Konto zu verwenden:
Mehrere Chatkonten
Viele können sich nicht vorstellen, dass man mit mehreren Konten gleichzeitig im Chat-Universum unterwegs sein kann. Oft bewährt es sich jedoch, nicht nur ein (einziges) Chat-Konto anzulegen sondern mehrere. So bietet es sich beispielsweise an, neben dem Konto für persönliche Kontakte ein weiteres, neutrales Konto zur anonymen Nutzung in allgemeinen oder öffentlichen Konferenzen (Chaträumen) zu verwenden. Aber auch eine einfache Trennung von privaten und beruflichen Kontakten ist so möglich.
Praxistipp:
Es ist sogar möglich und von Vorteil, ein Konto bei einem anderen Serverbetreiber zu haben. So kann auch bei eventuell vorkommenden Wartungsarbeiten zumindest ein Konto weiter genutzt werden.
Umzug
Es ist möglich, mit einem Chatkonto von einem Serverbetreiber zu einem anderen umzuziehen. Dabei werden die Kontodaten eines Nutzers (extern) vom ursprünglichen Anbieter geholt und bei einem neuen Chatkonto wieder hochgeladen.
Umzugsdienst: https://migrate.modernxmpp.org (extern)
Quelle: https://docs.modernxmpp.org/projects/portability (extern)
Grundsätzliches
Was ist ein Server
Server kommt vom englischen „to serve“, was soviel wie bedienen/liefern heißt. Das heißt Rechner, die für andere Arbeiten bzw. Dienste/Dienstleistungen erbringen, bedienen die an sie angeschlossenen Rechner von Anwendern. Ein solcher Server ist unabhängig von der Größe und kann sowohl ein Großrechner in einem Rechenzentrum sein - als auch ein Minicoumputer wie der Raspberry Pi. Oft werden als XMPP-Server handelsübliche PC oder Notebooks eingesetzt.
Warum braucht man einen Chatserver?
Wenn man von einem Gerät auf ein anderes Nachrichten senden will, müssen beide Geräte gleichzeitig verbunden und „online“ sein. Ist jedoch das Gerät ausgeschaltet oder gerade nicht mit dem Internet verbunden, wäre also eine Kommunikation nicht ohne Weiteres möglich. Server helfen hier weiter und fungieren als Vermittler. Eingehende Nachrichten werden zwischengespeichert und dem Empfänger dann zur Verfügung gestellt, wenn dieser eine Verbindung hat.
Registrierungsarten
Um XMPP nutzen zu können muss bei einem Server ein Chat-Konto eingerichtet werden. Einige Server bieten nur eine Registrierung über den Browser an, andere nur die Registrierung direkt im bzw. über das Chatprogramm an (sogenannte „InBand“-Registrierung) und manche beides.
Auswahl
Empfehlenswerte Server
Wenn jemand einfach und ohne große Gedanken einen deutschsprachigen Anbieter sucht, der kann aus der nachfolgenden Liste mit ruhigem Gewissen fündig werden. Einfach einen Anbieter wählen, dessen Name am Besten zusagt - schließlich wird dieser Name Teil der Chat-Adresse (alle folgenden Verknüpfungen in der Übersicht gehen auf EXTERNE Seiten):
Anbieter |
Rechtsform |
Registrierung www / App |
Webchat (Chatten im Browser) |
Speicherdauer Nachrichten |
Speicherdauer Dateien |
Maximale Dateigröße |
Kontolöschung bei Nichtnutzung |
Vertrag zur Auftrags- verarbeitung möglich |
Bemerkungen / Datenschutz |
5222.de |
privat |
<ja> / ja |
nein |
30 Tage +7 Tage MAM |
30 Tage |
50 MB |
1 Jahr |
ja |
max. 100 Nachrichtenhistorie bei öffentlichen Räumen Datenschutzerklärung (extern) |
anoxinon.de |
Verein |
<ja> / nein |
<ja> |
14 Tage |
14 Tage |
25 MB |
1 Jahr |
nein |
Registrierung mit Captcha (Zahl) Speicherung von IP-Adressen nur bei fehlerhaften Loginversuchen für 72 Stunden. Erlaubt Verbindungen von anderen Servern nur, wenn diese ein gültiges Zertifikat (signierter öffentlicher Schlüssel) vorweisen. Datenschutzerklärung (extern) |
conversations.im |
gewerblich |
<ja> / ja |
nein |
90 Tage |
90 Tage |
100 MB |
1 Jahr |
ja |
Datenschutzerklärung (extern) |
draugr.de |
privat |
nein / ja |
|
? MAM: 21 Tage |
30 Tage |
15 MB max. 50 MB insg. |
2 Jahre |
nein |
Mögliche Servernamen: - draugr.de - deshalbfrei.org - ubuntu-jabber.net - verdammung.org - xabber.de Datenschutzerklärung (extern) |
hookipa.net |
privat |
<ja> / ja |
nein |
365 Tage oder Kontolöschung |
30 Tage |
100 MB |
1 Jahr |
nein |
Mögliche Servernamen: - bangpath.net (Chat & E-Mail) - hookipa.net (Chat) - nerdculture.de (Chat & Mastodon) - nerdica.net (Chat & Friendica) - nerdwind.de (Chat & E-Mail) - windfluechter.org (Chat & E-Mail) - xmpp.social (Chat) Datenschutzerklärung D/E (extern) |
hot-chilli.net |
gewerblich |
<ja> / nein |
<ja> |
93 Tage +31 Tage MAM |
31 Tage |
512 MB max. 1.000 MB (1GB) insg. |
1 Jahr |
nein |
Registrierung mit eigenem Captcha Mögliche Servernamen: - jabber.hot-chilli.net - jabber.hot-chilli.eu - hot-chilli.net - hot-chilli.eu - hot-chilli.im - im.hot-chilli.net - im.hot-chilli.eu - jabb3r.de - jabb3r.org - jabber-hosting.de - openim.de - openim.eu - xmpp-hosting.de Datenschutzerklärung (extern) Serverdaten (extern) MUC-Log (Chaträume): 31 Tage |
jabber.at |
Körperschaft |
<ja> / nein |
<ja> |
31 Tage +21 Tage MAM |
31 Tage |
30 MB |
1 Jahr |
nein |
Registrierung mit eigenem Captcha Die Registrierung ist immer wieder mal deaktiviert. Datenschutzerklärung (extern) |
jabber.cat |
privat |
<ja> / nein |
nein |
14 Tage |
14 Tage |
10 MB |
3 Monate |
nein |
Stand 09/2023: Die Registrierung ist aktuell geschlossen! Registrierung mit Rechenaufgabe Max. 500 Chatkonten auf dem Server Datenschutzerklärung (extern) |
jabbers.one |
privat |
<ja> / ja |
<ja> |
31 Tage |
10 Tage |
50 MB (insg. max. 200 MB) |
6 Monate |
nein |
Registrierung mit h-Captcha Datenschutzerklärung (extern) |
jabjab.de |
privat |
<ja> / nein |
nein |
90 Tage +90 Tage MAM max. 1.024 Nachrichten |
30 Tage |
200 MB (insg. max. 256 MB) |
6 Monate |
nein |
Max. 100 Offlinenachrichten Registrierung mit eigenem Captcha Mögliche Servernamen: - planetjabber.de - jabjab.de - jabberwiki.de - jabberforum.de - ybgood.de - pad7.de … und andere Datenschutzerklärung (extern) Quelle (extern) |
laberzentrale.de |
privat |
<ja> / nein |
nein |
max 100 Nachrichten |
30 Tage |
50 MB (insg. max. 500 MB) |
2 Jahre |
nein |
Mögliche Servernamen: - laberzentrale.de - chatpointcharly.de - schwatzi.de Maximal in 50 Gruppen, maximal 250 Gruppenteilnehmer Datenschutzerklärung (extern) Quelle Serverinformation (extern) |
magicbroccoli.de |
privat |
<ja> / ja |
nein |
365 Tage +90 Tage MAM |
31 Tage |
50 MB |
1 Jahr |
ja |
Registrierung mit eigenem Captcha Datenschutzerklärung (extern) Quelle Servernformationen (extern) |
mailbox.org |
gewerblich |
s. Bemerk. |
nein |
bis online +7 Tage MAM |
7 Tage |
10 MB max. 1 Stunde |
nein, nur bei Vertrags- kündigung |
ja |
Chatadresse = E-Mail-Adresse Jährliche Kosten gem. Preisübersicht DSGVO-Selbstauskunft und Regelungen f. digitales Erbe in den Konto-Einstellungen Datenschutzerklärung (extern) |
monocles.de |
gewerblich |
<ja> / nein |
<ja> |
60 Tage |
60 Tage |
100 MB |
nein, nur bei Vertrags- kündigung |
? |
Chatadresse = E-Mail-Adresse = Cloud Login = Mastodon-Registrierungsberechtigung Halbjährliche Kosten (inkl. Cloud, E-Mail, A/V Konferenz, etc.): ab 12,00 €) Datenschutzerklärung (extern) |
pimux.de |
privat |
<ja> / nein |
nein |
bis online +30 Tage MAM o. Kontolöschung |
30 Tage |
1.000 MB (1 GB) |
1 Jahr |
nein |
Registrierung mit Rechenaufgabe Datenschutzerklärung (extern) Quelle Serverinformationen (extern) Serververfügbarkeit (extern) |
systemausfall.org |
Verein |
<ja> / nein |
nein |
365 Tage |
60 Tage |
100 MB |
2 Jahre |
nein |
Für jedermann: jabber.systemausfall.org E-Mail-Nutzer: systemausfall.org Datenschutzerklärung (extern, Sense.Lab e.V.) |
trashserver.net |
privat |
<ja> / ja |
<ja> |
4 Wochen |
4 Wochen |
100 MB |
2 Jahre |
nein |
Registrierung aktuell nur auf Anfrage per E-Mail (extern) – ansonsten über selbst gehostetes Captcha Datenschutzerklärung (extern) Quelle Serverinformationen (extern) |
Anbieter |
Rechtsform |
Registrierung www / App |
|
Speicherdauer Nachrichten |
Speicherdauer Dateien |
Maximale Dateigröße |
Kontolöschung bei Nichtnutzung |
Vertrag zur Auftrags- datenverarb. möglich |
Bemerkungen / Datenschutz |
Höchstwert Höchstwert 2 |
- |
- |
|
Kontolöschung / bis online |
90 Tage 60 Tage |
1.000 MB 512 MB |
keine 2 Jahre |
- |
Für normales Chatten nicht erforderlich („Luxuseinstellungen“) |
Minimalwert 2 Minimalwert |
- |
- |
|
30 Tage 14 Tage |
14 Tage 7 Tage |
15 MB 10 MB |
6 Monate 3 Monate |
- |
Reicht je nach persönlicher Anforderung für normales Chatten aus |
WhatsApp |
gewerblich |
nein / ja |
|
30 Tage |
30 Tage |
100 MB / Videos 16 MB |
??? |
- |
Zur Information und als Vergleich |
Tabelle: Stand Oktober 2024
Voraussetzungen für die Aufnahme in die Übersicht sind: Eine deutschsprachige Internetseite sowie verschiedene Funktionen (Erweiterungen) - vgl. auch Compliance-Liste (extern):
Erweiterungen (XEPs) die für die Liste vorhanden sein müssen im Detail
RFC 6121: Roster Versioning XEP-0045: Multi-User Chat XEP-0065: SOCKS5 Bytestreams (Proxy) XEP-0153: vCard-Based Avatar (MUC) XEP-0160: Best Practices for Handling Offline Messages XEP-0163: Personal Eventing Protocol XEP-0191: Blocking Command XEP-0198: Stream Management XEP-0280: Message Carbons XEP-0313: Message Archive Management XEP-0313: Message Archive Management (Multi-User Chat) XEP-0352: Client State Indication XEP-0357: Push Notifications XEP-0363: HTTP File Upload XEP-0368: SRV records for XMPP over TLS XEP-0384: OMEMO Encryption XEP-0398: User Avatar to vCard-Based Avatars Conversion XEP-0411: Bookmarks Conversion Empfohlen für Videotelefonie: XEP-0215: External Service Discovery (STUN/TURN)
Nicht empfehlenswert ist derzeit der Server des ChaosComputerClubs (CCC) wegen schlechter Erreichbarkeit bei Fragen und Verbindungsproblemen.
Einstellungen / Technische Grenzen
Alle aufgeführten Anbieter erlauben ausschließlich Verbindungen mit Transportverschlüsselung (‘TLS’) der Daten; unverschlüsselte Verbindungen sind nicht möglich.\
Dennoch kann bei der Auswahl auf folgende Unterschiede der technischen Einstellungen geachtet werden:
Maximale Dateigröße beim Hochladen (für zwischengespeicherte Dateien)
Mit dieser Begrenzung schützen sich die Betreiber davor, dass ihr Rechner z.B. durch riesige Film-, Sicherungsdateien o.ä. mißbraucht wird blockiert wird. Manche Betreiber haben hier als Limit sehr wenig (2 oder 4 Megabyte) - andere sehr viel (bis zu 100 MB) eingestellt. In der Regel reichen 30-50 MB für normale Sofortnachrichten und den Austausch von Fotos und kleineren Videos aus.
Wenn sowohl Sender als auch Empfänger gleichzeitig online sind, können auch größere Dateien ausgetauscht werden.
Speicherdauer der Nachrichten
Es muss festgelegt werden, wie lange Nachrichten auf dem Server zur Verfügung gehalten werden, bevor diese hier wieder gelöscht werden. Empfehlenswert sind mindestens 3-4 Wochen, damit auch Nachrichten nach einem längeren Urlaub ohne Internetverbindung noch heruntergeladen werden können.
Der Speicher für „Offlinenachrichten“ und der Speicher für die „Verteilung auf mehrere Geräte“ (“MAM”) sind technisch gesehen 2 separate Speicherbereiche. Manche Serverbetreiber speichern eingehende Nachrichten erst im „Topf“ für Offlinenachrichten und dann beim ersten Abholen wird die Nachricht in den erweiterten „MAM“-Speicher geschrieben - andere Serverbetreiber schreiben Nachrichten sofort in den Topf für die Verteilung an mehrere Geräte („MAM“). Das klingt vielleicht zunächst verwirrend - kann jedoch bei der Suche nach vermeintlichen Fehlern hilfreich sein.
Beispiel: „Speicherdauer bis online +30 Tage MAM oder Kontolöschung“
Bedeutet: Bleibt im Offline-Speicher bis zum nächsten Anmelden (=online); ab dann wird die Nachricht 30 Tage im MAM-Speicher auch noch für andere Geräte des selben Nutzers vorgehalten (oder bis zur Kontolöschung, falls die schon vorher wäre).
Chatten in beschränkten Netzwerken
Manche öffentliche Netzwerke beschränken den Datenverkehr auf Web-Anwendungen (i.d.R. Browser) durch bestimmte „ports“. Darunter kann man sich eine Tür/Durchgang vorstellen, die ein Rechner für Außenstehende öffnen/schließen kann und hierüber bestimmte Dienste anbietet.
Für die Verbindung mit einem Chatserver ist festgelegt (standardisiert), dass die Anschlüsse mit den Nummern 5222 und 5223 zu verwenden sind - dennoch kann der Chatdienst (hier Jabber/XMPP) auch über andere Anschlussnummern zur Verfügung gestellt werden.
Das ist wichtig, wenn Chatten über eine Firewall oder über ein öffentliches Netz (WLAN) möglich sein soll, das zum Beispiel nur Browserkommunikation (Anschluß Nr. 443 oder 80) erlaubt.
Serverlisten/-Vergleiche
Nicht jeder Server unterstützt alle gängigen Funktionen und man möchte nicht bei einem Server landen, der dann Probleme macht. Glücklicherweise gibt es verschiedene Übersichten mit guten und empfehlenswerten Servern. Hier verschiedenen Seiten, auf denen verschiedene Anbieter aufgeführt sind und Zusatzinformationen gegeben werden:
Tipp: Mehrere Server
Möchte man mehrere Chatkonten nutzen, bietet es sich an, diese nicht alle bei einem Server anzulegen - das kommt der Föderalität zu Gute.
Profitipp: Eigener Server
Für technisch Interessierte ist es relativ einfach, einen Server selbst zu betreiben - mit Snikket (s.u.) sogar eine „Einfachvariante“.
Technische Mindestanforderungen
Die Mindestanforderungen an einen Server sind relativ gering. Es ist möglich, einen Minicomputer (z.B. Raspberry Pi) hierfür zu verwenden. Ansonsten ist ein handelsüblicher Rechner (Desktop/Laptop) vollkommen ausreichend.
Anleitung für die Einrichtung und den Betrieb
Grundsätzliche Hinweise zur Server-Einrichtung von Prosody und Ejabberd: XMPP-Setup (extern; PDF-Datei)
Fernüberwachung
Bei dem Betrieb eines Servers ist das Server-Monitoring wichtig bzw. kann durch eine Fernüberwachung ergänzt werden:
Wenn ein XMPP-Dienst auf eine Weise ausfällt, die die bestehende Überwachung (falls vorhanden) nicht erkennen kann, ist es hilfreich, ein „zweites Paar Augen“ zu haben, das ihn überwacht. Über https://observe.jabber.network (extern) ist es möglich, selbst gehostete XMPP-Dienste aus der Ferne zu überwachen. Betreiber können sich so in Echtzeit über eventuelle Probleme per E-Mail benachrichtigen lassen, wenn ein Chat-Dienst nicht mehr zur Verfügung steht.
Ejabberd-Server
Prosody-Server
Snikket
Als sehr gute Eigenhosting-Lösung für Familie und Freunde bietet sich Snikket (extern; englisch) an, das auf der Serversoftware Prosody basiert. Fremde Personen können bei Snikket keine Chatkonten eröffnen - wohl aber können Nutzer natürlich serverübergreifend (interoperabel) kommunizieren.
Unterschiede:
Snikket |
Prosody |
Nutzer werden selbst angelegt, keine Fremdregistration |
Fremdregistration möglich |
Fast keine Konfigurationsoptionen |
Hunderte Einstellungsmöglichkeiten |
Wird als ‘Container’ zur Verfügung gestellt |
Installation i.d.R. als ‘Paket’ |
- Öffentlicher Snikket-Chatraum (englischsprachig):
xmpp:general@channel.snikket.org?join
Schnelleinstieg: https://snikket.org/service/quickstart/ (extern; englisch)
Anleitung: https://notes.nicfab.it/en/posts/snikket/ (extern; englisch)
Weitere Serversoftware
Neben Ejabberd und Prosody (und der Sonderversion Snikket) gibt es noch weitere Serversoftware wie z.B. Openfire (extern) oder Metronome IM (extern), die selbst betrieben werden können:
https://github.com/awesome-selfhosted/awesome-selfhosted#communication---xmpp (extern)
Hier gibt es eine gute Übersicht: https://xmpp.org/software/servers.html (extern)
Um den praktischen Mehrwert von Chat (auf der Basis von internationalen Standards) zu entdecken und optimal zu nutzen, gibt es hier verschiedene Tipps und Informationen.
Mehrere Konten
Viele können sich nicht vorstellen, dass man mit mehreren Konten gleichzeitig im Chat-Universum unterwegs sein kann. Oft bewährt es sich jedoch, nicht nur ein (einziges) Chat-Konto anzulegen sondern mehrere. So bietet es sich beispielsweise an, neben dem Konto für persönliche Kontakte ein weiteres, neutrales Konto zur anonymen Nutzung in allgemeinen oder öffentlichen Konferenzen (Chaträumen) zu verwenden. Aber auch eine einfache Trennung von privaten und beruflichen Kontakten ist so möglich.
Beispiele für neutrale Kontobezeichnungen, die keinen Rückschluß auf den Namen, das Alter oder das Geschlecht geben:
„fantasiename@server.de“, „zufallszahl@server.de“, „8fds9a0@server.de“, „tierfreund@server.de“, „blabla@server.de“
Egal, wie dieses weitere Konto heißt - hierüber kann dann untereinander unbedenklich und anonym in Konferenzen geplaudert werden.
Es ist sogar möglich und von Vorteil, ein Konto bei einem anderen Serverbetreiber zu haben. So kann auch bei eventuell vorkommenden Wartungsarbeiten zumindest mit einem Konto weiter getextet werden.
Tipp:
Man kann sich selbst (an sein eigenes Chat-Konto) Nachrichten senden, was sich für Notizen wunderbar anbietet.
Spezialtipp:
Was ist, wenn man bei der Anmeldung keine E-Mail-Adresse angegeben hat und sein Passwort vergessen hat (ja, das kommt vor)?
In diesem Fall ist es sehr schwer, den Serverbetreiber davon zu überzeugen, daß es sich um das eigene Konto handelt. Hier kann es hilfreich sein, wenn man einen nicht real existierenden Kontakt angelegt hat. Da das Adressbuch nicht an Dritte übertragen wird, ist dieser „Behelfs-/Sicherheitskontakt“ deshalb nur noch dem Serverbetreiber bekannt. Dies kann dann für den Serverbetreiber ein Indiz dafür sein, daß sich tatsächlich der rechtmäßige Kontoeigentümer bei ihm meldet.
öffentliche Gruppen
Zusätzlich zu normalen Gruppen gibt es öffentliche Chaträume zu vielen Themen. Oft für Fragen zu besonderen Themen (zum Beispiel „Sicherheit“, „Android“, „Spiele“) oder Gruppen, die Unterstützung zu bestimmten Programmen bieten („Gajim“, „Conversations“, “Serversoftware”, …). Mehr Informationen sowie Beispiele und Übersichten von/zu öffentlichen Chatgruppen findet sich >> hier <<.
Mehrere Geräte
Bei XMPP können gleichzeitig mehrere Endgeräte genutzt werden. Nachrichten werden automatisch auf alle Geräten verteilt. Auch ist es egal, auf welchem Gerät eine Nachricht geschrieben wird, diese erscheint automatisch auch bei den anderen eigenen Geräten. Auch kann beim Schreiben beliebig gewechselt werden.
So ist der Gesprächsverlauf z.B. bei gleichzeitiger Nutzung von Smartphone, Tablet und PC synchron und gleich.
Formatierter Text …
… für Normalnutzer:
Text kann hervorgehoben werden:
Fette Schrift wird mit * (Stern) markiert: *Test*
Bedeutung: Text kann als “*laut*” verstanden werden (sehr laut: *LAUT!*)
Kursiver Text mit Unterstrichen einfassen: _test_ = test
Bedeutung: Text kann als Gefühl verstanden werden (gerne / gut)
Durchstrichener Text in Tilde einfassen: ~test~ = test
… für Spezialisten:
Betonungen können auch kombiniert werden. Beispielsweise fett und kursiv
> Zitate können mit dem Größerzeichen (>) dargestellt werden.
Programmcode kann mittels Rückwärtsapostroph ( ` ) als nichtproportionale Schrift angezeigt werden: ` Rückwärtsapostroph
`
Das geht auch mehrzeilig mit Zeilenumbrüchen, wenn das Apostroph jeweils am Anfang und am Ende dreifach verwendet wird.
Englischsprachige Quelle / Beschreibung: XEP-0393: Message Styling (extern)
Verschlüsselung
Verschlüsselung ja/nein
Zur Verschlüsselung (Kryptografie) gibt es ganz unterschiedliche Meinungen. Manche fordern, alles und immer mit OMEMO zu verschlüsseln - anderen reicht die Transportverschlüsselung (Wikipedia (extern) der Nachrichten aus.
Bezüglich der Sicherheit und des Datenschutzes wäre tatsächlich eine Komplettverschlüsselung richtig - dann ist es jedoch konsequent und folgerichtig, dass bei neuen Geräten der alte Verlauf von anderen Geräten nicht angezeigt werden darf/kann. Für den nicht sicherheitsorientierten “Otto-Normalbenutzer” kaum nachvollziehbar und mehr als unbequem. Im Moment gibt es jedoch keine Möglichkeit, den Nutzer selbst über den Verschlüsselungsgrad entscheiden zu lassen (ob der Chat mit oder ohne “Foreward Privacy” verschlüsselt werden soll).
Das Verwenden der OMEMO-Verschlüsselung ist u.a. zu empfehlen, wenn die Chatkonten auf einem eigenen “Familien-Server” betrieben werden. Somit ist es dem Administrator (Familienmitglied) nicht möglich, die anderen Unterhaltungen auf Systemebene auszulesen.
Verschlüsselte Gruppenchats
Die Voraussetzungen für eine Verschlüsselung in Gruppenchats sind:
- nicht-anonym
- nur für Mitglieder
- (funktioniert nur mit Kontakten, die man in der Kontaktliste hat)
Die letzte Restriktion (Kontakte müssen im Roster (in der Kontaktliste) sein) gibt es zumindest mit Conversations nicht mehr, sofern die Server der Kontakte das passende Feature anbieten.
Spezialwissen
Einladungen an Dritte versenden
Einladungen zu Gruppen können nicht nur direkt sondern auch als Verknüpfung versendet werden. Hierzu ist folgendes Format zu verwenden:
„xmpp:gruppenname@server.de?join“
Beim Klick (oder Tippen) auf die Verknüpfung öffnet sich dann automatisch die Gruppe bzw. man kann auswählen, mit welchem Konto man dort beitreten will.
Private Nachrichten
Innerhalb eines Chatraumes können Nachrichten an alle Teilnehmer gesendet werden. Darüber hinaus jedoch kann ein Gruppenmitglied per „privater Nachricht“ direkt aus der Gruppe angeschrieben werden. Hierzu muss man wissen, dass
- der Gruppenadministrator bei öffentlichen Gruppen die Anzeige der echten Kontobezeichnungen i.d.R. deaktiviert hat. Nur Administratoren können dann die echten Kontonamen sehen,
- alle Teilnehmer untereinander sehen nur ihre jeweiligen Pseudonyme, die man beim Betreten einer öffentliche Gruppe eingibt.
Beispiel: Als Benutzer „max.muster@server.de“ kann man sich in einer öffentlichen Gruppe z.B. als “Schlumpf01” bezeichnen.
Schreibt man nun eine private Nachricht (direkt aus einem öffentlichen Raum heraus) an einen anderen Teilnehmer, so wird hier das Pseudonym verwendet. Bitte dieses nicht verwechseln mit einer normalen 1:1-Nachricht von einem echten, persönlichen Konto zu einem anderen.
Je nach genutztem Programm werden diese privaten Nachrichten unterschiedlich angezeigt:
- In Gajim wird beispielsweise ein neues Fenster für diese Konversation geöffnet
- In Conversations werden diese Nachrichten chronologisch richtig im Gruppenchat angezeigt (natürlich nur bei den beiden Gesprächspartnern). Das hilft oft bei Rückfragen zu einem gerade besprochenen Thema.
Der private Eingabemodus kann in Conversations mit langem Tippen auf das Profilbild des Gesprächspartners gestartet werden und wird mit dem “x” in der Eingabezeile dann wieder beendet.
Tipp: Das Beenden nicht vergessen, da sonst alle nachfolgenden Nachrichten nicht in die Gruppe gehen, sondern nur an den einen Kontakt.
”/me”-Kommando
Bei der Eingabe der Zeichenfolge “/me” wird dieser Text durch den eigenen Namen (Pseudoname in der Gruppe) ersetzt.
Beispiel: “/me geht mit” wird zu: “Schlumpf01 geht mit.”
Technische Grenzen
Wie lange darf eine Textnachricht sein?
Die Größe einer Textnachricht (Anzahl der Zeichen) ist seitens des Protokolls nicht limitiert.
Wie groß darf ein Video über XMPP sein?
Die maximale Größe für Videodateien ist eine Einstellungssache auf dem jeweiligen XMPP-Server. Dieses Limit liegt in der Regel bei 20 bis 50 MB. Wenn das Video größer als das hinterlegte “Sendelimit” ist, versucht Conversations, es direkt (peer-to-peer) an den Client des Kontaktes zu senden, wozu dieser natürlich online sein muss.
Wie viele Teilnehmer können einer Gruppe oder einem öffentlichen Raum beitreten?
Das ist nur durch die Speicherkapazität des Servers begrenzt. Eine Begrenzung oder Maximalanzahl seitens des Protokolls gibt es nicht.
Wie lange kann eine Trennung der Verbindung (z.B. beim Wechsel der Mobilfunkmasten) max. sein?
Kurze Verbindungstrennungen sind für die Übertragung kein Problem. Es sollten jedoch nicht mehrere Minuten sein.
Gruppen, zu denen man einlädt oder eingeladen wird, kennt vermutlich jeder. Neben solchen nichtöffentlichen Gruppen „nur für Mitglieder“ gibt es auch offene Gruppen / öffentliche Chaträume.
Inhalt
Vorwort
Was bedeutet öffentlich?
Öffentlich sind Chaträume, denen jeder ohne Einladung beitreten kann, was durch Ändern der entsprechenden Option von “nur für Mitglieder” auf “öffentlich” festgelegt wird.
Bildlich kann man sich einen öffentlichen Chat dann wie einen öffentlichen Platz vorstellen, zu dem grundsätzlich jeder Zutritt hat. Alles was gesagt wird, wird auf diesem Platz von allen gehört und jeder, der gerade da ist, kann antworten (sofern eine Schreibberechtigung vorhanden ist).
Chatadressen, über die Müllnachrichten eingestellt werden oder über die unter Mißachtung grundlegender Höflichkeitsregeln (sich daneben benehmen) getextet wird, können aus einem Chat hinausgeworfen oder sogar dauerhaft “gebannt” werden.
Funktionsweise
Jeder kann bei „seinem“ Serverbetreiber geschlossene und offene Chatgruppen erstellen. Die Einstellungen sind in der Regel so gewählt, dass nur die Administratoren/Moderatoren die tatsächliche Bezeichnung der Chatkonten sehen. Alle normalen Teilnehmer sehen i.d.R. nur den beim Zutritt gewählten Aliasnamen (Spitzname/engl.:„nickname“) und das eventuell hinterlegte Profilbild. Man kann jederzeit einen solchen öffentlichen Chatraum betreten, verlassen oder auch wieder mit einem anderen Alias beitreten, wenn der gewünschte im Moment von jemand anderem belegt wäre.
Zudem hat jeder im Chat Anwesende eine Rolle, mit der verschiedene “Rechte” verbunden sind: “Besucher”, “Teilnehmer”, “Moderator/Administrator” oder “Besitzer/Eigentümer”. Eine gute Beschreibung zu den Details ist hier zu finden: https://de.wikipedia.org/wiki/Multi-User_Chat#Die_Rolle_und_Rechte_eines_Anwesenden (extern)
Darüber hinaus können (bei jedem öffentlichen Chat) weitere Einstellungen gemacht werden wie zum Beispiel:
- Soll der Chat dauerhaft angelegt sein oder beim Verlassen des letzten Anwesenden gelöscht werden?
- Soll der Raum bei Suchanfragen an den Server sichtbar sein und angezeigt werden?
- Dürfen Besucher nur mitlesen oder selbst auch Nachrichten schreiben? (Soll der Chatraum “moderiert” sein?)
- Sollen die Chatadressen unter den Besuchern/Teilnehmern jeweils (öffentlich) sichtbar sein oder nicht?
- …
Die scheinbare Anonymität (besser: Pseudonymität) eines Chats verleitet immer wieder Teilnehmer zu unangemessenen Beiträgen. Wie für das weltweite Netz die „netiquette“ gelten jedoch auch für öffentliche Chaträume entsprechende Umgangs-/Höflichkeitsformen. Für Neueinsteiger empfiehlt es sich deshalb, nach dem Betreten eines öffentlichen Chatraums eine gewisse Zeit die Beiträge passiv mitzuverfolgen. So bekommt man einen guten Eindruck vom Umgangston und der aktuellen Stimmung, die - wie im realen Leben - schwankt und nicht zu unterschätzen ist. Auch in öffentlichen Chaträumen ist der (eigene) Datenschutz zu beachten.
In der Kürze:
Stets sachlich, respektvoll und vorsichtig bleiben. Das Duzen von Teilnehmern in öffentlichen Chaträumen ist normal - ist jedoch nicht auf das realen Leben zu übertragen.
Mehr Infos:
https://de.wikipedia.org/wiki/Netiquette (extern)
https://www.netplanet.org/netiquette/chat.shtml (extern)
Nutzen
Es kommen Personen zusammen, die im sonstigen Leben keinen Bezug zueinander haben müssen.
An dieser zentralen Stelle jedoch können Probleme, Fragen, Meinungen zu einem Thema ausgetauscht werden.
Die Gruppengröße ist nicht begrenzt. So gibt es beispielsweise öffentliche Chaträume mit mehreren hundert Teilnehmern.
Somit ist der Erfahrungsschatz entsprechend groß und es findet sich fast immer jemanden, der eine Antwort geben kann und hilft.
Beispiele
Öffentliche Chaträume gibt es unzählige. Hier eine kleine Auswahl aktiver Gruppen:
Natürlich zur Initiative „Freie Messenger“
xmpp:freie-messenger@conference.jabber.de |
|
Alles rund um „Jabber(XMPP) / Conversations & Co. / Gajim, Yaxim, Dino, Monal, Siskin, … / ‘sichere’ Messenger“
xmpp:chatstandard@chat.openim.de |
|
Alles rund um das Thema „IT-Sicherheit, Datenschutz und Privatsphäre“
xmpp:it@chat.disroot.org |
|
Englischsprachige Gruppen bei denen auch die Entwickler der Programme mit dabei sind:
Informationen von und rund um den Messenger “Conversations”
xmpp:conversations@conference.siacs.eu
Informationen von und rund um den Messenger „Gajim“
xmpp:gajim@conference.gajim.org
Für Serverbetreiber
xmpp:operators@muc.xmpp.org
Ohne Anmeldung: Lesezugriff. Um selbst auch Nachrichten erstellen zu können, ist eine Anmeldung erforderlich:
https://mail.jabber.org/mailman/listinfo/operators (extern)
Geeignete Software
Zur Administration von öffentlichen Gruppen sollte man eine Software verwenden, die eine erweiterte Rechteverwaltung bzw. volle Kontrolle Über Chaträume ermöglicht. für Windows/Linux kann dazu Gajim verwendet werden; geeignete Android-Apps sind monocles chat, Cheogram und aTalk.
Einrichtung
Geeignete Programme/Apps verwenden!
Beschreibung des Chatraums für „Regeln“ nutzen oder dort auf eine Seite verweisen, wo diese nachzulesen sind
Soll der Chatraum „moderiert“ sein? Je nach dem hat man den Vorteil, daß entweder jeder sofort schreiben kann - mit der Gefahr von Müllnachrichten (“Spam”) durch Fremde. Oder daß bei moderierten Chaträumen Müllnachrichten fast ausgeschlossen sind - mit dem zusätzlichen Aufwand, bei Anfragen entsprechend Schreibrechten zu vergeben.
Alle verfügbaren Raumeinstellungen prüfen, ob diese passen und ggf. den eigenen Wünschen entsprechend ändern.
Wichtig hier ist u.a., dass der Chatraum „dauerhaft“ ist und nicht automatisch gelöscht wird, wenn gerade kein Teilnehmer anwesend ist.
Wenn möglich nicht nur ein Chatkonto mit Eigentumsrechten ausstatten wegen Vertretungs-/Notfall. Entweder auf mehrere Personen berechtigen oder zumindest ein weiteres Chatkonto anlegen und dieses Chatkonto ebenfalls als weiteren Eigentümer im Chatraum berechtigen.
Für moderierte Chaträume mehrere Personen mit Administrationsrechten ausstatten ist von Vorteil. Wenn Anfragen auf Schreibrechte kommen, sind mehrere Personen (da zeitlich über den Tag verteilt) besser, die das dann schneller bearbeiten und einrichten können.
Moderation
Wie moderiert man öffentliche Chaträume? Tipps, die die ein freundliches Miteinander unterstützen:
Auf Sachlichkeit und gegenseitigen Respekt achten, darauf hinweisen und sich selbst daran halten.
Keine negative Wertung von / Äußerungen zu Personen, da das ein persönlicher Angriff wäre - Augenmerk auf Wertung von Aussagen legen.
Hinterfragen („Habe ich es richtig verstanden, dass …“) hilft, Mißverständnisse zu vermeiden!
Nicht alles öffentlich austragen/schreiben! Eskalation vermeiden!
Bei “Problemfällen” helfen oft auch private Nachrichten/Gespräche. Private Nachrichten (PN) sind generell sehr wertvoll und werden oft genutzt. Diese sind nur an einen Empfänger gerichtet; andere sehen diese „PN“ nicht.
Fachbegriffe, Abkürzungen und Fremdwörter vermeiden.
Technische Moderation („Stummschalten“, Rauswerfen oder Bannen von Teilnehmern, Löschen von Beiträgen, …) ist clientabhänig (gut dafür sind: Gajim + aTalk) - aber auch abhängig von Serversoftware. Beispiel: Mehrere Teilnehmer auf einmal entfernen geht bei (glaube) Prosody-Servern auf Grund eines Bugs nicht.
Als Raumadministrator in Conversations unbedingt bei sich die Serverdetails bei den Chatraumdetails einschalten (wegen der Anzeige der Rechtevergabe an Teilnehmer).
Beim Anlegen von Chaträumen die möglichen Rechte für Chaträume auf verschiedenen Servern mal anschauen. Da gibt es große Unterschiede. Manche bieten mehr/andere Einstellungen als andere Server.
Diskussionen auch abseits des Hauptthemas mal zulassen und nicht sofort abwürgen. Wenn etwas zu tief/zu lang/zu emotional wird, dann eingreifen und Alternativen (direkter Austausch, besser passende Chaträume) vorschlagen.
Bei mehreren Administratoren/Moderatoren ggf. einen separaten (nichtöffentlichen) Chatraum nur für diese einrichten/nutzen zur gegenseitigen Abstimmung.
In öffentlichen Chaträumen empfiehlt es sich auch, „Admin“, „admin“, „Administrator“ und „administrator“ als Spitzname/Alias in der Mitgliederliste zu reservieren und somit für andere zu blockieren.
…
Spamschutz
Welche Maßnahmen zum Schutz vor SPAM in öffentlichen Chaträumen gibt es?
Öffentliche Chaträume sind -wie es dar Name schon sagt- öffentlich. Man kann zwar Teilnehmer (eigentlich die entsprechende Chatadresse) bannen - aber das bringt nicht immer den gewünschten Erfolg. Leute, die es wirklich darauf anlegen sind nach wenigen Minuten mit einem neuen Chatkonto und neuem Alias/Pseudonym wieder da. In dem Fall hilft nur das Hinauswerfen des Störers und Umschalten des öffentlichen Chatraums auf „moderiert“. Dann haben neue Teilnehmer lediglich Leserechte und müssen um Schreibrechte zu bekommen anfragen.
Tipps
Raumsuche
Um öffentlich zugängliche Räume zu einem bestimmten Thema zu finden, gibt es die Seite https://search.jabber.network (extern). In einigen Programmen/Apps sind Funktionen eingebaut, die ebenfalls hierauf zurückgreifen.
Mehrere Konten
Für öffentliche Gruppen wird die Nutzung eines zweiten (anonymen) Chatkontos empfohlen. Damit ist eine leichte und einfache Trennung zwischen privater und öffentlicher Erreichbarkeit gewährleistet.
Urlaubsberichte / Reisetagebuch
Gruppen können beispielsweise auch für Urlaubsberichte u.ä. verwendet werden um die Famile/Freunde mit Neuigkeiten (engl.: broadcast list) zu versorgen. Hierzu den gewünschten Chatraum erstellen und diesen dann auf „moderiert“ stellen. Somit können alle Teilnehmer die Inhalte lesen - ohne daß störende Kommentare den Reiseblog stören. Je nach Bedarf hier kann die Gruppe öffentlich oder nur auf Einladung sein.
… und schon kann das Reisetagebuch mit Texten, Fotos, Videos, Sprachmemos und interessanten Neuigkeiten gefüllt werden.
Gruppen stummschalten
Um bei großen Chaträumen nicht bei jedem neuen Eintrag ein Gebimmel, Summen oder Vibrieren zu haben, können diese Benachrichtigungen begrenzt oder auch deaktiviert werden. Eine sinnvolle Einstellung ist oft die, nur eine Benachrichtigung zu erhalten, wenn man selbst (der Spitzname/Alias) erwähnt wird.
Vorwort
Auf Grund der restriktiven Vorgaben der Betriebssysteme ist es z.B. bei iOS noch schwerer als bei Android, im Hintergrund eine dauerhafte Verbindung aufrecht zu erhalten und auch Benachrichtigungen über neue Nachrichten richtig und zeitnah anzuzeigen.
Das Bestriebssystem versucht den Stromverbrauch des Gerätes zu reduzieren indem es vermeintlich nicht benutzte Apps in den Schlafzustand versetzt/beendet.
Auch kann es bei der Nutzung der Ende-zu-Ende-Verschlüsselung über mehrere Betriebssysteme hinweg sein, dass diese von einem “Nicht-Apple-Gerät” initiiert werden muss.
Dazu kommt, dass es für die Entwicklung einer App von Apple festgelegte Rahmenbedingungen/Voraussetzungen gibt:
- Ein Apple Rechner (Desktop/Laptop) ist zwingend erforderlich.
- Der Entwickler muß auf der Apple-Plattform registriert sein.
- Es werden seitens Apple Servicegebühren verlangt.
Quellen:
Diese Erschwernisse bei der Programmierung zeigen sich in der deutlich geringeren Vielfalt an Apps (auch an Chat-Apps) unter Apple-Betriebssystemen. Trotzdem gibt es verschiedene Chat-Programme - die ihre eigenen Stärken bzw. Schwächen haben:
„Monal“ ist für normale Chats und Telefonie sehr gut geeignet und hat zudem noch eine deutsche Benutzeroberfläche.
„Siskin“ hat noch keine deutsche Benutzeroberfläche. Mit komplett anderer Oberfläche und Benutzerführung. Von der Entwicklerfirma „Tigase“ werden die Server „sure.im“, „tigase.im“, „jabber.today“, „tigase.net“ und „tigase.org“ zur Registrierung von Chatkonten angeboten (alle Serverstandorte: USA). Es ist jedoch auch möglich, ein Chatkonto von einem beliebigen Server mit Siskin zu nutzen.
Benachrichtigungen
Einen ausführlichen Test zu den Benachrichtigungen bei verschiedenen iOS-Clients mit Beteiligung verschiedener Serversoftware hat Eversten.net (extern; englisch) gemacht: “I did a quick test of three popular iOS #XMPP chat app (regarding notification reliability)”. Hier sieht man, in welchen Konstellationen Benachrichtigungen funktionieren - oder auch nicht.
Allerdings wird dem Bimmeln von Benachrichtigungen oft zu viel Aufmerksamkeit geschenkt, denn durch die vermeintliche Pflicht zur sofortigen Antwort verliert man definitiv Selbstbestimmtheit.
Tipp
Ein Chatkonto kann gleichzeitig in mehreren Apps genutzt werden. Deshalb kann es hilfreich sein, sich ein Chatkonto bei einem Serveranbieter einzurichten und dann beide Apps zu installieren. So bekommt man einen Eindruck der jeweiligen Benutzeroberfläche und kann sich dann für die App entscheiden, die einem besser gefällt.
Unterstützung: |
Die Entwicklung bei Apple-Clients schreitet aktuell stark voran. Dies wird in erster Linie von Freiwilligen gemacht. Es ist jedoch auch möglich einen Entwicklungsauftrag für bestimmte Funktionen zu vergeben, so wie das bei der Audio-/Videoanruffunktion bei Android-Clients der Fall war. Im Ergebnis profitieren dann alle davon! |
Funktionsvergleich von iOS/MacOS-Jabber(XMPP)-Clients
Plattform |
iOS |
|
|
MacOS |
|
|
|
|
Programm/App |
Chat-Secure |
Monal |
Siskin (tigase) |
Adium |
Beagle (tigase) |
Monal |
PSI+ |
|
Sprache |
|
|
|
|
|
|
|
|
- Deutsche Benutzeroberfläche |
ja |
ja |
nein |
ja |
nein |
nein |
ja |
|
- Englische Benutzeroberfläche |
ja |
ja |
ja |
? |
ja |
ja |
ja |
|
Generell |
|
|
|
|
|
|
|
|
- Mehrere Chatkonten verwalten |
ja |
ja |
ja |
ja |
ja |
ja |
nein? |
|
- Anlegen von Chatkonten direkt über die App |
ja |
ja |
ja |
nein |
ja |
nein |
ja |
|
- Texthervorhebungen im Chat (fett, kursiv, Kommentar) |
nein |
nein |
nein |
? |
? |
nein |
? |
|
- Audio-/Videotelefonie |
nein |
ja/nein |
ja |
? |
ja |
ja/nein |
? |
|
- Umbenennung von Kontakten in der Kontaktliste |
nein |
ja |
ja |
ja |
? |
ja |
ja |
|
- Chatstatus Benachrichtigung (XEP-0085) |
ja |
ja |
? |
? |
? |
? |
? |
|
- Anzeigen, wann jemand zuletzt online war (XEP-0319) |
nein |
ja |
? |
? |
? |
? |
? |
|
- Blockieren von Kontakten (XEP-0191) |
ja |
ja |
ja |
? |
? |
? |
? |
|
- Letzte Nachricht korrigieren (XEP-0308) |
nein |
ja |
ja |
? |
ja |
? |
? |
|
- Nachricht zurück ziehen (XEP-0424) |
nein |
nein |
ja |
? |
ja |
? |
? |
|
Empfang und Versand von Dateien / Teilen |
|
|
|
|
|
|
|
|
- App erscheint bei „Teilen“-Funktion (Versand) |
? |
ja |
? |
? |
? |
? |
? |
|
- Empfang / Versand von Bildern |
ja/ja |
ja/ja |
ja/ja |
ja/nein |
ja/ja |
ja/ja |
?/? |
|
- Empfang / Versand von Videos |
nein/nein |
ja/ja |
ja/ja |
?/? |
ja/ja |
nein/nein |
?/? |
|
- Empfang / Versand von Sprachnachrichten |
ja/ja |
ja/ja |
nein/nein |
?/? |
nein/nein |
nein/nein |
?/? |
|
- Empfang / Versand von sonstigen Dateien |
nein/nein |
ja/ja |
ja/ja |
?/? |
ja/ja |
ja/ja |
?/? |
|
- Empfang / Versand von Positionsdaten |
ja/nein |
ja/ja |
nein/nein |
?/? |
?/? |
ja/ja |
?/? |
|
Nachrichtenzustellung |
|
|
|
|
|
|
|
|
- sofortige Zustellung (nicht merklich zeitverzögert) |
ja |
ja |
ja |
? |
ja |
ja |
? |
|
- Benachrichtigung über Pushnachrichten |
ja |
ja |
ja |
? |
nein |
ja |
? |
|
- Pushnachrichten mit Anzeige des Inhalts |
nein |
ja |
nein |
? |
nein |
ja |
? |
|
- Nachrichtenverteilung auf mehrere Geräte (MAM / MUC-MAM) |
? |
ja/ja |
? |
? |
? |
? |
? |
|
- Gruppenchats per „MIX“ |
? |
nein |
ja |
? |
ja |
? |
? |
|
Verschlüsselung (OMEMO) |
|
|
|
|
|
|
|
|
- Verschlüsselung in Einzelchats (je ein Endgerät) |
ja |
ja |
ja |
Plugin |
ja |
ja |
Plugin |
|
- Verschlüsselung in Einzelchats (auch mehrere Geräte) |
? |
ja |
ja |
? |
? |
? |
? |
|
- Verschlüsselung in Chaträumen/Gruppen |
ja |
ja |
ja |
Plugin |
nein |
nein |
Plugin |
|
- Verschlüsselter Dateitransfer („AESGCM“) |
? |
ja |
ja |
? |
ja |
? |
? |
|
- Anzeige von „AESGCM“-verschlüsselten Bildern |
ja |
ja |
nein |
? |
? |
ja |
? |
|
- Eigenen Fingerabdruck als Text anzeigen |
ja |
ja |
ja |
? |
ja |
ja |
? |
|
- Eigenen Fingerabdruck als QR-Code anzeigen |
nein |
ja |
nein |
? |
nein |
nein |
? |
|
- Eigene Geräte anzeigen |
ja |
ja |
ja |
? |
ja |
ja |
? |
|
- Anzeige aller Schlüssel des Kontakts |
ja |
ja |
ja |
? |
ja |
ja |
? |
|
- Fingerabdruck (Schlüssel von Kontakt) als Text anzeigen |
ja |
ja |
ja |
? |
ja |
ja |
? |
|
- Fingerabdruck (Schlüssel von Kontakt) als QR-Code anzeigen |
nein |
ja |
nein |
? |
nein |
nein |
? |
|
- Anderen Geräten vertrauen / Vertrauen entziehen |
? |
ja |
ja |
? |
ja |
? |
? |
|
Administration von Chaträumen/Gruppen |
|
|
|
|
|
|
|
|
- Thema ändern |
ja |
nein |
? |
? |
? |
nein |
? |
|
- Benutzerrechte verwalten |
nein |
nein |
? |
? |
? |
nein |
? |
|
- Einstellungen verwalten |
? |
nein |
? |
? |
? |
nein |
? |
|
- Löschen von Chaträumen/Gruppen |
? |
nein |
? |
? |
? |
nein |
? |
|
Anmerkung:
Informationen zu den noch zahlreich vorhandenen
Fragen (Zellen mit Fragezeichen) sowie Infos zu
Aktualisierungen (Versionsnummer mit angeben!) bitte an:
>> Kontakt <<
Tabelle: Stand Nov. 2023 (blau markierte Texte = Änderungen seit Feb. 2022)
Nicht aufgeführte Clients
Astra-Chat - Programmstand 2017
+ Version für iOS und MacOS
- Anti-Feature: Closed Source / unfrei
- Kein OMEMO sondern eigene Verschlüsselung (von AstraChat zu AstraChat)
- Keine Benachrichtigungen
- Bildversand/Datei/Sprachversand nur von AstraChat zu AstraChat
Movim (MacOS) BETA-Version 0.13.90 (Stand 08/2019)
PSI (MacOS) - noch keine Infos
Spark (MacOS) - Version 2.8.3 vom 17.01.2017
Inhalt
Vorwort
Hier geht es um Installation, Einrichtung und Benutzung des XMPP-Messengers Conversations. Dieser ist Vorreiter und Maßstab für andere aktuelle XMPP-Messenger mit OMEMO-Unterstützung und hat sogar die Fähigkeit andere Apps per „unified push“ (extern) aus dem Stromsparmodus zurückzuholen und „aufzuwecken“ damit diese Verbindung mit ihrem eigentlichen Dienstleister/Server aufnehmen können.
Die App ist „made in germany“, was vielleicht erklärt, daß Fehlerbehebungen und eine gewisse Qualität des Codes Vorrang vor neuen Funktionen haben. Die Originalseite von Conversations (extern) im Netz ist jedoch nur englischsprachig. Deshalb hier eine behelfsmäßige Übersetzung (extern) von Freiwilligen.
Varianten
Es gibt verschiedenste Conversations-Varianten und -Abspaltungen (forks). Alle basieren auf dem ursprünglichen Conversations-Quellcode und gehören somit zur Conversations-Familie:
Conversations
Conversations ist die Standardempfehlung und der „Klassiker“. Übersichtlich, aktuell, sicher.
Die Play Store-Variante unterscheidet sich auf Grund von Google-Restriktionen geringfügig von der F-Droid-Variante: In der Play Store-Variante sind Funktionen „integrierte Suche nach öffentlichen Chaträumen“ und die „Kontakt-Integration“ deaktiviert. Beides funktioniert beim Bezug über den sicheren F-Droid-Store :-) allerdings wird hier wiederum auf Google-Push verzichtet, da dies keine freie Komponente ist.
Bezugsquellen: F-Droid / Play Store
Versionshinweise/Änderungshistorie: https://codeberg.org/iNPUTmice/Conversations/src/branch/master/CHANGELOG.md (extern)
Quicksy
Mit dieser Sonderversion des Conversations-Entwicklers soll den Einstieg in das Messaging mit dem Standardprotokoll XMPP bzw. den Umstieg von WhatsApp-Nutzern erleichtert werden.
Es wird der selbe Basiscode verwendet - allerdings gibt es hier nur ein einziges Chatkonto, was in Verbindung mit der Verwendung der Telefonnummer eine ganz simple und automatisierte Chatkontoerstellung ermöglicht. Durch die Funktion der Identifikation von Kontakten per Telefonnummer ohne das Hochladen des kompletten Telefonbuchs ist Quicksy für Umsteiger von WhatsApp geeignet, die auf eine gewisse Bequemlichkeit nicht verzichten wollen. Ansonsten ist der Funktionsumfang sowie die Optik identisch mit dem Standard-Conversations.
Vorstellen kann man sich das System wie WhatsApp/Signal, in dem alle Nutzer mit der Telefonnummer angemeldet sind, sich hierüber erkennen und ansprechen. Man meldet sich also mit seiner Telefonnummer in Quicksy an und bekommt dann für seine Kontakte im Adressbuch die entsprechenden anderern Quicksy-Nutzer vorgeschlagen. Wo ist da jetzt der Unterschied zu WhatsApp/Signal/… !?
Der große Unterschied ist, daß alle Nutzer von Quicksy.im nicht nur untereinander sondern auch nach außen offen mit allen anderen Kontakten bei anderen XMPP-Servern kommunizieren können. Quicksy ist somit ein anderer/bequemerer Einstieg in das anbieterunabhänige Chat-Universum: Eine nach außen hin offene „Startinsel“.
Zudem können Nutzer, die ihr Konto auf anderen Servern haben, ihre Chatadresse zusammen mit ihrer Telefonnummer auf dem Server von Quicksy.im hinterlegen. Dadurch erkennt Quicksy auch automatisch Kontakte mit Chatadressen von „fremden“ Servern im Adressbuch. Im Gegensatz zur kostenlosen Nutzung von Quicksy (=Conversations mit Telefon-Sonderfunktion) ist das Eintragen und Registrieren von Chatadressen mit zugehörigen Telefonnummern i.d.R. nicht kostenlos und dient somit der Finanzierung des Systems. Es gibt jedoch Ausnahmen, bei denen eine kostenlose Registrierung im quicksy.im-Verzeichnis möglich ist: Bestandskunden von conversations.im als auch bei einer Registrierung mit entsprechend gültigem Registrierungsgutschein wie zum Beispiel bei der Einführung von Quicksy.
Wie bei anderen Systemen wird eine Überprüfungs-SMS mit einem Zahlencode an die angegebene Telefonnummer gesendet. Dieser Code muß dann als Bestätigung bei der Registrierung eingegeben werden.
Anmerkung: Telefonnummern sind nicht unbedingt schlechter zu bewerten als andere Kennungen. Genauso wie die Telefonnummer werden auch die Chatadresse (Jabber-ID/JID), Matrix-ID oder auch Threema-ID mit Personen verknüpft und gleichermaßen als Selektor verwendet, um Daten zuordnen zu können.
Quelle: https://de.wikipedia.org/wiki/Selektor_(Geheimdienstabfrage) (extern)
Der typische Anwendungsfall ist also nicht, daß ein neuer Quicksy-Nutzer für eine Anmeldung zahlt sondern: Ein begeisterter Freund von unabhängigem Messaging möchte seinen Freunden den Einstieg erleichtern und „investiert“ den Betrag (knappe 5 Euro) in die Registrierung seiner Adresse+Telefonnummer. Alle seine Freunde können sich Quicksy kostenlos installieren und haben dann die selbe Bequemlichkeit wie bei WhatsApp/Signal - verbunden mit der Freiheit jederzeit auch einen anderen Client oder mehrere Chatadressen nutzen zu können.
Für bestehende Nutzer ändert sich überhaupt nichts, da die Adressen von Quicksy-Nutzern wie normale Chatadressen aufgebaut sind („+491234567890@quicksy.im“) und auch ganz normal verwendet werden können.
Tipp für Quicksy-Nutzer:
Möchte man zu einem späteren Zeitpunkt weitere/mehrere Chatkonten nutzen, kann man sein bisheriges Chatkonto ganz einfach in anderen kompatiblen Programmen wie z.B. Conversations anlegen und weiterhin nutzen. Das wird beispielsweise dann interessant, wenn man zusätzlich noch über die selbe Chatadresse (‘+telefonnummer@quicksy.im’) am PC chatten möchte oder ein zweites Chatkonto z.B. für Beruf/Verein/öffentliche Chatgruppen nutzen will.
Mit Prav App gibt es in der Zwischenzeit sogar schon einen Ableger für den indischen Raum. Auch diese App ist über F-Droid verfügbar.
Es gibt kein anderes telefonnummern-basierendens Messengersystem, das seinen Benutzern (und deren Freunden) mehr Freiheit bietet und zudem noch quelloffen ist.
Wichtig: |
Beim Betreten von öffentlichen Chaträumen wird Quicksy-Nutzern empfohlen, einen Aliasnamen zu verwenden, da ansonsten alle anderen Teilnehmer als Benutzernamen die Telefonnummer sehen. |
Bezugsquellen: F-Droid / Play Store
Englischsprachige Startseiten: https://quicksy.im (extern) / https://prav.app (extern)
monocles chat
Diese Version basiert auf dem aktuellen Conversations und dem (seit 2022 nicht mehr weiterentwickelten) blabber.im (extern). monocles chat und bietet die aktuell beste deutsche Übersetzung (besser als im Original) und noch weitere, spezielle Änderungen und praktische Ergänzungen.
Unterschiede zu Conversations:
- Direkter Wechsel zwischen Chats, Kontakten und Konten
- Individuelle Benachrichtigungen für Kontakte (schöne Möglichkeit, um sich vom Druck sofort Antworten zu müssen, zu befreien)
- [kommt: Abschaltbare Telefonfunktion für Kontakte (nicht immer möchte man für alle Kontakte per Messenger telefonisch erreichbar und „immer“ verfügbar sein)]
- Konfiguration der vom jeweiligen Server zur Verfügung gestellten Chatraum-Einstellungen (für Administratoren wichtig)
- WebXDC (extern) (damit sind praktische Erweiterungen wie Umfragen oder gemeinsame Spiele möglich)
- Eigenes Bild für Chat-Hintergrund kann gewählt werden
- Optische Vorteile bei der Nutzung von mehreren Konten (z.B. unterschiedliche Farben)
- Profilbilder können vollständig (oder abgerundet) angezeigt werden - und sogar animiert (unter 100kb und 480pixel*480pixel)
- Statt des Profilbilds des Kontakts kann auch das entsprechende Profilbild aus dem lokalen Adressbuch angezeigt werden
- Sticker- und GIF-Auswahl, Anzeige animierter GIF-Bilder
- Lange Nachrichten können verkürzt angezeigt werden
- Zusätzliche Sicherheitseinstellungen wie z.B.:
- Sichern der App durch PIN (“App-Schloß”)
- Automatisches Löschen von Nachrichten (und Anhängen) nach einem festgelegten Zeitraum
- … und vieles mehr …
ABER: monocles chat ist ein Ein-Mann-Projekt. Wie bei blabber.im kann es sein, daß der Entwickler evtl. mal kurzfristig wegfällt oder eine Pause macht.
Bezugsquellen: F-Droid / Play Store / direkt
Projektseite: https://codeberg.org/Arne/monocles_chat (extern)
Änderungshistorie: https://codeberg.org/Arne/monocles_chat/releases (extern)
Snikket
Für IT-Freunde, die der eigenen Familie oder Freunden einen eigenen Server zur Verfügung stellen wollen - oder einfach die App (Conversations mit minimalen Änderungen) als Client nutzen. Einfache Einrichtung, einfache Pflege, keine fremden Nutzer auf dem eigenen Server.
Besonderheit:
Die Snikket-App kann von jedem und unabhängig von einem Snikket-Server genutzt werden - man braucht auch keine Einladung von einem anderen Snikket-Nutzer. Es ist derzeit (Stand Oktober 2024) die einzige Möglichkeit, eine App mit der vollen Funktionalität von Conversations über den Google Play Store für Freunde kostenlos zu installieren.
Interessant ist das deshalb, da man für eine Gruppe von Personen (Schule, Kindergarten, Spiel-/Sportgruppe) vorab bei einem selbst gewählten Server Konten anlegen kann und den Leuten dann einen einfachen Einstieg in anbieterunabhängiges Messaging ohne die Verwendung der Mobilfunknummer (vgl. Quicksy) ermöglicht.
Bezugsquellen: F-Droid / Play Store
Projektseite: https://snikket.org (extern; englisch)
Cheogram
Der Schwerpunkt liegt auf Funktionen, die für Nutzer nützlich sind, die auch mit Personen in anderen Netzen Kontakt aufnehmen möchten, z. B. mit SMS-fähigen Telefonnummern. Cheogram bündelt eine Reihe von Diensten, die offene Kommunikationsnetze miteinander verbindet (Funktionen für Gateway-Nutzer), so dass alle Kontakte über eine einzige App erreichbar sind. So z.B. JMP.chat, Vonage und Twilio, um sich mit Ihren Kontakten im Telefonnetz zu verbinden. Aber auch an der Anbindung an SIP und E-Mail wird gearbeitet.
Unterschiede zu Conversations:
- Nachrichten mit Medien und Text, einschließlich animierter Medien
- Unaufdringliche Anzeige von Betreffzeilen, sofern vorhanden
- Links zu bekannten Kontakten werden mit deren Namen angezeigt
- Anzeige von Zeitstempeln für Anrufe
- Benachrichtigungen über verpasste Anrufe
- Integriert sich in die “Add Contact Flows” der Gateways.
- Bei Verwendung eines Gateways zum Telefonnetz, Integration mit der nativen Android Phone App
- Adressbuch-Integration
Bezugsquellen: F-Droid / Play Store
Projektseite: https://cheogram.com (extern; englisch)
Weniger empfehlenswerte Apps
Neben den oben aufgeführten und empfehlenswerten Apps gibt es jedoch auch noch eine Vielzahl simpler Kopien, die sich teils nur durch andere Farben unterscheiden und vermutlich allesamt nicht besser als das Original sind. Teils ist bei diesen auch ein Verstoß gegen die Conversations-Lizenz nicht ausgeschlossen, denn eigentlich muß auf die Quelle (Gultsch/Conversations) verwiesen werden.
Beispiele für weniger empfehlenswerte Conversations-Kopien sind: AgriChat, c0nnect messenger PRO, Fnord, KwikChat, Ninja chat, Onion Messenger, Storiz IM, TenguChat, XMPP Jabber Client, …
Bezugsquellen
F-Droid
Wer bereits F-Droid kennt, wird sicherlich diese top Quelle verwenden. Das gilt auch für google-freie Geräte wie das „Fairphone“.
Die F-Droid-Versionen haben keine Google-Restriktionen: Die hilfreiche Adressbuchintegration der App ist aktiviert und auch die Suchmöglichkeit nach öffentlichen Chaträumen ist nicht abgeschaltet. Zudem sind alle Apps aus F-Droid kostenlos (Spenden sind willkommen).
Google-Play-Store
… wenn anbieterunabhäniger Chat auf einem Android-Gerät mit Google-Standard-Einstellungen genutzt werden soll und F-Droid nicht genutzt werden kann/will. Auf Grund von Google-Restriktionen sind hilfreiche Funktionen wie die Adressbuchintegration oder die Suche nach öffentlichen Chaträumen hier deaktiviert.
- Quicksy (extern)
- Conversations (extern) (Installation aus dem PlayStore unterstützt den Entwickler finanziell)
Tipp:
Zu besonderen Anlässen gibt es Conversations nicht nur in F-Droid, sondern auch im PlayStore kostenlos. Bisher war das regelmäßig (neben Jubiläen) immer in der Osterwoche sowie zum Jahresende die letzte Woche im Dezember!
- monocles chat (extern)
- Snikket (extern)
Direkt vom Entwickler
Onlinehilfe
Es gibt öffentliche Chaträume, in denen jeder mitlesen und Fragen zu Conversations stellen kann:
Installation
Eine “gute” Anleitung sollte aktuell, übersichtlich und bebildert sein. „Messtome“ hat hierfür ein excellentes Beispiel zur Verfügung gestellt:
Unterstützung gesucht: |
Der bisherige Autor pflegt die Anleitung leider nicht mehr. Falls jemand Interesse hat, diese für Freie Messenger zu aktualisieren, bitte gerne melden: >>Kontakt<< |
Die ganze Anleitung kann als Druckdatei heruntergeladen und frei weitergegeben werden: Anleitung Conversations (PDF-Datei)
Zur Anpassung für eigene Zwecke steht hier die Quelldatei im Scribus-Format zur Verfügung: Anleitung (Scribus-Datei) (Scribus-Version 1.5x) (ZIP-Datei)
Aber auch im Netz gibt es viele gute Anleitungen zu Conversations oder zu Schwester-Projekten wie „monocles.chat“:
Anmerkung:
Im Netz eine bessere/aktuellere Anleitung gefunden? Dann würde ich mich über eine kurze Information freuen: >>Kontakt<<
Erster Programmstart
Wird das Programm zum ersten Mal ausgeführt, kommt folgende Auswahl:
- “Konto erstellen” (bei conversations.im - mit Folgekosten)
oder
- “Nutze eigenen Provider” (hier kann ein bereits vorhandenes Chatkonto hinterlegt werden)
Bei der F-Droid-Version kann es anschließend sein, dass Conversations auf die eventuell eingestellte Batterieoptimierung hinweist und nachfragt, ob die Akkuoptimierung ignoriert werden soll (dies ist weiter unten in den Experten-Tipps nähers erklärt).
Anschließend sollten die Einstellungen insbesondere zur „Privatsphäre“ und zur „Benachrichtigung“ kurz überprüft werden. Unter der weiteren Rubrik “Benutzeroberfläche” empfehle ich folgende Einstellungen:
- Grüner Hintergrund (für empfangene Nachrichten): AUS
- Dynamische Tags (Markierungen) unterhalb der Kontakte anzeigen: EIN
Empfehlung:
Auch die Rubrik „Erweitert“ und die „Experteneinstellungen“ anschauen (es finden sich einige interessante Optionen) und in den Experteneinstellungen wählen, ob die Kontakte ihre Nachrichten nachträglich korrigieren dürfen oder nicht. Sollte es Probleme mit Benachrichtigungen von neuen Nachrichten geben, kann hier auch noch die Option “Dienst im Vordergrund ausführen” aktiviert werden.
Versteckte Funktionen
Einige Funktionen können in Conversations über kurzes Tippen oder langes Drücken auf bestimmte Bereiche oder durch Wischgesten gesteuert werden. Auch sind manche Funktionen nur über ein Symbol und nicht über ein Menü erreichbar.
Allgemeine Steuerung
Unterhaltung beginnen / Gruppenchat beitreten
Kurz auf das runde, grüne Symbol unten rechts mit der rechteckigen Sprechblase tippen. Danach entweder einen Kontakt aus der Liste wählen, einen Kontakt erstellen oder in die Ansicht für Gruppenchats wechseln.
Chat beenden (und aus der Ansicht entfernen)
Unterhaltungen können durch einfaches „Wegwischen“ beendet werden. Hierzu in der Liste der aktuellen Unterhaltungen auf den gewünschten Eintrag tippen und diesen nach links/rechts wischen. Versehentlich weggewischte Chats können über eine (wenige Sekunden) eingeblendete Meldung wieder angezeigt werden. Ansonsten muss die Unterhaltung wieder regulär über die Kontaktliste hinzufügt werden. Das Beenden von Unterhaltungen oder Verlassen von Gruppenchats löscht keine Nachrichten - diese sind bei einem späteren Neubeginn noch/wieder vorhanden.
In Gruppenchat: Einen Kontakt direkt „ansprechen“
Im Chatverlauf kurz auf das Profilbild des Kontaktes tippen, dann wird der Name mit nachfolgendem Doppelpunkt in das Eingabefeld eingefügt.
In Gruppenchat: Einen Kontakt persönlich anschreiben
Es ist möglich, einem einzelnen Kontakt einer Gruppe eine persönliche Nachricht zukommen zu lassen. Diese ist nur für diesen bestimmt und wird auch nur diesem zugestellt/angezeigt. Hierzu lange auf das Profilbild des Kontaktes drücken, so daß im Eingabefeld der Text „Private Nachricht an xy senden …“ steht.
Wichtig:
- Die Funktion gilt solange, bis sie wieder aktiv durch Drücken auf das am rechten Rand des Eingabebereichs befindlichen Symbol („x“) beendet wird.
- Eine private Nachricht innerhalb einer Gruppe entspricht nicht der normalen 1:1-Unterhaltung mit diesem Kontakt und ist davon unabhängig.
Onlinestatus
Die Senden-Schaltfläche (symbolischer Papierflieger) zeigt den Onlinestatus des Kontakts an:
- grün: online
- grau: offline
- orange: abwesend
- rot: nicht verfügbar
Kontodetails
Kontodetails direkt aufrufen
Kurzes Tippen auf das Profilbild bei einer eigenen Nachricht.
Statusnachricht bearbeiten
In den Kontodetails ganz oben auf die viereckige Sprechblase mit dem „!“ tippen, das sich neben dem „Teilen“-Symbol befindet.
Barcode anzeigen (eigener Barcode)
In den Kontodetails durch „Teilen“-Funktion. Bei erfolgreichem Einlesen und Prüfen wird neben dem Schlüssel ein grünes Schild mit weißem Haken angezeigt.
QR-Code scannen (eigener QR-Code z.B. von einem weiteren Gerät)
In den Kontodetails durch langes Drücken auf den Schlüssel bringt ein Kontextmenü zum Vorschein. Bei mehreren Geräten ist es egal, über welches die Scan-Funktion ausgewählt wird, der Schlüssel wird bei der Überprüfung automatisch richtig zugeordnet.
Kontaktliste/Kontextmenü
Langes Drücken auf einen Kontakt zeigt das dazugehörige Kontextmenü:
- Kontaktdetails anzeigen
- Barcode anzeigen
- Kontakt sperren
- Kontakt löschen
Kontaktdetails
Kontaktdetails in normalen 1:1-Chats aufrufen
Innerhalb eines normalen Chats kommen über kurzes Tippen auf das Profilbild des Kontaktes die entsprechenden Details (Optionen für das Senden/Empfangen des Onlinestatus’ sowie die verwendeten Schlüssel)
Barcode scannen (der eines Kontaktes)
In den Kontaktdetails ist die Funktion ganz unten („Barcode scannen“) nochmals bei den OMEMO-Fingerabdrücken versteckt.
-> Langes Drücken auf den Schlüssel zeigt ein Kontextmenü.
Gerät nicht mehr vertrauen
Durch langes Drücken auf einen bereits als vertrauenswürdig markierten OMEMO-Schlüssel in den Kontaktdetails kommt das entsprechende Kontextmenü.
Kontakt bearbeiten
In den Kontaktdetails nicht nur über das Stiftsymbol ganz oben, sondern auch über kurzes Tippen auf das Profilbild des Kontaktes.
Gruppenchats/Kontextmenü
Langes Drücken auf einen Gruppenchat zeigt das dazugehörige Kontextmenü:
- Gruppenchat beitreten
- Von Kontaktliste entfernen
- Teile URI mit …
Kontakt-Profilbild/Kontextmenü
Langes Drücken auf das Profilbild eines Kontaktes, das in einem einen Chat neben dem jeweilis empfangenen Text angezeigt wird, zeigt das dazugehörige Kontextmenü an:
- Gruppenchat beitreten
- Von Kontaktliste entfernen
- Teile URI mit …
Tipps
Notizen/Dateiübertragungen
Man kann Nachrichten an „sich selbst“ senden. Diese werden dann nur einfach angezeigt und nicht nochmals bzw. nicht doppelt (als „gesendet“ und „empfangen“). Diese Funktion bietet sich an für:
- Notizen an sich selbst
- spontane Übertragung einer Datei von einem eigenen Gerät auf ein anderes (z.B. von Mobil -> PC)
Längere Texte löschen
Hat man einen Text geschrieben, möchte diesen jedoch nicht versenden, kann dieser schnell über einen „Umweg“ gelöscht werden:
Erst lange auf ein Profilbild tippen (als ob eine private Nachricht gesendet werden würde) - dann die Funktion abbrechen und der Text ist weg.
Neue Räume individuell erstellen
Man kann neue Gruppen nicht nur über die Funktion „Gruppenchat erstellen“, sondern auch über die Funktion „Gruppenchat beitreten“. Wenn der Chatraum noch nicht existiert, wird dieser mit dem angegebenen Namen des „beizutretenden“ Raumes erzeugt und hat dann zunächst noch keine Mitglieder. Das hat folgende Vorteile:
Es kann nicht nur der angezeigte Name, sondern auch der „Adressname“ individuell gewählt werden.
Das ist für öffentliche Gruppen wichtig und sehr vorteilhaft, da die Adresse einen direkten Bezug zum Thema hat (wie z.B. freie-messenger@conference.jabber.de). Für normale Gruppen (private Gruppen) ist die Adresse unwichtig.
Man kann den Raum erst komplett einrichten (angezeigter Name, Beschreibung, ggfs. Gruppen-Profilbild, Einstellen der Gruppenchatoptionen) und kann dann die Mitglieder einladen.
Beenden verhindern
Android schließt selbstständig „ungenutzte“ Apps, wenn Speicher benötigt wird bzw. um Strom zu sparen. Ein Messenger kann dann logischerweise keine Nachrichten mehr empfangen. Dieses unerwünschte Verhalten kann i.d.R. durch folgende Einstellungen verhindert werden:
Batterieoptimierung deaktivieren (“doze”-Stromsparmodus oder “App-Standby”)
- In den Android-Einstellungen den Punkt „Akku“ auswählen.
- Im nächsten Bildschirm oben rechts (die drei Punkte) auf „Akku-Leistungsoptimierung“.
- In der Übersicht der optimierten Apps kann man nun den Stromsparmodus (nicht nur) für den Messenger beenden.
Conversations im Vordergrund ausführen
Hier gibt es auch noch die Möglichkeit, die App ständig aktiv zu halten:
- In den Conversations-Einstellungen
- ganz unten unter der Rubrik “Erweitert” die “Experteneinstellungen” wählen
- wieder ganzu unten unter der Rubrik “Sonstiges” die Funktion “Dienste im Vordergrund ausführen” aktivieren
Experten-Tipps
Audio-/Videoanrufe
Manchmal wird das Hörersymbol für A/V-Anrufe nicht angezeigt. Voraussetzungen (ausführliche Beschreibung: Where is the call button (extern)) hierfür sind:
- Beide Kontakte müssen sich jeweils in der Kontaktliste haben
- Beide Kontakte müssen online sein (je nach Einstellung der App auf der Gegenseite muß diese evtl. erst durch eine normale Nachricht aus dem Schlaf/Stromsparmodus geholt werden)
- TOR darf in Conversations nicht aktiviert sein (IP-Adressen würden sonst übermittelt)
- Mindestversion für A/V-Anrufe ist Conversations 2.8.0 (oder ein anderer kompatibler Client)
Push-Nachrichten
Bei der über den Playstore installierten Version von Conversations werden Push-Benachrichtigungen an bzw. von dem Google-Server an die Endgeräte gesendet. Das System nennt sich Firebase Cloud Messaging („FCM“) und ist die aktuelle Version des ehemaligen Google Cloud Messaging („GCM“).
Bei der über F-Droid installierten Version - die Google-frei ist - hält Conversations die Verbindung zum XMPP-Server offen, was ggf. etwas mehr Stromverbrauch bedeutet.
Conversations bekommt für eingehende Nachrichten nur dann eine Push-Nachricht über den externen Dienst, wenn keine nutzbare TCP-Verbindung zwischen Client und Server existiert. Wenn eine TCP-Verbindung offen ist (das geht über ein sog. Keep-Alive-Paket alle Viertelstunde, was keine nennenswerte Bedeutung in Bezug auf Datenverbrauch oder Stromverbrauch hat), wird die Nachricht direkt übertragen, ohne dass irgendetwas bei einem externen Push-Dienst landet.
Spezialwissen für technisch Interessierte: https://github.com/iNPUTmice/p2/blob/master/README.md (extern)
Die Nutzung von Google Push durch Riot (Matrix) läuft anders: >> hier <<
Permanente Benachrichtigung
Ab Conversations 2.3.6 (Version aus dem Google Play Store), zeigt Android ab Version 8 eine permanente, erzwungene Benachrichtigung an. Diese Android-Einstellung kann jedoch manuell deaktiviert werden:
Englischsprachige Anleitung: https://github.com/siacs/Conversations/blob/master/README.md#im-getting-this-annoying-permanent-notification (extern)
Anmerkung: Bei der F-Droid-Version werden keine erzwungenen Benachrichtigung angezeigt.
Mindestberechtigungen
Conversations läuft auch ohne Zugriff auf die App-Berechtigungen „Kamera“, „Kontakte“, „Mikrofon“ und „Standort“ (natürlich stehen dann die entsprechenden Funktionen nicht mehr zur Verfügung!):
Diese Information ist keine Empfehlung sondern eher als Hinweis zu verstehen, dass diese bei Bedarf deaktiviert werden können und die Grundfunktionalität trotzdem erhalten bleibt. Auch gilt es zu beachten, dass man nach der Auswahl von „nicht mehr fragen“ beim Deaktivieren von Funktionen auch keinen Systemhinweis mehr bekommt, warum bestimmt Menüpunkte nicht funktionieren (oder Conversations bei manchen Geräten dann evtl. abstürzt). In diesem Fall muß man selbständig daran denken, die entsprechende Berechtigung in den Android-App-Einstellungen wieder zu aktivieren.
Passwortanzeige
Manchmal wird das Passwort eines Chatkontos vergessen (Empfehlung: Passwortmanager nutzen!). Die Anzeige des gespeicherten Passworts für Chatkonten ist nur mit Root-Berechtigung (also Administrationsrechte auf Android-Ebene) möglich. Es ist in der Datei /data/data/eu.siacs.conversations/databases/history
gespeichert (bei Quicksy entsprechend anders).
- Direkt auf dem Gerät: Beliebiger Dateimanager, der Textdateien anzeigen kann.
Mittels Android Debug Bridge (ADB)
- Per ADB, die sqlite holen und dann mit sqlitebrowser o.ä. (es geht auch ein einfacher Textbrowser)
- Befehl ausführen:
adb shell "su -c 'cat /data/data/eu.siacs.conversations/databases/history'" > history && sqlitebrowser ./history
(Direkt per Pipe geht nicht (adb shell “su -c ‘cat /data/data/eu.siacs.conversations/databases/history’”|sqlitebrowser) !)
- In Sqlitebrowser dann auf ‘Daten durchsuchen’ klicken und man die Passwörter aller Konten einsehen.
Herstellerspezifische Einstellungen
- Sony
In den Android-Einstellungen zum „STAMINA-Modus“ die App bei „Im Standbymodus aktive Apps“ aktivieren; zudem darf der „Ultra STAMINA-Modus“ nicht aktiviert sein.
- Huawei
Vor automatischer Beendigung geschützte Apps sind unter „Telefonmanager“ / „Energiesparen“ zu finden und dort entsprechend auszuwählen.
Detailliertere Informationen auch zu anderen Herstellern/Geräten (um eine systembedingte Beendigung von Apps zu verhindern) gibt es >> hier <<.
CEB
Nur für Experten & nur mit Linux:
Conversations ist für Standardnutzer optimiert. Eine Extraktion von Daten ist definitiv etwas für Spezialisten, weshalb ein Export bewußt nicht in der App als Funktion vorhanden ist.
Unter Linux können können jedoch trotzdem über Umwege Sicherheitskopien der lokalen Kontodaten (z.B. Nachrichtenverlauf, OMEMO-Schlüssel, Anmeldedaten) erstellt werden, die verschlüsselt in Dateien mit der Erweiterung “.CEB” („Conversations Encrypted Backup“) abgelegt werden. Die Passphrase für die Anmeldung ist in der Regel auch die Passphrase für die Backup-Verschlüsselung. Um eine Sicherungsdatei zum Beispiel auf einem Desktop-Rechner zu öffnen oder umzuwandeln, gibt es verschiedene CEB-Werkzeuge („tools“) (extern) wie ceb2txt, ceb-extract, ceb2xml und ceb-tools.
Spezialwissen
Hintergrundinformationen zur Vorgehensweise bei der Versionierung: https://semver.org/lang/de/ (extern)
Wer die verschiedenen Variablen/Standardwerte wie z.B. die Werte zur Videokompression (extern) von Conversations wissen möchte, findet diese in den (englischsprachigen) Quellen zum Programmcode:
https://github.com/siacs/Conversations/blob/master/src/main/res/values/arrays.xml (extern)
Erweiterungen (plugins)
… für die ehemalige Version “Conversations Legacy” (1.x). Die Erweiterungen sind ab der Version 2.x von “Conversations” nicht mehr erforderlich, da sie in die App integriert sind. Allerdings kann man das „Location Plugin“ weiterhin nutzen wenn man GoogleMaps bevorzugt. Das „Voice Recording Plugin“ wird von Conversations nicht mehr benötigt, ist aber technisch wohl noch von anderen Apps nutzbar (deshalb wurde es noch nicht aus den Android-Stores entfernt).
Erklärung zur Emoji-Kompatibilität:
Wenn statt einem empfangenen Emoji ein durchgestrichenes Rechteck dargestellt wird, hat das Betriebssystem eine andere Emoji-Liste als das des Senders. Das durchgestrichene Rechteck zeigt an, dass das vom Gegenüber versendete Emoji nicht korrekt dargestellt werden kann.
Passieren kann das, wenn sich Android- und iOS-Nutzer unterhalten, da Apple die Aktualisierungen selbst in der Hand hält und neue Emojis i.d.R. schneller einführen kann. Aber auch zwischen einzelnen Android-Nutzern kann das durchgestrichene Rechteck manchmal auftauchen, wenn unterschiedliche Androidversionen genutzt werden.
Um dieses Problem zu lösen, hat Google „EmojiCompat“ geschaffen, das ab Android 4.4 KitKat funktioniert. Hierbei handelt es sich um eine Probrammbibliothek, die die vom Androidsystem empfangenen und nicht darstellbaren Emojis erkennt und entsprechend ersetzt.
Die Emojis sehen somit überall gleich aus und sind quasi “kompatibel” (=“compatible”).
Vorwort
Hier geht es um Installation, Einrichtung und Benutzung des XMPP-Messengers aTalk für Android. Diesen sehr funktionsreichen Client eines augenscheinlich asiatischen Entwicklers gibt es seit ca. 2014 und ist definitiv eine Erwähnung wert!
Grundsätzlich
aTalk beschreibt sich selbst als „Ein verschlüsselter Messenger mit Video-Anrufen sowie GPS-Funktionen für Android“ und hat gegenüber anderen bekannten Clients, die den Chatstandard XMPP beherrschen gewisse Vorzüge. Darüber hinaus ist der Quellcode einsehbar („open source“).
Wenn man sich in die Benutzerführung etwas gewöhnt hat, bekommt man einen sehr funktionsreichen Client und kann damit nicht nur Chaträume anlegen sondern detailliert konfigurieren. Das ist ansonsten nur mit dem Desktop-Programm „Gajim“ (das „Schweizer Taschenmesser“ unter den Clients) möglich.
Es werden sehr gute und ausführliche (englische) Beschreibungen sowie Antworten auf regelmäßig gestellte Fragen (FAQ) (extern) bereitgestellt. So zum Beispiel, warum eine Erstanmeldung nach der Neuanlage eines Chatkontos manchmal nicht sofort funktioniert (hat Sicherheitsgründe).
Installation
aTalk kann entweder über F-Droid (extern) oder den PlayStore (extern) installiert werden.
Bedienung
Bei der ersten Benutzung von aTalk ist es von Vorteil, den grundsätzlichen Aufbau bzw. die grundsätzliche Bedienung zu kennen. So gibt es mehrere „Seiten“, die sich virtuell nebeneinander befinden und zwischen denen man durch Wischen nach links/rechts wechseln kann:
- Kontaktliste
- Liste der Chaträume(Gruppen)
- die Übersicht der „letzten Nachrichten“
- der Anrufverlauf sowie
- eine „Pod-Liste“”
Eine Seite kann auch leer sein und zunächst keine Inhalte anzeigen.
Generell gilt: Überall in der App kann auf fast alle angezeigten Elemente einfach oder lange getippt werden, um entsprechende Kontextmenüs anzuzeigen.
Aus der Beschreibung von aTalk zur Benutzerführung:
ViewPager:
aTalk verwendet das android ViewPager-Konzept, um mehrere Menüs zu präsentieren. Der Benutzer schiebt nach links/rechts, um auf andere Menüs der gleichen Kategorie zuzugreifen. Die ViewPager-Navigation wird in der Haupt-UI und während Chat-Sitzungen für 1:1-Chats sowie bei Gruppen-Chats verwendet.
Pull-Down-Menü:
Jedes Menü wird in der Regel von weiteren vom Benutzer auswählbaren Optionen begleitet. Der Zugriff auf diese Optionen erfolgt über die in der Navigationsleiste angezeigten Werkzeugsymbole oder über das Pull-Down-Menü für Überlaufoptionen. Auf einigen älteren Android-Geräten gibt es eine spezielle Menü-Taste.
Zugriff auf Chat/Info:
Auf einige der Informationen oder aTalk-Funktionen kann durch kurzes Berühren/Klicken auf das Element oder das angezeigte Symbol auf der Ansichtsseite zugegriffen werden, z. B. auf das Symbol für den Anwesenheitsstatus, die Anrufschaltflächen, das Profilbild usw. Ein Klick auf den Kontakt oder den Chatraum startet die Chatsitzung.
Kontextmenü:
Alle aTalk-Kontextmenüs werden durch langes Klicken/Drücken auf das Element aufgerufen. Langes Drücken auf ein Kontaktelement im Hauptmenü öffnet das Kontextmenü, z.B. um Text->Sprache für eingehende Nachrichten während der Chat-Sitzung zu aktivieren.
Heads-up-Benachrichtigung:
Bei einem eingehenden Anruf oder einer eingehenden Nachricht wird eine Heads-up-Benachrichtigung eingeblendet. Die Heads-up-Benachrichtigung wird vom Benutzer verwendet, um einen eingehenden Anruf anzunehmen oder abzulehnen. Im Falle einer eingehenden Nachricht kann der Benutzer die Nachricht als gelesen markieren oder direkt auf die Nachricht antworten, ohne die Chat-Sitzung zu öffnen. Sie können die eingehende Nachricht für eine halbe Stunde in den Schlummermodus versetzen.
Ereignisbenachrichtigung:
aTalk implementiert Systray-Benachrichtigungen für viele der eingehenden Ereignisse, z.B. eingehende Anrufe (besetzt, verpasst, gesichert), eingehende Nachrichten usw. Für viele dieser Ereignisse gibt es benutzerdefinierte Benachrichtigungsoptionen, z. B. Pop-up, Tonwiedergabe und Vibration. aTalk Benachrichtigungsereignisse
Funktionen
Hier ein Auszug:
- Instant Messaging im Klartext und Ende-zu-Ende-Verschlüsselung mit OMEMO oder OTR
- SSL-Zertifikat-Authentifizierung, DNSSEC- und DANE-Sicherheitsimplementierung für verbesserten sicheren Verbindungsaufbau
- OMEMO-Verschlüsselung in Gruppen-Chat-Sitzungen zur Verbesserung von Datenschutz und Sicherheit
- OMEMO Media File Sharing für alle Dateien einschließlich Stickern, Bitmoji und Emoji-Inhalten
- Unterstützung des HTTP-Datei-Uploads für die gemeinsame Nutzung von Dateien mit Offline-Kontakten und im Gruppenchat
- Unterstützung von Stickern, Bitmoji und Emoji Rich Content Sharing über Google Gboard
- Senden und Empfangen von Dateien für alle Dokumenttypen und Bilder, mit Miniaturvorschau und Gif-Animation
- Automatische Annahme von Dateiübertragungsanfragen mit Option für maximale Dateigröße
- Unterstützung von Teilen, Zitieren und Weiterleiten von Nachrichten und Medien mit Vorschau vor dem Senden
- Implementierung von Anklopfen, um einen zweiten eingehenden Anruf anzunehmen, indem der laufende Anruf in die Warteschleife gelegt wird, und um das Umschalten zwischen Anrufen zu ermöglichen
- Multi-User-Chat Betreten oder Erstellen von Räumen mit vollständiger Unterstützung der Raumkonfiguration für den Eigentümer (s.u.)
- Integrierte Captcha-geschützte Raum-Benutzeroberfläche mit Wiederholungsversuch bei Fehlschlag
- Unterstützt sowohl Sprach- als auch Videoanrufe mit ZRTP, SDES und DTLS SRTP Verschlüsselungsmodi
- Einzigartige GPS-Location-Implementierung als Standalone-Tool zum Senden von Standorten an den gewünschten Kontakt für Echtzeit-Tracking oder Playback-Animation
- Eine 360°-Straßenansicht Ihres aktuellen Standorts kann für eine selbstgeführte Tour verwendet werden. Die Straßenansicht verfolgt und folgt der Blickrichtung.
- Eingebaute Demo für GPS-Lokalisierungsfunktionen
- Integrierter Foto-Editor mit Zoomen und Zuschneiden, der Benutzer kann seinen Avatar ganz einfach aktualisieren
- Korrektur der letzten Nachricht, Nachrichtenkopie und Offline-Nachrichten (OMEMO)
- Unterstützung für vom Benutzer wählbare Themes
- …
Chaträume
Ein Alleinstellungsmerkmal von aTalk ist u.a. die Möglichkeit für Raumeigentümer die Konfiguration der vom jeweilgen Server zur Verfügung gestellten Einstellungen.
Mögliche Einstellungen sind beispielsweise:
- Kennzeichnung, ob private Gruppe oder öffentlicher Chatraum
- Beschreibungstext hinterlegen/ändern
- Sprache (z.B. de, en, fr, …), die verwendet werden sollte
- Passwort zum Zugang hinterlegen
- Festlegung, wer die Chatadressen sehen darf
- Optionen wie zum Beispiel …
- Kennzeichnung, ob der Chatraum dauerhaft sein soll oder wenn kein Teilnehmer mehr da ist gelöscht werden soll
- Nur (eingeladenen) Mitgliedern den Zutritt erlauben
- Erlaubnis, wer das Thema des Raums anpassen darf
- Schalter zur Moderation (Gäste können dann nur lesen)
- Eintrag in öffentliche Verzeichnisse erlauben/verbieten
- Speicherdauer von Nachrichten auf dem Server festlegen
-> Also für Eigentümer von Gruppen ein präzises Werkzeug für mehr Möglichkeiten als das „normal“ möglich ist.
Verweise
Projektseite: http://atalk.sytes.net (extern)
FAQ von aTalk: https://atalk.sytes.net/atalk/faq.html (extern)
Quellcode: bei Github (extern)
Installation: F-Droid (extern) oder PlayStore (extern)
Video: YouTube (extern)
Vorwort
Hier geht es um Installation, Einrichtung und Benutzung des XMPP-Messengers Monal. Monal bietet auf Apple-Geräten die Möglichkeit ein Jabber(XMPP)-Chatkonto zu nutzen. Wie viele andere Clients wird auch Monal als Open Source Software von Freiwilligen entwickelt und das Projekt kann mit Spenden oder Entwicklungsaufträgen gefördert werden. Monal gibt es sowohl für iOS aber auch für MacOS. Bei Smartphones ist mindestens iOS12 erforderlich.
Installation
Die Installation erfolgt über den Apple App Store (extern)
Anleitung
Eine gute Anleitung für Nutzer gibt es auf der Seite eversten.net (extern). Auf dieser Seite sind außerdem sehr gute Videos (extern) zur Einrichtung und Nutzung zu finden:
Empfehlungen für Nutzer: https://github.com/monal-im/monal/wiki/Considerations-for-XMPP-users (extern)
Empfehlungen für Server-Administratoren: monal-im (extern)
Sicherheit
Radically Open Security (ROS) hat am 15.04.2024 eine Sicherheitsüberprüfung einiger Teile von Monal durchgeführt. Insbesondere haben sie die Verwendung der XML-Abfragesprache und die Implementierungen von SASL2, SCRAM und SSDP geprüft. Die Ergebnisse in Kürze: Es wurden keine Sicherheitsprobleme gefunden.
Bekanntmachung: https://monal-im.org/post/00011-security-audit-1 (extern)
Sicherheitsaudit: Monal IM Penetrationstestbericht 2024 1.0 (extern)
Tipps
Das Bearbeiten der letzten Nachricht für Rechtschreibkorrekturen ist so möglich:
-> Nachricht einfach nach links wischen, um zum entsprechenden Menü zu gelangen.
Telefonie in China
Das chinesische Ministerium für Industrie und Informationstechnologie (MIIT) hat verlangt, dass die CallKit-Funktionalität in allen im chinesischen App Store verfügbaren Apps deaktiviert wird. Deshalb ist die Telefonie bei Monal in China nicht aktiviert.
Da Monal zur rechtkonformen Nutzung über die Lokalisation prüft, ob das Telefon-Icon angezeigt wird oder nicht, kann das lt. Nutzerberichten durch einfaches Umschalten der Region in iOS das Anruf-Icon in Monal angezeigt werden.
Quellen:
https://developer.apple.com/forums/thread/103083
https://www.phonearena.com/news/Apple-told-by-China-to-remove-CallKit_id105049
Profitipp
Wer bei der Weiterentwicklung und Fehlerbehebung helfen möchte, bekommt durch die Freischaltung einer versteckten Option Zugriff auf die hierfür benötigten Protokolldateien: Im Einstellungsmenü > 16 mal auf die Versionsnummer der App tippen, damit der Menüpunkt „Einstellungen / Debug“ sichtbar wird.
Detailierte Anleitung: https://github.com/monal-im/Monal/wiki/Introduction-to-Monal-Logging (extern; englisch)
FAQ
- Was bedeutet “online” und “offline” in Monal?
- Warum ist ein Feature/UI nicht implementiert oder ein Fehler behoben?
- Monal ist langsam und reagiert nicht, wenn ich mich das erste Mal mit meinem bestehenden Konto verbinde?!
- Wie exportiert man eine Log-Datei?
- Warum lässt Monal keine selbstsignierten oder abgelaufenen Zertifikate zu?
- Wie lösche ich alle Nachrichten für einen Kontakt oder Gruppenchat (MUC)?
- Wie löscht man einen Kontakt?
- Wie entfernt man einen Gruppenchat oder Kanal (MUC)?
- Wie fügt man einen neuen Gruppenchat / Kanal (MUC) oder Benutzer / JID zu seiner Kontaktliste hinzu?
Antworten zu den genannten Fragen gibt es in den (englischen) „FAQ“ (extern).
Anmerkung: Im Netz eine bessere/aktuellere Anleitung gefunden? Dann würde ich mich über eine kurze Information freuen: >>Kontakt<<
Sonstiges
Einen Vergleich verschiedener Apple-Clients gibt es >> hier <<.
Verweise
Projektseite (englischsprachig): https://monal-im.org (extern)
Aktuelle Versionshinweise (extern)
Wiki: GitHub (extern)
ACHTUNG
ChatSecure wird nicht mehr aktiv weiterentwickelt - es gibt eventuell (noch) Fehlerbehebungen! Deshalb wird empfohlen, stattdessen besser Monal oder Siskin zu nutzen! |
Vorwort
Hier geht es um Installation, Einrichtung und Benutzung des XMPP-Messengers ChatSecure. ChatSecure bietet auf iPhones die Möglichkeit ein XMPP Konto und dessen gängiste Features zu benutzen.
Die Originalseite von ChatSecure im Netz (englischsprachig) ist zu finden unter: https://chatsecure.org/ (extern)
Wie viele andere Clients wird auch ChatSecure als Open Source Software von Freiwilligen entwicklelt.
Aktuelle Versionshinweise: https://github.com/ChatSecure/ChatSecure-iOS/releases (extern)
Installation
Hier eine kurze Anleitung/Einführung (Stand: 18.07.2018) , die von “Rob” zur Verfügung gestellt wurde:
Konto hinzufügen
ChatSecure aus dem [Appstore] https://itunes.apple.com/us/app/chatsecure/id464200063 (extern) herunterladen und installieren. Beim ersten Öffnen wird um eine Spende gebeten (bitte ernsthaft darüber nachdenken, denn jeder Betrag unterstützt die Entwicklung und den Open-Source-Gedanken). Nach dem Starten erscheint zuerst ein weißer Bildschirm. Mit dem Zahnrad rechts oben kann ein neues Chatkonto hinzugefügt werden. Dazu im folgenden Bildschirm „Neues Konto“ wählen. In der Folge entweder ein „Bestehendes Konto hinzufügen“ (wenn vorhanden) oder ein „Neues Konto erstellen“.

Ein neues Konto kann auf einem der vorgeschlagenen (klick auf das Logo) oder einem selbst definiertem Server erstellt werden. Hinweis: Im Moment wird Captcha von ChatSecure noch nicht unterstützt. Falls der Server dies verlangt muss der Account vorher z.B. mit dessen Webinterface erstellt werden und als „Bestehendes Konto hinzugefügt“ werden (siehe unten). Unter „Erweitere Optionen anzeigen“ können Details angepasst werden (spezifischer Benutzername abweichend vom Spitznamen, eigenes Passwort anstatt einem zufällig generierten, Tor, Medienabruf):

Ein vorhandenes Konto kann wie folgt hinzugefügt werden (das „i“ zeigt das Passwort im Klartext). Danach empfiehlt sich das Aktivieren von Push-Nachrichten, ansonsten gibt es keine Benachrichtigung, wenn die App geschlossen ist. Nachdem diese Einstellung erlaubt wird, ist das Konto fertig eingerichtet:

Kontakte hinzufügen
Nachdem das Konto konfiguriert ist, wird das Nachrichtensymbol links aktiv. Damit können neue Chats geöffnet oder Kontakte, bzw. Gruppen hinzugefügt werden. Neben dem Account kann auch ein Name vergeben werden. Wichtig: Momentan kann der Name im Nachhinein nicht mehr geändert werden. Sobald der Name gesetzt ist, erscheint er immer so in der Kontaktliste. Nachdem der Kontakt die Anfrage akzeptiert hat, wird man benachrichtigt. Der Kontakt wird ab jetzt in der Liste angezeigt und kann für Chats angeklickt werden.

Chatten und Kontakteinstellungen
Nach dem Anklicken können Nachrichten, Bilder und Sprachnachrichten verschickt werden. An einem Schloss (offen/geschlossen) kann man erkennen ob der Chat verschlüsselt ist. Das „i“ öffnet die Kontakteinstellungen. Hier werden die Keys (eigene und die des Kontakts) angezeigt und es können einige Optionen gesetzt werden. Mit dem TOFU Schalter kann man einzelnen Keys des Kontakts vertrauen. Pro Gerät und Verschlüsselungsmethode steht ein Key zur Verfügung. Je nach Client werden nicht alle Methoden unterstützt. Unter „Erweiterte Verschlüsselungseinstellungen“ kann die bevorzugte Methode konfiguriert werden.

Profileigenschaften
Durch Klicken auf das Zahnrad rechts im Startbildschirm und das „i“ am entsprechenden Konto können dessen Einstellungen angepasst werden. Mit „Freunde einladen“ kann ChatSecure mit anderen über einen Link zusammen mit dem eigenen Benutzernamen geteilt werden. Mit „Konto bearbeiten“ erreicht man die Accounteinstellungen. „Meine Schlüssel verwalten“ zeigt die eigenen Schlüssel dieses und eventueller anderer verwendeter Geräte. Serverinformationen zeigt, welche Eigenschaften der Server unterstützt und den Status der Push Registrierung. Je mehr grün umso besser. Mit „Abmelden“ kann man sich am Server abmelden (ausloggen). „Konto migrieren“ zieht die Einstellungen auf ein anderes Konto um (inklusive Kontakte und Chats).

Hinweise
Um Fotos/Bildschirmkopien hochladen zu können, muß die Option „Filesharing via HTTP“ aktiviert werden.
Bilder und Sprachdateien können versendet werden - Videos oder andere Dateien noch nicht. (Stand 07/2018)
„Captcha“ beim Erstellen von Konten wird noch nicht unterstützt. (Stand 07/2018)
Wenn Benachrichtigungen nicht angezeigt werden, folgende Einstellungen prüfen:
- Push-Status prüfen (Kontoeinstellungen)
- „Einstellungen > Allgemeine > Hintergrundaktualisierung“ generell und für ChatSecure aktivieren
- „Einstellungen > Mitteilungen > ChatSecure“ Einstellungen prüfen
In manchen Fällen funktioniert die gegenseitige Statusfreigabe (subscription) nur einseitig oder nicht.
Lösungsversuche:
Kontakt komplett von der Liste entfernen und neu hinzufügen (dann kann auch der Spitzname des Kontakts neu gesetzt werden)
Sich einem anderen Client (z.B. Gajim/Conversations) anmelden und dort die Statusfreigabe erneut erfragen/erteilen
Nachrichten scheinen nicht anzukommen, wenn OMEMO aktiv ist:
Eventuell hat das gegenüber sein Endgerät gewechselt oder man selbst. Testhalber OMEMO deaktivieren und noch einmal probieren. Wenn dies funktioniert, dann prüfen ob alle Schlüssel sichtbar sind in den Kontakteigenschaften. Auf manchen Servern gibt es Probleme, wenn der gegenseitige Onlinestatus nicht sichtbar ist (siehe oben).
Ausführliche Anleitung
Eine ausführliche Anleitung zur Konfiguration von ChatSecure mit guten und wichtigen technischen Hinweisen zu
- Hintergrundaktualisierung,
- Push-Diensten und
- TLS-Serverzertifikaten
… findet man auf der Seite:
https://grupp-web.de/cms/2018/02/09/chatsecure-statt-whatsapp/ (extern)
Englischsprachige Anleitung
Eine englischsprachige Anleitung (für verschiedene Clients) gibt es hier:
Anmerkung: Im Netz eine bessere/aktuellere Anleitung gefunden? Dann würde ich mich über eine kurze Information freuen: >>Kontakt<<
Vorwort
Hier geht es um Installation, Einrichtung und Benutzung des XMPP-Messengers Siskin. Siskin bietet auf Apple-Geräten die Möglichkeit ein Jabber(XMPP)-Chatkonto zu nutzen. Wie viele andere Clients wird auch Siskin als Open Source Software von Freiwilligen entwickelt und das Projekt kann mit Spenden oder Entwicklungsaufträgen gefördert werden.
Projektseite (englischsprachig): https://siskin.im (extern)
Installation
Die Installation erfolgt über den Apple App Store (extern)
Anleitung
Leider ist Siskin im Moment noch nicht internationalisiert - d.h. es gibt keine Anpassung der Sprache für die (englische) Benutzeroberfläche.
Einstellungen
Nach der Installation sollten in den Einstellungen (“settings”) noch folgende Einstellungen geprüft/aktiviert werden:
- Accounts / Chatkonto wählen / die Funktionen “Push” und “MAM”
Das Aktivieren von “MAM” beinhaltet die Optionen “Enabled”, “Automatic synchronization”, “Synchronisation” / “Last 365 days”
- Chats / Funktion “HTTP upload and download”
- Chats / Messages / Funktion “Request delivery receipt” und “Encryption: OMEMO”
- Chats / Attachments / “File sharing via HTTP”
- Experimental / Die Funktion “Bookmark sync” und evtl. noch “Markdown”
- Contacts / General / “Auto-authorize contacts”
Es gibt keine automatische Erkennung der Push-Funktionalität. Wenn Push-Benachrichtigungen technisch vom Server unterstützt werden, fragt Siskin (nur einmal) nach, ob diese gewollt sind. Wird hier versehentlich “Nein” gewählt, kann man das in den Chatkonto-Einstellungen manuell wieder “aktivieren”. Auch beim Übertragen von Dateien (Hochladen von Dateien per “HTTP”) fragt Siskin beim ersten mal nach. Die Option hierzu findet sich bei “Einstellung / Chat”.
Wenn die Option “HTTP upload” in Siskin nicht aktiviert ist, wird man beim Versenden einer Datei gefragt, ob man dies aktivieren möchte.
A/V-Telefonie
Mit Siskin sind Audio- und Video-Anrufe auch zu Conversations möglich (von Conversatins zu Siskin nur, wenn beide Teilnehmer online sind).
Tipp: Bilder speichern
Es ist möglich in Siskin empfangene Bilder abzuspeichern bzw. zu teilen obwohl es keine spezielle Funktion dafür gibt. Nicht sehr intuitiv aber funktionier:
* im Chat oben auf das (i) gehen
* dann unten zu Attachments
* länger auf das entsprchende Bild tippen
* „share“ oder „copy“ wählen
Tipp: Ende-zu-Ende-Verschlüsselung
Sollte der Schlüsselaustausch nicht funktioniert haben, kann folgendes helfen:
- “push” deaktivieren und anschließend wieder aktivieren
- In Siskin den Kontakt in der Kontaktliste nach links wegwischen, “Edit” wählen und hier “Subscriptions Presence Send/Receive” deaktivieren und wieder aktivieren.
Eine Bestätigung der Option führt dazu, daß die Schlüssel und der Status etc. ausgetauscht werden, was für die Ende-zu-Ende-Verschüsselung erforderlich ist.
Entwickler-Infos (Stand 08/2019)
Externe Anleitungen
Französische Anleitung: https://www.chapril.org/Siskin-IM-pour-iPhone.html (extern)
Anmerkung: Im Netz eine bessere/aktuellere Anleitung gefunden? Dann würde ich mich über eine kurze Information freuen: >>Kontakt<<
Sonstiges
Einen Vergleich verschiedener Apple-Clients gibt es >> hier <<.
Vorwort
Hier geht es um Installation, Einrichtung und Benutzung des XMPP-Messengers Gajim. Er ist ein auf Linux und Windows sehr oft genutzter Client und wird regelmäßig aktualisiert. Gajim ist das “Schweizer Taschenmesser” unter den Chat-Clients und für Raum-Administratoren sehr zu empfehlen.
Die Projektseite von Gajim im Netz ist mehrsprachig: https://gajim.org/de/ (extern)
Aktuelle Versionshinweise: https://dev.gajim.org/gajim/gajim/blob/master/ChangeLog (extern)
Installation
Eine “gute” Anleitung sollte aktuell, übersichtlich und bebildert sein. Im Netz gibt es bereits viele gute Anleitungen, weshalb hier keine neue erfunden werden muß.
Gajim lässt sich unter Windows ohne eine Zeile Code installieren. Über die Seite https://gajim.org/de/download/#windows (extern) kann sowohl eine Installationsdatei - als auch eine portable Version heruntergeladen werden. Das Herunterladen und das Aktivieren des OMEMO-Plugins funktioniert über den Plugin-Manager: https://dev.gajim.org/gajim/gajim-plugins/wikis/OmemoGajimPlugin (extern). In Linux ist die Installation etwas aufwändiger.
Diverse Anleitungen:
Anmerkung: Im Netz eine bessere/aktuellere Anleitung gefunden? Dann würde ich mich über eine kurze Information freuen: >>Kontakt<<
Plugins
Es gibt dutzende Erweiterungen, die über den Plugin-Manager direkt in Gajim geladen und verwaltet werden können. Nach einer Neuinstallation werden konkret folgende Erweiterungen empfohlen:
OMEMO
Erweiterung für sichere Multi-Client- und Ende-zu-Ende-Verschlüsselung, die auf Axolotl und PEP basiert.
ggfs. noch “Message Box size”, was die Anpassung der Höhe des Texteingabefeldes neuer Nachrichten erlaubt.
Einstellungen zu den Erweiterungen sind direkt in bei den “Plugins” und nicht über die Einstellungen von Gajim zu machen. Beispielsweise sind bei OMEMO die eigenen Schlüssel oder die Schlüssel der Kontakte beim Plugin “OMEMO” ersichtlich.
Tipps
Es lohnt sich, einen Blick in die Einstellungen zu werfen - Gajim bietet extrem viel und ist individuell einstellbar!
Auf Grund der Offenheit von XMPP können neben einem normalen Nachrichtenaustausch auch noch viele andere Dinge gemacht werden. Das Internet der Dinge (internet of things = IoT) ist hier eine Fundgrube.
Inhalt
Corona / Covid-19
Inzidenz-Info
Über die Seite https://www.impfpush.de (extern) kann man sich Inzidenzwerte täglich und automatisch zusenden lassen. Es ist sogar möglich, mehrere Postleitzahlen zu hinterlegen, über die man informiert werden möchte. Sehr praktisch.
Impftermine
Sehr erfolgreich läuft die automatische Information über freie Impftermine für Corona/Covid19 mit Hilfe des „VaxBot“ https://vaccine.monal.im (extern) in den Vereinigten Staaten von Amerika (USA) sowie in Kanada. Das wäre auch in Europa/Deutschland schnell und ohne Probleme möglich, wenn die Termine ebenfalls veröffentlicht würden. Es ist zu hoffen, daß das bei Wegfall der Impfpriorisierung erfolgt.
An dem Projekt beteiligt sind auch mehrere deutsche Entwickler!
MAXS
… für Android-Steuerung / -Benachrichtigungen.
Die Modular Android XMPP Suite (MAXS) besteht aus einer Reihe von quelloffen lizenzierten (GPLv3) Android-Anwendungen, die es ermöglichen, ein Android-Gerät zu steuern und Benachrichtigungen über XMPP zu erhalten. So kann beispielsweise eine SMS-Nachricht auf dem Desktop/Laptop erstellt und gesendet werden, indem eine Befehlsnachricht von jedem standardkonformen XMPP-Client an MAXS dem Smartphone gesendet wird.
Beispielsweise kann der Klingelmodus geändert werden, SMS gesendet, Kontakte abgefragt - aber auch Benachrichtigungen von diesem Gerät empfangen wie eingehende SMS, letzter Standort , Batteriestatususw.
MAXS ist somit interessante Möglichkeit, das System XMPP mit Mehrwert zu nutzen.
Funktionsweise
Bei MAXS hat der Schutz der Privatsphäre einen besonderen Stellenwert. Damit der Benutzer selbst die von ihm benötigen Funktionen wählen kann, ist es modular aufgebaut. Dies bedeutet, dass die Funktionalität auf Komponenten aufgeteilt ist, die selbst Standard-Android-Anwendungen sind.
Diese Komponenten lassen sich in drei Typen einteilen: Module, Transporte und die Hauptkomponente. Module liefern die Benachrichtigungen und Befehle, die zwischen MAXS und dem Benutzer über sogenannte Transporte ausgetauscht werden. MAXS-Module und Transporte werden mit der MAXS-Hauptapplikation gesteuert.
Mehr Informationen hierzu gibt es auf der (englischsprachigen) Projektseite: http://projectmaxs.org (extern).
Die einzelnen Module sind hier beschrieben: http://projectmaxs.org/docs (extern)
Da es sich um ein offenes Projekt handelt, sind alle Informationen (auch der Quellcode) auf öffentlich verfügbar.
Englischsprachige Projektseite auf Github: https://github.com/ProjectMAXS/maxs (extern)
Quelle: MAXS
Movim
… Soziales Netzwerk mit XMPP.
Movim (extern) ist ein dezentrales soziales Netzwerk, das mit dem XMPP-Protokoll arbeitet. Man kann es mit jedem beliebigen Chatkonto nutzen; es unterstützt Gruppen-Nachrichten, Gruppen-Chats und hat die Standard-Ende-zu-Ende-Verschlüssselung (OMEMO).
Quelle: https://www.hasecke.eu/post/movim/ (extern)
Hausautomation
FHEM
Ein einfaches Command-Interface:
Mit Hilfe des Jabber-Moduls für FHEM kann man nicht nur von FHEM Nachrichten auf sein Handy senden lassen, sondern auch die Gegenrichtung benutzen, um Befehle und Anweisungen an den Server zu schicken.
Beschreibung: https://wiki.fhem.de/wiki/FHEM_spricht_jabber (extern)
FHEM-Wiki: https://wiki.fhem.de/wiki/Hauptseite (extern)
FHEM-Forum: https://forum.fhem.de/ (extern)
Heim- und Klimaüberwachung
Wer sein Zuhause auf Raumklima (Temp, Luftfeuchtigkeit, CO2 Wert, Luftdruck, etc.) oder den Zustand der Zimmerpflanzen überwachen möchte, kann dies eigentlich recht einfach erledigen. Mithilfe eines Raspberry Pi und den entsprechenden Modulen von Tinkerforge (extern) kann man sich in regelmäßigen Abständen über die klimatischen Zustände im Haus und Hof informieren zu lassen. Die Klimawerte werden dann einfach mittels XMPP auf das Handy gesendet.
Quelle: https://www.jabber.de/raspberry-pi-xmpp-einfache-heim-und-klimaueberwachung/ (extern)
Home Assistant
“Die letzten Jahre waren sehr ereignisreich für die Hausautomatisierung. IoT ist in aller Munde und viele Hersteller bieten Lösungen dafür an.
Nach der anfänglichen Begeisterung folgt aber meist die Ernüchterung: es gibt unendlich viele Standards und Lösungen, vieles wird in einer Cloud verwaltet und nicht selten werden Produkte nutzlos und zueinander inkompatibel falls der Hersteller den Service einstellt. Dazu kommen noch die vielen verschiedenen Programme und Apps zum Steuern der einzelnen Geräte.
Home Assistant ist die Lösung all dieser Probleme für Sie als DIYler. Sie können hier auf Ihrem eigenen Server – und da reicht im einfachsten Fall ein Raspberry Pi leicht aus – eine eigene mächtige Hausautomatisierungssoftware aufspielen und sie nicht nur für selbst entwickelte Geräte benutzen, sondern auch auf Integrationen für alle vorstellbaren IoT-Hersteller zurückgreifen. Und das alles Open Source.“
Quelle und Anleitung zur Einrichtung: reichelt.de (extern)
Englischsprachige Dokumentation: https://www.home-assistant.io/integrations/xmpp/ (extern)
Es ist möglich, sich RSS-Feeds per Chat (extern) zusenden zu lassen.
Nach dem Hinzufügen von „jabrss@cmeerw.net“ bekommt man nach dem Absenden von „help“ einen kleinen Hilfetext zu den verfügbaren Befehlen angezeigt (zugesendet).
Ein anderer RSS-Bot: https://github.com/jabberworld/jrd_rss
Übersetzungsdienst
Mit einer Transport-Erweiterung (extern) kan Google Translate genutzt werden. Beispielhaft zeigt jabberworld.info, wie das geht:
Einfach „ru2en@gtans.jabberworld.info“ oder „en2ru@gtans.jabberworld.info“ als Kontakt hinzufügen und alle gesendeten Texte werden nach der Übersetzung durch Google als Antwort in den Chat zurückgesendet.
- Lesezeit: 52 Minuten / ganze Rubrik: 101 Minuten - |
Über neue Informationen oder gefundene Fehler (nicht nur zu Matrix) bin ich wie immer sehr dankbar:
>> Kontakt <<
Anbieterunabhängiger Chat auf Basis des Protokolls “Matrix” ist eine Empfehlung in der Schnellübersicht!
Matrix“ befindet sich seit 2014 in der Entwicklung und ist wie XMPP ein föderiertes Messengerprotokoll. Es ist jedoch kein Internetstandard, der von der IETF definiert wurde. Es ist nicht bekannt, ob sich die Foundation um eine öffentliche Standardisierung der Kommunikationsprotokolle bemüht.
Inhalt:
- Begriffe
- Matrix als ‘die’ Lösung
- Gründe für die Entwicklung von Matrix
- Konzept
- Ende-zu-Ende-Verschlüsselung
- Datenschutz
- Brücken
- Nutzung
- Finanzierung
- Beteiligungen Matrix
- Beteiligungen New Vector
- Blockchain und Kryptowährung
- Strukturen
- Personen
- Gemeinsamkeiten
- Fazit
Begriffe
Die Strukturen sind nicht leicht zu durchschauen und oft gibt es keine klare Abgrenzung zwischen den beteiligten Organisationen und Firmen sowie den Begriffen Matrix und Element, was sich auch in der Finanzierung von Matrix/Element widerspiegelt. Selbst in der nicht in Juristensprache gehaltenen Datenschutzerklärung (extern) nur von der Matrix-Foundation (als eine von mehreren beteiligten Firmen) sind die Grenzen nicht klar auf Protokollzuständigkeit definiert bzw. beschränkt.
Unter „Matrix“ kann verstanden werden:
- Das Protokoll selbst,
- die Matrix Foundation, die nicht nur “neutral” für das Protokoll verantwortlich ist, sondern u.a. auch selbst Dienste/Server (bei Element) bereit stellt,
- das gesamte Matrix-Ökosystem,
- die Internetseite matrix.org oder auch
- der von Element bereitgestellte Server (matrix.org).
Unter „Element“ kann verstanden werden:
- Der Client / die Element-Chat-App,
- die Internetseite element.io (vector.im wird auf element.io umgeleitet) oder
- als Auftragsverarbeiter für Datenverarbeitung, Hosting und Verwaltung (die Firma).
Lt. https://element.io/privacy (extern) kann im Regelfall „Element“ mit New Vector Ltd, New Vector SARL (extern) und Element Software Inc gleichgesetzt werden:
Where you read ‘Element’ or ‘we’ or ‘us’ below, it refers to Element, a trading name of New Vector Ltd., its French subsidiary: New Vector SARL, its U.S. subsidiary: Element Software Inc, and their agents.
Matrix als ‘die’ Lösung
Matrix sieht sich selbst als die zentrale Lösung für Interoperabilität - und zum Geschäftsmodell gehört, dass durch unterschiedliche Brücken (s.u.) möglichst vielen anderen Systemen (extern) erreichen:
An important idea in Matrix is Interoperability. … We refer to the connection to other platforms as bridging.
Dieser Gedankenwelt folgend formuliert Matrix das z.B. wie folgt:
“Mit dem Kommunikationsprotokoll Matrix sollen Nutzer – unabhängig der jeweiligen App – miteinander kommunizieren können.” („Web3 Summit“ im Mai 2020)
Das hört sich super an, aber was bedeutet das tatsächlich und in der Praxis?
Es erfolgt immer eine Umleitung über Matrix, eine direkter Nachrichtenaustausch zwischen den angebundenen „Ziel“-Systemen gibt es nicht. In der Folge findet je nach Ausführung der Brücke (s.u.) eine Anreicherung von Metadaten im Matrix-Universum statt, obwohl Nutzer dort überhaupt keine Chatkonten eröffnet haben. Und sobald der Begriff „Interoperabilität“ im Marketing verwendet wird, sollte hintefragt werden, was darunter konkret verstanden wird.
Querverweise: Gedanken zur „Interoperabilität“ und Meinung zu Matrix
Gründe für die Entwicklung von Matrix
Das Matrix-Team verwendete XMPP (Openfire, ejabberd, spectrum, asmack, XMPPFramework) für Instant Messaging, bevor es etwa 2012 begann, mit offenen HTTP-APIs als Alternative zu experimentieren.
Die Hauptprobleme mit XMPP, die uns ab 2012 in diese Richtung trieben, waren:
- Nicht besonders webfreundlich - Sie können XMPP nicht einfach von einem Webbrowser aus nutzen.
- Ein einziger logischer Server pro Mehrbenutzerchatraum ist ein einziger Punkt der Kontrolle und Verfügbarkeit. Mehrbenutzerchaträume können über mehrere physische Server verteilt sein, aber sie sitzen immer noch hinter einer einzigen logischen Chatadresee und Domain. Föderierte Mehrbenutzerchaträume (FMUC) improvisiert mit einem ähnlichen Ansatz wie Matrix, aber seit Oktober 2015 gibt es keine Open-Source-Implementierungen mehr. Die MIX-XMPP-Erweiterung zielt ebenfalls darauf ab, diese Einschränkung zu beheben.
- Die Verlaufssynchronisierung ist eine Funktion zweiter Klasse.
- Die Überbrückung zu anderen Protokollen und die Defragmentierung bestehender Kommunikationsanwendungen und -netze ist eine Funktion zweiter Klasse.
- Stanzas werden ohne Erweiterungen nicht gerahmt oder zuverlässig ausgeliefert. Siehe wiki.xmpp.org für eine Stellungnahme von XMPP zu diesem Thema.
- Die Unterstützung mehrerer Geräte ist begrenzt. Carbons und MAM zielen darauf ab, dies zu beheben.
- Der grundlegende Funktionsumfang ist so minimal, dass eine Fragmentierung der Funktionen zwischen Clients und Servern üblich ist, zumal die Interoperabilitätsprofile für die Funktionen in Verzug geraten sind (Stand: Juli 2015).
- Kein starkes Identitätssystem (d. h. keine standardmäßige E2E-PKI, es sei denn, Sie zählen X.509-Zertifikate, die fragwürdig sind)
- Nicht besonders gut für mobile Anwendungsfälle konzipiert: Push; bandbreiteneffiziente Transporte. Seit dem Zeitpunkt der Erstellung dieses Artikels ist ein Push XEP erschienen, und wiki.xmpp.org gibt an, dass XMPP über eine Verbindung mit 9600bps + 30s Latenzzeit nutzbar ist.
Abgesehen davon ist der ganze Bereich XMPP vs. Matrix ziemlich subjektiv. Anstatt darüber zu streiten, welcher offene interoperable Kommunikationsstandard am besten funktioniert, sollten wir einfach zusammenarbeiten und alles miteinander verbinden. Je mehr Föderation und Interoperabilität, desto besser.
Wir betrachten Matrix und XMPP als recht unterschiedlich; im Kern kann man sich Matrix als eine letztendlich konsistente globale JSON-Datenbank mit einer HTTP-API und Pubsub-Semantik vorstellen - während man XMPP als ein Nachrichtenübertragungsprotokoll betrachten kann. Man kann beide verwenden, um Chatsysteme zu bauen; man kann beide verwenden, um Pubsub-Systeme zu bauen; jedes kommt mit unterschiedlichen Kompromissen. Matrix verfügt über eine absichtlich umfangreiche Grundausstattung an Funktionen, XMPP über eine absichtlich minimale Grundausstattung an Funktionen. Wenn XMPP das tut, was Sie brauchen, dann freuen wir uns wirklich für Sie :) In der Zwischenzeit hat eine XMPP-Brücke wie Skaverats xmpptrix beta oder jfreds matrix-xmpp-bridge oder Matrix.org’s eigene purple-matrix das Potential, beide Umgebungen nebeneinander existieren zu lassen und die Vorteile der jeweils anderen zu nutzen.
Maschinell übersetzt aus Quelle: https://web.archive.org/web/20180711050333/https://matrix.org/docs/guides/faq.html (extern)
Querverweis: Kritik
Konzept
Bei Matrix werden Daten nicht nur von einem Server sondern jeweils von allen Servern der in der Gruppe bzw. bei dem Gespräch beteiligten Personen gespeichert. Des Weiteren ist das Bereitstellen von “Brücken” zu anderen Systemen ist ein wesentlicher Punkt, mit dem Matrix einen Beitrag zur Interoperabilität leistet.
Durch die auf alle beteiligten Servern verteilte Daten besteht eine gewisse Ausfallsicherheit von Chaträumen.
Jede Konversation (egal ob 1:1, Gruppe oder Brücke zu irgendeinem anderen Protokoll) ist ein Raum - auch wenn 2er-Chats nicht als solche benannt werden. Dadurch läßt sich dann z.B. ein 1:1 Chat zu einer Gruppe machen oder auch umgekehrt. Man kann auch problemlos beliebig viele Räume mit einem Kontakt öffnen. Für einen Chat mit egal wie vielen Nutzern (auch in eigenen Chats für sich selbst, um sich bspw. selbst Notizen über mehrere Clients zu senden) wird also ein Raum erstellt. Auf Grund dieses Umstand kann also jederzeit ein persönliches Gespräch um weitere Teilnehmer ergänzt werden.
Chaträume werden unter allen beteiligten Servern der Teilnehmer synchronisiert (auf jedem beteiligten Server sind alle Nachrichten des Raumes gespeichert). Das bedeutet bei einem eventuellen Ausfall eines Servers, dass alle Teilnehmer von anderen Servern den Chatraum ganz normal weiternutzen können. Bezogen auf die Versionsverwaltung „git“ könnte man sich das ungefähr als „chatten über git“ vorstellen. Natürlich ist das nicht tatsächlich „git“ - aber das Prinzip ist das Selbe und deshalb für das Verständnis hilfreich.
Die Ausfallsicherheit von Chaträumen wird durch einen höheren Ressourcenbedarf erkauft. Ausfallsichere Chaträume sind insbesondere für Firmen, Unternehmen, Behörden interessant. In den Spezifikationen (https://spec.matrix.org/latest/#architecture) (extern) wird diese Replikation und Matrix-eigene-Definition von ‘Föderation’ beschrieben:
Clients kommunizieren in der Regel miteinander, indem sie Ereignisse im Kontext eines virtuellen “Raums” senden. Die Raumdaten werden auf allen Homeservern repliziert, deren Benutzer an einem bestimmten Raum beteiligt sind. Somit hat kein einzelner Homeserver die Kontrolle oder das Eigentum über einen bestimmten Raum. Die Homeserver modellieren die Kommunikationshistorie als einen teilweise geordneten Graphen von Ereignissen, den so genannten “Ereignisgraphen” des Raums, der mit Hilfe der “Server-Server-API” zwischen den teilnehmenden Servern synchronisiert wird und schließlich konsistent ist. Dieser Prozess der Synchronisierung des gemeinsamen Gesprächsverlaufs zwischen Homeservern, die von verschiedenen Parteien betrieben werden, wird “Föderation” genannt. Matrix optimiert die Eigenschaften Verfügbarkeit und Partitionierung des CAP-Theorems auf Kosten der Konsistenz.
Bezüglich des Konzepts bzw. der erfordelichen Ressourcen hat sich der Gründer/Mitentwickler/Direktor Hodgson persönlich in einem Blog-Kommentar; Mai 2021 (extern) so geäußert:
Die Tatsache, dass Matrix so viele Ressourcen für einen einzelnen Benutzer verbraucht, liegt daran, dass es sich um einen Nachrichtenspeicher und nicht um ein Nachrichtenprotokoll wie XMPP handelt. Wenn Sie einer Vielzahl von belegten Räumen beitreten, werden die Räume auf Ihrem Server repliziert. So kann ein einzelner Benutzer leicht Gigabytes an Speicherplatz verbrauchen. Wir sind dabei, die Effizienz zu verbessern, aber letztendlich kann ein begeisterter Benutzer viel mehr Speicherplatz verbrauchen als Tausende von Benutzern, die sich nur gegenseitig DM schicken.
Das Protokoll ist monolitisch (aus einem Guß) und besteht nicht aus unterschiedlichen oder erweiterbaren Modulen. Bei neuen oder veränderten Anforderungen wird das Protokoll als Einheit geändert/ergänzt. Die Serverimplementation kann dabei auch aus mehreren Teilen bestehen, solange der Server als Ganzes, die Matrix Spezifikation komplett unterstützt.
Für Telefonie (Audio-/Videotelefonie) wird seitens des Protokolls „WebRTC“ verwendet - für Videokonferenzen dagegen das sehr gut integrierte „Jitsi“ und BigBlueButton (BBB). Jitsi widerum verwendet die XMPP-Erweiterung „Jingle“ zum Signalieren der Videostreams zwischen Clients und Bridge. Darüber hinaus wird „XMPP MUC“ zur Verwaltung der Konferenzräume verwendet.
Im Juli 2020 wurde der Matrix-Referenz-Client „Riot“ (der Messenger), New Vector (der Firma hinter Riot) und Modular (Webhosting für Matrix-Server) in „Element“ unbenannt. Ein Wechsel des Lizenzmodells (von GPL zu AGPL) folgte Ende 2023. Informationen dazu von Element.io (extern) und Matrix.org (extern). Das ist hier deshalb aufgeführt, da es eine enge Verquickung/Verbindung von matrix.org und element.io gibt.
In der Kürze bedeutet AGPL: Wenn Änderungen am AGPL-Code vorgenommen werden und dieser verteilt wird, müssen die Änderungen an das ursprüngliche Projekt zurücksendet werden.
Das Matrix-Protokoll hier mal (sehr komprimiert) zum nachlesen: https://github.com/matrix-construct (extern)
Und hier noch ein Übersicht von Dokumenten zu Sicherheitsthemen: https://github.com/jryans/awesome-matrix#research (extern)
Quellen (alle englischsprachig):
Ende-zu-Ende-Verschlüsselung
Die Matrix-Ende-zu-Ende-Verschlüsselung bietet keine sogenannte „vorwärtsgerichtete Sicherheit“ (perfect forward secrecy / PFS; vgl. Grenzen der Matrix Verschlüsselung). Sie hat das Betastadium im Mai 2020 verlassen und ist in privaten Chaträumen aktiviert.
Quelle: https://github.com/vector-im/riot-web/issues/6779#issuecomment-624140449
Technisch basiert die Verschlüsselung auf „Olm“ bzw. „Megolm“. Es ist eine Implementierung des Double Ratchet-Verfahrens, das auch Grundlage der bei Jabber bekannten OMEMO-Verschlüsselung ist. 2016 wurde die Olm-Implementierung von der ncc group geprüft. >> Prüfbericht vom 01.11.2016 << (PDF-Datei)
Quelle: nccgroup (extern).
Die Einführung der Verschlüsselung im Echtbetrieb fand jedoch überhastet statt und viele Benutzer wussten nichts vom „Beta“-Stadium (das erst im Mai 2020 abgeschlossen wurde):
„negatives: the python server impl (synapse) was rushed & we are still paying off tech debt; it’s still a bit of a resource hog. E2EE is still not force-enabled until we have full parity with non-E2EE. The SS API is fairly subtle (there are few alt impls). The groups API sucks.“
Maschinell aus dem Englischen (Twitter-Eintrag vom 21.11.2019 (extern)) übersetzt:
„Die python-server-Implementierung (synapse) wurde überstürzt installiert & wir sind immer noch dabei, unsere technischen Schulden zu begleichen; er ist immer noch ein bisschen ressourcenfressend. E2EE ist immer noch nicht zwingend aktiviert, bis wir volle Parität mit Nicht-E2EE haben. Die Server-Server-API ist ziemlich subtil (es gibt nur wenige Alt-Impls). Die API der Gruppe ist sch….“
Zum Verschlüsselungsprotokoll von Matrix gibt es eine gute Ausführung/Beschreibung (extern; englisch) im Blog von jabberhead.tk.
Verschlüsselung deaktivieren?
In manchen Fällen kann es sinnvoll sein, die Verschlüsselung bei Bedarf zu deaktivieren. Beispielsweise wenn über Brücken mit Nutzern anderer Systeme kommuniziert werden soll oder wenn das firmeninterne Regelungen erforderlich machen.
Grenzen der Matrix-Verschlüsselung
Nachfolgende Punkte beschreiben die Grenzen von Megolm (extern):
Wiederholungen von Nachrichten
Eine Nachricht kann mehrere Male erfolgreich entschlüsselt werden. Das bedeutet, dass ein Angreifer eine Kopie einer alten Nachricht erneut senden kann, und der Empfänger wird sie als
als neue Nachricht behandeln.
Um dies abzuschwächen, wird empfohlen, dass Anwendungen die Ratchet-Indizes und Nachrichten mit einem Ratchet-Index, den sie bereits entschlüsselt haben, abzulehnen, die sie bereits entschlüsselt haben.
Fehlende Konsistenz des Protokolls
In einer Gruppenkonversation gibt es keine Garantie, dass alle Empfänger die gleichen Nachrichten erhalten haben. Befindet sich Alice beispielsweise in einer Unterhaltung mit Bob und Charlie beteiligt ist, könnte sie unterschiedliche Nachrichten an Bob und Charlie senden, oder sie könnte einige Nachrichten an Bob, aber nicht an Charlie, oder umgekehrt.
Dies zu lösen, ist im Allgemeinen ein schwieriges Problem, insbesondere in einem Protokoll, das nicht die ordnungsgemäße Zustellung von Nachrichten garantiert. Dies bleibt vorerst Gegenstand von zukünftigen Forschung.
Fehlende Rückwärtsverschwiegenheit
Rückwärtige Geheimhaltung (auch “future secrecy” oder “post-compromise security” genannt) ist die Eigenschaft, daß ein Angreifer bei einer Kompromittierung der aktuellen privaten Schlüssel keine zukünftige Nachrichten in einer bestimmten Sitzung nicht entschlüsseln kann. Mit anderen Worten, wenn man einer bereits erfolgten Kompromittierung rückwärts betrachtet, sind aktuelle Nachrichten immer noch geheim.
Megolm an sich hat diese Eigenschaft nicht: Sobald der Schlüssel einer Megolm Sitzung kompromittiert ist, kann der Angreifer jede Nachricht entschlüsseln, die mit einem Schlüssel verschlüsselt wurde, der aus den kompromittierten oder nachfolgenden Ratchet Werten abgeleitet wurde.
Um dies abzuschwächen, sollte die Anwendung sicherstellen, dass Megolm-Sitzungen nicht unendlich lange verwendet werden. Stattdessen sollte sie in regelmäßigen Abständen eine neue Sitzung starten,
mit neuen Schlüsseln, die über einen sicheren Kanal ausgetauscht werden.
Teilweises Vorwärtsgeheimnis
Vorwärtsgeheimnis (auch “perfektes Vorwärtsgeheimnis”, “perfect forward secrecy”/“PFS” genannt) ist die Eigenschaft, dass ein Angreifer, wenn die aktuellen privaten Schlüssel kompromittiert werden, kann ein Angreifer die vergangenen Nachrichten in einer bestimmten Sitzung entschlüsseln kann. Mit anderen Worten, wenn man in die Zukunft blickt und eine einer möglichen zukünftigen Kompromittierung, sind die aktuellen Nachrichten geheim.
In Megolm behält jeder Empfänger eine Aufzeichnung des Ratchet-Wertes bei, die es ihm ermöglicht alle Nachrichten zu entschlüsseln, die in der Sitzung nach dem entsprechenden Zeitpunkt in der Konversation. Wenn dieser Wert kompromittiert wird, kann ein Angreifer auf ähnliche Weise Nachrichten entschlüsseln, die mit einem Schlüssel verschlüsselt wurden, der von dem kompromittierten oder nachfolgenden Ratchet-Werten abgeleitet wurden. Dies ergibt eine “teilweise” Vorwärtsgeheimhaltung.
Um dieses Problem zu entschärfen, sollte die Anwendung dem Nutzer die Möglichkeit bieten historische Konversationen zu verwerfen, indem alle gespeicherten Ratchet-Werte vorwärts gespult werden oder die Sitzungen ganz zu verwerfen.
Abhängigkeit von einem sicheren Kanal für den Schlüsselaustausch
Das Design der Megolm-Ratsche beruht auf der Verfügbarkeit eines sicheren Peer-to-Peer-Kanals für den Austausch von Sitzungsschlüsseln. Alle Schwachstellen im zugrunde liegenden Kanal werden wahrscheinlich verstärkt, wenn sie auf den Aufbau von Megolm-Sitzungen angewendet werden. Ist der Peer-to-Peer-Kanal beispielsweise anfällig für einen unbekannten Key-Share, wird die gesamte Megolm-Sitzung in ähnlicher Weise anfällig. …
Datenschutz
Aktuell gibt es noch keine deutschen Allgemeinen Geschäftsbedingungen (AGB). In den “privacy notice” (extern) ist jedoch zu lesen:
“2.1.2 Right to Erasure - “We therefore share state events sent by your account with all non-essential data removed (‘redacted’), even after we have processed your request to be forgotten. This means that your username will continue to be publicly associated with rooms in which you have participated, even after we have processed your request to be forgotten.”
Übersetzt in etwa:
“Daher teilen wir die von Ihrem Konto gesendeten Statusereignisse mit allen nicht wesentlichen Daten, die entfernt wurden (“redigiert”), auch nachdem wir Ihre Anfrage, vergessen zu werden, bearbeitet haben. Das bedeutet, dass Ihr Benutzername weiterhin öffentlich mit Räumen in Verbindung gebracht wird, an denen Sie teilgenommen haben, auch wenn wir Ihre Anfrage, vergessen zu werden, bearbeitet haben.”
Das bedeutet, daß die Beziehung von Personen zu Raumen nicht gelöscht werden kann, was im Zusammenhang mit der DSGVO evtl. zu prüfen ist.
Wie oben bereits geschrieben, werden die Raumdaten konzeptbedingt auf allen Homeservern repliziert, deren Benutzer an einem bestimmten Raum beteiligt sind. Somit hat kein einzelner Homeserver die Kontrolle oder das Eigentum über einen bestimmten Raum. Dadurch verliert man bei offfener Föderation (Replikation mit anderen Matrix-Instanzen) die Datenhoheit!
Durch die Empfehlung zur Eingabe der Telefonnummer (Identitätsserver) werden diese in einem zentralen Verzeichnis vorgehalten.
Englische “Hinweise zum Datenschutz und zur Datenerfassung von Matrix.org”:
- Teil 1 (extern): Focusing on the software stack and the privacy impact of its default configuration.
- Teil 2 (extern): Focusing on GDPR compliance, example of a GDPR Information and Data request, and disclosure of a Personal Data Breach by Matrix.org
The Grid
Mit „The Grid“ (extern) gibt es von ein paar ehemaligen Matrix-Entwicklern eine Matrix-Abspaltung die mehr Freiheit und Datenschutz zum Ziel hat. Zwar stimmen einige der dort aufgeführten Punkte, allerdings wurden diese jedoch größtenteils behoben: https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 (extern).
„The Grid’s data collection papers contained some valid points, which were mostly fixed.“
Quelle: Aus weitergeleiteter Information per E-Mail
„The Grid“ strebt folgende Ziele an:
- Lösung des Problems, das ursprünglich durch das Matrix-Protokoll identifiziert wurde, fragmentierte Kommunikation, Einbeziehung einer sozialen Sichtweise
- Einfache Client-Implementierungen, und föderierte Serverkommunkation, die die Hauptlast trägt
- Dezentralisierte Datenspeicherung, verteilt auf die teilnehmenden Server
- Entwickelt zur Vermeidung von Zentralisierung und/oder Monopolbildung
“Matrix’s ideals are Openness, Decentralization and Encryption while The Grid’s ideals are Freedom, Privacy and Security.”
Quelle: https://gitlab.com/thegridprotocol/home/blob/master/docs/overview.md (extern)
Brücken
Für Matrix sind Brücken („Matrix-Bridges“) elementar und ein Teil des Geschäftsgrundlage (wobei das für alle Teammessenger - also auch Mattermost, Rocket.Chat und Zulip gilt).
Es gibt verschiedene Brücken, um mit anderen Systemen Nachrichten auszutauschen und man möchte so für Interoperabilität sorgen. Es wird also versucht - wie bei
unterschiedlichen Sprachen - zwischen diesen zu übersetzten. Ideal für die Nutzer wäre es, wenn diese von diesem Vorgang überhaupt nichts mitbekommen und alle Funktionen wie gewohnt nutzen könnten. Es ist jedoch sehr schwer bzw. aufwändig, zwei unterschiedliche Systeme mit allen jeweiligen Regeln („Protokollen“) komplett kompatibel zu machen. Deshalb kann eine Brücke i.d.R. nur eine begrenzte Schnittmenge an Funktionen bereitstellen wie z.B. den Austausch von einfachen Nachrichten. Der Onlinestatus als wesentliches Merkmal von Chat kann z.B. natürlich nicht übertragen werden.
Querverweis: Sind Brücken und deren Nutzung legal?
Leider ist es auch so, daß Brücken nicht an Standards gebunden sind und vom Betreiber nach Belieben eingerichtet und verändert werden können. Auch können zum Beispiel Nachrichteninhalte nicht nur 1:1 transportiert, sonden auch auf dem Transportweg geändert werden, um so nativen Matrix-Nutzern ein angenehmeres Nutzererlebnis zu bieten. (Querverweis: Kritikpunkt ‘Datenintegrität’ )
Arten von gebrückten Räumen
Portalräume
Bridges können sich selbst als kontrollierende Teile des Raum-Alias-Namensraums registrieren, so dass Matrix-Benutzer entfernten Räumen auf transparente Weise beitreten können, wenn sie /join #freenode_#wherever:matrix.org oder ähnlich eingeben. Der resultierende Matrix-Raum wird in der Regel automatisch mit dem einzelnen entfernten Zielraum verbunden. Die Zugangskontrolle für Matrix-Benutzer wird in der Regel von der Seite des entfernten Netzwerks aus verwaltet. Dies wird als Portalraum bezeichnet und ist nützlich, um in entfernte Räume zu springen, ohne dass irgendeine Konfiguration erforderlich ist - mit Matrix als “Türsteher” für das entfernte Netzwerk.
Vorherige Beschreibung:
Portalräume steuern Teile des Raum-Alias-Namensraumes. Zum Beispiel entspricht #freenode_#channelname:matrix.org dem #channelname auf Freenode. Auf diese Weise können Matrix-Benutzer auf transparente Weise IRC-Kanälenauf Freenode beitreten. Portalräume werden in der Regel von der Seite des entfernten Netzes verwaltet, in dem der Raum liegt.
‘Plumbed’-Räume
Alternativ kann ein bestehender Matrix-Raum in einen oder mehrere spezifische Remote-Räume eingebunden werden, indem eine Bridge konfiguriert wird (die von jedem ausgeführt werden kann). Zum Beispiel ist #matrix:matrix.org mit #matrix auf Freenode verbunden, matrixdotorg/#matrix auf Slack, usw. Die Zugangskontrolle für Matrix-Benutzer wird notwendigerweise von der Matrix-Seite des Raums verwaltet. Dies ist nützlich für die Verwendung von Matrix, um verschiedene Gemeinschaften miteinander zu verbinden.
Das Migrieren von Räumen zwischen einem Portal- und einem ‘Plumbed’-Raum ist derzeit ein bisschen chaotisch , da es noch keine Möglichkeit für Benutzer gibt, Portalräume zu entfernen, sobald sie erstellt wurden, so dass Sie mit einer Mischung aus Portal- und Plumbed-Benutzern enden können, die in einem Raum verbunden sind, was sowohl aus der Matrix- als auch aus der Nicht-Matrix-Sicht seltsam aussieht. https://github.com/matrix-org/matrix-appservice-irc/issues/387 (extern) verfolgt dies.
Arten von Brücken
Es gibt viele theoretisch verfügbare Brücken - allerdings werden von den beiden eng verbundenen Unternehmen matrix.org und element.io nur manche davon aktiv angeboten und das sind teilweise sogar unterschiedliche. Das Marketing dazu ist nicht leicht zu durchschauen, denn es scheint keine gemeinsame Positionierung sondern unterschiedliche Priorisierungen von angebotenen Brücken seitens matrix.org und element.io zu geben. Brücken zu populären aber geschlosseenen Plattformen wie WhatsApp werden angepriesen - die Schnittstelle zum Standardprotokoll für Chat (XMPP) dagegen ist aktuell immer noch im experimentellen Stadium und geht (vielleicht deshalb?) im Marketing unter.\
Es wäre interessant zu erfahren, wie viele Entwicklungstage/-stunden und wie viel der aufgebrachten Gelder in die verschiedenen Arten von Brücken investiert werden:
Bridgebot-basierte Brücken
Die einfachste Möglichkeit, Nachrichten mit einem entfernten Netzwerk auszutauschen, besteht darin, dass sich die Bridge mit einem oder mehreren vordefinierten Benutzern, den so genannten Bridge-Bots, in das Netzwerk einloggt - typischerweise MatrixBridge oder MatrixBridge[nnn] usw. genannt. Diese leiten den Verkehr im Namen der Benutzer auf der anderen Seite weiter, aber das ist eine schreckliche Erfahrung , da alle Metadaten über die Nachrichten und Absender verloren gehen . So funktioniert die telematrix matrix<->telegram-Brücke derzeit.
Vorherige Beschreibung:
In diesem Fall werden Nachrichten in beide Richtungen von einem Bot [Automatismus, der wie ein Roboter funktioniert und automatisierte Aufgaben übernimmt] übermittelt, der sich auf der jeweiligen Plattform
befindet. Dies ist eine suboptimale Erfahrung, da Metadaten verloren gehen. Beispielsweise könnten alle Nachrichten von demselben Bot gesendet werden, wobei dem Nachrichtentext jedoch der Name des ursprünglichen Absenders vorangestellt wird.
Die Probleme des Bot-basierten Bridging werden durch “Puppeting” [=Schattennutzer] gelöst. Das heißt, die Steuerung eines Benutzers auf der anderen Seite der Brücke. Das wiederum bedeutet, dass einheimische Benutzer die Nachrichten so sehen, als ob sie vom richtigen Absender gesendet würden. Doppeltes Puppeting bedeutet, dass dies in beide Richtungen der Brücke erfolgt. Dies ist die bevorzugte Art der Implementierung einer Matrix-Brücke.
Bot-API (auch bekannt als virtueller Benutzer) basierte Brücken
Einige entfernte Systeme unterstützen die Idee, Nachrichten von “falschen” oder “virtuellen” Nutzern einzuschleusen, die verwendet werden können, um die Nutzer auf der Matrix-Seite als einzigartige Entitäten im entfernten Netzwerk darzustellen. Mit den eingehenden Webhooks von Slack können beispielsweise bei Bedarf Remote-Bots erstellt werden, mit denen Matrix-Benutzer kosmetisch korrekt als virtuelle Benutzer in der Zeitachse anzeigen. Die daraus resultierenden virtuellen Benutzer sind jedoch keine echten Benutzer auf dem entfernten System, haben also keine Präsenz/kein Profil und können keine Tabs ausfüllen oder Direktnachrichten senden usw. Sie haben auch keine Möglichkeit, Typisierungsbenachrichtigungen oder andere umfassendere Informationen zu erhalten , die nicht über Bot-APIs verfügbar sind. Dies ist, wie die aktuelle Matrix-App-Service-Slack-Brücke funktioniert.
Einfache Marionettenbrücke
Dabei handelt es sich um eine umfassendere Form des Bridging, bei der sich die Bridge beim Remote-Dienst anmeldet, als wäre sie ein echter 3rd-Party-Client für diesen Dienst. Folglich muss der Matrix-Benutzer bereits über ein gültiges Konto auf dem entfernten System verfügen. Im Gegenzug “verkörpert” der Matrix-Benutzer seinen entfernten Benutzer, so dass andere Benutzer auf dem entfernten System nicht einmal wissen, dass sie mit einem Benutzer über Matrix sprechen. Die gesamte Semantik des entfernten Systems steht der Bridge zur Verfügung, um sie in Matrix freizugeben. Allerdings muss die Bridge den Authentifizierungsprozess für die Anmeldung des Benutzers bei der entfernten Bridge durchführen.
Dies ist im Wesentlichen die Art und Weise, wie die aktuelle matrix-appservice-irc-Brücke funktioniert (wenn Sie sie so konfigurieren, dass Sie sich mit Ihrem “echten” IRC-Nickname beim entfernten IRC-Netzwerk anmelden). matrix-appservice-gitter wird erweitert, um sowohl den Puppet- als auch den Bridgebot-basierten Betrieb zu unterstützen. So funktioniert die experimentelle matrix-appservice-tg-Brücke.
In Zukunft sollen alle Brücken zumindest einfach, wenn nicht sogar doppelt gepuppt sein.
Doppelte Marionettenbrücke
Eine einfache “Puppeted Bridge” ermöglicht es dem Matrix-Benutzer, sein Konto in seinem entfernten Netzwerk zu steuern. Idealerweise sollte dieses Puppeting jedoch in beide Richtungen funktionieren, d. h. wenn sich der Benutzer z. B. bei seinem nativen Telegram-Client anmeldet und Unterhaltungen beginnt, Nachrichten sendet usw., sollten diese in Matrix zurückgespiegelt werden, als ob der Benutzer dies dort getan hätte. Dazu muss die Brücke in der Lage sein, die Matrix-Seite der Brücke im Namen des Benutzers zu steuern.
Dies ist der heilige Gral der Überbrückung, da sowohl das Matrix-Konto als auch das Konto eines Dritten in ihren jeweiligen Netzwerken korrekt dargestellt werden, wobei alle Metadaten des Benutzers intakt sind. Dies steht im Gegensatz zu einem Relaybot, der als ein von dem Benutzer, den er vertritt, getrennter Benutzer erscheinen würde.
Es gibt mehrere Hindernisse für die ordnungsgemäße Implementierung von Double-Puppeted-Bridges. Auf der Matrix-Seite benötigen wir eine elegante Möglichkeit, die Bridge mit Matrix als Matrix-Benutzer zu authentifizieren (was eine Art von scoped access_token-Delegation erfordert). Im Netz von Drittanbietern gibt es besondere Probleme , die von den Einschränkungen des jeweiligen Netzes abhängen. Viele Netzwerke von Drittanbietern sind beispielsweise nicht in der Lage, andere Matrix-Benutzer zu repräsentieren als denjenigen, der als Puppe angemeldet ist (siehe Hybrid-Relaybot).
matrix-puppet-bridge ist ein Gemeinschaftsprojekt, das versucht, die Entwicklung von Double-Puppet-Bridges zu erleichtern, und das dies, ohne Bridgebot, für mehrere Netzwerke getan hat. Ein Nachteil ihres Ansatzes ist die Annahme, dass eine Person die Bridge auf ihrem eigenen Homeserver betreibt und so das Problem der gemeinsamen Nutzung von Anmeldeinformationen auf einem gemeinsamen Homeserver umgeht.
Hybride Relaybot-Puppenbrücke
Bei dieser Art von Brücke handelt es sich um eine kombinierte Einzel- oder Doppelpuppenbrücke, die versucht , das Problem der Vertretung anderer Benutzer mit Hilfe der Bridgebot-Technik zu lösen. mautrix/telegram arbeitet auf diese Weise.
Server-zu-Server-Überbrückung
Einige Protokolle (IRC, XMPP, SIP, SMTP, NNTP, GnuSocial usw.) unterstützen Föderation - entweder offen oder geschlossen. Die eleganteste Art der Überbrückung zu diesen Protokollen wäre es, die Brücke als Server an der Föderation teilnehmen zu lassen und den gesamten Namensraum direkt in Matrix zu überbrücken.
Uns ist niemand bekannt, der dies bisher getan hat.
[Anmerkung: Das ist nicht die Aufgabe der Anderen. Sollte das nicht der heilige Gral der Überbrückung sein, statt der Doppelpuppenbrücke? Bitte verwenen Sie hier etwas von dem investierten Geld, um einen xmpp-Server direkt in den Matrix-Server zu integrieren, um Interoperabilität zu erreichen!]
Einseitige Überbrückung
Eine einseitige Überbrückung ist selten, kann aber verwendet werden, um eine Brücke vom entfernten System zur Matrix darzustellen. Dies ist häufig der Fall, wenn das entfernte System das Versenden von Nachrichten nicht zulässt oder einfach nicht in der Lage ist, das Versenden außerhalb seines Systems zu verarbeiten. Die vom entfernten System überbrückten Benutzer erscheinen oft als virtuelle Benutzer in Matrix, wie im Fall von matrix-appservice-instagram.
Seitenwagenbrücke
Schließlich: Bei den oben beschriebenen Arten der Überbrückung wird davon ausgegangen, dass Sie den Gesprächsverlauf des entfernten Systems in Matrix synchronisieren, so dass er dezentralisiert und mehreren Benutzern innerhalb des größeren Matrix-Netzwerks zugänglich sein kann.
Dies kann zu Problemen führen, wenn das entfernte System über beliebig komplizierte Berechtigungen (ACLs) verfügt, die den Zugriff auf die Historie steuern, die dann korrekt mit dem ACL-Modell von Matrix synchronisiert werden müssen, ohne dass Sicherheitsprobleme wie z. B. Wettrennen auftreten. In der IRC-Bridge gibt es bereits einige Probleme damit, da die Sichtbarkeit des Verlaufs für +i und +k Kanäle sorgfältig mit den Matrix-Räumen synchronisiert werden muss.
Es kann auch zu Problemen mit anderen netzspezifischen Funktionen kommen, die noch keine gleichwertige Darstellung im Matrix-Protokoll haben (z. B. ephemere Nachrichten oder Nur-Op-Nachrichten - obwohl das wohl eine Art von ACL ist).
Eine Lösung könnte darin bestehen, eine völlig andere Architektur der Überbrückung zu unterstützen, bei der die Matrix-Client-Server-API direkt auf den entfernten Dienst abgebildet wird, was bedeutet, dass ACL-Entscheidungen an den entfernten Dienst delegiert werden und Unterhaltungen nicht in die breitere Matrix einfließen. Dies bedeutet, dass die Bridge effektiv als reiner 3rd-Party-Client für das Netzwerk verwendet wird (ähnlich wie Bitlbee). Die Bridge steht nur einem einzigen Benutzer zur Verfügung, und Unterhaltungen können nicht mit anderen Matrix-Benutzern geteilt werden, da es sich nicht um tatsächliche Matrix-Räume handelt (eine andere Lösung könnte die Verwendung von Active Policy Servern sein, um ACLs für einen Raum zu zentralisieren und zu delegieren).
Dies ist im Wesentlichen ein völlig anderes Produkt als der Rest von Matrix, und obwohl es eine Lösung für einige besonders schmerzhafte ACL- Probleme sein könnte, konzentrieren wir uns vorerst auf Nicht-Seitenwagen-Brücken.
Quelle: https://matrix.org/docs/guides/types-of-bridging (extern; 01.08.2022)
Es fällt auf, dass oft über Probleme und in der Möglichkeitsform gesprochen wird. Das ist auch der Grund, warum Brücken oft als alte Krücken bezeichnet werden.
Querverweise: Kritikpunkt: ‘Brücken’ und Interoperabilität: ‘Brücken’
Eine weitere Beschreibung im Netz zu Brücken: blog.novatrend.ch (extern)
XMPP-Brücke
Der Begriff [„Bifröst“](https://de.wikipedia.org/wiki/Bifr%C3%B6st_(Mythologie) (extern) stammt aus der nordischen Mythologie und bedeutet “brennende Regenbogenbrücke”.
Mit „Bifröst/libpurple“ gibt es eine Brücke, die auf der FOSDEM 2020 (extern) vorgestellt wurde:
„… and demonstrate high quality bridging with XMPP, Slack, Discord, WhatsApp, and more!“
Was wird konkret unter „high quality“ verstanden? Zumindest passt der für diese Brücke gegebene Hinweis nicht ganz zu „high quality“: „Marionettenbrücke für allgemeine Zwecke mit libpurpule und anderen Systemen. Diese Brücke befindet sich zur Zeit in sehr aktiver Entwicklung und ist hauptsächlich für Experimentier- und Evaluierungszwecke gedacht.“
„General purpose puppeting bridges using libpurple and other backends. This bridge is in very active development currently and intended mainly for experimentation and evaluation purpose.“ (Originaltext Stand 04/2022)
Hinweis: |
In öffentlichen Chaträumen bietet Matrix keine „Halb-Anonymität“. Das bedeutet, daß nicht nur Administratoren, sondern alle Teilnehmer nicht nur den Alias, sondern die tatsächlich verwendete (XMPP)-Chatadresse sehen. |
Technische Details zu Bifröst finden sich bei https://github.com/matrix-org/matrix-bifrost/wiki/Address-syntax (extern) und https://aria-net.org/SitePages/Portal/Bridges.aspx (extern). Zudem bietet matrix.org eine öffentliche Instanz der Brücke an:
„matrix.org hosts a public instance of Bifröst for XMPP bridging. You can join any chat from either side of the bridge using the address syntax below. …“_ (Stand 02.05.2020)
Es funktioniert:
Unverschlüsselte Nachrichten zwischen Matrix- und XMPP-Räumen
Hinzufügen einzelner XMPP-Nutzer zu 1:1 Unterhaltungen (also unabhängig von Gruppen/öffentlichen Chaträumen):
- über die Internetseite(!?): -> invite -> @xmpp=40:matrix.org
- über den Client „Element“ -> +chat -> invite ID -> @_xmpp_xmppusername=40xmppserver.TLD:matrix.org
Einladungen in einen bereits bestehenden Chatraum
- Die native Verbindung zum Verbinden von XMPP-Chaträumen für Matrix-Nutzer:
#_xmpp_CONFERENCE.SERVER.TLD_MUCNAME:matrix.org
(anstatt des teils “CONFERENCE” natürlich je nach server individuell auch: room/rooms/muc/chat/…
- Der Befehl lautet: /join #xmpp_:matrix.org
- Beispiel, wie man in den öffentlichen Chat von “Freie Messenger” kommt: /join #_xmpp_conference.jabber.de_conversations:matrix.org
Andersherum kann ein XMPP-Nutzer einen Matrix-Nutzer über den zentralen Dienst matrixuser_matrixserver.tld@matrix.org erreichen.
Tippbeanachrichtigungen werden auf der Matrix-Seite angezeigt (“XY tippt geade”).
Github: https://github.com/matrix-org/matrix-bifrost (extern), https://github.com/matrix-org/matrix-bifrost/graphs/code-frequency (extern)
Einschränkungen:
Die Kommunikation in dem Raum darf nicht Ende-zu-Ende-verschlüsselt sein.
Vereinzelt können Jabber(XMPP)-Chaträume nicht betreten werden, wenn über die Matrix-Brücke anstatt „beitzutreten“ versehentlich „erstellen gewählt wird. Dann erscheint die (falsche) Fehlermeldung „does not exist“.
Bei über die Brücke versandten Bildern fehlt die Dateierweiterung, so dass hier ohne manuelles Hinzufügen von z.B. „.JPG„“ oder „.PNG“ nur das Vorschaubild angezeigt wird.
Weiterentwicklung von Bifröst / Aria Networks
Eine große Motivation scheint matrix.org an der Entwicklung der Bifröst-Brücke nicht zu haben. Dafür hat Aria Networks (Aria-net (extern) an der Bifröst-Brücke einge Verbesserungen gemacht und diese fehlerbereinigt/weiterentwickelt. Leider werden diese Punkte von Ursprungsprojekt nicht übernommen. In der Zwischenzeit wird in Matrix-Kreisen deshalb oft die aria-net-Brücke) (extern) anstatt der Bifröst-Brücke von matrix.org empfohlen.
Gedanken zur XMPP-Bridge
Grundsätzlich sind für Verbindungen von Matrix zu XMPP drei Möglichkeiten für Entwicklungen einer Verbindung (bridge/transport) denkbar:
Eine echte, direkte Brücke (wo ein Matrix-Nutzer im XMPP-Raum einen eigenen Namen („alias/nickname“) bekommt und umgekehrt) - so wie das mit „bifröst“ aktuell möglich ist.
Ein Automatismus in Form eines einzeln angelegten Benutzers, der alle Nachrichten einfach weiterleitet - als Roboter (=robot = bot) - ist/war fehleranfällig.
Kommunikation über eine dritte Stelle
z.B. über IRC. Vorteil ist, daß man den “matrix api service” nutzen kann.
Ablauf: Der Matrix-Server geht über einen matrix-irc-appservice, der sich mit einem IRC-Kanal verbindet. Das Selbe müsste dann von xmpp aus (z.B. per „biboumi“ in den selben IRC-Kanal.
Dies hätte jedoch einen entscheidenden Nachteil: Kommunikation über eine Drittes System und somit mehr Komplexität und Fehleranfälligkeit.
Ein anderes Brücken-Projekt https://matrix.org/docs/projects/as/matrix-xmpp-bridge (extern) wurde 2019 eingestellt.
WhatsApp
Matrix hat eine Brücke zum Chatstandard XMPP mit dem Namen Bifröst/Libpurple und vermarket diese auch. Mit dem Projekt Mautrix (extern) gibt es weitere Möglichkeit. Die aktuell verfügbaren Funktionen (extern) sind beeindruckend.
Alle Anbieter/Nutzer, die die Web-Schnittstelle von WhatsApp für ihre Zwecke vewenden müssen jedoch damit rechnen, daß diese (mißbräuchliche) Vewendung von Meta/Facebook durch Änderungen schnell unterbunden werden kann.
Querverweis: Rechtmäßigkeit von Brücken
Weitere
- Mit Matterbridge (extern) sind ebenfalls sehr viele Brücken zwischen unterschiedlichsten Systemen möglich.
- Dieses Projekt (extern) beschäftigt sich damit, per Shell-Scripten auf Matrix zuzugreifen.
Nutzung
Anleitungen
Matrix-ID
Aufbau der Benutzerkennung im Echtbetrieb: @benutzername:servername.tld
Für Verbindungen, die über IRC in anderen Systeme gehen: #channel%ircserver@xmpp_component
Umwandelung
Chatadressen (Chatstandard XMPP), SMS (Telefonnummern), E-Mail-Adressen sowie SIP-Adressen kann man sich hier im Matrixformat anzeigen lasen: https://cheogram.com/matrix (extern)
Berechtigungen
Für Teilnehmer von Gruppenchats gibt es verschiedene Berechtigungsstufen. Diese Einstellung/Änderung kann ein Raum-Administrator derzeit nur vom PC aus machen:
- 0 - Standard
- 50 - Moderator
- 100 - Administrator
Die Heraufstufung von Benutzern zu Moderatoren oder zu Administratoren kann dann jedoch auch Mobil z.B. über ein Smartphone/Tablet gemacht werden.
Server
Bei der Server-Installation werden zunächst selbst signierte TLS-Zertifikate erstellt, die dann jedoch problemlos durch Let’s Encrypt-Zertifikate ersetzt werden können. Dies muss manuell vorgenommen werden. Für die Kommunikation zwischen verschiedenen Servern (Föderation) wird standardmäßig der Port 8448 genutzt.
Neben der Standard-Matrix-Serversoftware „Synapse“ (extern) gibt es auch noch andere Lösungen wie z.B. „Conduit“, mit dem eine eigene Matrix-Insel (ohne Föderation und natürlich ohne Interoperabilität) betrieben werden kann. Die Serversoftware kann sogar auf einem Mini-Computer wie dem Raspberry Pi installiert werden.
Als Nachfolger von Synapse wird seit 2020 an „Dendrite“ gearbeitet. Diese Serversoftware ist nicht in Phyton sondern in der Programmiersprache „Go“ geschrieben. Mit Dendrite sollen die Effizienz, die Zuverlässigkeit und die Skalierbarkeit verbessert werden (vgl. https://gnulinux.ch/matrix-von-synapse-zu-dendrite (extern)) - allerdings ist Dendrite noch im Beta-Stadium.
Eine schöne Anleitung gibt es hier: https://ersei.net/en/blog/setting-up-matrix-dendrite (extern; englisch)
Synapse: https://github.com/matrix-org/synapse (extern; englisch)
Dendrite: https://github.com/matrix-org/dendrite (extern; englisch)
Conduit: https://conduit.rs (extern; englisch)
Verbindungen
Einen Überblick über die Serverlandschaft bei Matrix bietet die Seite https://voyager.t2bot.io/#/graph (extern).
Voyager is a bot that travels through Matrix trying to find new rooms. It does this by sitting in rooms and waiting for someone to mention another room, at which point it tries to join that room. Each new room it discovers is mapped to a public graph.
Matrix-Server-Verbindungen
Im zentralen Bereich sind die Server mit vielen Verbindungen - weiter außen die mit weniger Verbindungen und am Randbereich der Scheibe die Server ohne Verbindungen.
| |
Matrix-Server-Verbindungen (zentraler Ausschnitt)
Die meisten Verbindungen laufen bei den zwei großen Instanzen „Matrix.org“ und „Element.im“(=„Riot.im“) zusammen.
| |
Serverlisten
Eigener Server
Tipp: Ressourcenverbrauch reduzieren: Matrix-Synapse nativ auf Ubuntu verbraucht viel RAM und CPU (extern)
Weitere:
- Tipp 1: Bei einem eigenen Synapse-Server ist auch Hausautomation möglich.
- Tipp 2: Wenn keine öffentlichen Räume besucht werden sollen:
In diesem Fall Synapse bezüglich der Föderation beschränken bzw. nur lokal unter 127.0.0.1:8448 lauschen lassen und eine Föderation zusätzlich per Whitelist beschränken. D.h. die Konfigurationsdatei (homeserver.yaml) entsprechend anpassen und bei federation_domain_whitelist:
einfach - <EigenerServerName>
eintragen.
- Tipp 3: Datenbank komprimieren:
- Stuff that no longer needs to be kept around
- Optimizing synapse cache
- Table bloat & Index bloat in PostgreSQL
Quelle: https://levans.fr/shrink-synapse-database.html (extern, englisch)
Weitere Serverinfos
Clients
Ein Pluspunkt von Matrix ist, dass es für so gut wie alle Betriebssysteme funktionierende Klienten (Programme/Apps) (extern, englisch). Aber Vorsicht: Viele der auf der Seite aufgeführten Apps sind noch im Alpha- oder Betastadium befinden oder die nicht mehr weiterentwicklet werden (den Status der einzelnen Projekte sieht man nicht mehr sofort auf der Übersichtsseite - jetzt bitte eine Ebene tiefer in den Details schauen).
Element (PlayStore: USK 18) ist der quasi Referenzclient mit der größen Verbreitung. Es ist nur 1 Chatkonto möglich; die Desktopanwendung basiert auf Electron.
FluffyChat (extern) (PlayStore: USK 18)
Dieser knuffige Client läuft u.a. auch auf dem Betriebssystem „UbuntuTouch“. Einzige Anwendung ohne Electron für den Desktop, da die anderen sich noch im Entwicklungsstadium (Alpha/Beta) befinden oder nicht mehr weiterentwickelt werden. *
SchildiChat (extern) (PlayStore: USK 0)
Syphon (extern) (PlayStore: USK 0)
Dieser Client hat einen sehr interessanten Ansatz, denn hier soll neben der serverbasierten auch eine direkte, serverlose Kommunikation ermöglicht werden („P2P“). Allerdings ist Syphon noch in einem frühen Alphastadium und deshalb noch nicht für den tatsächlichen Produktiveinsatz geeignet. Basis hierfür ist p2p-matrix (extern) / pinecone-overlay-network (extern).
Zom (extern) (PlayStore: USK 0)
Mit ZOM für Android und iOS (früher ein XMPP-Client; jetzt Matrix) können mehrere Chatkonten genutzt werden. Es ist möglich, sich hier mit all den Konten anzumelden, die unter Element angelegt wurden. Im Gegensatz zu Element ist bei ZOM keine Telefonie und keine Videotelefonie möglich. Ein weiterer Vorteil ist, daß die Verschlüsselung schon eingeschaltet ist und relativ einfach zu bedienen ist.
Quellcode: https://github.com/zom (extern)
*) Andere Electron-freie Desktop-Clients als FluffyChat sind nicht zu empfehlen:
- Fraktal (extern): Maturity: Beta
- NeoChat (extern): Maturity: Beta
- Nheko (extern): Maturity: Beta
- Seaglass (extern): Maturity: Not actively maintained / At this stage it is early in development and stands a good chance of being buggy and unreliable.
- Spectral (extern): Maturity: Alpha
Chaträume
Da alles als „Raum“ betrachtet/behandelt wird, können problemlos (versehentlich) mehrere Räume mit demselben Kontakt geöffnet werden.
Die Matrix-Raummitgliedschaft ist zustandsabhängig (wer angemeldet ist, ist ‘da’) und nicht flüchtig (wer online ist, ist ‘da’). Das ist nicht besser oder schlecher, sondern schlicht anders als beim Chatstandard XMPP (vgl. Unterschiede).
Für Chaträume (alles sind ‘Räume’) gibt es verschiedene Versionen (extern). Da sich die Raumspezifikationen fortentwickeln, entstehen teilweise Inkompatibilitäten: “Why do I get a M_INCOMPATIBLE_ROOM_VERSION error when trying to join some rooms?” (extern)
Finanzierung
Im Gegensatz zu anderen Messengern wie Telegram sind die Strukturen (Informationen zur Firma, den beteiligten Personen sowie zur Finanzierung) öffentlich:
- Finanzierung:
Von 2014 bis 2017 wurde Matrix von Amdocs (extern) (Morris Kahn, Israel) finanziert, auch später gab es noch Kontakte. Mehr zu Amdocs >> hier <<.
Bei Golem (extern) ist dazu zu finden:
… Die beiden Gründer des Projekts, Matthew Hodgson und Amondine Le Pape, sowie ein kleines Kernentwicklerteam werden aber vom US-Softwaredienstleister Amdocs bezahlt, der auch die Rechte an Riot hält. Amdocs habe bei der Entwicklung natürlich ein kommerzielles Interesse, bestätigt Hodgson. Ziel sei vor allem, Hosting- und Supportdienste für Geschäftskunden zu entwickeln und so die Matrix-Plattform zu vermarkten. … Ein weiteres Geschäftsfeld für Amdoc könnten kostenpflichtige Bridges für Geschäftsanwendungen sein.
Darauf gründeten die Matrix-Entwickler ihre eigene Firma New Vector Limited für die Finanzierung.
Die Investmentgruppe “Notion Capital” hat sich auf europäische Firmen spezialisiert, die Software-Anwendungen über das Internet, d.h. als Service, anbieten oder als Lizenzmodell haben („Notion Capital is a VC firm focused on European SaaS and Cloud“). Der Investor hat sich erstmals 2017 bei Element.io engagiert und ins Portfolio mit aufgenommen: https://www.notion.vc/portfolio/element (extern). Über Notion werden auch immer wieder Arbeitsplätze bei Element.io angeboten.
Finanzierungsprobleme
Die Finanzierung scheint Ende 2022 ins Wanken zu geraten, denn Matrix-Nutzer werden in einem Blog-Artikel von matrix.org (extern) trotz offener Lizensierung deutlich dazu aufgefordert, sich an der Finanzierung (von was genau?) zu beteiligen. Gedanken dazu sind >> hier << formuliert.
Beteiligungen Matrix
- Jan 29, 2018: Matrix raised $5,000,000 from Status.im
Gesamt (extern):
Matrix has raised a total of $5M in funding over 1 round. This was a Venture - Series Unknown round raised on Jan 29, 2018. Matrix is funded by Status.im.
Beteiligungen New Vector
- Jan 29, 2018: Element raised $5,000,000 / Seed from Status.im
- Oct 10, 2019: Element raised $8,500,000 / Serie A von Dawn Capital und 2 weiteren Investornen (Firstminute Capital, Notion Capital) (extern)
- May 21, 2020: Element raised $4,600,000 / Serie A von Automattic (Firma hinter Wordpress) (extern)
EU-Startups — London-based New Vector nabs €4.1 million for ‘Matrix’, its decentralised comms ecosystem
- Sep 30, 2020: Element acquired Gitter for an undisclosed amount
- Dec 20, 2020: Element raised an undisclosed amount / Series Unknown from Public
- Jul 26, 2021: Element raised $30,000,000 / Serie B von Automattic (Firma hinter Wordpress) und 3 weiteren Investoren (Protocol Labs, Notion Capital, Metaplanet Holdings) (extern)
Gesamt (extern):
- Element has raised a total of $48.1M in funding over 5 rounds. Their latest funding was raised on Jul 26, 2021 from a Series B round.
- Element is funded by 8 investors. Metaplanet Holdings and Notion Capital are the most recent investors.
- Element has acquired Gitter on Sep 30, 2020.
Blockchain und Kryptowährung
2018 investierte der Blockchain-Messenger Status.im, der sehr eng mit der Kryptowährung „Etherum“ verbunden ist, 5 Millionen Dollar in Matrix.org (und weitere 5 Mio $ in New Vector):
Status invests $5 million in Matrix to create a blockchain messaging superpower
Enter Status, the mobile Ethereum client built entirely on peer-to-peer technologies. Today, Status has announced a significant investment in New Vector, the company behind Matrix.org, the open standard for secure and decentralized communication.
How significant? Status is making a $5 million investment in New Vector, effectively creating a partnership between two of the industry’s largest decentralized messaging platforms.
Quelle: https://venturebeat.com/2018/01/29/status-invests-5-million-in-matrix-to-create-a-blockchain-messaging-superpower (extern)
Im Direktorium der Stiftung ist (Stand 04/2022) auch die Firma Parity Technologies (extern) vertreten, die im Bereich Blockchaintechnologien tätig ist.
Strukturen
Organisation und Firmen
Amdocs: Der Beginn von Matrix noch unter der Bezeichnung „Amdocs Unified Communications“ (extern)
The Matrix.org Foundation C.I.C. entwickelt und betreut das Matrix-Protokoll (aber nicht nur!) The Matrix.org Foundation is a public provider everybody can register an account on for free
NEW VECTOR LIMITED ist der weltweit größte Matrix-Hoster, ist der Eigentümer der eingetragene Marke “Element” und betreibt beispielsweise auch die Identitässerver Matrix.org und Vector.im bzw. ist der “Data Controller” für diese Dienste Quelle (extern). Die Seite https://element.io (extern) ist von New Vector.
Registerauszug bei service.gov.uk (extern)
New Vector SARL Gesellschaft nach französischem Recht (zu den Aufgaben noch keine konkreten Informationen im Netz dazu gefunden)
ELEMENT SOFTWARE INC., USA
Bei opencorporates.com (extern) bzw. nhcompanyregistry.com (extern) bzw. bizpedia.com (extern) werden insgesamt 11 [ELEMENT SOFTWAR INC. …] gefunden, von denen 3 als alt/inaktiv vermerkt sind. (Informationen zur Tätigkeit fehlen noch) …
PARITY TECHNOLOGIES LIMITED und Parity Technologies Deutschland GmbH, Berlin / Blockchain-Technologie (extern))
Beauftragte Unternehmen:
- Wirtschaftskanzlei „King & Wood Mallesons“ (extern) in London: Postadresse für New Vector Limited
- CT Corporation System / Wolters Cluwer (extern) (Der nach eignenen Angaben weltweit führende Anbieter von Lösungen für Legal Entity Management, Corporate Compliance und Due Diligence / führendene Gesellschaft für Lösungen zur Verwaltung von Rechtspersönlichkeiten): Eingetragener Vertreter für diverse ELEMENT SOFTWARE INC.
Personen
Gemeinsamkeiten
Sowohl M. Hodgson als auch A. La Pape sind als Direktoren sowohl bei Matrix.org als auch bei der Firma New Vector Limited (sowie den Tochterfirmen angestellt - eine gemeinsame Anzeige im Register jedoch bei beiden durch unterschiedliche Vornamen verhindert wird:
- NEW VECTOR LIMITED: “Matthew Hodgson“
- THE MATRIX.ORG FOUNDATION C.I.C.: “Matthew James Hodgson“
- NEW VECTOR LIMITED: “Amandine LE PAPE“
- The MARTIX.ORG FOUNDATION C.I.C.: “Amandine Beatrice Marie LE PAPE“
Schlimm? Nein - aber sehr interessant, da Direktoren bezahlt werden und eine gewisse Transparenz auch bezüglich der Verbindungen gegeben sein sollte.
Die enge Verbindung zeigen auch die Büros der sog. „juristischen Personen“, die direkt nebeneinander im selben Gebäude (14 Turnham Green Terrace Mews) liegen:
Die Postanschrift der New Vector Limited (“10 Queen Street Place, London, United Kingdom, EC4R 1AG”) ist die Adresse der internationalen Wirtschaftskanzlei „King & Wood Mallesons“ in London (Hauptsitz Hongkong), was bei internationalen Konzernen nicht unüblich scheint.
OpenStreetMap: Auf Karte anzeigen (extern)
Sonstiges
Fazit
Trotz allem:
Matrix ist eine sehr gute Lösung für verteilte Arbeit in Organisationen, Unternehmen oder Behörden! Im Gegensatz zu manch anderem Teammessenger wie z.B. Slack ist der komplette Quellcode offen und somit überprüfbar - auch ist eine systeminterne Föderation möglich, was Matrix zudem von Mattermost, Rocket.Chat und Zulip abhebt.
Allerdings gibt es eine enge organisatorische, personelle, finanzielle und begriffliche Verbindung/Abhängigkeit zwischen den Firmen den beteiligten Personen und den Aufgaben (Protokollzuständigkeit, Marketing, Softwareentwicklung, Dienstebereitstellung). Das Matrix-Protokoll ist zwar offen - aber nicht wirklich unabhängig.
Ideal wäre eine noch bessere Unterstützung des internationalen Standards (XMPP). So könnten Unternehmen/Behörden intern die Vorteile von ausfallsicheren Chaträumen und Teamchatfunktionen genießen - und trotzdem wäre ein standardisierter Austausch von Nachrichten von/nach außen möglich. |
Zum Systemvergleich von Matrix und dem Chatstandard (XMPP): >> hier <<

Riot is now Element!
Der client „Riot“ (übersetzt: Unruhe, Aufruhr, Tumult, Krawall, Aufstand) wurde von „RiotX“ abgelöst. Im Juli 2020 wurde „RiotX“ wiederum durch „Element“ ersetzt.
Quelle: https://element.io/blog/welcome-to-element/ (extern)
Als Anwenderprogramm setzt im Moment „Element“ die Maßstäbe. Element ist eine Marke von „New Vector“ („Element is trading name of New Vector.“ (extern)) und seit 15.07.2020 der Nachfolger von „RiotX“ bzw. ursprünglich „Riot“.
Element-Desktop läuft in einer „Webumgebung“ (Electron) und ist kein klassisches, eigenständiges Programm. Das hat den Vorteil, dass eine App als Browser quasi überall funktioniert abe auch den Nachteil, dass die Anwendung sehr groß wird und mehr Angriffspunkte bietet. Hauptargument für Element ist jedoch die Plattformunabhängigkeit, denn sowohl die App für Android, iOS - aber auch der Windows Desktop sehen für den Nutzer alle gleich aus.
Projektseite: https://element.io (extern)
Aktuell gibt es keine deutschsprachigen AGB!
Es gibt auch noch andere Messenger für Matrix, die sich oft jedoch noch in einem sehr frühen Entwicklungsstatus (alpha/beta) befinden:
https://matrix.org/docs/projects/try-matrix-now.html (extern; englisch)
Kurzanleitung
https://kmj.at/element-matrix-messenger-kurzanleitung-fuer-benutzer-03-2021/ (extern)
Neue Kontakte
Andere Matrix-Nuzter fügt man über
- »+«
- »Gespräch beginnen«
- »Mit ID einladen«
- »@user:example.com«
hinzu. Danach sollte die Matrix-ID auch im Adressbuch (Kontakte) gespeichert werden, damit die Matrix-Kontaktliste nicht nur von der Existenz des jeweiligen eigenen Chatkontos abhängig ist und bei einem Wechsel des Matrix-Providers die Kontaktliste schnell wieder hergestellt werden kann.
Identitätsserver
Identitätsserver sind für den föderalen Betrieb nicht nötig. Das heißt, dass man andere Benutzer außerhalb des eigenen Server erreichen kann, auch wenn man die Identitätsserver ausschließt. Dies kann in den Einstellungen hinterlegt werden.
Bei der Nutzung von Identitätsservern können sich Nutzer nicht nur über die Matrix-ID hinzufügen, sondern auch über Mailadressen oder Telefonnummern. Das erhöht den Komfort bei der Kontaktaufnahme. Auf der anderen Seite bedeutet das, dass zusätzliche Daten weitergegeben werden und dass man bei einer ggf. späteren Änderung (z.B. einem Wechsel der Mobilfunknummer) mehr Aufwand hat.
Generell ist zu empfehlen, die Adresse des Systems zu verwenden, für das sie ursprünglich auch vorgesehen wurde:
- Briefpost: Postadresse/Postfach
- Telefonie/SMS: Telefonnummer
- E-Mail: E-Mail-Adresse
- Chat: Chatadresse
Anonymisierte Analysedaten
Die Sammlung »anonymisierter Analysedaten« und das Übermitteln von Fehlermeldungen ist seit verpflichtender Umsetzung der europäischen Verordnung „General Data Protection Regulation“ (GDPR) - respektive in Deutschland die „Datenschutz Grundverordnung (DSGVO)“_ - vollständig deaktiviert.
Über die jeweiligen Clients lässt dich das Tracking aktivieren/deaktivieren. Unter der Android-App ist die Funktion unter Einstellung -> Anonymisierte Analysedaten zu finden. Sowohl das Sammeln dieser Daten als auch das Senden von Fehlerberichten können dort aktiviert werden (opt-in).
Es handelt sich dabei um Google Firebase Analytics, das zur Fehlerübermittlung verwendet wird und Matomo (Piwik), das Analysedaten sammelt.
Quelle: https://reports.exodus-privacy.eu.org/reports/14343/
Nachrichteneingang / Push-Nachrichten
Element in der Play Store-Version bekommt bei jeder eingehenden Nachricht eine Push-Nachricht über „Google Cloud Messaging“. Das veranlaßt Element, die eigentliche Nachricht vom Server abzuholen.
Datenschutz
NewVector weist bei element.io ganz offen darauf hin, daß sie Metadaten zur Profilierung der Nutzer speichern und auswerten:
“… we might profile metadata…”](https://element.io/privacy) (extern; englische ‘Datenschutzerklärung’)
Riot als auch miniVector bauen bereits vor der Anmeldung und vor der Änderung des Identitätsservers eine Verbindung auf -> warum? wohin? welche Daten? -> keine Ahnung.
Externe Artikel
Eine Kurzanleitung ist hier zu finden:
https://kmj.at/2018-03-12-riot-im-messenger-kurzanleitung-fuer-benutze-updated (extern)
Englischsprachige Einführung: https://www.snoyman.com/blog/2018/05/guide-to-matrix-riot (extern)
Meinung/Kritik zu „Matrix“
Vorwort
Diese Gedanken beschäftigen sich nicht mit der in der Tat großartigen Funktionsvielfalt von Matrix-Clients oder anderen Vorteilen - sondern sollen vielmehr dazu anregen, sich mit mit verschiedenen Themen auseinanderzusetzen und vorgebrachte Argumente bewusster wahrzunehmen und auch mal zu hinterfragen. Sie spiegeln meinen persönlichen Eindruck zum „Matrix-Hype“ und meine private Meinung dazu. Allerdings habe ich keine in Stein gemeißelte Meinung sondern sehe das als Entwicklungsprozess.
Deshalb auch hier nochmals die ausdrückliche Bitte um kurze Information, wenn jemand veraltete Informationen oder Fehler findet! . |
Die Matrix-Spezifikation wird oft als die Lösung im Mittelpunkt des Chat-Universums gesehen und als solche verkauft, mit deren Hilfe Interoperabilität erreicht werden könnte. Das sehe ich nicht so.
Das Matrix-Ökosystem ist kein Heilsbringer für Interoperabilität sondern Teil des Interoperabilitäts-Problems selbst. Aber Matrix-Installationen können die dringend notwendige Interoperabilität unterstützen, wenn die vorhandene Schnittstelle zum internationalen Standard im Bereich Chat auch tatsächlich in der Praxis freigeschaltet wird und genutzt werden kann.
Die Erfahrung aus vielen Gesprächen zeigt, daß oft etwas aufgeschnappt wird und so (oder so ähnlich) einfach in einem anderen Kontext weitergegeben wird - ohne davor die Äußerungen zu hinterfragen. Dadurch entsteht dann ein falsch positiver Eindruck oder es gibt Mißverständnisse.
Vor allem sind die nachfolgenden Punkte der Grund für meine Antwort auf die oft an mich gestellte Frage, wie ich zu Matrix stehe - denn: Ich bin zwiegespalten!
Kritikpunkte
Die Presse- und Lobbyarbeit im Matrix-Umfeld ist beneidenswert gut und clever - und vielleicht war es exakt das, was mich dazu gebracht, genauer hinschauen:
- Neutralität
- Finanzierung/Lizensierung
- Übersetzung
- Datenschutz/Privatsphäre
- Blinde Empfehlungen
- Internetstandard
- Monolithische Protokoll
- Föderation
- Freie Anbieterwahl
- Ressourcenbedarf
- Verschlüsselung
- Nutzerzahlen
- Electron
- Externe Dienste
- VS-NfD
- Brücken
- Markdown
- Gründe für Matrix
… sind die Punkte, da mir aufgefallen sind. Ob und wie man diese für sich als relevant bewertet, bleibt jedem selbst überlassen. Danach dann:
Neutralität
Matrix.org (die Foundation) ist sehr eng mit der Firma (den Firmen) New Vector verbunden. >> mehr << Seitens der Matrix.org Foundation wird hier auch offen darauf hingewiesen: https://matrix.org/foundation (extern)
Die Matrix.org Foundation wurde genau mit dem Zweck der Unabhängigkeit - auch von New Vector Ltd. - gegründet, um eine unabhängige Instanz die Spezifikationen des Matrix-Protokolls zu haben. Diese Unabhängigkeit is so groß/wichtig, dass New Vector Inc. sogar in den offiziellen Regeln der Foundation explizit genannt wird:
to ensure there is continuity, but also neutrality, between the Foundation and New Vector Ltd.
Heißt das dann im Umkehrschluß, daß die Firma New Vector derart einflussreich ist, daß sie es namentlich in die „Rules“ schafft, um keinen besonderen Einfluss haben zu sollen?
In den offiziellen Matrix-Foundation-Regeln ist festgelegt, daß die vorhandenen Personen (also zu Beginn die beiden Gründer) über Neubesetzungen entscheiden - und dabei auf Neutralität achten sollten, was jedoch nicht nähers konkretisiert ist. Im Vergleich dazu sind die Regeln der IETF(XSF) bezüglich der Neutralität sehr deutlich: Es ist klar definiert, daß …
- die Akteure ihre Arbeitgeber/Interessen benennen müssen,
- der Anteil eines Arbeitgebers nicht größer als x sein darf und
- das Council/Board ansonsten von den Mitgliedern frei gewählt wird.
Die Art und Weise der Neutralität kann und sollte prinzipiell auch ein Kriterium für sowohl kommerzielle als auch staatliche Entscheider sein. Auch wenn diese Dinge aktuell völlig im Matrix-Hype untergehen und keine Beachtung finden.
Was viele nicht wissen: Die Matrix.org Foundation ist nicht ausschließlich für das Protokoll zuständig, sondern darüber hinaus insbesondere auch für Softwareprojekte, Infrastruktur und ihr gehören Copyright-Rechte (https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite) (extern):
Ihre Hauptaufgabe ist die Pflege der Matrix-Spezifikation, aber sie tut noch viel mehr als das.
Finanzierung/Lizensierung
Ist Matrix gefährdet?
Eng mit der Neutralität verbunden ist die Ende 2022 in einem Blog-Artikel bei Matrix.org (extern) veröffentlichte Aufforderung, sich an der teuren Entwicklung (von was konkret?) zu beteiligen.
Allerdings ist nach dem Lesen des Artikels nicht ganz klar, ob das Protokoll „Matrix“ (es gibt keinen Krypto-Messenger „Matrix“!) an sich gefährdet ist, oder ob „lediglich“ die Softwareschmiede/der Dienstleister „Element” (New Vector) in Finanznot ist. Da wird einiges miteinander vermischt.
Im Originalblog von matrix.org steht (maschinell übersetzt):
… Wir haben sogar das Gegenteil erlebt: Kommerzielle Anbieter fälschen das Protokoll und versuchen, das Kernteam aufzulösen. Matrix-Ausschreibungen gingen an “bevorzugte” Anbieter verloren, die absolut nichts über Matrix wissen. Anbieter, die Matrix-Hosting oder -Dienste verkaufen, ohne überhaupt etwas zum Projekt beizutragen. Organisationen mit riesigen Geldbeträgen (Regierungen, $$B-Massivunternehmen) haben mit Begeisterung proprietäre Matrix-Lösungen auf den Weg gebracht, indem sie auf den frei lizenzierten Apache-Referenz-Matrix-Implementierungen aufbauen - und nichts zum Projekt beitragen. …
Hoppla! Harte Worte.
Erst als Matrix.org ein freies Protokoll anpreisen - und sich dann bei/für Element über die selbst gewählte Lizenzierungsart beschweren?
Daß es bei kommerziellen Implementierungen evtl. keine Spenden und keine Zusammenarbeit gibt, ist bei der gewählten Lizensierung logisch. Man muß damit rechnen und sollte weder jammern noch mit Forderungen auftreten. Es scheint, daß die deutliche Aufforderung zur finanziellen Beteiligung tendenziell als Finanzspritze für die Entwicklerschmiede verstanden werden soll. Eine Klarheit, für welche Zwecke Gelder gefordert/verwendet werden, wäre schön.
… Element sei jetzt buchstäblich nicht mehr in der Lage, “die gesamte Matrix Foundation im Namen aller anderen zu unterhalten” …
… noch durch indirekte Unterstützung in Form von Zusammenarbeit mit dem Ableger Element, über den aktuell Matrix maßgeblich vorangetrieben werde. …
Das ist zu hinterfragen, denn die im Artikel zu Ausdruck gekommene Vermengung von Matrix (Protokoll) und Element (Software & Dienstleistungen) bzw. diese „Querfinanzierung” durch Element ist nicht unproblematisch: Wo bleibt die gewollte Unabhängigkeit?
Wurde nicht gerade deshalb die Stiftung gegründet, die sich doch unabhängig um die Fortentwicklung des Matrix-Protokolls kümmern soll?
Größere Summen von Risikokapital wurden sowohl in Matrix.org als auch Element gesteckt. Insofern scheint es, daß sowohl die 5 Millionen Risikokapital als auch weitere zig Millionen Dollar Investment von Element („Element has put tens of millions of dollars into Matrix”) aufgebraucht sind …
Zum Glück sind internationale Standards wie IMAP oder XMPP nicht genauso von einzelnen Geldgebern und Risikokapital abhängig.
Fazit:
Egal ob matrix.org oder element.im (New Vector): Man sollte nicht unter Apache lizensieren und sich hinterher beklagen!
Übersetzung
Ein für mich sehr wichtiger Punkt, denn deutsche Informationen zu Matrix sind rar und fast alles liegt nur auf Englisch vor:
- Weder die Seite von Matrix.org (extern)
- noch die Seite von Element (extern) ist deutschsprachig.
Eine wichtige Frage hierzu ist: Sind englischsprachige AGB im deutschsprachigen Raum (D/A/CH) ausreichend bzw. wo sind deutsche AGB (=Allgemeine Geschäftsbedingungen) der beteiligten Firmen/Organisationen (New Vector Limited, New vector SARL, ELEMENT SOFTWARE INC. und The Matrix.org Foundation) zu finden?
Auch zur Lizensierung findet sich auf der Seite von matrix.org (extern) sehr wenig und noch weniger auf Deutsch:
The Matrix protocol is licensed by the Matrix Foundation which makes it available to third parties who set up their own homeserver.
Datenschutz/Privatsphäre
Matrix wurde nicht mit dem Fokus auf Datenschutz entwickelt (vermutlich ist das auch der Grund für die vielen Insellösungen und die Nicht-Nutzung der Schnittstelle zu standardisiertem Chat (XMPP). Es wird auch nicht damit geworben, daß Nutzer die volle Kontrolle über ihre Kommunikation behalten - statt dessen ist der Vorteil lt. Matrix:
In einer Matrix-Konversation, die sich über mehrere Server erstreckt, gibt es keinen einzelnen Kontroll- oder Fehlerpunkt: Die Kommunikation mit einer Person an einem anderen Ort in der Matrix ist gleichermaßen Eigentum der Konversation wie diese.
Übersetzt aus Quelle: Privacyhandbuch (extern)
Interessanterweise wird genau Datenschutz als Argument aufgeführt, um geschlossene Matrix-Instanzen zu rechtfertigen und um keine Schnittstelle nach außen (=Interoperabilität) haben zu müssen. Aus einer E-Mail auf Landesebene:
…, was von uns aus datenschutzrechtlichen Gründen ausdrücklich nicht gewünscht ist.
Auf die Frage nach einer Konkretisierung der Datenschutzbedenken bekommt man jedoch trotz gezielter Nachfragen von keiner Firma und keiner Behörde eine Auskunft. Es werden bisher keine Argumente gegen echte Interoperabilität geliefert.
Querverweise: Unterschied Föderation und Interoperabilität und öffentliche Vorbildfunktion
Das Grundkonzept von Matrix ist die Replizierung von Chaträumen (auch 1:1-Chats) auf alle am jeweiligen Chat beteiligten Server. Und genau das führt nicht nur zu höherem Ressourcenverbrauch (s.u.), sondern ist auch bei offener/öffentlicher Föderation datenschutztechnisch problematisch. Vermutlich müsste der Auftrag zur Datenverarbeitung jeweils erweitert werden, was praktisch kaum möglich ist. Eine Lösung hier ist nur, bei der Kommunikation mit anderen Systemen auf standardisierte Schnittstellen zurückzugreifen, die keine Replizierung von Datenbanken erfordern.
Datensparsamkeit
Die allgemein gebotene Datensparsamkeit ist in Bezug auf unnötig gespeicherte Benutzernamen und Profilbildern in Anbetracht von teils riesigen Chaträumen schwer zu erreichen.
Identitätsserver
Eigentlich, so erklärt uns Matrix-Mitbegründer Matthew Hodgson im Gespräch, sollten die Matrix-IDs nach außen gar nicht mehr sichtbar sein. Stattdessen sollen Nutzer neue Kontakte über bekannte Merkmale wie etwa die E-Mail-Adresse finden können. Bereits jetzt ist es möglich, die eigene Matrix-ID freiwillig mit einer E-Mail-Adresse zu verknüpfen. Später sollen auch Telefonnummern oder andere bekannte Merkmale wie Skype- oder Facebook-Namen hinzukommen.
Allerdings ist das Zusammenführen solch sensibler Informationen in einem föderierten Netz wie Matrix eine (datenschutz-)technische Herausforderung. Aktuell speichert Matrix die mit den Matrix-Konten verknüpften Informationen auf einem zentralen Identity-Server. “Das ist ein Desaster”, sagt Hodgson. In einem föderierten Netz “solltest du nicht dazu gezwungen werden, einem zentralen ID-Server zu vertrauen”.
Hodgson und sein Team seien auf der Suche: “Wir müssen das in diesem Jahr lösen”. Angedacht ist demnach ein hierarchischer Ansatz, ähnlich der Funktionsweise des Domain Name Systems (DNS). Eine schnelle Lösung des Problems scheint aber eher unwahrscheinlich, denn das Matrix-Team ist mit drängenderen Arbeiten beschäftigt: Aktuell werden die Identitätsinformationen des zentralen Servers noch nicht einmal gehasht.
Quelle: golem.de (extern)
Amdocs
Die Firma Amdocs ist Matrix’ Vater/Mutter: „The initial project was created inside Amdocs …“ (extern; Wikipedia)
In 2016,[20] a subsidiary of Amdocs was created, named “Vector Creations Limited”, which employed the team working on the Matrix protocol and software.[21] Funding by Amdocs was announced to be cut in July 2017, leading to the Matrix core team creating their own UK-based company, “New Vector Limited”.
Quelle: https://en.wikipedia.org/wiki/Matrix_(protocol) (extern; englisch - auf der deutschen Wikipedia-Seite ist die Verbindung zu Matrix nicht ersichtlich und viele Informationen fehlen dort)
Amdocs hat über 26.000 Mitarbeiter und erstellt in ca. 85 Ländern und für mehr als die Hälfte der Weltbevölkerung die Mobilfunkabrechungen. Das heißt, sie wissen seit den 80er-Jahren wer mit wem Kontakt hat, wie oft, wie lange und zu welcher Uhrzeit … das sind Metadaten.
In diesem Zusammenhang der Hinweis, dass Element offen darauf hinweist, dass sie Metadaten zur Profilbildung der Nutzer speichern und auswerten:
„… we might profile metadata…“](https://element.io/privacy) (extern; ‘privacy policy’).
Auch nach 2017 gab es Kontakte zu Amdocs. So war Matthew Hodgeson im August 2020 zu Gast bei Avishai Sharlin (Division President of Amdocs Technology) und es gab einen Podcast
Weitere Informationen:
Gesammelte Kommentare
Unendliche Speicherung < (hier klicken zum Öffnen des Abschnitts)
Jeder Chat, dem man jemals beigetreten ist (die Aktion des Beitritts/Austritts), wird in der Datenbank jedes Servers, der an diesem Raum teilnimmt, für immer registriert. Wenn also z.B. die NSA, der KGB oder was auch immer hypothetisch jetzt oder irgendwann in der Zukunft einen Matrix-Server starten und allen im Netzwerk bekannten Räumen beitreten würde, hätten sie Daten darüber, wer wann dem Raum beigetreten ist oder ihn verlassen hat, wer wo Administrator ist, seit dem Beginn der Existenz des Raums. Ganz zu schweigen von anderen Metadaten, die auf dem Ursprungsserver gespeichert sind, gegen die man nicht wirklich etwas tun kann und die größtenteils nicht gespeichert werden, so dass sie für immer in der Datenbank verbleiben. Dies führt, abgesehen von Datenschutzbedenken, zu einer Situation, in der das Hosting von Matrix-Servern auf lange Sicht nicht nachhaltig ist, da die Datenbank immer weiter wächst, je älter der Raum wird, desto größer werden die Daten, unabhängig davon, zu welchem Zeitpunkt Ihr Server dem Raum beigetreten ist. wie jemand sagte, und ich denke, das fasst die ganze Sache gut zusammen: "Die Art und Weise, wie ich Matrix' Verwendung von DAG sehe, ist, dass es perfekt für Regierungen und Unternehmen ist. Es ermöglicht eine granulare, atomare Überwachung Ihrer Mitarbeiter mit unendlicher Tiefe. Es gibt keine Opt-Out-Möglichkeit in der Struktur des Protokolls, das ist so vorgesehen. Das ist cool für Unternehmen, aber es ist das genaue Gegenteil von Privatsphäre.
Hinweis: Es ist so, daß Datenbanken zumindest vom jeweiligen Server-Administrator aufgeräumt werden können.
Eine Meinung zu privaten bzw. teilprivaten IRC-Räumen
If the irc channel is intended to be private then I’m sure it’s best not to bridge to matrix. Heads up if you have a semi-private IRC channel with bridged #Matrix users in it. Once the channel logs arrive at the Matrix server hosting the bridge, every Matrix user can join this channel and the Matrix sever will happily provide the complete channel logs without anyone on the IRC side ever noticing. (tested with matrix.org & freenode) This is a HUGE privacy concern and I don’t understand why anyone would consider using Matrix.
Hier würde mich interessieren, ob das tatsächlich so ist >> Kontakt <<.
Blinde Empfehlungen
Das Kommunikationssystem „Matrix“ mit dem Referenzclient Element wird vermehrt bei großen Einheiten (Organisationen, Verwaltungen, Firmen) als Alternative zu proprietären (geschlossenen, firmeneigenen) Systemen eingesetzt oder es bestehen Überlegungen hierzu. Das ist an sich nichts besonderes, denn der Trend geht hin zu quelloffenen Systemen für Arbeitsgruppen, die unbestritten Vorteile haben.
Oft wird der Umstand „Sogar Organisation XY nutzt Matrix“ als (blinde) Empfehlung verstanden, ohne die Hintergründe oder Zusammenhänge zu kennen. Aber außer matrix(.org) sind fast alle wirklich großen Instanzen wie …
- „BW-Messenger“ (Bundeswehr)
- „Tchap“ (Französische Regierung/Verwaltung)
- „TI-Messenger“ (gematik) oder auch
- viele (nicht alle!) Instanzen im Bildungsbereich
… für eine rein interne Kommunikation und so konfiguriert, daß keine öffentliche Föderation erlaubt ist. Ganz zu schweigen von einer echten Interoperabilität, denn theoretisch mögliche Brücken zu anderen Systemen wie beispielsweise dem Standardprotokoll „XMPP“ sind/werden in der Praxis oft nicht aktiviert.
Interoperabilität ist so nicht möglich. Und von blindem Vertrauen bei solchen Empfehlungen ist abzuraten - es ist Eigenverantwortung gefragt.
Kein Internetstandard
Das Matrix-Protokoll selbst gehört der Matrix.org-Foundation (extern) und ist lediglich eine offengelegte Schnittstellenbeschreibung. Matrix ist kein durch die IETF (extern) geprüftes, legitimiertes oder standardisiertes Protokoll. Die Matrix.org-Foundation lizensiert das Protokoll an andere:
The Matrix protocol is licensed by the Matrix Foundation which makes it available to third parties who set up their own homeserver.
Quelle: Matrix.org Homeserver Privacy Notice (nur englisch)
Ob/wann der Standardisierungsprozess angestoßen wird, ist aktuell nicht bekannt. Es gibt jedoch eine in der Zwischenzeit relativ gut funktionierende Schnittstelle zum Chat-Standard „XMPP“, was als Brücke bezeichnet wird.
Etwas seltsam dazu ist folgende Selbsteinschätzung von Matrix.org:
„… abschließendes positives Fazit: matrix.org/foundation ist eine ziemlich solide Stiftung (hah) in Bezug auf die Führungsstruktur - wir schützen das Protokoll so weit wie möglich vor Sabotage durch unser zukünftiges Ich (oder irgendjemand anderen).“
Quelle: https://twitter.com/matrixdotorg/status/1197297411300958208 (extern; maschinell aus dem Englischen übersetzt)
Die Kritik seitens Matrix am IETF-Standardisierungsprozess von XMPP wird nicht sachlich begründet. Es gibt ein paar IETF-RFCs, die den Kern des XMPP-Protokolls spezifizieren (und auch schon eine komplette Überarbeitung in 2011 hinter sich haben) - mit allen Garantien/Sicherheiten die das mit sich bringt. Plus dank der Modularität des Protokolls die XEPs, die das Protokoll beliebig dynamisch weiterentwickeln können und von der XSF, die nicht nur formal völlig unabhängig ist kontrolliert werden. Strukturell also die besten Voraussetzungen. Wenn vorhanden ist ein Internetstandard einer individuellen “REST-API” vorzuziehen. Darüber hinaus könnte die Matrix-Schnittstelle auch durch die IETF standardisiert werden … wenn man das wollte.
Monolithisches Protokoll
Matrix will alle für einen modernen Chat erforderlichen Funktionen in einem Protokoll vereinen. Es ist monolithisch. Technisch verzichtet Matrix auf Modularität (also auf das ‘X’ in XMPP). Damit soll eine Fragmentierung vermieden werden. Eigenes Zitat dazu von 2018:
Das Problem ist, dass heute ‘nötige Funktionen’ nicht denen der Zukunft entsprechen müssen - die Entwicklung geht weiter. Künftige Anwendungsfälle brauchen andere Funktionen und keiner weiß, wie in 5 Jahren der Bereich Sofortnachrichten aussieht. Dem Protokoll fehlen die Mechanismen, um es entsprechend anpassen zu können. Also wird es irgendwann aktualisiert und in der Folge wird es mit alten Servern Schwierigkeiten geben oder überhaupt nicht mehr funktionieren.
Damit soll eine Fragmentierung vermieden werden. Das ist umstritten („illusorisch“). Im Gegenteil - es wird so viel schwieriger, die Fragmentierung in den Griff zu bekommen.
Das Problem ist, dass heute ‘nötige Funktionen’ nicht denen der Zukunft entsprechen müssen; die Entwicklung geht weiter. Künftige Anwendungsfälle brauchen andere Funktionen und keiner weiß, wie in 5 Jahren der Bereich Sofortnachrichten aussieht.Dem Protokoll fehlen die Mechanismen, um es entsprechend anpassen zu können. Also wird es irgendwann aktualisiert und in der Folge wird es mit alten Servern Schwierigkeiten geben oder überhaupt nicht mehr funktionieren.
Der Ansatz, auf Modularität zu verzichten um keine Fragmentierung zu bekommen funktionierte zu Beginn wunderbar. Allerdings ist/war schon nach ein paar Jahren eine gewisse Fragmentierung festzustellen:
Der angebliche Vorteil gegenüber dem Chatstandard XMPP von damals hat sich in Luft aufgelöst.
Flexibilität des Protokolls
Für moderne IM-Anforderungen ist das Matrix-Protokoll geeignet (es wäre ja auch schlimm, wenn nicht) - für andere Dinge jedoch wie das Internet der Dinge (IoT) oder neue Entwicklungen nicht wirklich. Also braucht es dafür separate Lösungen, was schade ist.
Föderation & Interoperabilität
Beim Matrix-Protokoll können verschiedene Matrix-Server miteinander föderieren, was gegenüber anderen quelloffenen Teammessengern ein großer Vorteil ist. Deshalb auch meine Empfehlung im Systemvergleich.
Durch die Föderation von Matrix-Servern wird eine Ausfallsicherheit bei Chaträumen erreicht. Wird bei Matrix von Föderation gesprochen, so können hierunter verschiedene Dinge gemeint sein:
- Bei einer internen Föderation gibt es organisationsintern mehrere Server, die zwar verbunden sind, aber die nicht nach/von außen kommunizieren können.
- Bei einer öffentlichen Föderation ist eine Kommunikation auch mit (von/zu) anderen Matrix-Anbietern möglich.
Es ist also immer wichtig zu hinterfragen, ob eine tatsächliche Kommunikation mit beliebigen Matrix-Instanzen (Föderation) möglich ist oder nicht!
Denn es ist festzustellen, daß in Werbeversprechen immer wieder auf Föderation (welche?) hingewiesen wird und angebliche Interoperabilität versprochen und fleißig damit geworben wird. Aber: Föderation ist nicht mit Interoperabilität zu verwechseln!
Dadurch hat man nicht nur eine große Matrix-Welt, sondern auch viele einzelne Matrix-Inseln, die für sich genommen eine tolle Lösung sind - aber eben nicht föderieren und somit nicht interoperabel sind. Das ist so, wie wenn man E-Mails nur betriebsintern versenden/empfangen könnte!
Interessant wird diese Konstellation, falls politisch eine zwangsweise Interoperabilität zur Pflicht gemacht würde (-> Sektoruntersuchung) des Bundeskartellamts. Wie sieht es dann mit der öffentlichen Vorbildfunktion aus?
Ja, unbestritten - aber nochmals: „Matrix ist nicht gleich Matrix“ und vor allem nicht von vornherein mit öffentlicher Föderation oder gar Interoperabilität gleichzusetzen. Geschlossene Matrixinstanzen tun der offenen Föderation anderer Installationen keinen Abbruch - genauso, wie es zum Teil auch extrem große, geschlossene Instanzen anderer Systeme gibt.
Vielmehr geht es hier um die Sensibilisierung, ob mit Matrix eine öffentliche Interoperabilität erreicht werden kann oder nicht. Denn das ist gerade für die Frage des Einsatzes bei öffentlichen Einrichtungen und in der Bürgerkommunikation ein wesentlicher Punkt.
Trägt die Matrix-Brücke zu standardisiertem Chat („Bifröst“) zu einer Interoperabilität bei Messengern bei oder nicht?
- Theoretisch ja, denn so können Nachrichten übergreifend ausgetauscht werden.
- In der Praxis werden jedoch sehr viele Matrix-Instanzen für eine rein interne Kommunikation und so konfiguriert, daß keine öffentliche Föderation erlaubt ist. Ganz zu schweigen von einer echten Interoperabilität. Theoretisch mögliche Brücken zu anderen Systemen wie insbesondere dem Standardprotokoll „XMPP“ sind/werden in der Praxis oft nicht aktiviert. Aus Ängsten, die nicht sachlich und konkret zu begründen sind?
Eine interne Matrix-Föderation bringt jedoch keine in der Politik geforderte Interoperabilität von Messengersystemen und hilft auch nicht beim Erreichen dieses Ziels.
Wenn beispielsweise Frankreich auch Nicht-Regierungsmitarbeitern anbieten würde, mit diesen zu kommunizieren (also mit Nutzern anderer Matrix-Server=Föderation), dann müssten die Matrix-Chatadressen konsequenterweise irgendwo kommuniziert und veröffentlicht werden: Auf einer Internetseite, auf Visitenkarten, in E-Mails, in Gesprächen, …
Da das nicht gemacht wird, hat das auch in der Praxis rein gar nichts mit öffentlicher Interoperabilität zu tun.
Theorie (das technisch Machbare sowie Marketingversprechungen) und Praxis (tatsächliche Servereinstellungen) laufen somit oft auseinander.
Freie Anbieterwahl
Eine freie Wahl des Anbieters ist seitens des Protokolls zwar ohne Probleme möglich - wird jedoch in der Praxis etwas eingeschränkt, da kleine Anbieter durch den erhöhten Ressourcenbedarf an Hauptspeicher, CPU und „Platten-“Speicher deutlich schneller an ihre Kapazitätsgrenzen kommen. Das Eigenhosting (das Betreiben eines eigenen Matrix-Servers) für Privatpersonen wird dadurch erschwert. Natürlich kann man eine private Matrix-Instanz auch auf einem Raspberry PI laufen lassen - aber gewisse Unterschiede gibt es doch …
Ressourcenbedarf
Ein Beispiel mit konkreten Zahlen gibt Disroot.org (extern): Es ist ein Unterschied, ob für ca. 20 Nutzer 140 GB Datenbank und 4,5 GB Hauptspeicher benötigt werden (Matrix) oder für ca. 450 Nutzer nur 6 GB Datenbank und weniger als 400 MB Hauptspeicher (XMPP). Dabei ist nicht die Benutzeranzahl der eigentliche Grund sondern es ist die Komplexität des Matrix-Raums die den hohen Speicher- und CPU-Verbrauch verursacht.
Weitere Beispiele mit konkreten Zahlen sind im Systemvergleich XMPP-Matrix zu finden.
Die einfachste Lösung für das Ressourcenproblem, das seitens Matrix derzeit mit „conduit“ (Beta-Status Stand Nov. 2024) (extern) versucht wird zu verbessern, ist die Einschränkung bei der Föderation. Die Komplexität von föderierten Räumen wird begrenzt und somit die Ressourcenanforderungen reduziert. Allerdings unterstützt diese Serversoftware dadurch nur Räume ab Version 6 (extern) was zu Inkompatibilitäten (s.o.) führt.
Um im Rahmen der vorhandenen technischen Möglichkeiten zu bleiben, werden manche Matrix-Instanzen deshalb nicht öffentlich betrieben.
These/Frage:
Bei Matrix-Instanzen ohne Föderation müsste eine verbessere Interoperabilität ressourcenschonend auch durch die Nutzung des Chatstandards und der Schnittstelle “XMPP” möglich sein?
Verschlüsselung
Auch bei Matrix ist es nicht so, daß das Protokoll eine Verschlüsselung vorschreibt (das wäre auch nicht sinnvoll). Statt dessen ist das eine Sache der Clients (extern):
This guide is intended for authors of Matrix clients who wish to add support for end-to-end encryption.
Trotzdem wird immer behauptet, bei Matrix wäre automatisch alles verschlüsselt. Das stimmt nicht.
Ein weiterer Punkt ist die fehlende Flexibilität bei den zur Verfügung stehenden Verschlüsselungsarten. Es gibt ausschließlich das gerätebezogene OLM/MEGOLM - benutzerbezogene Verschlüsselungsarten wie PGP sind als Alternative gar nicht möglich.
Anmerkung zu „gerätebezogen“: Matrix spricht von „device keys“ (extern) - was jedoch eigentlich client-keys sind (auf einem Gerät können mehrere Clients mit dem selben Chatkonto arbeiten).
Sicherheitsprobleme
Lt. Soatok.blog (extern) gibt es seit Jahren Sicherheitsprobleme in der Matrix-Verschlüsselungsbibliothek „Olm“. Statt diese zu korrigieren empfiehlt Matrix den Entwicklern von Clients, statt dessen eine andere Bibliothek zu implementieren (Addendum vom 14.08.2024 (extern))
Nutzerzahlen
Wie auch bei Telegram werden die Nutzerzahlen durch das Zählen ehemaliger und irgendwann einmal in Chaträumen vorhandener Nutzer immer größer. Sie sollten nicht mit Nutzern verwechselt werden, die aktuell gerade online sind. Die für Matrix-Chaträume angegebenen und teils riesigen Nutzerzahlen sind also mit Vorsicht zu genießen und zu hinterfragen, denn …
- Nutzer anderer Systeme zu denen gebrückt wird, werden einverleibt und finden sich in der „Nutzerstatistik“ von Matrix wieder (z.B. werden verbundene IRC-Nutzer als Teil des Matrix-Netzwerks gesehen)
- Auch vergißt ein Matrix-Server die ehemaligen Nutzer eines Chats nicht so einfach, sondern läßt diese weiter im Chatraum „vorhanden sein“ - obwohl diese gar nicht mehr online sind. Bei den Chaträumen werden also alle bisherigen Mitglieder (egal ob noch aktuell oder nicht) weiter mit aufgeführt - natürlich auch die unter Punkt 1 genannten Nutzer (die von über Brücken „angezapften“ Chaträumen anderer Systeme mal online waren). Das kann unter dem Gesichtpunkt von unnötig gespeicherten Benutzernamen und Profilbildern auch ein Datenschutzthema (Datensparsamkeit) sein.
Räume können zwar aktiv verlassen werden aber das Problem ist, daß Benutzer oft einfach ihren Matrix-Client deinstallieren ohne entweder Räume zu verlassen oder ihre Chatkonten vorher zu deaktivieren. Die Deaktivierung eines Chatkontos führt dagegen dazu, daß der Benutzer sich von allen Matrix-Räume abmeldet und diese “verlässt”. Auch Serveradministratoren legen ihre Server in der Regel immer wieder nicht ordnungsgemäß still, indem sie Ihren Server herunterfahren ohne vorher alle Konten zu deaktivieren.
Es werden also teilweise deutlich mehr Nutzer angezeigt als tatsächlich „vorhanden“ - und diese werden in der Folge dann auch oft als aktive Matrix-Nutzer interpretiert und als solche in Gesprächen „verkauft“.
„Anzahl der Nutzer“ ist nicht mit „Anzahl der aktuell angemeldeten Nutzer“ oder gar „Anzahl der Nutzer mit einem Konto bei Matrix“ gleichzusetzen!
„Bei Matrix sind öffentliche Chaträume viele größer!“
Oft wird gefragt „Gibt es in System X/Y denn keine Chaträume, die so groß sind wie bei Matrix?“. Doch, aber dort werden einfach nur die Nutzer angezeigt, die aktuell im Chat anwesend sind. Trotzdem meinen manche, es wäre ein Qualitätsmerkmal, wenn Chaträume tausende schreibberechtigte Mitglieder hätten.
Electron
Der Referenzclient Element ist eine Electron-Anwendung und deshalb für manche ein (Un-)Sicherheitsfaktor. Die Anwendung ist in einen eigenen Browser eingebettet und müsste auch bei jedem Sicherheitsupdate des Browsers mit aktualisiert werden. Zudem benötigen Electron-Anwendungen mehr Speicherressourcen als native Programme/Apps. Das ist jedoch kein spezifisches Matrix-Phänomen sondern ist bei allen Electron-Anwedungen so.
Zur Erklärung: Wenn eine Anwendung „nativ“ läuft, wurde sie direkt für die Betriebssystemumgebung erstellt (Fachausdruck: kompiliert) und kann somit auch direkt vom Betriebssystem ausgeführt und interpretiert werden. Läuft eine Anwendung „nicht nativ“, kann sie nur in einem emulierten Modus (oder eben innerhalb einer Browserumgebung) ausgeführt werden.
Externe Dienste
Element.io bietet mit „Element Matrix Services“ die weltweit größte Hostingplattform für Matrix (Infrastruktur zum Hosten von Matrix-Instanzen) an. Für diesen Hosting-Service werden auch die externen Dienste Cloudflare und „AWS“ (Amazon Server) genutzt, die seitens Datenschützern in der Kritik stehen. Im Falle von matrix.org werden also AWS-Server genutzt, deren Domains hinter Cloudflare liegen. Auch bei jedem Dateiupload (auch von anderen Instanzen, sofern der Admin da die Voreinstellung nicht geändert hat), geht alles über element.io, wiederum auf AWS und hinter Cloudflare.
Kritiker meinen: Cloudflare ist die Pest des Internets. Keiner braucht es, aber alle verwenden es, weil sie glauben, dass sie es brauchen. (Aus einem Kommentar)
In der Tat kann man einen Widespruch darin finden, wenn ein auf Dezentralisierung angelegtes System wie Matrix im Hintergrund zentralisierte Systeme nutzt, die für Überwachungszwecke mißbraucht werden können und nicht dem EU-Recht unterliegen.
Privacy policy von Element: https://element.io/privacy (extern) unter „2.10 Who Else Has Access to My Data?“:
We host the Element Matrix Services on Amazon Web Services (AWS), specifically:
Our admin server is hosted in an AWS data centre in Amsterdam;
Our deployment server is hosted in an AWS data centre in Stockholm;
Customer deployments have the option to select the geographical location which is the most convenient for them;
We also host the Gitter.im app on AWS, in a datacenter based in the East of the US.
Amazon employees may have access to this data. Here’s Amazon’s privacy policy. Amazon controls physical access to their locations.
We use Cloudflare to mitigate the risk of DDoS attacks. Here’s CloudFlare’s privacy policy.
Zu Cloudflare steht in der Dokumentation Integration Manager Privacy Notice (extern) unter „3.9 Who Else Has Access to My Data?“:
We host the majority of the Service in UpCloud data centres. Here’s UpCloud’s privacy policy. UpCloud controls physical access to their locations. We use Cloudflare to mitigate the risk of DDoS attacks. …
Anfragen auf Github zum Beenden der externen Dienstenutzung wurden mit dem Hinweis zur Verhinderung von DDoS-Attacken erledigt:
In der Dokumentation der Element Matrix Services EMS Server With Custom Domain (extern) wird die Nutzung des Verweises auf Cloudflare - der „report-uri“ - beschrieben.
Informationen dazu: https://www.kuketz-blog.de/the-great-cloudwall-weshalb-cloudflare-ein-krebsgeschwuer-ist/ (extern)
Viele gesammelte Infos: https://mypdns.org/dCF/deCloudflare/-/blob/master/readme/de.md (extern)
„VS-NfD“
Auch eine vermeintlich offizielle Einstufung des Matrix-Protokolls als sicheres Kommunikationsmittel ist ein Mißverständniss, das immer wieder auftaucht. Es geht dabei um „Verschlußsache - Nur für den Dienstgebrauch (VS-NfD)“. Im Privacyhandbuch wird versucht, hierüber aufzuklären:
Es kursiert das Gerücht, [matrix] wäre aufgrund sicherer Krypto vom BSI für klassifizierte Kommunikation der Einstufung VS-NfD in der Bundeswehr zugelassen. Das ist eine Legende bzw. irreführende Werbung, also Fake News. Für die Nutzung des bwmessenger gelten in der Bundeswehr die gleichen Regeln, wie für unverschlüsselte E-Mails.
Daraus abzuleiten, das Protokoll selbst wäre für “VS NfD” konzipiert/freigegeben oder besonders sicher ist falsch - auch wenn der Gedankengang nahe liegt. Wenn das so wäre, könnten die meisten (alle?) Inselsysteme als “sicher” eingestuft werden.
Zum Thema „VS NfD“ würde ich mich über mehr offizielle Informationen freuen: >> Kontakt <<
Quellen:
- Privacyhandbuch (extern)
- Pressemitteilung der Bundeswehr (extern)
- Information des BWI (IT-Dinstleister der Bundeswehr) vom 16.11.2021 (extern)
Brücken
Ganz allgemein gilt:
Werden zwei strukturell unterschiedliche Systeme durch Hilfskonstrukte wie Brücken verbunden, so summieren sich die Nachteile der beteiligten Messenger und die jeweils einzigartigen Vorteile werden in der gemeinschaftlichen Kommunikation verworfen.
Grundsätzliches
- Die Matrix-Bifröst-Brücke ist bisher noch nicht über den Experimentalstatus (extern; 01.02.2023) hinaus gekommen („This bridge is in very active development currently and intended mainly for experimentation and evaluation purposes.“) - offensichtlich wird in anderen Brücken mehr Wertschöpfungspotential gesehen. Die Original-Bifröst-Brücke ist nicht stabil und wird nicht aktiv weiterentwickelt. Deshalb wird in Nutzerforen allgemein empfohlen, die Bifröst-Variante von aria-net.org zu verwenden.
- Austausch nur über Matrix
Brücken sind lediglich Brücken von/zu Matrix - ein direkter Austausch zwischen anderen Systemen ist damit nicht möglich. Folglich sind Brücken also Teil des Interoperabilitätsproblems und nicht der Problemlöser (das Selbe gilt auch für Brücken (“Transporte”), die es bei XMPP gibt!).
Matrix-Grafik mit Matrix als zenraler Stelle, um für übergreifende Kommunikaition (=/= Interoperabilität) zu sorgen - worauf auch in entsprechenden Pressetexten (z. B. bei t3n.de (extern)) eingegangen wird. Allerdings kann das Schaubild suggerieren, daß zwischen den Systemen und systemübergreifend ohne Probleme und in vollem Funktionsumfang kommuniziert werden kann (was falsch wäre).
Bildquelle: t3n.de (extern)
| |
Rechtmäßigkeit und Zukunftssicherheit
Matrix wirbt damit, viele Brücken zu geschlossenen Messengerdiensten wie beispielsweise Discord, Facebook Messenger, Instagram, Signal, Threema, WeChat und auch WhatsApp zu haben: https://matrix.org/bridges (extern)
Dabei ist jedoch nicht klar, ob es mit den jeweiligen Eigentümern von zentralen Diensten (z.B. Facebook, Microsoft, Apple oder Google - um mal die Großen zu nennen) überhaupt Verträge diesbezüglich gibt oder nicht. Denn andere Clients als den Eigenen zu nutzen ist nicht erwünscht. Vielleicht lohnt sich hier ein Blick in die Allgemeinen Geschäftsbedingungen der jeweiligen Anbieter …!?
Wenn also Brücken zu zentralen Diensten als funktionierend angeboten werden, sollte das auch durch einsehbare und transparente Verträge des eigenen Dienstleister mit dem jeweiligen Zielsystem sichergestellt werden. Alles andere ist heiße Luft und nicht wirklich zukunftssicher.
In der Vergangenheit war es zumindest so, daß alle Brücken anderer Systeme, die beispielsweise zu WhatsApp oder zu Signal erstellt wurden, lediglich eine gewisse Zeit geduldet waren. Wenn die Nutzung zu intensiv wird und die Geschäftsinteressen zu sehr berühren, sind dafür angelegte Chatkonten schnell vom Anbieter gesperrt/gelöscht.
Bezüglich des Einsatzes von Brücken zwischen verschiedenen Messengersystemen gibt es kritische Stimmen, wie die von Mike Kuketz (extern). Hier ist es jedoch vermutlich sinnvoll, kein pauschales Urteil abzugeben, sondern zu hinterfragen, welche Art von Chat (Einzelchat, Gruppe oder öffentlich Chaträume) wie (per Föderation oder per Brücke) verbunden werden soll und ob sich in diesen jeweils unterschiedlichen Fällen tatsächlich datenschutzrechtliche Fragen/Probleme ergeben oder nicht.
Datenintegrität
Die aktuellere und oft verwendete Bifröst-Brücke von aria-net.org hat einen großen Nachteil: Seit März 2022 verändert diese Inhalte und ‘übersetzt’ XMPP URIs (Adressen) in das Matrix-Format. Diese „Funktionalität“ wurde bisher zum Glück noch nicht in die ursprüngliche (extern) Bifröst-Brücke integriert.
Das Ändern von Inhalten ist für mich ein absolutes „no-go“ - denn das, was beim Empfänger ankommt, entspricht nicht dem, was der Absender der Nachricht tatsächlich geschrieben hat. Inhalte von Nachrichten werden auf Matrix-Seite geändert angezeigt und in der Folge auch Zitate verfälscht. Auch wenn das für Matrix-Nutzer praktisch erscheinen mag - ich finde das nicht gut.
Ganz abgesehen davon, daß Nachrichten von einer Brücke nicht inhaltlich geändert sondern nur transportiert werden sollten:
Hier werden Aufgaben, die ein Client übernehmen sollte (optionale Anpassung in der Anzeige von Inhalten) von der Brücke übernommen. Verknüpfungen (Links) beinhalten bewußt das zu berücksichtigende Protokoll, was viele Gründe haben kann - unter anderem Sicherheit. Der Kontext von Nachrichten kann sonst inhaltlich total verfälscht werden.
Abstrakte Beispiele:
- “Die Adressen xmpp-adresse und matrix-adresse betreffen unterschiedliche Systeme!” wird auf Matrix-Seite zu:
“Die Adressen matrix-adresse und matrix-adresse betreffen unterschiedliche Systeme!”
- “Wer administriert den Chatraum xmpp-chatraum?” wird auf Matrix-Seite zu:
“Wer administriert den Chatraum matrix-chatraum?”
Konkretes Beispiel:
- Die Einladung auf Matrix-Seite
#matrixistsuper:matrix.org
wird von der Bridge in Richtung XMPP nicht verändert (so wie es auch richtig ist). Aber …
- Aus der Einladung
xmpp:testchatraum@conference.irgendeinserver.tls?join
wird auf Matrix-Seite: https://matrix.to/#/#_bifrost_testchatraum_conference.irgendeinserver.tls:aria-net.org
Auch wenn nur Inhalte in Richtung Matrix-Seite verändert werden - bei Antworten zurück über die Brücke erscheinen diese dann mit geändertem (verfälschtem) Inhalt. Kein Punkt also in Sachen Datenintegrität.
Praktische Mängel
Insbesondere bei der Verbindung und dem Brücken von öffentlichen Chaträumen kommt es immer wieder zu Mißverständnissen und Problemen durch „im anderen Chatraum nicht angezeigte Nachrichten“. Grund dafür ist die fehlende Synchronisation der Berechtigungen. So werden weder die Rollen der Teilnehmer (Eigentümer, Moderatoren, Mitglieder, Teilnehmer) sowie auch blockierte und somt eigentlich ausgesperrte Chatadressen nicht automatisch gebrückt.
Auch ist für Matrix-Nutzer beim Besuch von öffentlichen Chaträumen (XMPP) nicht eindeutig klar, daß man nur „Gast“ im anderen System ist. Durch das systemseitige Erstellen eines Matrix-Chatraums als unabhängiges Pendant zum Original besteht in diesem Fall bei Gesprächen ständig Verwechslungsgefahr, was (welche Seite der Brücke) mit „hier im Chatraum“, “wir hier” oder “hier” gemeint ist.
Unklare Positionierung
Auf der einen Seite wird mit Brücken zwischen den Protokollen Matrix und XMPP geworben - auf der anderen Seite wurde XMPP überhaupt nicht bei den Matrix-Brücken (extern) aufgeführt bzw. mit keinem Wort erwähnt. Zumindest nicht auf dieser wichtigen Seite. Der Kritikpunkt scheint jedoch angekommen zu sein: Bei einem weiteren Besuch der Seite im April 2024 habe ich festgestellt, daß nun auch das XMPP-Logo mit Link zur Beschreibung (extern) aufgeführt wird.
Um „XMPP“ zu finden, musste man vorher unter „libpurple“ schauen, wo widerum auf „matrix-bifrost“ verwisen und der Hinweis “General purpose puppeting bridges using libpurple and other backends. This bridge is in very active development currently and intended mainly for experimentation and evaluation purposes.” gegeben wurde. Erst auf der dort verlinkten Github-Seite stand bzw. fand man dann „XMPP“.
Es wird/wurde also teilweise mit Brücken zu XMPP geworben - aber Interoperabilität auf der Basis von internationalen Protokollen wird nicht aktiv verfolgt. Dieser vermeintliche Widerspruch resultiert vermutlich aus dem Geschäftsmodell.
Es erschließt sich generell auch nicht so einfach, warum unterschiedliche Brücken beworben werden oder im Einsatz sind - oder auch nicht.
Bei Matrix.org (extern) wird eine Brücke (trotz experimentellem Status) zu standardisiertem Chat betrieben - Stand April 2022 wurden aufgeführt: IRC (6x), Slack, Gitter und XMPP
In den Informationen zu den verfügbaren Brücken fand man auf Matrix.org (extern) jedoch kein Wort zum Standard XMPP, kein Logo und keinen Hinweis darauf (die Brücke war hinter “libpurple” unter “matrix bifrost” versteckt). Der Kritikpunkt scheint jedoch angekommen zu sein, denn Stand April 2024 ist das nicht mehr so.
Quellen: https://element.io/element-matrix-store#bridges (extern) oder https://element.io/enterprise/matrix-bridging-services (extern) oder https://element.io/matrix-services/hosted-bridges (extern)
| |
Wird die Hosting-Dienstleistung von element.io (extern) als weltweit größtem Matrix-Hoster in Anspruch genommen, wurden Stand April 2022 dagegen folgende 8 unterschiedliche Brücken aufgeführt: WhatsApp, Slack, MS Teams, Signal, Gitter, Discord, Telegram und IRC. Auf der offiziellen Internetseite von Element.io fehlte somit die Brücke zum internationalen Standard XMPP, was auch in der dortigen Matrix-Grafik zum Ausdruck kam. (Stand April 2024 sind auf den Seiten von element.io überhaupt keine Brücken mehr zu finden.)
Dort waren darüber hinaus auch noch Verbindungen zwischen dein einzelnen ‘Zielsystemen’ eingezeichnet (nebenstehend farblich deutlicher als im Original hervorgehoben), woraus man eine direkte Kommunikation zwischen diesen (und ohne Matrix in der Mitte) ableiten konnte (was falsch wäre). Interoperabilität kann unterschiedlich gesehen werden.
| |
Sicherheitsprobleme
Von Libera.Chat wurden bezüglich der Matrix-Brücke verschiedene Punkte festgestellt, die sicherheitsrelevant bzw. datenschutzproblematisch waren. Hier die Zusammenfassung von Libera.Chat vom 10.08.2023:
Wir haben darum gebeten, das Portalling zu deaktivieren, da wir Bedenken bezüglich der Arbeitsbelastung durch Missbrauch, verschiedener Datenschutz- und Sicherheitsprobleme sowie der allgemeinen Stabilität hatten. Wir haben die vorübergehende Abschaltung aufgrund eines wiederkehrenden Datenschutzproblems veranlasst, bei dem Matrix-Nutzer, die nicht mit Libera.Chat verbunden sind, Kanalinhalte sehen konnten. Das Problem konnte nicht schnell behoben oder auf Opt-in-Kanäle beschränkt werden. Brücken von Drittanbietern sind nach wie vor willkommen und werden individuell beurteilt, wenn Bedenken auftreten.
Chronik zu Matrix’ Fehlverhalten gegenüber libera.chat und die dadurch verursachten Probleme im Jahr 2023:
07.06.2023 / Libera.Chat: Aktualisierungen auf der Matrix<>IRC-Brücke (extern)
”… Wir sind uns bewusst, dass die Libera.Chat Matrix<>IRC-Brücke (betrieben von Element Matrix Services, ‘EMS’) in letzter Zeit eine Reihe von Problemen hatte, darunter das stille Verwerfen von Nachrichten, das Abbrechen von Verbindungen und das Durchsickern von Informationen über die Existenz von +s (geheimen) Kanälen an Benutzer, die nicht in diesen Kanälen sind. …”
03.07.2023 / Libera.Chat: Abschaltung der Matrix-Portalisierung (extern)
”… Libera.Chat wird EMS auffordern, die portierten Kanäle zu deaktivieren, und zwar bis zum 31. Juli 2023, jedoch nicht vor dem 25. Juli 2023. Wenn die Deaktivierung der portierten Kanäle nicht möglich ist, wird Libera.Chat EMS auffordern, die gesamte Matrix-Brücke im gleichen Zeitrahmen zu deaktivieren.”
28.07.2023 / Libera.Chat: Verzögerungen bei der Matrix-Entportalisierung (extern)
”… In Anbetracht der Art der Probleme haben wir zugestimmt, die Frist bis zum 11. August 2023 zu verlängern, was zusätzliche zwei Wochen zur Verfügung stellt, um diese Probleme mit hoher Priorität zu beheben und die Situation zu verbessern. …”
28.07.2023 / Matrix.org: Verschiebung der Matrix-Entportalisierung von Libera.Chat (extern)
”… zum jetzigen Zeitpunkt kann der Plumbed-Modus jedoch noch nicht als ausreichend stabil angesehen werden. Außerdem wurden wir im Rahmen des Projekts auf mehrere neue Sicherheitsprobleme der Brücke aufmerksam gemacht. Diese Probleme müssen vor den Stabilitätsarbeiten an den angedockten (plumped) Chaträumen behoben werden, wodurch sich der Gesamtumfang des Projekts erhöht. Die begrenzten Ressourcen der Matrix.org Foundation erlaubten es uns nicht, den Termin rechtzeitig einzuhalten.”
(Hier sei die Frage erlaubt, warum Matrix.org als für das Protokoll zuständige, neutrale Organisation, Programmierarbeiten macht?)
05.08.2023 / Libera.Chat: Vorübergehende Deaktivierung der Matrix-Brücke (extern)
”… Um unsere Benutzer und unsere IRC-First-Communities vor zunehmenden Stabilitäts-, Sicherheits- und Datenschutzproblemen zu schützen, haben wir EMS gebeten, die Matrix-Brücke von Libera.Chat zu entfernen, bis diese schwerwiegende Regression behoben ist und alle anderen offenen Probleme ebenfalls gelöst sind. EMS hat zugestimmt, die Brücke bis Samstag, den 5. August, 1400UTC abzuschalten. …”
10.08.2023 / Libera.Chat: Matrix Bridge Temporary Shutdown, a Retrospective (extern)
”… Einige haben um Transparenz darüber gebeten, wie Libera zu dem Schluss gekommen ist, dass wir die drastische Maßnahme ergreifen müssen, Element Matrix Services (EMS) aufzufordern, die Türsteher-ähnliche Funktion der Matrix-Brücke zu deaktivieren und sie auf ausdrücklich zugelassene Räume zu beschränken, und dann zu einer ernsteren Maßnahme überzugehen, indem wir die vollständige Deaktivierung der Brücke fordern. …”
28.11.2023 / Matrix.org: Shutting down the Matrix bridge to Libera Chat (extern)
”… Leider müssen wir Ihnen heute mitteilen, dass wir nicht in der Lage sind, die Libera Chat-Brücke wieder online zu stellen. …”
”… Wer eine Bridge für seine Community benötigt, kann seine eigene betreiben: Die Software matrix-appservice-irc wird weiterhin gepflegt. Nur die Libera-Chat-Instanz, die so konfiguriert war, dass Verbindungen über Neustarts hinweg bestehen bleiben, wird abgeschaltet. …”
Ergänzende Informationen: https://libera.chat/guides/matrix (extern)
Markdown
Markdown ist eine einfache Art, um Texte formatiert anzuzeigen und hervorzuheben - unter anderem auch zum Anzeigen von Verknüpfungen (Links). Im Chatstandard XMPP ist es nicht möglich, gefälschte Links zu erstellen, da es keine Möglichkeit gibt, explizit einen Formatierungscode aufzurufen, um einen Link zu beginnen und zu beenden. In Matrix dagegen hat man die Möglichkeit, gefälschte Links zu erstellen und man überlässt es der Client-Software zu entscheiden, was zu tun ist.
Beispiel:
Man stelle sich vor, man hätte ein Konto bei der Bank ‘XY’ und auch ein Matrix-Chatkonto. Eines Tages erhält man die Nachricht: „Unerwartetet Geldeingang auf Konto bei Bank XY - bitte prüfen: https://bankXY.tld” (gerne mal testen!)
Formatierte Texte per Markdown sind gut für Textdaten in einem Kontext, in dem man Zeit zum Lesen hat und etwas Zeit erübrigen kann, um auch den Link zu untersuchen. Aber für ein Kommunikationsmittel, das sich durch „sofort“ als Haupteigenschaft auszeichnet, ist es auf Protokollebene problematisch.
Gründe für Matrix
Die Entscheidung zu einem neuen Protokoll und der Entstehung von Matrix wurde 2012 durch verschiedene Argumente begründet. Diese Punkte hätten lt. Verfechtern von XMPP direkt auch am kritisierten Protokoll (XMPP) verbessert/ergänzt werden können, statt ein neues Protokoll zu kreieren:
… es ist besser, Bestehendes zu verbessern anstatt das Rad neu zu erfinden …
Investoren erwarten jedoch i.d.R. nach einer gewissen Zeit einen ROI (return of investment). Die Investitionen sollen sich natürlich lohnen und das ist bei der Verbesserung eines öffentlichen Standards nicht möglich.
Trotzdem haben sich viele Punkte beim damals (zu Recht) bemängelten Standard XMPP verbessert und „erledigt“ - obwohl keine Millionengelder geflossen sind:
- Mehrere Geräte,
- nutzbar auf mobilen Geräten,
- mehrere Geräte sind möglich,
- Verlaufsynchronisierung,
- es gibt Brücken zu anderen Systemen
Und: Die damals bemängelte Fragmentierung findet nun auch schon bei Matrix statt, so wie das bei dezentralen Systemen ganz natürlich ist.
Zusammenfassung/Fazit
**Matrix ist eine sehr gute Lösung für verteilte Arbeit IN (aber nicht zwischen!) Organisationen, Unternehmen oder Behörden!** Im Gegensatz zu manch anderer Groupware wie z.B. Slack ist der komplette Quellcode offen und somit überprüfbar. Interoperabilität ist meiner Meinung nach bei Matrix nicht durch offene Föderation mit anderen Matrix-Instanzen möglich, sondern lediglich durch die Verwendung der Schnittstelle zu Chatstandard XMPP.
Das Standardprotokoll, das WhatsApp tatsächlich mittelfristig in der Breite ersetzen kann, ist aus heutiger Sicht und mit diesem Hintergrundwissen nicht das Protokoll Matrix sondern anbieterunabhängier Chat (auf der Basis des Standards XMPP).
Daß es Schnittstellen (Brücken) zu standardisiertem Chat gibt, ist jedoch ein großer Vorteil von Matrix, der nicht zu unterschätzen ist. Diese Schnittstelle sollte jedoch:
- deutlicher kommuniziert,
- unbedingt auch aktiviert,
- an manchen Stellen noch verbessert,
- ohne inhaltliche Änderungen an Nachrichten umgesetzt und
- in der Praxis genutzt werden
… aus Sicht einer generellen Interoperabilität ist diese Brücke sogar wichtiger als die matrixinterne Föderation. Nicht durch eine öffentliche Föderation von Matrix-Servern sondern durch Aktivierung und Nutzung der wichtigen Brücke zu standardisiertem Chat - also durch das Einhalten von internationalen Standards - wird tatsächliche Interoperabilität unterstützt und ermöglicht.
Weitere Meinungen
Auch wenn evtl. manche Punkte in den folgenden (kritischen) Artikeln in der Zwischenzeit behoben sind, dürfen diese dennoch nicht als Ganzes verteufelt werden:
koehntopp.info: The Matrix Trashfire (extern)
Der Co-Founder von Matrix ist auf den Artikel bei lobste.rs (extern) eingegangen.
telegra.ph: Why not matrix? / 2023 (extern)
Zu deren Punkt 11 und 12: Diese müssten sich mittlerweise lt. Matrix-Spezifikationen (ab Raum-Version 6) erledigt haben, wurde in einem Forum berichtet. Hier würden mich konkretere Informationen interessieren. Bei Sachkenntnis gerne melden: >> Kontakt <<
Zu deren Punkt 17: Ein Ausschalten des Servers reicht tatsächlich nicht; das ist lt. Spezifikation aber so gewollt. Ein Raum kann jedoch in einer Föderation durch den Admin des Raumes (oder dessen Serveradmin) geschlossen werden - entweder durch das Kicken aller Personen im Raum oder dem Entziehen der Berechtigungen. Alle wohlgesonnenen Server, die föderieren, werden das respektieren.
cr-online.de: Fehler in der Matrix / 2022 (extern)
nuegia.net: Why I don’t use Matrix / 2020? (extern)
hackea.org: Matrix? No, thanks / 2020 (extern)
Auf die Frage, ob es inhaltliche Rückmeldungen auf den Artikel gab, kam per E-Mail (31.03.2024⁄02.04.2024) folgende Antwort:
„Wir haben einige wenige Nachrichten dazu erhalten, die im Wesentlichen besagten, dass ihnen der Artikel nicht gefiel, aber keiner konnte beweisen, dass etwas falsch oder ungenau war.“ und
„Dem Bericht zufolge mussten Sie keine Unterhaltung oder einen Chatroom mit einem Benutzer von matrix.org zu haben, damit Ihre selbst gehostete Instanz all diese Mengen an Metadaten an matrix.org und vector.im zu senden, Ihre selbst gehostete Instanz hat sie ohnehin gesendet. Wir schreiben in der Vergangenheitsform, weil wir das wissen, vielleicht passiert es noch vielleicht passiert das auch heute noch, wir wissen es nicht.“
(maschinell aus dem Englischen übersetzt)
Gerne werden hier weitere korrigierende Hinweise mit aufgenommen! >> Kontakt <<
Datum: 18.11.2024
Rechte: CC BY-SA
Autoren: Diverse (Initiative Freie Messenger)
Alle Artikel/Gedanken rund um das Thema Messenger:
Inhalt
Allgemein
Evgeny Poberezkin (extern) ist der Gründer von SimpleX Chat - einer Messaging- und Anwendungsplattform, die ohne jegliche Benutzerkennungen auskommt. Nicht einmal Zufallszahlen werden zur Identifizierung von Benutzerprofilen verwendet.
Werbeversprechen
SimpleX ist 100% privat, by Design!
Der erste Messenger ohne Benutzerkennungen
Die privateste und sicherste Chat- und Anwendungsplattform.
SimpleX Chat ist die nächste Generation der dezentralen Kommunikation, die zur Abwechslung mal NICHT auf Kryptowährungen basiert.
Auf der Projektseite ist ein interessanter Vergleich zu anderen Protokollen (extern) und auch in den FAQ (extern) gibt es dazu Informationen:
Was ist der Unterschied zu Matrix, Session, Ricochet, Cwtch usw., die ebenfalls keine Benutzeridentitäten erfordern?
Obwohl diese Plattformen keine echte Identität erfordern, stützen sie sich auf anonyme Benutzeridentitäten, um Nachrichten zu übermitteln - dies kann z. B. ein Identitätsschlüssel oder eine Zufallszahl sein. Die Verwendung einer dauerhaften Benutzeridentität, auch wenn sie anonym ist, birgt das Risiko, dass der Verbindungsgraph des Benutzers den Beobachtern und/oder Dienstanbietern bekannt wird, und kann dazu führen, dass einige Benutzer deanonymisiert werden. Wenn dasselbe Benutzerprofil verwendet wird, um sich mit zwei verschiedenen Personen über einen anderen Messenger als SimpleX zu verbinden, können diese beiden Personen bestätigen, dass sie mit derselben Person verbunden sind - sie würden in den Nachrichten dieselbe Benutzerkennung verwenden. Bei SimpleX gibt es keine gemeinsamen Metadaten zwischen Ihren Unterhaltungen mit verschiedenen Kontakten - eine Eigenschaft, die keine andere Messaging-Plattform hat.
Einschätzung
Die pauschale Formulierung “privateste und sicherste Chat- und Anwendungsplattform” ist ein Extrem und läßt wie immer aufhorchen. Es sollte tatsächlich jeder für sich selbst prüfen, ob das “privateste und sicherste” tatsächlich den eigenen Anforderungen entspricht. Denn es gibt viele mögliche Kriterien zur Sicherheit und Privatsphäre/Anonymität, die jeder individuell sehen und unterschiedlich bewertet werden kann! Insgesamt ist SimpleX jedoch trotzdem sehr interessant.
Konzept
SimpleX ist ein relativ junger Messenger mit einem unkonventionellen Konzept zur Vermeidung von Metadaten. Benutzerprofile, Kontakte und Gruppen werden nur auf dem Client und nicht auf einem Server gespeichert.
Um das Abgreifen einer kompletten Konversation auf dem Verbindungsweg zu erschweren, sind Verbindungen nicht bidirektional. Das bedeutet, daß über eine Verbindung Nachrichten entweder nur gesendet oder nur empfangen werden können. Zur Kommunikation sind somit 2 voneinander unabhängige Verbindungen erforderlich und die beteiligten Server bekommt jeweils von den Nachrichten in die andere Richtung nichts mit. Diese Sicherheit hat jedoch nichts mit Anonymität zu tun!
Bewertung
- positiv: es gibt keine Benutzerkennungen, so wie das bei anderen Systemen der Fall ist!
- positiv: gute Ende-zu-Ende-Verschlüsselung mit „doppelter Ratsche (double ratchet)“
- Vollständige Unabhängigkeit von Anbietern („providern“). Also nicht nur in dem Sinne, daß man (wie bei Mastodon oder XMPP) auch mit Nutzern (sowie der Software) anderer Anbieter kommunizieren kann. Sondern eben auch in dem Sinn, dass das Konto (besser das Gerät für den Zugang) nicht an einen Anbieter gebunden ist.
- positiv: Messaging-Apps für Konsole (Desktop), iOS und Android
- positiv: Client ist durchgängig quelloffen
- positiv: Client für Smartphone, Desktop und auch Terminal
- positiv: Server ist durchgängig quelloffen
- positiv: eigene Server sind möglich (und erwünscht)
- positiv: unterschiedliche (eigene) Anzeigenamen für jeden Kontakt im Inkognito-Modus
- positiv: kein Google reCAPTCHA (Infos: https://dr-dsgvo.de/google-recaptcha (extern))
- positiv: ohne Mindestalter nutzbar
- positiv: Authentifizierung des Kommunikationspartners ist möglich
- positiv: keine Kryptowährung
- positiv: einfache Textformatierung durch Markdown
- positiv: tragbare verschlüsselte Datenbank - das Profil kann auf ein anderes Gerät verschoben werden
- positiv: keine Tracker in der Android-App (16 Berechtigungen): Exodus (extern)
- positiv: lt. webbkoll (extern) keine Cookies von Dritten auf der Internetseite
- positiv: deutsche Projektseite/Hilfe
- neutral: Interoperabilität bzw. eine Schnittstelle zum Chatstandard XMPP ist designbedingt nicht gewünscht/möglich
- pos./neg.: externe Sicherheitsprüfung (Audit) (extern; PDF) (audit), die im November 2022 veröffentlich wurde - ist jedoch kein „full audit“
- pos./neg:: „Simplex ist eine relativ neue Entwicklung (die Apps wurden im März 2022 veröffentlicht)“ (extern)
- negativ: lt. webbkoll (extern) 2 Drittanfragen (third-party) auf der Internetseite
- negativ: Audio- und Videotelefonie sind nur möglich, wenn kein Tor verwendet wird
Funktionsweise
Kennung/ID
Die Identität, das Profil, die Kontakte und Metadaten sollen dadurch geschützt werden, daß es im Gegensatz zu anderen Messaging-Plattformen keine Identifikatoren gibt, die den Benutzern zugeordnet werden. Es werden weder Telefonnummern, Domain-basierte Adressen (wie E-Mail oder XMPP), Benutzernamen, öffentliche Schlüssel oder sogar Zufallszahlen verwendet, um Benutzer zu identifizieren. Niemand weiß, wie viele Leute die SimpleX-Server benutzen.
The first messenger without user IDs
Other apps have user IDs: Signal, Matrix, Session, Briar, Jami, Cwtch, etc.
SimpleX does not, not even random numbers.
Das stimmt - allerdings werden für Verbindungen dann doch Kennungen benötigt:
uses temporary anonymous pairwise identifiers of message queues, separate for each of your connections — there are no long term identifiers.
Es gibt also keine Benutzerkennungen wie bei anderen Systemen - die Art und Weise der verbindungsbezogenen Kennungen bzw. das Konzept ist jedoch in der Tat einmalig und verspricht nicht umsonst mehr Privatsphäre.
Da es keine feste/serververwaltete Benutzerkennungen oder Chatkonten gibt, werden beim Aufbau eines Chats Ende-zu-Ende verschlüsselte Sitzungen zwischen zwei SimpleX Clients eingerichtet. Die Server schieben nur die Datenpakete von A nach B durch das Netz und ermöglichen den Austausch von Offlinenachrichten.
Darüber hinaus gibt es die Möglichkeit, mit der SimpleX-Desktop-App direkt die Profile vom mobilen Gerät zu verwenden. Das ist allerdings nur möglich, wenn sich beide Geräte im selben Netzwerk befinden - ein wirkliche Synchronisation zwischen den Geräten (wie beim Chatstandard XMPP) gibt es jedoch nicht.
Kontakte hinzufügen
Das Hinzufügen von Kontakten (extern) kann per einmaligen Einladungslink/QR-Code geschehen, der dann über einen anderen Kanal wie E-Mail versendet wird - oder mann kann seine SimpleX-Kontaktadresse als QR-Code teilen, was eine Mehrfachverwendung ermöglicht.
Nachrichtenübermittlung
Da es keine klassischen Benutzerkennungen/Chatkonten gibt, gibt es auch keine Verifikation von Kommunikationspartnern. Um sicherzustellen, dass man wirklich mit dem gewünschten Gesprächspartner verbunden ist, kann der Aufbau einer Chat-Verbindung durch Scannen eines One-Time-QR-Code bei einem persönlichen Treffen erfolgen oder durch Versendung einer Einladung über einen sicheren, verifizierten Kanal.
Um Nachrichten zu übermitteln, verwendet SimpleX temporäre, anonyme, paarweise Identifikatoren von Nachrichten-Warteschlangen, getrennt für empfangene und gesendete Nachrichten - es gibt keine langfristigen Identifikatoren. Die Nutzung ist quasi so, als ob für jeden Kontakt eine eigene E-Mail oder ein eigenes Telefon genutzt würde.
Nachrichten werden per doppelter Ratsche Ende-zu-Ende-verschlüsselt und über offengehaltene Verbindungen per „push“ übertragen.
Server
Systembedingt werden für ein- und ausgehende Nachrichten getrennte Verbindungen benutzt und hierfür können unterschiedliche Server (SMP-Relays) verwendet/vorgegeben werden. Damit man Nachrichten erhält, verbindet sich der eigene Server (genauer: ein Server aus der eigenen Serverliste) mit einem Server aus der Liste des Kommunikationspartners - auch dann, wenn diese Adresse nicht in der eigenen Serverliste steht. Jeder kann nur seinen eigenen Empfangs-/Sende-Server definieren.
In der App sind zwar Server vorkonfiguriert - man kann jedoch einen beliebigen anderen SimpleX-Server oder auch einen selbst betriebenen SimpleX-Server eintragen. Man kann also selbst festlegen welcher Server für den Empfang der Nachrichten verwendet werden soll und jede Konversation kann so auf zwei verschiedene und voneinander unabhängige Server aufgeteilt werden.
Um die eigene IP-Adresse vor dem Empfänger zu verbergen ist es jedoch sinnvoll, für den Versand nicht einen eigenen privaten SMP-Server zu verwenden (der ja wieder zugeordnet werden könnte), sondern einen der SMP-Standard-Server.
Offlinenachrichten
… sind möglich. Die Zustellung von Offlinenachrichten (mehr Infos dazu bei Github (extern)) erfolgt über individuelle „Relay-Server“:
SimpleX speichert alle Benutzerdaten auf den Client-Geräten, die Nachrichten werden nur temporär auf den SimpleX-Relay-Servern gehalten, bis sie empfangen werden. …
Ist der Empfänger nicht gleichzeitig online, so werden die Nachrichten auf einem SMP-Server bis zur Abholung/Löschung maximal 21 Tage zwischengespeichert, danach verworfen. Größere über XFTP geroutete Dateien werden maximal 48 Stunden zur Abholung beim XFTP-Server aufbewahrt. Die Aufbewahrungswerte können von Serverbetreibern für ihre eigenen SMP-/XFTP-Server verändert werden.
Push-Benachrichtigung
Dieser Blog-Beitrag behandelt das Design für Benachrichtigungen auf den Plattformen Android und iOS: https://simplex.chat/blog/20220404-simplex-chat-instant-notifications.html (extern)
In der Kürze:
Android: SMP-Server pushen die Nachrichten selbst, es werden keine Metadaten mit anderen Diensten geteilt, und es wird nichts verwendet, was nicht mit unseren Apps selbst gehostet werden kann.
iOS: Erfordert einen dedizierten Benachrichtigungsserver pro App, der ein Gerätetoken hat und einige Metadaten beobachten kann; Benutzer können ihn nur selbst hosten, wenn sie die App modifizieren und die App bei Apple registrieren (sie muss nicht im App Store sein, und Apple mag dort eigentlich keine Kopien, sie kann intern für eine Gruppe von Benutzern / Unternehmen sein - es gibt keinen Genehmigungsprozess für solche Apps).
Technischer Hintergrund bei iOS
Damit Sofortbenachrichtigungen unter iOS funktionieren, muß der Benutzer bei der Anmeldung entscheiden, ob Push-Benachrichtigungen verwendent werden sollen. Falls ja, erfolgt beim Starten der App eine DNS-Anfrage an den iOS-Push-Benachrichtigungsserver (ntf2.simplex.im / 139.162.221.251). Das ist nicht abschaltbar.
Der Entwickler schreibt dazu (per E-Mail): Es ist ein Kompromiss zwischen Privatsphäre und Bequemlichkeit. Für sicherheits- und datenschutzrelevante Szenarien sollte iOS eigentlich nicht verwendet werden.
Expertenwissen
Dieser Abschnitt zur Anonymität ist speziell für technisch Interessierte: Nur lesen, wenn einem die Begriff wie IP-Adresse, Hop, Relais etwas sagen - sonst verzweifelt man!
Verkehrsanalyse
Unter (Daten-)Verkehrsanalyse wird die Analyse des Datenverkehrs verstanden, um doch Metadaten (wer, wann mit wem, wie lange oder auch nicht kommuniziert hat) zu erlangen. Eine solche Analyse ist bei dem für mich als Laien als vorteilhaft gesehene Trennung von Sendeweg und Empfangsweg anscheinend jedoch potentiell einfacher als bei unidirektionaler Kommunikation. Dafür ‘paddet’ SimpleX jede Nachricht (auch beim Schlüsseltausch) auf die selbe Länge (16k Zeichen), was wiederum sehr gut ist.
Um die eigene IP-Adresse zu schützen, gibt es dafür folgende Lösung:
2-Hop-Routing mit vom Absender gewählten Sende-Relais und vom Empfänger gewählten Empfangs-Relais …
Es löst nicht nur den Schutz von IP-Adressen, sondern verbessert auch das Bedrohungsmodell für Absender, da die empfangenden Relays keine Sitzungen mehr mit den Absendern haben und keine gemeinsamen Metadaten zwischen verschiedenen Nachrichten-Warteschlangen (vorausgesetzt, die sendenden Relays geben die Daten nicht an die empfangenden Relays weiter).
Entwicklung
Es gibt häufig neue Funktionen und Updates; es wird zügig auf gemeldete Punkte oder Benutzerwünsche reagiert. Aus der Vision (extern) von SimpleX:
In Zukunft planen wir, die grundlegende Nutzung der Plattform kostenlos zu halten und gleichzeitig die Vorteile für die Projektsponsoren bereitzustellen. Zum Beispiel wird es zusätzliche App-Symbole und Benutzerprofilabzeichen geben. Außerdem wird es höhere Limits für den Dateitransfer geben - derzeit beschränken wir ihn überhaupt nicht, sondern nur die Dateigröße, aber das ist wahrscheinlich nicht nachhaltig. In jedem Fall wird die App weiterhin für jedermann kostenlos nutzbar und vollständig quelloffen sein. Mehrere andere Apps werden bereits auf der Grundlage unseres App-Kerns entwickelt, was zu einem vollständig dezentralisierten Netzwerk führen wird.
Der Entwickler hat eine eigene Auffassung zur Privatsphäre und definiert diese neu. Privatsphäre ohne Risikokapital wäre nicht möglich:
https://www.poberezkin.com/posts/2022-12-07-why-privacy-needs-to-be-redefined.html
https://www.poberezkin.com/posts/2023-10-31-why-privacy-impossible-without-venture-funding.html
Es sind weitere Funktionalitäten geplant wie:
- SMP queue redundancy and rotation (manual is supported)
Auch bei bestehenden Kontakten können durch eine automatische Rotation zufällige Server genutzt werden, was die Nachverfolgung der Kommunikation weiter erschweren wird.
- Large groups, communities and public channels
Die jetzigen Gruppen sind eigentlich nur für kleinere Teilnehmerzahlen gedacht.
- Feeds/broadcasts
- Web widgets for custom interactivity in the chats
- Programmable chat automations / rules (automatic replies/forward/deletion/sending, reminders, etc.)
Sitz
Die SimpleX Chat Ltd wurde am 20.10.2021 gegründet und hat den Sitz in Londen (20-22 Wenlock Road, London N1 7GU).
Verweise
Projektseite: https://simplex.chat/de (extern)
Quellcode: https://github.com/simplex-chat (extern)
F-Droid: https://f-droid.org/de/packages/chat.simplex.app/ (extern)
Aktueller Stand/Planung: Roadmap (extern)
Zum SimpleX-Protokoll: Dokumentation (extern), Github (extern)
Vergleich mit anderen Protokollen: Github (extern) und Diskussion dazu bei Reddit (extern)
Zum Angriffsszenario: Thread-Modell (extern)
Bericht und Kurztest von Kuketz (extern)
Im Privacy-Handbuch (extern) wird SimpleX als „Exot mit besonderen Privacyfeatures“ geführt.
Fazit
SimpleX wird stark entwickelt und ist ein Messenger, der gewisse Vorteile von serverbasierten Systemen (Offlinenachrichten) und serverlosen Systemen (Anonymität) verbindet.

„E-Mail“ kennt man doch von früher - und damit kann man modern „texten“? Ja!
Das Kommunizieren mit formlosen Nachrichten geht sogar wunderbar und einfach (für formale E-Mails ist jedoch ein klassischer E-Mail-Client besser geeignet).
Als Vorzeigeprojekt mit moderner Messengeroptik hier gilt „Delta Chat“ - es gibt jedoch auch andere Projekte wie „Dib2Qm“.
Zu anderen Messsengersystemen gibt es jedoch wesentliche Unterschiede:
pro: Riesige Erreichbarkeit (weltweit alle E-Mail-Adressen)
pro: Es wird kein sozialer Druck aufgebaut, ein bestimmtes Programm zu installieren. Stattdessen kann mit jeder beliebigen E-Mail-Adresse kommuniziert werden, ohne daß der Empfänger dasselbe oder ein spezielles Messenger-Programm benötigt.
kontra: Keine Anzeige, ob die Kontakte online/offline sind.
kontra: Nur Gruppenverteiler - keine wirklich administrierbaren Chaträume
Spot-On
Spot-On hat E-Mail-Texting lange vor Delta Chat und anderen eingeführt. Es heißt Poptastic und ist seit 2014 verfügbar. Poptastic umfasst SMP, Weiterleitungsgeheimnis, Schlüsselerneuerung und Statusinformationen. Es ist in das Desktop-Programm Goldbug bzw. der Android-App Smoke integriert.
Delta Chat
Die App sieht aus und funktioniert wie ein klassischer Messenger, nutzt jedoch die bewährte E-Mail-Infrastruktur u.a. mit den standardisierten und
offenen Protokollen „IMAP“ und „SMTP“.
Empfehlung: |
Falls bereits ein privater PGP-Schlüssel mit dem normalen E-Mail-Programm genutzt wird, sollte dieser Schlüssel aus Sicherheitsgründen nicht auf ein Smartphone kopiert werden.
Besser ist es, den von Delta Chat automatisch neu erstellten Schlüssel zu exportieren und als zusätzlichen Schlüssel in das E-Mail-Programm zu importieren.
oder als weitere Alternative ein separates E-Mail-Konto nur für Chatzwecke einrichten! |
Neben Apps für Android und iOS gibt es auch Desktop-Versionen für Windows, GNU/Linux und MacOS. Allerdings ist diese eine Electron-Anwendung Es ist möglich, sog. „chat bots“ für DeltaChat einzurichten: https://github.com/deltachat-bot/deltabot (extern) oder https://github.com/simplebot-org (extern).
Startseite des Projektes: https://delta.chat/de/ (extern)
Aktuelle Versionshinweise (englisch): https://delta.chat/en/changelog (extern)
Welche Bezugsquelle?
Anbieter
Delta Chat basiert auf standardisierten Protokollen - trotzdem kann es sein, dass es bei manchen E-Mail-Anbietern (Providern) Probleme gibt oder Chatten - aus welchen Gründen auch immer - nicht möglich ist. Hier eine (englischsprachige) Übersicht von Anbietern, die mit Delta Chat genutzt werden können:
https://support.delta.chat/t/provider-overview (extern)
Standards
Neben den bekannten Protokollen „IMAP“ und „SMTP“ verwendet Delta Chat auch diverse andere:
https://github.com/deltachat/deltachat-android/blob/master/standards.md#standards-used-in-delta-chat (extern)
Variante
Mit DeltaLab (extern) gibt es eine Variante („fork“) von Delta Chat, die um verschiedene Funktionen ergänzt wurde:
- Unterstützung von Markdown
- Unterstützung für Sticker mit Lottie-Animationen
- Pseudo-Online-Status-Indikator, um einfach zu wissen, wann ein Peer kürzlich gesehen wurde (verrät nicht den Online-Status, sondern basiert auf dem letzten Empfang einer E-Mail vom Kontakt)
- Unterstützung für SVG-Bildvorschauen
- Mehrere Farbthemen/Skins
- Option zum Löschen/Leeren aller Nachrichten in einem Chat
- Videochat-Instanz standardmäßig eingestellt
- Eingehende Gruppen und Mailinglisten sind standardmäßig stummgeschaltet
- Antworten auf Ihre Nachrichten in stummgeschalteten Gruppen lösen Benachrichtigungen aus
- Mehr Kaomoji-Emoticons
- Das Verifizierungssymbol wird in der Chatliste für verifizierte Kontakte und im Chat “Gerätenachrichten” angezeigt
- Videos werden in einer Schleife abgespielt, nützlich für kurze GIF-Videos
- Es ist möglich, OPENPGP4FPR: und mumble: Links in Nachrichten anzuklicken
- Option zur Deaktivierung des automatisch generierten E-Mail-Betreffs, der von Delta Chat festgelegt wurde
- Wenn Sie eine Nachricht auswählen, haben Sie zusätzliche Optionen, um den Absender einfach aus der aktuellen Gruppe zu entfernen/hinzufügen
- Sprachnachrichten haben eine stärkere Kompression / niedrigere Qualität, um Daten zu sparen
- Standardkonfiguration geändert: alle E-Mails werden standardmäßig angezeigt, Nachrichten werden sofort aus der INBOX gelöscht, um die INBOX sauber zu halten, Medienqualität auf schlechter eingestellt, um Datenvolumen zu sparen, automatischer Download von Nachrichten auf 160KB begrenzt, nur der INBOX-Ordner wird überwacht
Quelle: IzzyOnDroid (extern)
Projektseite: https://github.com/adbenitez/deltalab-android (extern)
Sonstiges
Verweise auf externe Informationen:
- Aufzählung von Vor- und Nachteilen: hasecke.eu (extern)
- Einschätzung Mike Kuketz (extern) vom 12.07.2017.

Interessantes Zusatzwissen
Serverliste E-Mail-Anbieter
In der folgenden Übersicht (Bildschirmkopie Stand 15.12.2018) finden sich viele technisch relevante Informationen zur Sicherheit von E-Mail-Anbietern:
Quelle / zur aktuellen Übersicht: https://dismail.de/serverlist.html (extern)
Verschlüsselung
Eine Verschlüsselung für E-Mail einzurichten und den öffentlichen Schlüssel anderen zur Verfügung zu stellen ist nicht schwer …
Sicherheit
Passwörter
- Prüfen, ob Passwort für das E-Mail-Konto in öffentlichen Listen ist: beim Hasso-Plattner-Institut (extern)
- Hintergrundinformationen dazu bei Kuketz (extern)
= = = Servergestützt = = =
- Lesezeit: 1 Minute / ganze Rubrik: 24 Minuten - |
Abgrenzung:
- Serverbasierte Messengersysteme („Bedingung“) benötigen für die Nutzung entsprechende Server - z.B. für die Kontaktliste, Nachrichtenweiterleitung, Gruppen oder Chatraumverwaltung.
- Servergestützte Messengersysteme („Möglichkeit“) funktionieren grundsätzlich auch ohne Server - jedoch können für Spezialfunktionen (wie Zwischenspeicherung von Nachrichten) Server in Anspruch genommen werden.
- Serverlose Messengersysteme („Verzicht“) sind komplett dezentral und ohne spezielle (weitere) Server organisiert.
Übersicht
Echo-Protokoll
Das Echo-Protokoll wird z.B. von Goldbug (Desktop-Client) oder Smoke (Android-Client) genutzt und ist Hauptbestandteil vom „Vergleich der großen 7 (quelloffenen) Messengersysteme“. Das Projekt wird ausschließlich von Freiwilligen gestemmt und wird nicht von Dritten bezahlt.
In der Kürze: Sehr interessant, umfassend, schlüssig. Leider jedoch viele Spezial- und Fachbegriffe; viele abstrakte und auch merkwürdige Bezeichnungen in den Erklärungen (Moleküle, …) ; wirkt für Nomalnutzer auf den ersten Blick unübersichtlich und kompliziert. Bisher noch kein Kontakt zu deutschem Ansprechpartner möglich / kein deutsches Forum.
- Dezentralität: direkt/vermascht (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- positiv: deutsches Benutzerhandbuch
- negativ: KEINE deutsche Projektseite
Mehr Informationen: >> hier <<
Scuttlebutt
Das Protokoll „SecureScuttlebut /SSB“ (kurz: Scuttlebutt) hat einen ebenfalls sehr interessanten Ansatz und setzt auch auf Dezentralität.
- Dezentralität: direkt (P2P, keine separaten Server erforderlich)
- positiv: gewisse Anonymität
- positiv: geniales Konzept (spezialisiert auf Offline-Funktionalität)
- positiv: eingebaute Untestützung für TOR
- negativ: KEINE deutsche Projektseite/Hilfe
- negativ: Anfangs muss man sehr große Datenmengen herunterladen
- negativ: Maximal 7 Teilnehmer bei „geschlossenen Gruppen“
Mehr Informationen: >> hier <<
Allgemein
Das Protokoll wird z.B. von Goldbug (Desktop-Client) oder Smoke (Android-Client) genutzt, und ist Hauptbestandteil vom „Vergleich der großen 7 (quelloffenen) Messengersysteme“. Das Projekt ist wird ausschließlich von Freiwilligen gestemmt und wird nicht von Dritten bezahlt.
In der Kürze: Sehr interessant, umfassend, schlüssig. Leider jedoch viele Spezial- und Fachbegriffe; viele abstrakte und auch merkwürdige Bezeichnungen in den Erklärungen (Moleküle, …) ; wirkt für Nomalnutzer auf den ersten Blick sehr technisch, unübersichtlich und kompliziert.
GoldBug ist quasi eine Oberfläche (skin/theme) für den Programmkern „Spot-On“. Das deutsche Marjorie-Wiki (extern) beschreibt Goldbug wie folgt:
GoldBug ist ein quelloffener sicherer Messenger und E-Mail-Klient sowie auch eine Internet- bzw. URL-Datenbank-Suchmaschine basierend auf dem Netzwerkprotokoll namens Echo und dem Programmkern Spot-on (spot-on.sf.net). Die beiden Grundfunktionen des Internets und seiner Nutzer – Kommunikation und Websuche – werden somit durch diese Applikation abgebildet.
Es gibt zwar keine deutschsprachige Übersetzung der Projektseite - aber ein sehr ausführliches deutsches Benutzerhandbuch (s.u.). In Smoke und Spot-On gibt es Standard-Chaträume („channel“) die dort „Fire“ bzw. „Buzz“ heißen. Ein “Buzz” ist ein “ge-echo-ter IRC Channel” (e*IRC) -Raum.
Entwicklerworte
some interpretations of the Echo from the developper
The Echo is not a strict protocol. It itself does not specify a protocol. It is not contractual.
There are several implementations of the Echo: Smoke, SmokeStack, Spot-On, and Spot-On-Lite. Smoke, as an example, implements a TCP-like protocol through the Echo for file sharing. What does this mean? It means that two participants may share a file in a reliable manner without being connected directly.
[A] <-----> [B] <-----> [C] <- ... -> [X]. So, A publishes a file for X and Smoke guarantees that the transfer completes. The Steam protocol works within the Echo. It is TCP implemented through a network of applications (nodes). The [K] nodes may be Smoke, SmokeStack, Spot-On, Spot-On-Lite or something else capable of Echoing.
Spot-On-Lite introduced cryptographic routing so that specific Smoke clients receive their intended data. SO-Lite does this through inspecting special digests which Smoke clients attach to their messages. When a
message is published, a non-secret digest is attached to it. This digest instructs SO-Lite nodes to direct their inbound packets to their intended destinations. If a Smoke client attaches to an SO-Lite node, it provides the node with its pseudo-identity. The SO-Lite node shares this identity through the network so that other nodes are capable of addressing messages to their correct destinations.
Spot-On introduced the concept of the Adaptive Echo. Without too much detail, this subset of the Echo allows SO nodes to be programmed with secrets so that data from a Spot-On node is only forwarded to nodes which are aware of the secrets. This arrangement creates an exclusive sub-network.
Spot-On also introduced streaming of application data through itself. A sort of private proxy. For example, it is possible to transfer a file through SO using an application which does not offer TLS by configuring two so nodes such that both nodes are aware of the same secret. One application can write data to a local SO node while the counterpart SO node in some other network receives the ciphertext and writes the plaintext to a separate and local application.
Smoke and SmokeStack are exclusive to Android. SO and SO-Lite are available for just about any platform.
Weitere Erläuterungen des Entwicklers (Alias ‘textbrowser’):
Ich finde das Echo einfach und großartig. Ich kann einen Server in wenigen Sekunden vorbereiten und zwei Geräte in wenigen Minuten oder weniger miteinander kommunizieren lassen (das hängt von den Geräten ab). Das Echo funktioniert einfach. Ich muss keine Server, Konten usw. konfigurieren. Außerdem ist es sehr flexibel.
Als ich den öffentlichen Server finanziert habe, war meine Schnittstelle von zu Hause aus ein Raspberry Pi. Geräte von zu Hause aus wurden mit diesem verbunden und manchmal auch mit einem separaten Rechner, der mit dem Pi verbunden war. Der Pi stellte dann eine Verbindung zum Remote-Server her. Leider gibt es nicht viele (oder gar keine) Dienste, die auf Raspberry Pis laufen, so dass auch das ein interessanter Test gewesen wäre. Es wurden viele Szenarien getestet, und diese Experimente sind wahrscheinlich nirgends erwähnt. Eine weitere Idee des Echo ist, dass es die Erkundung unterstützt.
Das Echo ist transparent. Es erfordert keine spezielle Software. Es ist natürlich erweiterbar. Ich denke, es braucht Fantasie bei der Implementierung :) Es gibt vier verschiedene und ähnliche Implementierungen: Smoke, SmokeStack, Spot-On, Spot-On-Lite. Sie arbeiten alle zusammen, ungeachtet ihrer Unterschiede. Das ist ein weiteres Konzept des Echo. Dinge, die es implementieren, sollten sich nicht um andere Produkte im Netzwerk kümmern. Natürlich ist es nicht grenzenlos.
Berichtigung. Die Implementierungen sind begrenzt. Das Echo? Keiner weiß es.
Original:
I think the Echo is simple and splendid. I can prepare a server in a few seconds and have two devices communicating with one another in a few minutes or less (depends upon the devices). The Echo just works. I do not have to configure servers, accounts, etc. It’s also quite flexible.
_When I was funding the public server, my interface from home was a Raspberry Pi. Devices from home would connect to it and sometimes to a separate machine connected to the Pi. The Pi would connect to the remote server. Unfortunately, there are not many (or any) services which live on Raspberry Pis so that would have been an interesting test as well. Many scenarios were tested and these experiments are probably not mentioned anywhere. Another idea of the Echo is that it endorses exploration.
The Echo is transparent. It doesn’t require special software. It’s naturally extensible. I think it needs imagination with implementation. :) It has four distinct and similar implementations: Smoke, SmokeStack, Spot-On, Spot-On-Lite. They all work together regardless of their differences. That is another concept of the Echo. Things that implement it should not care about other products in the network. Of course, it’s not boundless.
Correction. The implementations are bounded. The Echo? No one knows.
Verschlüsselung
Eine Analogie zur Verschlüsselung beim Echo-Protokoll:
Die Kryptographie des Echo-Protokolls kann verglichen werden mit dem Geben und Nehmen von Überraschungseiern. Bob gibt ein Überraschungsei an Alice, Alice öffnet es und verzehrt die Schokolade und stößt auf die Plastik-Kapsel im Inneren des Überraschungsei und versucht, diese zu öffnen und die darin befindlichen Teile zu einem Spielzeug, einem Schlumpf, zusammen zu bauen. Der Zusammenbau gelingt ihr aber nicht, der Schlumpf lässt sich nicht bilden und daher packt sie die Einzelteile wieder in die Plastik-Kapsel, gießt neue Schokolade drum rum und gibt das Ei an den Nachbarn weiter, der ebenso versucht, einen Schlumpf aus den Teilen zu basteln. Alice weiß nicht, wer das Überraschungsei bzw. den Schlumpf erfolgreich zusammenbauen kann, daher kopiert sie es (- welch ein Wunder, Alice hat eine Ü-Ei-Kopiermaschine - ) und gibt jeweils eine Kopie an alle ihre Freunde weiter. (Auspacken, basteln, anschauen, einpacken, verschenken und wieder auspacken, basteln, anschauen, einpacken, verschenken, und so fort … - Aus Sicht der im Netzwerk vertretenen Instanzen (Kernels) wäre in diesem Bild das Netz zum Ü-Ei-Paradies geworden, wenn nicht mit Congestion Control die Bastelvorgänge wieder reduziert würden. Einmal bekannte Bastel-Teile werden nicht ein zweites Mal zusammen gebaut). Alice bastelt so lange, bis sie einen Schlumpf mit roter Mütze erkennen kann, sie hat die für sie bestimmte Figur des Papa-Schlumpfs bzw. ihre Nachricht erhalten.
Offline-Nachrichten
Offline Nachrichten werden über die Funktion „Poptastic“ realisiert, wozu ein E-Mailkonto mit IMAP oder POP3 erforderlich ist.
Frage: Wie funktionieren Offline-Nachrichten?
Antwort:
Für Smoke gibt es „SmokeStacks“ und „Ozones“. Ozones sind Adressen. Ein oder mehrere Stacks können von identischen Ozones Kenntnis haben. Nehmen wir an, die Ozone ist blau und sagen wir, 10 Stacks kennen diese Ozone. In Smoke teile ich meine Schlüssel und er überträgt sie über die von Blue generierten Schlüssel. Ein Freund tut dasselbe. Unsere Nachrichten werden dann auf diesen erreichbaren Stacks aufgezeichnet. Spot-On hat Institutionen, aber der Prozess ist nicht so einfach. (übersetzt mit DeepL)
Frage: Wird für Offline-Nachrichten ein Server benötigt? Auf beiden Seiten?
Antwort:
SmokeStacks können sowohl Clients als auch Server sein. Wenn sie Clients sind, verbinden sie sich mit Dingen. Also nein. Zum Beispiel bin ich auf dem Mars und mein Freund ist auf der Venus. Die Stacks können sich auf dem Pluto, der Sonne und auf der Erde befinden. Wenn die Elektronen von unseren Geräten diese Stacks erreichen können, funktioniert alles wie erwartet. Ich brauche keinen eigenen Stack, und mein Freund auch nicht. Wir müssen auch nicht die Details der Upstream-Verbindung kennen. Stellen Sie sich vor, jemand konfiguriert eine Reihe von Stacks und betritt ein Echo-Netzwerk.
Deutsches Benutzerhandbuch: https://de.wikibooks.org/wiki/Goldbug (extern)
Deutsches Wiki: https://marjorie-wiki.de/wiki/GoldBug_(Instant_Messenger)/ (extern)
Englisches Benutzerhandbuch: https://compendio.github.io/goldbug-manual/ (extern)
Demonstration serverlose Kommunikation: >>Video<< (extern) (STUN nicht erforderlich)
Quellcode: https://sourceforge.net/projects/goldbug/ (extern)
Quellcode: https://textbrowser.github.io/spot-on (extern)
Android-Client (F-Droid): Smoke (extern)
Projektseite: http://goldbug.sf.net/ (extern)
Vorwort
Forever
free
No ads.
No pay wall.
No data centers.
No cloud. No cookies.
No company. No investors.
No token. No ICO. No blockchain.
No tracking. No spying. No analytics.
No tedious registration. No premium costs.
No annoying notifications, emails, and banners.
… treffend formuliert.
Allgemein
Ein soziales Netzwerk mit Messenger, das so konstruiert ist, dass es auch offline, über WLAN, Bluetooth oder gar USB-Speicherstick funktioniert. Das ist natürlich nichts für Sofortnachrichten (instant messenging), wie man das allgemein so kennt - aber dafür interessant, falls man mal keinen Internetzugang hat (am Schiff, längerer Strom/Netzausfall, z.b. wie beim Hochwasser). Man verpasst dann nichts, denn es synchronisiert sich nach, sobald man wieder Zugang hat, oder jemand im selben WLAN ist, der Zugang hatte.
Für wirklich kritische Kommunikation (Journalisten, Dissidenten, Geheimnisverräter (‘whistleblower’), …) ist Briar natürlich die bessere Wahl. Briar ist ähnlich - nur muss der andere gleichzeitig online sein. Scuttlebutt ist jedoch offlinefähig und dadurch verbindungsunabhängig. Das macht es besonders spannend.
Eine Meinung über SSB:
Ich habe die Idee so verstanden, dass man bewusst online geht und nachher wieder abdrehe - also ein Bierli mit Freunden im Pub, und dann nach Hause. Im Garten kann ich dann nachlesen, was sich bei den anderen so getan hat. Geschlossene Gruppen mögen nicht der primäre Anwendungsfall von ‘social’-Dingen sein. Anderseits sind die auch in Facebook schon sehr beliebt. Ich würde Scuttlebutt eher als Twitter-Ersatz sehen und finde es auch etwas problematisch, daß dein social Graph (mit wem man in Verbindung ist) sichtbar ist.
Hybrid statt reines P2P
Entwickelt hat es einer, der in Neuseeland am Segelschiff unterwegs ist und dort gibt es einfach kein Internet. Im Hafen wird dann synchronisiert, während er zu tun hat. Dann, wenn wieder Zeit ist, wird gelesen und geschrieben - denn reines P2P ist einfach unpraktisch, da man nur Nachrichten schicken/empfangen kann, wenn der andere online ist. Letztlich will man einfach Hybrid-Modelle statt reinem P2P: So wie bei den Funklöchern und dem „Surfvergnügen“ während des Bahnfahrens oder wenn man auf der Alm im Urlaub ist … das erfordert „hybrid“:
Also: P2P wenn möglich, Server wo nötig!
Bei den klassischen sogenannten „sozialen“ Medien darf jeder Depp rausschreien, was ihn gerade so stört. Und der Algorithmus spült es in die Timeline, wann immer man reinschaut. „Freedom of Speech“ heißt es dann. Das Internet ist laut geworden - ständig Benachrichtigungen immer und überall, ständig irgendwelcher Müll, der aufregt und dich aufwühlt.
Scuttlebutt gibt einem die „Freiheit des Zuhörens“.
Bei Scuttlebutt kant man nur mitmachen, wenn man eingeladen wird. Entweder in einen „Pub“ (geselliger Treff), einen Raum („room“) oder direkt von einer anderen Person. Man kann Nutzer blockieren, von dem und mit dem es dann keinerlei Nachrichtenaustausch mehr gibt. Und: Man tritt nur mit anderen Nutzern in Kontakt, denen man vertraut.
Konzeptionell
So sehr man den Chatstandard XMPP evtl. mag, man ist dort auch wieder abhängig von Servern - auch wenn es sogar ein eigener ist. Der Nachteil von serverbasierten Systemen ist, daß sämtliche Inhalte und Nachrichten mit der Datenbank des Anbieters stehen und fallen: Fällt diese aus, ist alles weg und das ist nicht prickelnd.
Scuttlebutt ist mehr als ein Messenger - das ist eher so ein Soziales Netzwerk, was XMPP nur bedingt kann (Libervia und Movim sind dort erste Ansätze, die auch sehr spannend sind) und grob vergleichbar mit einem lokalen Git-Repo, das mit anderen abgeglichen wird.
Scuttlebutt hat Pull-Benachrichtigung! Das hört sich in einer Welt, die vermeintlich ohne Push-Benachrichtigungen nicht funktioniert merkwürdig an, denn Push-Benachrichtigungen entsprechen der „Freiheit zu sprechen“. Jeder kann immer und überall sprechen und seinen Sermon in die Welt hinausbrüllen. Und jeder kriegts mit. Ständig klingelt das Smartphone oder bimmelt etwas am Desktop … ah, neue Nachricht - und schon ist man wieder abgelenkt.
Pull-Benachrichtigungen dagegen entsprechen der „Freiheit zuzuhören“. Soll jeder seinen Müll raustragen, wann und wohin er will - aber man selbst entscheidet, wann man ihn hören möchte. Und ob.
Eine Meinung zum aktiven Abrufen („Pull“) von Nachrichten am Beispiel der Telefonie:
Meine Mitmenschen leiden seit der Einführung der Mobiltelefonie in meinem Freundes/Bekanntenkreis darunter, dass ich selten abhebe. Klar, macht es das nicht immer einfach. Aber ich lebe das, seit ich ein Mobiltelefon habe (seit über 20 Jahren) konsequent so weiter, wie es noch zu Festnetzzeiten gewesen ist (ohne Anrufbeantworter wohlgemerkt! Mailbox deaktiviert). Wenn ich nicht daheim bin, kann ich gar nicht hören, dass du anrufst. Wenn es wirklich wichtig ist, ruf noch einmal an. Und wenn ich grad am Klo bin, heb ich auch nicht ab. Und im Zug telefoniere ich auch nicht gern, weil es niemanden etwas angeht, was ich mit dir spreche. Und im Supermarkt heb ich auch nicht ab. Das Einzige was mich interessiert ist: Hat jemand angerufen und wer, und eventuell noch wann? Dann kann ich zurückrufen, und mir die Info abholen (pull) die du für mich gehabt hast. Vielleicht gefällt mir deshalb Scuttlebutt so gut. :)
Funktionsweise
Grundsätzliches
Öffentliche Treffpunkte
Es gibt öffentliche Treffpunkte („pubs“) - also öffentlich in dem Sinne, dass sich jeder (mehrfach) ohne explizite Einladung (mit öffentlichem Einladungscode) registrieren/einklinken kann. Das System ist in der Tat sympathisch und „cool“ - gerade die Art und Weise des Austauschs von Offline-Nachrichten. Man schreibt auf seinem Geräte und wenn die Internetverbindung nicht funktioniert, kann man nichts posten und nichts Neues lesen - weder auf Facebook, noch auf Mastodon, noch auf Friendica. Aber durch diese Konzeption hat man zumindest die Möglichkeit, geschlossenere Gemeinschaften zu pflegen.
Der Austausch zwischen zwei Geräten gelingt direkt, wenn beide im selben Netzwerk sind; also beide im selben WLAN angemeldet oder per Bluetooth verbunden sind. Will man über das weltweite Netz kommunizieren, dann muss man in einen sogenannten „pub“ oder Raum („room“) gehen. So wie ich mit meiner Frau daheim plaudern kann, mich aber mit meinem Freund im „Pub” (der Kneipe / im Wirtshaus) treffen muß.
Man kann also öffentliche Pubs betreten, die quasi immer online sind. Diese haben einen Identifier, der die öffentlich erreichbare Adresse (domain oder IP+Port) und den öffentlichen Schlüssel (Public-Key) zur Verschlüsselung beinhaltet. Um mit anderen kommunizieren zu können, benötige ich einen Einladungscode mit diesen Informationen - man kommt also nur auf „Einladung“ rein. Und man kann nur mit Kontakten direkt kommunizieren, die ebenfalls in diesem Pub sind. Man entscheidet selbst, ob und wann man ins Gasthaus geht, sich dort austauscht und wann man wieder heim geht.
Man kann auch relativ einfach einen eigenen Pub aufmachen, und seinen Freunden einen Einladungscode dafür zukommen lassen. In dem Fall kann man natürlich selbst entscheiden, wen man zu sich reinläßt - man hat das Hausrecht.
Größere Dateien wie Bilder, Videos, Audio-Files usw. können anscheinend gefahrlos vom eigenen Gerät gelöscht werden, um Platz zu sparen.
Räume statt Kneipen
Es gibt Pub-Server, die den Verlauf aller damit verbundenen Nutzer vorhalten und diese natürlich auch im Internet repräsentieren - als Alternative dazu gibt es auch noch „Room-Server“, die mit aktuell verbundenen Nutzern den Austausch über das Internet ermöglichen (und damit den Abgleich von gemeinsamen Freunden), aber keine Gesprächs-/Nutzerdaten vorhalten.
Replikationsweite
Der geniale Part bei Scuttlebutt ist die einstellbare Replikationsweite: Wenn ein Kontakt, mit dem man gerade verbunden ist, einen aktualisierten Nachrichtenverlauf eines gemeinsamen Kontaktes von uns hat, der aber momentan nicht online ist, kann man sich über unseren gemeinsamen Freund dessen Aktualisierungen abholen. Man wird also indirekt auf dem aktuellen Stand gehalten.
Sollte ein Gerät verloren gehen, kaputt gehen oder gestohlen werden, benötigt man nur seinen privaten, geheimen Schlüssel (das ist die Datei ~/.ssb/secure) und überträgt diesen auf das neue Gerät. Dann holt sich z.B. die Android-App Manyverse von den Freunden (man ist mit dem geheimen Schlüssel automatisch authentifiziert) die persönliche Historie wieder zurück. Die Sicherungskopie (das „Backup“) sind also Freunde, denen man vertraut.
Da auf dem eigenen Handy/Laptop/PC der gesamte Verlauf aller Kontakte gespeichert ist, sollte man automatisch auch darauf zu achten, wirklich nur mit Menschen Kontakt zu haben, denen man 1. vertraut und die es 2. wirklich wert sind, den Kontakt zu halten. Über die Replikationsweite kann man einstellen, über wie viele Verbindungen man man sich Nachrichten herunterlädt (und somit, wieviele Daten). Trotzdem kann man ausschließlich das lesen, was für einen selbst bestimmt ist.
Your scuttlebutt app is interested in the people you follow, and the people they follow (2 hops out). It won’t show those more distant people to you in most screens of the app, but it will try to download their posts in case you try to look at them.
Quelle: https://scuttlebutt.nz/docs/introduction/detailed-start/
Blockieren
Wenn sich jetzt jemand daneben verhält, so kann man ihn blockieren. Wenn das viele tun, ist die Person dann ziemlich schnell einsam. Damit diese wieder mitmischen kann, müsste sie sich eine neue (Scuttlebutt-)Identität zulegen - da man in der Regel jedoch nur eingeladen wird, wenn einem jemand vertraut, ist das Vertrauen auch schnell einmal für einen Wiedereintritt verspielt. Ganz anders als Bei Facebook oder Twitter, bei denen sich jeder vielfach registrieren kann, andere nerven oder Unwahrheiten verbreiten.
Das Blockieren eines Nutzers führt also dazu, dass dieser einen Zugang weniger zur Gemeinschaft hat. Wird ein Nutzer von vielen blockiert, so ist dieser irgendwann abgeschnitten - und alleine. Das und die Tatsache, daß man seine eigene Gemeinschaft aufgrund des Speicherplatzes am Smartphone klein halten wird, führt wahrscheinlich automatisch dazu, dass sich Ungute, Deppen, Aufrührer, Hassverbreiter, Trolle usw. nicht lange in der Gemeinschaft wohlfühlen werden. Oder in ihrer eigenen abgeschotteten Hater-Gemeinschaft alleine bleiben und den Rest nicht mehr belangen können. Das könnte womöglich erstmals das „Troll-Problem“ in öffentlichen Foren „lösen“ …
Unterschied zu Movim
Bei Movim hat man ein Konto bei einem Anbieter, wo man seine eigenen Einträge („postings“) auf einem öffentlichen Service speichern kann, die von anderen abonniert werden. Man sucht sich also ein Movim-pod aus, auf dem man sen soziales Netzwerk pflegen will. Egal auf welchem pod man ist, man hat die eigenen Beiträge immer mit dabei - die der anderen allerdings nicht.
Ja die Movim-Architektur ist verwirrend: Ein “Pod” ist eine Movim-Instanz, also PHP-Code der auf einem Webserver läuft. Dieser PHP-Code ist ein reiner XMPP-Chatclient; die Interaktion ist also “podübergreifend” genau wie jede andere XMPP-Kommunikation “clientübergreifend” ist.
Der Hauptunterschied ist also, daß man bei Movim(XMPP) ein Chatkonto bei einem Anbieter hat und bei Scuttlebut total unabhängig von irgendwelchen Anbietern ist.
Nutzungsdetails
Nochmal zur Replikationsweite:
Unter ‘Verbindungen’ werden eine Hand voll Pubs angezeigt, die mit scuttlebutt.de befreundet sind. Im ‘Öffentlichen Bereich’ sollten sämtliche (öffentliche) Posts von allen anderen Nutzern auftauchen, die mit den Pubs verbunden sind/waren, mit denen man sich gerade synchronisiert. Die “Tiefe” der angezeigten Bekanntschaften in den Einstellungen festgelegt werden. Sie ist auf “2” voreingestellt.
Das heißt man sieht die eigenen Freunde (besser: direkten Kontakte), mit denen man sich aktiv befreundet hat und deren Freunde, mit denen diese befreundet sind. Je höher die Zahl, desto mehr siht man. Also bei einem Pub, bei dem 1.200 Leute sind, müsste man 1.200 Leute zumindest synchronisiert haben und deren updates bekommen.
Clients
Es gibt verschiedene Clients. Auf Android gibt es „Manyverse“; die Desktopclients „Patchwork“ und „Patchbay“ z.B. haben einen noch größeren Funktionsumfang. Am Desktop-Rechner ist es egal, ob man Patchwork oder Patchbay verwendet - beide greifen auf die selbe Datenbank zu. Einsteigerfreundlich oder Funktionsmonster? -> Einfach mal hier schauen und dann testen: https://scuttlebutt.nz/get-started/ (extern)
Kennung/ID
Die Kennung ist der öffentliche Schlüssel eines ed25519-Schlüsselpaares.: @xlJXm+xuEcf8EDH0rBajDnFrTWR+xMdrT+x5JBAaXAD/U8k=.ed25519
Jedes Gerät hat seine eigene Kennung. Wenn man den geheimen Schlüssel auf mehreren Geräten gleichzeitig benutzt, werden die jeweils anderen Geräte automatisch geblockt, was man nicht möchte. Deshalb bietet es sich an, diese zu unterscheiden in z.B. ““meinname :pc:” und “meinname :mobil:“.
Räume
Räume kann man erstellen, indem man einfach einen Hashtag schreibt.
Neuerungen („Rooms 2.0“): https://m.youtube.com/watch?v=W5p0y_MWwDE (extern)
Spezialwissen
Interessant an Scuttlebutt ist auch die Verbindung zu Git:
Vorteile
- Vollständige Unabhängigkeit von Anbietern („providern“). Also nicht nur in dem Sinne, daß man (wie bei Mastodon oder XMPP) auch mit Nutzern (sowie der Software) anderer Anbieter kommunizieren kann. Sondern eben auch in dem Sinn, dass das Konto (besser das Gerät für den Zugang) nicht an einen Anbieter gebunden ist.
- Einfacher Umzug auf neue/andere Geräte, da verteilte „Sicherung“ bei Kontakten
- Spezialisierung auf Offline-Funktionalität
Nachteile
- Anfangs muss man sehr große Datenmengen herunterladen (je nach Replikationstiefe mehrere GB!)
- Maximal 7 Teilnehmer bei „geschlossenen Gruppen“ was direkten Nachrichten an mehrere (max. 7) Empfänger entspricht. (stimmt diese Beschreibung?)
- Nicht mehrgerätefähig. Echte Mehrgerätefähigkeit ist ohne Anbieterabhängigkeit (ohne autoritative Server-Instanz zur Verwaltung der Daten) sicherlich auch nicht ganz einfach.
- Hoher Akkuverbrauch. Auf Grund der Synchronisation über ggfs. mehrere Ebenen beansprucht Manyverse den Akku mehr als Briar
- Viel Speicherbedarf (maximal viele Daten lokal vorzuhalten maximiert natürlich die Chance, dass die Offline-Nutzung funktioniert).
- Es hat aber schon auch technische Aspekte, die evtl. negativ gesehen werden können wie “Ad-hoc-JSON-Spec, Node.js-Server, …
Fragen
- Wie viele Ressourcen braucht es, um gut zu funktionieren?
- Irgendwie scheint es einen “basic account” auf einem Server zu geben … ?
Fazit
Massentauglich scheint Scuttlebut (noch) nicht zu sein - aber mit einem eigenem pub/room-server sehr wohl familientauglich und auch für echte Freunde geeignet!
Projektseite: https://scuttlebutt.nz (extern)
Wiki: https://github.com/ssbc/ssb-server/wiki/#ssbrooms (extern)
Manyverse-Client: https://www.manyver.se (extern)
Infos zu Manyverse: https://gitlab.com/staltz/manyverse/-/wikis/roadmap (extern)
Entwickler von Maniverse: https://staltz.com (extern)

- Lesezeit: 17 Minuten / ganze Rubrik: 23 Minuten - |
Abgrenzung:
- Serverbasierte Messengersysteme („Bedingung“) benötigen für die Nutzung entsprechende Server - z.B. für die Kontakliste, Nachrichtenweiterleitung, Gruppen oder Chatraumverwaltung.
- Servergestützte Messengersysteme („Möglichkeit“) funktionieren grundsätzlich auch ohne Server - jedoch können für Spezialfunktionen (wie Zwischenspecherung von Nachrichten) Server in Anspruch genommen werden.
- Serverlose Messengersysteme („Verzicht“) sind komplett dezentral und ohne spezielle (weitere) Server organisiert.
Neben den im Systemvergleich aufgeführten Systemen gibt es noch viele weitere interessante Projekte, von denen hier ein paar aufgeführt werden. Auch wenn hierzu teilweise noch wenig Informationen gesammelt sind, sollen diese nicht unterschlagen werden.
Immer wieder wird nachfolgend „P2P“ und „anonym“ ins Auge springen - dazu folgende Erklärungen: P2P / Anonymität
Generell gilt:
- Vermaschte/P2P-Systeme können i.d.R. ohne Kosten genutzt werden (Spenden/Entwicklungsaufträge nicht vergessen!)
- Der Akkuverbrauch auf den Mobilgeräten ist höher als bei serverbasierten Systemen
- Mehrgerätefähigkeit ist bei P2P-Systemen ohne zusätzliche Server als Zwischenstation extrem schwer zu realisieren
- Eine Zustellung von Offlinenachrichten ist ohne zusätzliche Zwischenstation („Briefkasten“) nicht möglich
In der nachfolgenden Übersicht wird eine deutsche Internetseite als positiv bzw. fehlende deutschsprachige Informationen als negativ bewertet. Warum? Es wäre überheblich davon auszugehen, daß „alle“ Englisch verstehen oder gar Grundkenntnisse zu fordern. Informationen sollten von jedem Muttersprachler verstanden werden und unnötige Mißverständnisse durch unzureichende Übersetzungen vermieden werden. Gute Übersetzungen machen ein Produkt generell (hier: Messenger) interessant und überhaupt erst der Masse zugänglich, denn Sie ersparen vielen Interessierten/Nutzern unnötigen Übersetzungsaufwand. Sie sind enorm hilfreich und somit Gold wert.
Übersicht
Ebenfalls „serverlos“ sind LAN-Messenger, die jedoch einen ganz anderen Anwendungsfall abdecken.
Oversec
Unabhängig von der jeweils verwendeten Lösung, kann auf Android-Geräten zusätzlich die App „Oversec“ verwendet werden. Diese App legt sich quasi über andere und verschlüsselt/entschlüsselt Eingaben schon bevor sie im eigentlichen Messenger sind. Hört sich verrückt an, ist es aber nicht und funktioniert super. Sicherheitorientierte Personen sollten sich diese App also unbedingt mal anschauen!
Download: bei F-Droid (extern) oder direkt als APK: https://www.oversec.io/#download (extern)
Projektseite: https://www.oversec.io (extern)
Anmerkung: Oversec wird wohl seit 2019 nicht mehr aktiv weiterentwickelt / es wird nicht mehr auf Github-Issues reagiert.
Anonymous Messenger
- Dezentralität: direkt, nutzt TOR (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- positiv: nutzt für die Verschlüsselung das Signal-Protokoll
- negativ: das Protokoll (extern) ist noch nicht richtig dokumentiert!
- negativ: nur für Android verfügbar
- negativ: KEINE deutsche Projektseite
Projektseite: https://anonymousmessenger.ly (extern)
Bitmessage
pyBitmessage (Bitmessage)
Sendet an ALLE Teilnehmer, nur der Empfänger kann entschlüsseln und Nachricht lesen (keine Absende-/Empfängeradresse).
- Dezentralität: direkt/vermascht (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- negativ: KEINE deutsche Projektseite/Hilfe
- negativ: NUR auf PC/Laptop nutzbar - NICHT auf Smartphones
Quellcode: github (extern)
Projektseite: bitmessage.org (extern)
Briar
- Dezentralität: direkt, nutzt TOR (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- negativ: KEINE deutsche Projektseite
Mehr Informationen: >> hier <<
Databag
Databag ist ein selbst gehosteter Messenger (und müsste eigentlich bei den serverbasierten Messengersystemen aufgeführt sein).
- Dezentralität: Databag hat eine “eigene” Definition von P2P
- positiv: gewisse Anonymität
- positiv: sehr geringer Ressourcenbearf
- positiv: Clients für Android, iOS und Browser
- negativ: KEINE deutsche Projektseite
- negativ: es gibt noch keine technische Beschreibung / Whitepaper (entsprechende Dokumentation und Tutorials sollen kommen)
- negativ: nur ein Entwickler stemmt das Projekt derzeit
Mit seinem umfangreichen Funktionsumfang und dem Fokus auf Datenschutz und Sicherheit soll eine umfassende und zuverlässige Self-Hosted-Messaging-Lösung angeboten werden. Das letztendliche Ziel von Databag ist es, auch in preiswerter Elektronik eingebettet/genutzt zu werden, um ein viel breiteres, weniger technisches Publikum zu erreichen. Zurzeit läuft der Netzwerkknoten gut auf einem Raspberry Pi Zero v1.3., da extrem wenig Ressourcen benötigt werden. Zu den Hauptmerkmalen gehören:
- Dezentralisiert (direkte Kommunikation zwischen App und Serverknoten)
- Föderiert (Konten auf verschiedenen Knoten können kommunizieren)
- Auf öffentlichem und privatem Schlüssel basierende Identität (nicht an eine Blockchain oder Hosting-Domäne gebunden)
- Ende-zu-Ende-Verschlüsselung (der Hosting-Administrator kann versiegelte Themen nicht einsehen, standardmäßig unversiegelt)
- Audio- und Videoanrufe (nat traversal erfordert separaten Relay-Server)
- Themenbasierte Threads (Nachrichten werden nach Themen und nicht nach Kontakten organisiert)
- Geringes Gewicht (Server kann auf einem Raspberry Pi Zero v1.3 laufen)
- Geringe Latenz (Verwendung von Websockets für Push-Ereignisse zur Vermeidung von Polling)
- Unbegrenzte Anzahl von Konten pro Knoten (Host für die ganze Familie)
- Mobile Benachrichtigungen für neue Kontakte, Nachrichten und Anrufe (unterstützt UnifiedPush, FCM, APN)
Der Messenger kann sogar in einer Testinstanz (extern) getestet werden - aber bitte nichts Wichtiges posten, da der Server regelmäßig gelöscht wird.
Informationen direkt vom Entwickler:
Gekoppelt mit den Ressourcenanforderungen ist die Effizienz und die schnelle Client-Synchronisierung. Der Benutzer muss nicht warten, bis der Client alle Unterhaltungen beim ersten Start der App oder bei einem Neustart nach einer längeren Zeitspanne abgeholt hat. Das Datenmodell für Databag ist sehr einfach und man weiß, wo die eigenen Daten sind. Die Daten befinden sich nur auf dem Knoten des Kontos für die Konversation und den vorgesehenen Client-Geräten.
Der Databag-Knoten (Protokoll/API) ist abstrakt und konzentriert sich nicht primär auf den Nachrichtenaustausch, sondern einfach auf die gemeinsame Nutzung von Daten. Das Databag-Netzwerk ist offen, und ich habe mehrere andere Anwendungen, die ich für das Netzwerk schreiben möchte (insbesondere dezentralisierte Bewertungen und Dateifreigabe durch vertrauenswürdige Kontakte).
Technische Details: Die Ende-zu-Ende-Verschlüsselung ist mit RSA und AES implementiert. Die Synchronisationsdaten werden als Körper von HTTP-Nachrichten übertragen.
Quelle für Informationen: medevel.com (extern)
Quellcode: github (extern)
Jami
Namensentwicklung: „SFLphone“ -> „Ring“ -> „Jami“
Ursprünglich für Telefonie entwickelt (je nach Betriebssystem Audio / Audio und Video / Audio und Video in Gruppen), es sind aber genauso auch Textnachrichten möglich; an textbasierten Chaträumen wird gearbeitet.
Jami ermöglicht sichere Text-, Sprach- und Videokommunikation über das Internet. Es ermöglicht auch Telefonkonferenzen und Videokonferenzen, aber seltsamerweise noch keine textbasierten Chatrooms, da die Entwickler versuchen, diese vollständig dezentralisiert zu machen. Jami ist eine gute Wahl für sichere Telefongespräche über das Internet, solange die Gesprächspartner ebenfalls Jami benutzen. Jami ist ein Peer-to-Peer-System; es ist nicht auf zentrale Server angewiesen und benötigt diese auch nicht.
Jami ist plattformübergreifend, mit Versionen für Android, FreeBSD, iOS, iPhone, Linux, Microsoft Windows und OS X. Es gibt (Stand März 2020) keine Version für das Pinephone.
Es ist sowohl ein Peer-to-Peer-Voice-over-IP-Client-Programm als auch ein benutzerdefiniertes Protokoll für die Dienstsuche unter Verwendung einer verteilten Hash-Tabelle (DHT). Es verwendet SRTP zur Übertragung von Kommunikationsdaten.
P2P mit Server?
Wir sagen immer wieder, dass das charakteristischste und innovativste Merkmal von Jami die Tatsache ist, dass es keinen Server benötigt, um Daten zwischen den Benutzern weiterzuleiten. Damit sind viele Vorteile verbunden, darunter eine erhöhte Privatsphäre, eine leichtgewichtige Infrastruktur, hohe Skalierbarkeit, keine Bandbreitenbeschränkung (abgesehen von der deiner Internetverbindung), keine Größenbeschränkung für Dateiübertragungen und vieles mehr. Dies alles ist richtig, aber obwohl Server nicht erforderlich sind, werden sie dennoch in fünf spezifischen Fällen eingesetzt: Push-Benachrichtigungen, der OpenDHT-Proxy, Bootstrap, Name-Server und TURN. … >> mehr << (extern)
Beschreibung: https://linuxreviews.org/Jami (extern; englisch)
Fragen zur Sicherheit und Antworten eines Entwickler: stackexchange.com (extern)
Nutzung von GIT für Nachrichten (‘swarm’): jami.net (extern; englisch)
Auch über F-Droid und somit ohne Tracker verfügbar: https://f-droid.org/en/packages/cx.ring (extern)
- Dezentralität: direkt (P2P mit unterstützung von separaten Server)
- positiv: gewisse Anonymität
- negativ: Die Projektseite bindet u.a. auch Dienste Dritter (transifex) ein: webbkoll (extern)
- negativ: KEINE deutsche Projektseite
Quellcode: https://jami.net/contribute/ (extern)
Projektseite: http://jami.net (extern)
Katzenpost
Verkehrsanalyse-resistente Nachrichtenübermittlung - durch Protokollbibliotheken für gemischte Netze. Was ist ein Mix-Netzwerk? Es ist ein anonymes Kommunikationssystem - allerdings ist das Wort “anonym” problematisch, weil einige Regierungsbehörden Anonymität mit Terrorismus gleichsetzen. Wir ziehen es vor, es stattdessen “Netzwerksicherheit” zu nennen, weil Sie sich sicherer fühlen können, wenn Sie mit verkehrsanalysesicheren Kommunikationsprotokollen kommunizieren. …
Übersetzt aus der englischen Quelle:
Traffic analysis resistant messaging - We write mix network protocol libraries. What is a mix network? It is an anonymous communications system… however the word anonymous is problematic because some government authorities equate anonymity with terrorism. We prefer to instead call it “network security” because you can feel more secure when you communicate using traffic analysis resistant communications protocols. …
Dieses Projekt wurde gefördert/finanziell unterstützt von „European Union’s Horizon 2020 research and innovation programme“, „Samsung Next Stack Zero grant“ und „NLnet and the NGI0 PET Fund paid for by the European Commission“.
- Dezentralität: direkt/vermascht (P2P, keine separaten Server)
- positiv: gewisse Anonymität
Quellcode: https://github.com/katzenpost (extern)
Projektseite: https://katzenpost.mixnetworks.org (extern; englisch)
Mesh-Chat
- Dezentralität: direkt/vermascht (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- negativ: KEINE deutsche Projektseite/Hilfe
Quellcode und Projektseite: https://github.com/neuravion/mesh-chat-protocol (extern; leider nur englisch)
Quiet
Eine Messaging-Plattform die Tor und IPFS verwendet und die sich als Alternative zu Slack und Discord sieht.
- Dezentralität: direkt, nutzt TOR (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- positiv: Es wird konkretes Bedrohungsmodell (”threat-model” (extern)) beschrieben
- negativ: KEINE deutsche Projektseite
Jede Gruppe, in Quiet als “Community” bezeichnet, arbeitet in einem eigenen Netzwerk. Dies garantiert, dass die Daten einer Gemeinschaft vollständig von den Geräten anderer Quiet-Nutzer isoliert bleiben, selbst wenn sie verschlüsselt sind.
Die Synchronisierung von Nachrichten wird nahtlos durch OrbitDB erleichtert, das die Funktionen von Git, einem Gossip-Protokoll, und BitTorrent kombiniert. Es sendet effizient neue Nachrichten, synchronisiert die letzten Nachrichten und ruft Dateien ab. Als Ergebnis können die Benutzer erwarten, dass sie alle Nachrichten erhalten, die gesendet wurden, während sie offline waren.
Einladungen, Zugriffsberechtigungen und Benutzernamen werden ausschließlich vom Eigentümer der Community vergeben, der die Verantwortung für die Erstellung der Community übernimmt.
Der Eigentümer stellt einen exklusiven “Einladungscode” bereit, mit dem sich die Eingeladenen mit ihrem Gerät verbinden, einen Benutzernamen registrieren und ein kryptografisches Standardzertifikat erwerben können, um ihre Mitgliedschaft gegenüber anderen Peers innerhalb der Gemeinschaft zu bestätigen.
So sieht sich Quiet selbst im Vergleich zu Slack, Discord, Signal, Matrix, Session, Briar, Cwtch, Cabal und Ricochet Refresh: https://medevel.com/quiet (extern)
Quelle für Informationen: https://medevel.com/quiet (extern)\
Quellcode: https://github.com/TryQuiet/quiet (extern)
Projektseite: https://tryquiet.org (extern; englisch)
Reticulum
Extreme Privatsphäre ist viel schwieriger zu erreichen als Sicherheit. Reticulum scheint das sehr gut zu gelingen, denn es basiert nicht auf dem Internt-Protokoll (IP). Beim Internet-Protokoll ist immer eine Quell- und Zieladresse bekannt (IP-Adressen). Selbst Tor (the onion routing) oder VPN (virtuelle private Netzwerke) basieren ebenfalls auf IP. Im Gegensatz dazu kennt das Netzwerksystem Reticulum keine Quelle sondern nur das Ziel.
- Dezentralität: direkt, IP-unabhänig (P2P, keine separaten Server erforderlich)
- positiv: sehr gute Anonymität / sehr „sicher“
- negativ: Reticulum befindet sich noch im Beta-Stadium und ist experimentelle Software (Juni 2024)
- negativ: Für den Unternehmenseinsatz nicht geeignet, da ausschließlich verschlüsselte Kommunikation möglich ist.
Auf Reticulum baut wiederum das Protokoll „Lightweight Extensible Message Format“ (LXMF) auf, das ein verteiltes, verzögerungs- und unterbrechungstolerantes Nachrichtenübertragungsprotokoll ist. LXMF ist ein einfaches und flexibles Nachrichtenformat und Übermittlungsprotokoll, das eine Vielzahl von Implementierungen ermöglicht und dabei so wenig Bandbreite wie möglich benötigt. Das Protokoll bietet Zero-Conf Message Routing, Ende-zu-Ende-Verschlüsselung, vorwärts gerichtete Sicherheit (Forward Secrecy) und kann über jedes von Reticulum unterstützte Medium transportiert werden.
LXMF ist so effizient, dass es Nachrichten über Systeme mit extrem niedriger Bandbreite wie Packet Radio oder LoRa übertragen kann. Verschlüsselte LXMF-Nachrichten können auch als QR-Codes oder textbasierte URIs kodiert werden, was einen vollständig analogen Nachrichtentransport auf Papier ermöglicht.
Zielgruppe sind z.B. Einsatzkräfte in Katastrophengebieten.
Software
- Nomad Network
Eine netzunabhängige, verschlüsselte und widerstandsfähige Mesh-Kommunikationsplattform.
- Sideband
Die Android-, Linux- und macOS-Anwendung verfügt über eine grafische Oberfläche und legt den Schwerpunkt auf Benutzerfreundlichkeit.
Hardware
Reticulum kann über praktisch jedes Medium verwendet werden, das mindestens einen Halbduplex-Kanal mit einem Durchsatz von 500 Bit pro Sekunde und einer MTU von 500 Byte unterstützt. Datenfunkgeräte, Modems, LoRa-Funkgeräte, serielle Leitungen, AX.25-TNCs, digitale Amateurfunkmodi, WiFi- und Ethernet-Geräte, optische Verbindungen im freien Raum und ähnliche Systeme sind Beispiele für physische Geräte, die Reticulum verwenden kann. Zu den unterstützten Schnittstellentypen gehören:
- Jedes Ethernet-Gerät
- Fast alle WiFi-basierte Hardware
- LoRa mit RNode
- Packet Radio TNCs (mit oder ohne AX.25)
- KISS-kompatible Hardware- und Software-Modems
- Jedes Gerät mit einer seriellen Schnittstelle
- TCP über IP Netzwerke
- UDP über IP Netzwerke
- Externe Programme über stdio oder Pipes
- Kundenspezifische Hardware über stdio oder Pipes
Es ist beispielsweise möglich, einen Raspberry Pi sowohl mit einem LoRa-Funkgerät als auch mit einem Paketfunk-TNC und einem WiFi-Netzwerk zu verbinden. Sobald die Schnittstellen konfiguriert sind, kümmert sich Reticulum um den Rest, und jedes Gerät im WiFi-Netzwerk kann mit Knoten auf der LoRa- und Paketfunkseite des Netzwerks kommunizieren und umgekehrt.
Quelle und Projektseite: https://reticulum.network/index_de.html (extern)
Retroshare
- Dezentralität: direkt/vermascht, nutzt TOR (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- negativ: KEINE deutsche Projektseite
Dokumentation: https://retrosharedocs.readthedocs.io/en/latest/ (extern; englisch)
Quellcode: https://github.com/RetroShare (extern)
Projektseite: https://retroshare.cc (extern; englisch)
Ricochet Refresh
Ricochet Refresh ist ein gepflegter und aktueller Fork des ehemaligen Ricochet-Projektes.
- Dezentralität: direkt, nutzt TOR (P2P, keine separaten Server)
- positiv: gewisse Anonymität
- negativ: KEINE deutsche Projektseite/Hilfe
Quellcode: https://github.com/blueprint-freespeech/ricochet-refresh (extern)
Projektseite: https://www.ricochetrefresh.net (extern)
Silence
Föderiert über TK-Anbieter und funktioniert auf Basis von SMS.
- Dezentralität: direkt (P2P, keine separaten Server erforderlich)
- negativ: Mobilnummer erforderlich (SMS-Versand/-Empfang)
- negativ: Messenger nur für Android
Quellcode: https://git.silence.dev/Silence/Silence-Android/ (extern)
Projektseite: https://silence.im (extern)
TinfoilChat (TFC)
Wer glaubt, wirklich von Geheimdiensten gezielt angegriffen zu werden, sollte sich sich die hardware-unterstützte Chat-Lösung TinfoilChat (TFC) ansehen. Die meinen es anscheinend ernst und das ist noch eine Stufe „extremer“ als z.B. Briar:
Tinfoil Chat (TFC) ist ein FOSS+FHD Peer-to-Peer-Nachrichtensystem, das auf einer hochsicheren Hardware-Architektur basiert, um Benutzer vor passivem Sammeln, MITM-Angriffen und vor allem vor Remote-Schlüssel-Exfiltration zu schützen. TFC wurde für Menschen mit einem der komplexesten Bedrohungsmodelle entwickelt: organisierte kriminelle Gruppen und staatliche Hacker, die die Ende-zu-Ende-Verschlüsselung herkömmlicher sicherer Messaging-Apps umgehen, indem sie den Endpunkt hacken.
- Dezentralität: direkt, nutzt TOR (P2P, keine separaten Server erforderlich)
- positiv: bestmögliche Anonymität / extrem „sicher“
- negativ: separate Hardware erforderlich
- negativ: KEINE deutsche Projektseite/Hilfe
Quellcode und Projektseite: https://github.com/maqp/tfc/ (extern; leider nur englisch; wirklich spannend zu lesen!)
Tox
Audio- und Videoanrufe sind möglich und es gibt verschiedene Clients mit grafischer als auch reiner Text-Benutzeroberfläche.
- Dezentralität: direkt, auch per TOR (P2P, keine separaten Server erforderlich)
- positiv: gewisse Anonymität
- negativ: Hinweis auf der Projektseite (bei „download“): „Tox is still under heavy development — expect to run into some bugs“
- negativ: KEINE deutsche Projektseite
Erfahrungsbericht: https://herrdoering.de/de/sicheres-messenging-mit-tox-chat/ (extern)
Nutzung mit TOR: https://wiki.tox.chat/users/tox_over_tor_tot (extern)
Raspberry Pi für Offline-Nachrichten (extern; englisch)
Mögliche Clients: qTox, uTox, Toxygen, Toxic, aTox (extern), Trifa (extern)
Client-Funktionen: https://wiki.tox.chat/clients#features (extern)
Quellcode und Projektseite: https://tox.chat (extern)
Vuvuzela
Auch ein interessantes Projekt - allerdings aktuell keine aktive Weiterentwicklung mehr (letzte Änderung am Quellcode war im September 2019).
- Dezentralität: direkt (P2P, verschiedene Server)
- positiv: gewisse Anonymität
- positiv: will unnötige Metadaten verschleiern
- negativ: nur Konzept, keine Änderungen am Quellcode mehr seit 2019
- negativ: KEINE deutsche Projektseite/Hilfe
Interview mit einem dem Entwickler: netzpolitik.org
Quellcode: https://github.com/vuvuzela/vuvuzela (extern)
Projektseite: https://vuvuzela.io (extern, leider nur englisch)
Mit Briar (engl. für dorniges Dickicht, Dornenbusch) können sich Nutzer anonym und zur Not auch ohne Internetverbindung austauschen. Die Kommunikation läuft über das Tor-Netzwerk und kommt ohne zentrale Server aus. Dabei kann Briar über Bluetooth oder WLAN auch direkte Verbindungen zu anderen Instanzen in der unmittelbaren Umgebung aufbauen. Sämtliche Gesprächsinhalte sind verschlüsselt nur auf den Geräten der beteiligten Kommunikationspartner gespeichert.
Neue Kommunikationspartner können sich untereinander nur direkt (Gerät-zu-Gerät) bekanntmachen und müssen also zur selben Zeit am selben Ort sein. Einen bereits bekannten Kontakt kann man per Einladungsvorschlag einem anderen bekannten Kontakt vorschlagen, was zwar sehr restriktiv ist, allerdings dafür auch sehr sicher. Briar unterscheidet sich von anderen Messengern dadurch, dass zur Kontaktregistrierung keine persönlichen Daten wie SIM-Karte, Telefonnummer, E-Mailadresse, oder Messenger-ID notwendig sind. Wichtige Benutzergruppen für Briar umfassen Aktivisten und Journalisten, die auf sichere Kommunikation angewiesen sind. Auch in Katastrophenfällen kann die verwendete Technologie (kein zwingender Internetzugang) eingesetzt werden und hilfreich sein.
Briar schützt vor:
- der Überwachung von Metadaten (wer mit wem, wann und wie lange schreibt),
- der Überwachung der Inhalte (worüber getextet wird),
- der Zensur von Inhalten durch Filter,
- der Unterbrechung der Kommunikation durch Trennung/Abschalten des Internets,
- Denial-of-Service-Attacken.
Bietet Briar komplette Anonymität? Nein (extern; englisch)
Briar verbirgt Ihre Identität nicht vor Ihren Kontakten. Es bietet Unverknüpfbarkeit, aber keine Anonymität. Das bedeutet, dass niemand sonst herausfinden kann, wer Ihre Kontakte sind, aber Ihre Kontakte könnten herausfinden, wer Sie sind.
Technischer Hintergrund:
Briar nutzt das Hidden-Service-Protokoll von Tor. Die Apps der Teilnehmer kommunizieren nicht direkt miteinander, sondern verbinden sich zunächst mit dem auf dem Gerät laufenden Tor-Dienst. Damit soll sichergestellt sein, dass die Kommunikation vollständig anonym abläuft und niemand herausfinden kann, wer sich mit wem austauscht.
Briar kann sowohl über den offiziellen F-Droid-Store, über den Google-Play-Store - aber auch direkt von der Entwicklerseite (extern) heruntergeladen werden.
Nutzungshinweise
Erster Start
Beim ersten Start muß ein Name und ein Passwort eingegeben werden. Der Benutzername kann danach nicht mehr geändert werden - außer man hat die Zugangsdaten „vergessen“ und legt eine neue, leere Datenbank (mit neuem Namen) an. Das Passwort wird auf die Verschlüsselungsstärke geprüft. Das bedeutet, es muss eine Kombination von Länge und unterschiedlichen Zeichen sein, die nicht als „unsicher“ gilt. -> MEHR INFOS??
Kontakte hinzufügen
Das Hinzufügen von Kontakten ist nur möglich, wenn beide Geräte physisch am selben Ort sind oder durch Empfehlung eines schon vorhandenen Briar-Kontaktes an einen anderen (dazu später mehr).
1. Direkte Bekanntmachung
Der Barcode (angezeigter QR-Code) des jeweils anderen Geräts muß auf beiden Geräten eingelesen (mit der Kamera erfasst und erkannt) werden. Erst wenn dies gegenseitig funktioniert hat, werden die Kontaktdaten automatisch ausgetauscht. Anschließend ist man verbunden und kann lostexten.
2. Bekanntmachung durch Empfehlung
Wenn jemand zwei Kontakte in Briar hat und diese untereinander „vermittelt“ werden sollen, ist das möglich und hat für diese den Vorteil, nicht am selben Ort sein zu müssen. Hierzu schlägt man einem Kontakt einen anderen als „Kontaktempfehlung“ vor und fungiert als Vermittler:
Eigenes Gerät |
Gerät von Kontakt |
|
|
|
|
Beim zweiten Kontakt läuft das entsprechend wie beim ersten Kontakt ab.
Stromverbrauch
Briar benötigt auf Grund des Betriebes ohne Server deutlich mehr Strom auf einem Endgerät als beispielsweise ein Jabber-Client. In Praxisvergleichen hat sich gezeigt, das der Stomverbrauch ca. 4mal höher ist. Eine durchgehende, tägliche Nutzung ist bei einem Geräte-Akku mit geringerer Leistung nicht/schwer möglich.
Aber:
Ökologisch und ökonomisch betrachtet ist der Betrieb von Briar in der Summe jedoch besser (im Vergleich zu dezentralen oder zentralen Systemen), da lediglich Endgeräte betrieben werden und keine Server erforderlich sind. Diese benötigen deutlich mehr Strom für den Betrieb und die durchgehend erbrachte Leistung wird oftmals nur zu einem Bruchteil tatsächlich genutzt - und somit Ressourcen verschwendet.
Sonstiges
Englischsprachige Startseite des Projektes: https://briarproject.org/ (extern)
Englischsprachige Briar-Anleitung: https://briarproject.org/manual/ (extern)
Englischsprachige FAQ: https://code.briarproject.org/briar/briar/-/wikis/FAQ (extern)
Aktuelle Versionshinweise: https://code.briarproject.org/briar/briar/wikis/changelog (extern)
Mindestversion Android: 4.01 (Sdk-Version 15)
Quellcode: https://code.briarproject.org/briar/briar (extern)

Messenger für lokale Netzwerke (LAN):
BeeBEEP
Ein seit ca. 2010 ständig fortentwickelter LAN-Messenger für alle Betriebssysteme!
Projektseite: https://www.beebeep.net (extern; englisch)
Quellcode: https://sourceforge.net/projects/beebeep (extern)
Meshenger
In Stichworten:
- Android-App
- Audio/Video Telefon App
- Funktioniert im lokalen LAN ohne Internet, Server oder andere Clients mit einer direkten Verbindung per IPv6
- Kontaktaustausch per QR-Code, auch fremde Kontakte können damit weitergegeben werden
- bisher keine Kompatibilität zu anderen Systemen
- eine deutsche Dokumentation gibt es nicht
Technologien
Privatsphäre
- Meshenger tauscht als Kontakt die MAC-Adresse aus
- eine Authentifizierung findet zur Zeit nicht statt
Bezugsquelle F-Droid: https://f-droid.org/en/packages/d.d.meshenger/ (extern)
Quellcode auf Github: https://github.com/meshenger-app/meshenger-android/releases (extern)
qaul
qaul – قول
Die arabischen Zeichen قول bedeuten übersetzt „Wort“, „Rede“, „Text“.
qaul ist eine Internet unabhängige wifi Kommunikations App. Kommuniziere mit anderen in der Nähe, ohne Internet-Verbindung oder Kommunikations-Infrastruktur.
Du siehst Nutzer in der Nähe automatisch, kannst Nachrichten an alle senden, Chat-Gruppen erstellen, Ende-zu-Ende-Verschlüsselte Chat Nachrichten, Bilder und Dokumente senden.
Kommuniziere von Gerät zu Gerät in deinem lokalen Wifi-Netzwerk oder über den von deinem Telefon erstellten Wifi-Hotspot.
- positiv: deutsche Projektseite
- positiv: Apps für Android, iOS, Windows, Linux und MacOS!
- negativ: Beta-Status! („Wir testen qaul“)
Projektseite: https://www.qaul.net/de (extern)
Quellcode: https://github.com/qaul/qaul.net (extern)
- - - - - Sonstiges - - - - -
- Lesezeit: 5 Minuten / ganze Rubrik: 88 Minuten - |
Hier ein paar kurze Erläuterungen zu:
„Das weiß doch jeder“ - das zu behaupten ist überheblich! Auch im Zusammenhang mit Sofortnachrichten (chat) werden immer wieder besondere Abkürzungen und Begriffe verwendet:
Abkürzung/Begriff |
Beschreibung |
Anonymität |
ohne Bezug zur Identität / ohne personenbezogene Daten / namenlos / unbekannt / verdekt / auch: „inkognito“ >> Beschreibung << |
CAPTCHA / reCaptcha |
Ein Test, mit dem festgestellt werden kann, ob ein Mensch oder ein Computer diesen beantwortet. Info: Datenschutz und Google reCAPTCHA (extern) Abkürzung für englisch: “completely automated public turing test to tell computers and humans apart” |
channel |
Englischer Begriff für einen öffentlichen und offen zugänglichen Chatraum oder einfach kurz: „öffentlicher Chat“ Wörtlich übersetzt: „Kanal“ / siehe auch ->muc |
API |
Eine Schnittstelle um zwischen Anwendungen/Programmen Informationen auszutauschen >> mehr << Abkürzung für englisch: „Application Programming Interface“ / ein hauptsächlich technisch geprägter Begriff |
Electron |
System, bei dem eine Anwendung in einen eigenen Browser eingebettet ist. >> mehr << |
Flutter |
System von Google, bei dem eine Anwendung eingebettet ist. >> mehr << |
IETF / Internetstandard / IESG |
Die IETF ist eine neutrale Organisation mit unterschiedlichsten Mitgliedern und geregelten Abläufen, die sehr viel Qualitätssicherungs-Aufwand betreibt und dafür weltweit anerkannt ist. Ein Internetstandard ist ein von der Internet Engineering Task Force (IETF) spezifiziertes Netzwerkprotokoll für den Einsatz im Internet. Es handelt sich dabei um einen offenen Standard, der sich im praktischen Einsatz bewährt hat und von einer breiten Öffentlichkeit unterstützt wird. Jeder Internetstandard besteht aus einem oder mehreren Request for Comments (RFC); jedoch nicht jedes RFC stellt einen Internetstandard dar. Über die Anerkennung als Internetstandard entscheidet die Internet Engineering Steering Group (IESG). Ein Beispiel für einen Internetstandard ist das Domain Name System (DNS), das als STD 13 die beiden Request for Comments RFC 1034 und RFC 1035 umfasst. Dieser Internetstandard ist nützlich, technisch ausgereift und genießt Unterstützung durch die Internetgemeinschaft. DNS-Erweiterungen wie EDNS0 werden als separate Standards geführt. Quelle: https://de.wikipedia.org/wiki/Internetstandard (extern) |
Jabber |
Ursprünglich von der Fa. Jabber entwickeltes Chat-System; entspricht heute dem Standardprotokoll „XMPP“; nicht zu verwechseln mit „Cisco Jabber“! Englisch für: „plaudern“ |
JID |
Name/Bezeichnung für ein Chatkonto oder einem Chat / Jabber-Kennung / Abkürzung von „Jabber-ID“ Format: „kontoname@server.tld“ oder „chatraum@xyz.server.tld“ / Beispiel: „im@jabber.de“ oder „freie-messenger@conference.jabber.de“ |
LAN |
Lokales (eigenes) Netzwerk Abkürzung für englisch: „local area network“ |
muc |
Gruppe / Gruppenchat / Raum / Chatraum / Chat / Konferenz Chats können jeweils geschlossen/offen, privat/öffentlich persönlich/unpersönlich und mit/ohne Schreibrechte sein. Abkürzung für englisch: „multi user chat“ / ein hauptsächlich technisch geprägter Begriff |
NAT |
Die Übersetzung privater IP-Adressen in eine öffentliche IP-Adresse hinter Routern erfolgt durch NAT, was zu Problemen bei der Internettelefonie mit WebRTC führen kann. Abkürzung für englisch: „Network Address Translation“ |
OMEMO |
XMPP-Erweiterung (-> XEP) für sichere Ende-zu-Ende-Verschlüsselung auch bei mehreren Endgeräten, selbst wenn diese offline sind. Nutzt die selbe Technik wie „Signal“. Abkürzung für englisch: „OMEMO Multi-End Message and Object Encryption“ |
P2P |
Direktverbindung Abkürzung für englisch: „Peer to Peer“ >> Erläuterung << |
push / Push-Benachrichtigung |
Push-Benachrichtigungen dienen dem indirekten Starten von systembedingt beendeten Apps >> mehr << |
RFC |
„Request for Comments“; vgl. ->IETF |
STUN |
Technische Hilfe, um bei Internettelefonie die IP-Adressen der Gesprächspartner auszutauschen, wenn diese nicht im selben Netzwerk sind. >> mehr << Abkürzung für englisch: „Session Traversal Utilities for NAT“ |
TURN |
Technische Hilfe, um bei Internettelefonie die IP-Adressen der Gesprächspartner auszutauschen, wenn eine Firewall eingesetzt wird. >> mehr << Abkürzung für englisch: „Traversal Using Relays around NAT“ |
UI |
Benutzeroberfläche/-schnittstelle Abkürzung für englisch: „user interface“ |
URI |
Eindeutige Ressourcenkennung / Identifikationskennzeichnung Abkürzung für englisch: „uniform resource identifier“ |
WAN |
Großflächiges (eigenes) Netzwerk, das sich in größeren Firmen weltweit erstrecken kann; selbe Technik wie ->LAN Abkürzung für englisch: „wide area network“ |
WebRTC |
Kommunikationsprotokoll für Internettelefonie >> mehr << Abkürzung für englisch: „Web Real-Time Communication“ |
XEP |
Standardisierte XMPP-Erweiterungen Abkürzung für englisch: „XMPP Extension Protocols“ |
XMPP |
Erweiterbares Nachrichten- und Anwesenheitsprotokoll, das auf ->XML basiert Abkürzung für englisch: „Extensible Messaging and Presence Protocol“ |
XML |
Erweiterbare Beschreibungssprache Abkürzung für englisch: „Extensible Markup Language“ |
Allgemein gilt: |
Fachbegriffe und Abkürzungen sollten nur verwendet werden, wenn alle angesprochenen Teilnehmer diese auch verstehen. Es ist überheblich zu davon auszugehen, dass eigenes Wissen auch Allgemeinwissen wäre. |
- Lesezeit: ca. 4 Minuten / ganze Rubrik: 37 Minuten - |
Bei Chat wird unter diesem Begriff allgemein eine „messengerübergreifende Kommunikation“ verstanden. Besser ist jedoch diese Definition:
Interoperabilität ist die Fähigkeit, sich unabhängig von Anbietern über standardisierte Schnittstellen und Protokolle austauschen zu können. |
Analogie:
Das System „E-Mail“ ist beispielsweise interoperabel, da jeder Nutzer einen anderen Anbieter und ein anderes E-Mail-Programm wählen kann und trotzdem alle untereinander und anbieterübergreifend kommunizieren können.
Auf europäischer Ebene gibt es mit dem Digital Markets Act Bestrebungen, vor allem die großen und bisher geschlossenen Anbieter von Messengersystemen zu einer gewissen Offenheit (nicht Interoperabilität) zu zwingen.
Vorwort
Mit diesen Gedanken soll ein bewußteres Wahrnehmen von vorgebrachten Aussagen insbesondere zur „Interoperabilität“ -aber auch zur „Föderation“- sowie eine sachlichere Argumentation erreicht werden. |
Interoperabilitätsverpflichtung
Es gibt verschiedene Gründe warum man eine gesetzliche Verpflichtung zur Interoperabilität zwischen Messengediensten befürworten oder auch ablehnen kann.
Selbstverständlich haben die marktbeherrschenden Unternehmen wie Facebook oder auch andere große bekannte Messengeranbieter kein Interesse ihre geschlossenen Systeme in irgendeiner Art zu öffnen. Aber auch auf der Seite der offenen Systeme ist das Thema Interoperabilitätsverpflichtung umstritten!
Die Monopolkommision formuliert hierzu im 12. Sektorgutachten „Telekommunikation 2021: Wettbewerb im Umbruch“ (extern; PDF):
Interoperabilitätsverpflichtungen, die eine diensteübergreifende Kommunikation ermöglichen würden, sind für nummernunabhängige interpersonelle Telekommunikationsdienste wie z. B. WhatsApp, Signal, Threema und Wire aktuell abzulehnen, da sie derzeit mehr Nachteile als Vorteile für den Wettbewerb verursachen würden. …
Eine asymmetrische Interoperabilitätsverpflichtung bei nummernunabhängigen interpersonellen Telekommunikationsdiensten sollte sich, wenn sie doch erforderlich würde, auf zu definierende Basisfunktionen beschränken, sodass der Wettbewerb über innovative Zusatzfunktionen möglich bleibt.
Ich kann mich diesbezüglich nur anschließen und der Aussage „Interoperabilität ja aber keine Interoperabilitätsverpflichtung“ zustimmen, denn eine zwanghafte „individuelle Öffnung per DMA“ ist nicht mit „allgemeiner Interoperabilität“ gleichzusetzen. Aber was hält die Politik davon ab, vorhandene Standards zu nutzen?
Vorbildfunktion
Die Politik/Verwaltung hat eine öffentliche Vorbildfunktion - aber gerade wenn es um Interoperabilität bei Messengern geht, fehlt diese. Statt Flagge zu zeigen wird mit zwei Zungen gesprochen und es herrscht eine bequeme Doppelmoral:
Janusköpfig wird auf der einen Seite Interoperabilität gefordert aber auf der anderen Seite wird die selbe Interoperabilität bei eigenen Projekten abgelehnt oder sogar bewußt von vornherein ausgeschlossen. Das Tolle: Beides mit der selben, vorgeschobenen Begründung “mehr/besserer Datenschutz”. Eine Beispielantwort dazu bezüglich einer Ausschreibung auf Länderebene:
… , was von uns aus datenschutzrechtlichen Gründen ausdrücklich nicht gewünscht ist.
Die Politik macht es sich einfach: Es werden selbst keine Systeme genutzt, die Standards einhalten, sondern viele verschiedene und untereinander nicht kompatible Systeme. Auch bei Ausschreibungen wird der Punkt “Schnittstelle nach außen” aus (unbegründeter) Angst vor “dem” Datenschutz oft überhaupt nicht berücksichtigt oder sogar bewußt ausgeschlossen. Gleichzeitig wird aber mit den konkreten Überlegungen zur Interoperabilitätsverpflichtung auf EU-Ebene von den Dienstebetreibern gefordert, das Problem (für die Politik) zu lösen.
Passender Querverweis: Gedanken zu „Alternativen zu WhatsApp“
Egal welche Behörde, welches Amt oder welche Einrichtung:
Niemand konnte mir bisher beantworten, welche datenschutzrechtlichen Punkte in der Praxis denn konkret gegen Interoperabilität sprechen würden! Deshalb muß der Finger auf diese Wunde gelegt und hier angesetzt werden. Denn alle nutzen Briefpost, E-Mail, Telefon und Mobilfunk - und alle Beteiligte setzen hier Interoperabilität als gegeben voraus! Es mangelt vermutlich also einfach an Wissen oder es liegen Fehlinformationen vor, die in der Folge ein falsches Bild ergeben.
Aber auch Funktionsträger sind letztendlich nur Menschen, die nicht über ihren eigenen Schatten springen können (wollen). Auch ihnen ist die Bequemlichkeit von WhatsApp mit dem automatischen Hochladen des Adressbuchs wichtiger als vieles andere. Deshalb wird konsequent von anderen gefordert, sich zu ändern und man bastelt am „Digital Markets Act (DMA)“ …
Entscheidungen
Unzählige Unternehmen kaufen sich Messengerdienstleistungen ein und auch im öffentlichen Bereich sitzen Steuergelder hierfür locker/werden ausgegeben. Der Messengermarkt ist also milliardenschwer, es kann viel Geld verdient werden und deshalb ist er hart umkämpft. Im Marketing (und folglich auch bei Entscheidungen) wird also das Schlagwort „Interoperabilität“ oft verwendet und das hört sich auch super an. Aber was steckt eigentlich hinter den Marketingsprüchen?
Und verstehen alle dasselbe unter dem Begriff „Interoperabilität“? Denn dieser wird oft falsch verwendet, unterschiedlich interpretiert oder zumindest seeeeehr weit gedehnt.
Warum?
Aus Sicht der Entscheider ist es von Vorteil, wenn Entscheidungen schnell mit einem eindeutigen Ergebnis herbeigeführt und getroffen werden können. Da hilft es vordergründig sehr, Werbeaussagen und auch Entscheidungen anderer für sich einfach so und ohne Nachzufragen zu übernehmen. Denn „das muß ja bestimmt gut überlegt gewesen sein“ und „wenn die das machen, kann das für uns nicht falsch sein“.
Wie so oft, ist das leider nicht so einfach, denn jede Messengerlösung hat Vor- und Nachteile. Und zu den primären Vorteilen gehört nicht, daß sehr große Organisationseinheiten intern ein bestimmtes System einsetzen, das dort super funktioniert - das ist aber im Zusammenhang mit Interoperabilität nicht relevant.
Wichtig dagegen ist zu wissen, ob ein Messengersystem ausschließlich als internes Kommunikations- und Arbeitsmittel eingesetzt werden soll (für Außenstehende nicht erreichbar) oder als generelle und interoperable Kommunikationslösung wie z.B. Telefon und E-Mail auch. Also als Ergänzung der in der Regel öffentlichen Kontaktdaten, die auf Internetseiten oder Visitenkarten stehen:
- Name: …
- Postadresse: …
- Telefon-Nr.: …
- E-Mail-Adresse: …
- Chatadresse: …
Um zukunftssichere Entscheidungen zu treffen, ist es deshalb beispielsweise auch bei Ausschreibungen wichtig, daß Interoperabilität (anbieterübergreifender Nachrichtenaustauch auf der Basis von Standards) mit im Pflichtenheft steht. Eine derzeit konkret angedachte, gesetzliche Verpflichtung zur Interoperabilität (s.o.) wäre dann gar nicht erforderlich.
Ängste/Befürchtungen
In der öffentlichen Diskussion hat man den Eindruck, daß durch vorgeschobene Argumente versucht wird, eine praktikable Interoperabilität bewußt verhindern zu wollen. Aber es geht um einen riesigen Markt mit enormen Gewinnchancen - insofern ist das auch verständlich.
Auf der einen Seite wird eine Interoperabilität von Messengern immer wieder kritisch gesehen oder sogar abgelehnt, da negative Auswirkungen befürchtet werden. Auf der anderen Seite (wie oben schon beschrieben) möchte die Politik eine Interoperabilität die gut für die Verbraucher sei verpflichtend (aber nicht konsequent) einführen.
Näher betrachtet sind die Befürchtungen und Ängste jedoch alle substanzlos und entstehen nur dann, wenn nicht das Selbe unter Interoperabilität verstanden wird. Eine Definition und Beschreibung von „Interoperabilität“ ist deshalb sehr wichtig und schützt vor solchen Mißverständnissen.
Unbegründete Ängste im Zusammenhang mit der Nutzung von internationalen Protokollen (nicht bezüglich APIs) lassen sich so schnell ausräumen, denn anerkannte Standards sind Innovationsgrundlage, bieten Funktionsvielfalt, besseren Datenschutz und mehr Privatsphäre.
Hinweis: „Besser“ und „mehr“ bedeutet nicht „sehr gut“ oder „optimal“ - hier sind P2P-Systeme geeigneter (aber weniger massentauglich). Aber mit der Möglichkeit mehrerer Chatkonten sowie der Nutzung verschiedener Serverbetreiber (oder sogar Eigenhosting) hat man viel mehr Kontrolle über die anfallenden Metadaten und Autonomie als bei klassischen „Silos“.
Industrie/Wirtschaft/Politik
In diesen Bereichen wird von manchen (teils sogar von Messengeranbietern) befürchtet, daß …
- durch Standards die Innovationskraft von einzelnen Marktteilnehmern (Messengeranbietern) gehemmt oder sogar ausgehebelt würde.
Das läßt sich jedoch schnell und eindeutig widerlegen, denn durch internationale Standards werden Neu- oder Weiterentwicklungen nicht verzögert oder gar verhindert, sondern überhaupt erst ermöglicht und gefördert. Das ist in allen Bereichen und nicht nur der Informationstechnologie so und unbestritten. Nur deshalb gibt es Standards. Unabhängig von definierten Standards kann jede Entwicklungsfirma aufbauend auf Standards (oder auch unabhängig davon) eigene Funktionen oder sogar Speziallösungen entwickeln.
WhatsApp z.B. basiert auf dem Protokoll und internationalen Standard „XMPP“ - trotzdem sind Weiterentwicklungen (z.B. Verschlüsselung MLS) oder Mehrgerätefunktionalität (Nachrichtensynchronisation), Telefonnummernunabhängigkeit, mehrere Chatkonten, Verfügbarkeit auf Mobilgeräten usw. Merkmale der meisten modernen Messenger.
Privatbereich
Privatnutzer haben dagegen ganz andere Ängste und Befürchtungen:
Verlustangst von bisher lieb gewonnenen und praktischen Funktionen bei Nutzern, die sich deswegen evtl. speziell bei Messengersystem XY angemeldet haben.
Durch eine Interoperabilität auf der Basis von internationalen Standards ist mit keinerlei Reduzierung in der Funktionsvielfalt zu rechnen. Jeder Anbieter kann auf Basis von Standards (HTTPS, IMAP, USB, HDMI, … und auch XMPP) individuelle Zusatzfunktionen für seinen Bereich (z.B. speziell für Firmenkunden) entwickeln und implementieren!
Bisher bestehende Funktionen von geschlossenen Messengerlösungen können innerhalb dieses Systems weiterhin verwendet werden. Durch eine mögliche und nicht zwingende Interoperabilität ist das auch nicht gefährdet, denn letztendlich ist „Chat“ nichts anderes als „E-Mail mit Onlinefunktionalität“: Auch bei E-Mail gibt es unzählige/unterschiedliche Anwendungen und viele Firmen, die sich auf Soft-/Hardware mit verschiedensten Zusatzfunktionen spezialisiert haben. Freie Messenger sind, wie alle Freie Software, aufgrund des für alle verfügbaren Programmcodes besonders für solche Spezialentwicklungen geeignet.
Angst vor einer unberechtigten Weitergabe von Nutzerdaten an andere Systeme, die man selbst bewußt nicht nutzen möchte.
Muß man z.B. um Nachrichten von außerhalb an WhatsApp zu senden Facebook per API seine Telefonnummer mitteilen? Das wäre fatal.
Durch das Verwenden von internationalen Protokollen wird der Datenschutz und die Privatsphäre weder beschnitten oder eingeschränkt. Ein wichtiger Punkt dabei ist auch die Datenhoheit: Um anbieterübergreifend kommunizieren zu wollen, müssen keine Datenbestände von Anbieter A nach Anbieter B übertragen oder abgeglichen werden.
Durch das Verhindern von zentralen Strukturen kann zudem jeder selbst oder auch beispielsweise der Arbeitgeber für sich entscheiden, wo die eigenen Daten (eigene Chatkonten, Kontakte, Gesprächsverläufe, …) liegen sollen und welche Datenspuren man wo hinterlassen möchte.
Befürchtung von unbemerkter Ausspähung über angenommene Einfallstore bei „sicheren“ Messengern.
Interoperablität bedeutet nicht, daß Systeme aufgebrochen werden. Es werden lediglich die Wege beschrieben, die für eine Kommunikation möglich sind und wie die Regeln dazu aussehen, diese Wege zu benutzen. Standardisierung bedeutet „Regelvereinbarung“ und nicht die Installation von unbekannten oder suspekten Zusatzmodulen. Eine Kommunikation ist möglich, ohne Chatkonten bei anderen Systemen haben zu müssen.
Durch die Verwendung von mehreren voneinander getrennten Chatkonten (auch bei unterschiedlichen Anbietern) kann man kann sich sogar besser vor unbemerkter Ausspähung schützen!
Angst vor Müllnachrichten (Spam)
Auch Befürchtungen zum Problem von Müllnachrichten (Spam) werden immer wieder genannt. Wenn Serverbetreiber untereinander internationale Standards nutzen, bedeutet das jedoch nicht automatisch, in der Folge mehr Müllnachrichten zu bekommen. So ist eine ggfs. nach außen hin anonymisierte Chatadresse von Nutzerkonten denkbar - am Besten mit einer durch die Nutzer selbst wählbaren Aliasadresse. So kann man eigenverantwortlich wählen, ob und wie man erreichbar ist. Müllnachrichten sind in der Regel nur ein Problem, wenn Kontaktdaten öffentlich gemacht werden - so wie das bei allen anderen Kommunikationsformen auch der Fall ist. Darüber hinaus hilft die Einstellung “Nachrichten von Unbekannten annehmen/ablehnen” hier ebenfalls.
Schaubild
Benötigt man für tatsächliche Interoperabilität eine öffentliche Föderation oder einfach nur Schnittstellen, um internationale Standards einhalten zu können? Dazu eine schematische Darstellung des Prinzips, wie das beispielhaft aussehen und ohne Interoperabilitätsverpflichtung erreicht werden kann. Für alle, die sich mit der systemischen/technischen Realisierung von Interoperabilität zwischen den Serverbetreibern beschäftigen oder dafür interessieren soll dies eine Diskussionsgrundlage darstellen - für normale Nutzer ist die Betrachtung der diesbezüglichen Hintergründe (und somit auch das Schaubild) nicht wichtig:
Das Schaubild kann auch als Druckdatei heruntergeladen werden: Interoperabilität.PDF (ca. 0,6 MB)
Es soll ein Hilfsmittel und Diskussionsgrundlage sein, um bei Gesprächen eine gemeinsame Sprache zu finden, die dann ja auch anders aussehen kann, als hier dargestellt - aber man vermeidet Mißverständnisse!
Nachfolgend der Versuch einer Definition der beiden Begriffe …
Föderation
Unter Föderation versteht man die Zusammenarbeit verschiedener Diensteanbieter (Serverbetreiber) des selben Systems. Jedoch kann es Einschränkungen geben: Im Gegensatz zu einer öffentlichen Föderation gibt es oft nur eine interne Föderation, bei der organisationsintern mehrere Server zwar verbunden sind, aber die Nutzer nicht nach außen kommunizieren können (s.o., z.B. manche Matrix-Instanzen).
Bei Föderation ist also immer wichtig zu hinterfragen, was gemeint und was möglich ist! Denn immer wieder wird auf Föderation (welche genau?) hingewiesen wird und dadurch angebliche Interoperabilität versprochen und fleißig damit geworben.
Aber Föderation ist nicht mit Interoperabilität gleichzusetzen und Föderation alleine bringt keine in der Politik geforderte Interoperabilität von Messengersystemen bzw. hilft auch nicht beim Erreichen dieses Ziels.
Interoperabilität
Im Gegensatz zur Föderation ist Interoperabilität die Fähigkeit, sich über standardisierte Schnittstellen und Protokolle (und unabhängig von Anbietern) austauschen zu können. Egal ob ein Dienst föderiert oder nicht, es müssen also standardisierte Schnittstellen/Protokolle festgelegt und genutzt werden, um interoperabel zu sein. Praxisbeispiele die man kennt sind E-Mail, Bluetooth, Telefonie, WWW, Papierformate, USB, HDMI, verschiedene DIN usw.
Auch das Bundeskartellamt (s.u.) versteht unter Interoperabilität im Zusammenhang mit Chat „die Fähigkeit unabhängiger, heterogener Messaging-Systeme oder Messenger-Clients, in verschieden hohem Maße zusammenarbeiten zu können.“
Gerade im Messengermarkt ist und wird Interoperabilität (die Zusammenarbeit unterschiedlicher Anbieter) immer wichtiger. Was man von anderen Kommunikationsformen wie Telefon und E-Mail dank öffentlicher Föderation auf der Basis von internationalen Standards kennt und als selbstverständlich voraussetzt, gibt es für „Chat“ noch nicht. Viele haben sich an unterschiedliche und untereinander inkompatible Chatsysteme/Messenger gewöhnt.
Idealerweise hat ein Kommunikationssystem jedoch (egal ob Telefon, E-Mail oder Chat) öffentliche Schnittstellen und nutzt hierfür Standards, so daß Bürger, Kunden, Lieferanten, Mitarbeiter usw. anbieterunabhängig miteinander kommunizieren können.
Internationaler Standard?
Für die Standardisierung im Internet ist die IETF (extern; Internet Engineering Task Force) zuständig und international anerkannt. Hier werden viele Standardprotokolle wie beispielsweise SMTP für E-Mail erarbeitet und durch Fortentwicklungen auf dem aktuellen Stand gehalten.
Standardprotokolle sind quasi die öffentlich vereinbarten und anerkannten Regeln zur Kommunikation.
So gibt es auch für Chat einen Standard (XMPP), der flexibel erweitert werden kann. Auf diesem aufbauend können sogar Spezialanforderungen für einzelne Bereiche (Sicherheitsstufen, Spezialverschlüsselung, abgeschottete Bereiche, Sonderfunktionen) bedarfsgerecht implementiert werden, ohne daß die grundsätzliche, föderale Funktion und der freie Informationsfluß dadurch gestört wird.
Genauso … (ja Wiederholung) … wie das auch bei anderen Kommunikationsformen (Post, Telefon, E-Mail, oder Mobilfunk) ist.
Zukunftssicherheit durch Standards
Ein Negativbeispiel dafür, wie Standards mißbraucht werden können, ist WhatsApp, das das Protokoll für eigene Zwecke verwendet, für sich abgeändert und sich abgeschottet hat. Das hat in diesem Fall zu enormen Abhängigkeiten geführt statt Zukunftssicherheit zu haben. Kleine Hintergrundinformation dazu:
In einem Posting (extern) von einem der beiden WhatsApp-Gründer wurde beispielsweise gefragt, wie man die Serversoftware „ejabberd“ für WhatsApp ‘hinbiegen’ kann. Das zeigt natürlich nicht, inwiefern WhatsApp noch heute darauf (bzw. dem ursprünglichen Servercode) basiert, aber interessant ist dieses Hintergrundwissen trotzdem. Darüber hinaus sind zumindest auch der Facebook Messenger, Google Talk KIK-Messenger, Zoom und Nintendo auf Basis des Standards XMPP entstanden.
Aber nur durch die Nutzung öffentlicher, internationaler Standards lassen sich auch bei „Chat“ Mehrfachinvestitionen von Steuergeldern in unterschiedliche Systeme vermeiden und wie in allen Bereichen (Baubranche, Entwicklung, Verwaltung, Finanzwesen, …) gilt:
Anerkannte Standards sind der Garant für Innovation und Zukunftssicherheit! |
Jeder investierte Euro in Lösungen, die Standards unterstützen und einhalten, kommt quasi der Öffentlichkeit zu Gute, denn genauso, wie E-Mail oder Telefon keiner einzelnen Firma gehören, ist das auch bei „Chat“ - es ist (standardisiertes) Allgemeingut. Es ist erprobt und erfolgreich im Einsatz. Oft auch im Hintergrund wie kleine Beispiele aus dem Bildungsbereich zeigen:
Bei der Lernplattform „Moodle“ (extern) ist es möglich, auch per standardisierter Chat-Schnittstelle System-Mitteilungen (extern) an die Nutzer zu versenden. Sehr lobenswert. Auch die E-Mail-Konten für 22.000 Lehrkräfte in Thüringen sind nicht nur reine E-Mail-Adressen, sondern gleichzeitig auch Chatadressen (nur weiß das kaum eine Lehrkraft).
Eine öffentliche Interoperabilität durch das Einhalten von Standards ist gerade für die Frage des Einsatzes von Chatsystemen bei öffentlichen Einrichtungen und in der Bürgerkommunikation jedoch ein wesentlicher Punkt. Schließlich geht es nicht nur um Unabhängigkeit, sondern schlicht auch um die sinnvolle Verwendung von Steuergeldern.
XMPP bei bestehenden Diensten
Bei einer Interoperabilitätsverpflichtung auf der Basis von XMPP hätte es ironischerweise gerade Meta/Facebook am einfachsten, denn WhatsApp wurde auf der Grundlage von XMPP erstellt. Die Zurverfügungstellung einer Schnittstelle wäre also technisch relativ einfach und schnell möglich. Messenger/Videokonferenzsysteme, die XMPP beinhalten oder sich in der Vergangenheit schon damit beschäftigt haben:
- WhatsApp: Basiert auf XMPP; die (aktuell nicht sichtbare aber verwendete) Chatadresse ist: ‘+Telefonnummer@whatsapp.com’ Querverweis
- Wire: Hat sich schon 2019 gedanklich damit befasst Quelle (extern)
- Jitsi Meet: Auch hier wird XMPP für die Chatfunktion verwendet Quelle (extern)
- Zoom: „Zoom communications chat is based on the XMPP standard“ Quelle (extern) Die (aktuell nicht sichtbare aber verwendete) Chatadresse ist: ‘username@xmpp.zoom.us’
Brücken
Beim Einsatz von Brücken zu standardisiertem Chat ist es möglich, mit anderen Systemen zu kommunizieren. Aber das geht in diesem Fall nur bedingt, denn Brücken sind quasi nur eingeschränkte Schnittstellen, die ein Protokoll nur teilweise abdecken bzw. durch Schattennutzer („Puppen“) realisieren. Eine solche Brücke kann schon bei kleinen Änderungen am anderen System Fehler zur Folge haben oder komplett versagen. Brücken gibt es von und für verschiedene Systeme.
Grundlegende Funktionen wie zum Beispiel der ganz normale Nachrichtenversand funktionieren in der Regel einigermaßen gut. Für tiefergehende Funktionen wie beispielsweise die zuverlässige Zurverfügungstellung des Onlinestatus’ müssten jedoch mehr Details des Standards integriert werden.
Kompliziert und fast schon visionär wird es dann, wenn ganze Chatgruppen oder öffentliche Chaträume über verschiedene proprietäre und nicht standardkonforme Systeme hinweg und dann ggfs. auch noch verschlüsselt funktionieren sollen.
Deshalb sind manche Brücken eher Krücken.
Brücken zu WhatsApp
Bei „Brücken zu WhatsApp“ (oder anderen geschlossenen Systemen) sollte hinterfragt werden, ob diese …
- illegal sind,
- von Meta/Facebook inoffiziell geduldet,
- offiziell genehmigt oder
- ob eventuell sogar eine gegenseitige Vereinbarung getroffen wurde (gibt es das?).
Denn lt. deren Nutzungsbedingungen (extern; „terms of Service = „TOS“) ist folgendes eindeutig nicht erlaubt:
“Zulässige Nutzung unserer Dienste
Du darfst weder direkt oder indirekt noch durch automatisierte oder sonstige Methoden unsere Dienste auf unzulässige oder unberechtigte Arten die uns, unsere Dienste, Systeme, Benutzer oder andere belasten oder beeinträchtigen bzw. ihnen schaden, nutzen oder diese kopieren, anpassen, ändern, verbreiten, lizenzieren, unterlizenzierer, übertragen, anzeigen, vorfüren oder anderweitig ausnutzen bzw. auf sie zugreifen …”
Da WhatsApp jedoch auch per Web-Client im Browser nutzbar ist, gibt es eine „Web-Schnittstelle“, die für (illegale?) Brücken ausgenutzt werden kann. Schön wenn man die Verantwortung dann mal wieder auf die Nutzer schieben kann … Ganz abgesehen davon ist man nicht von WhatsApp unabhängig, denn man benötigt bei WhatsApp weiterhin/trotzdem eine Telefonnummer zum Registrieren und hat dort ein Konto, um den darauf aufbauenden Web-Dienst zu nutzen.
Hinweise von Anbietern wie …
„Die Brücke zu nutzen hat im Regelfall keine Sperre durch den Anbieter zur Folge.“
… sind nicht ohne Grund so formuliert. Ohne den originalen Client gelegentlich mal zu öffnen kann es sein, daß das WhatsApp-Konto und somit auch die Brücke vielleicht doch irgendwann nicht mehr geht.
Werbeversprechen
Ein Beispiel für gewagte und fast schon unlautere Werbeversprechen zur „Interoperabilität“ ist das Marketing des TI-Messengers vom deutschen Gesundheitswesen Gematik (extern):
“TI-Messenger - Der neue Standard für sicheres, interoperables Instant Messaging im deutschen Gesundheitswesen“
“… Interoperabilität - und somit den sektoren- und anbieterübergreifenden Austausch …“
Super - Interoperabilität! Aber was versteht die Firma tatsächlich darunter? Das steht weit hinten in deren Konzeptpapier (PDF) (extern):
“6.3 TI-Messenger-Föderation
Die TI-Messenger-Anwendung unterstützt die Föderationsmechanismen des Matrix-Protokolls um Homeserver und Domains verschiedener TI-Messenger Anbieter nutzen zu können. Die Föderation ist jedoch auf Homeserver der TI-Messenger Anbieter beschränkt. Homeserver anderer Matrix Messenger Anbieter sind ausgeschlossen.“
“Homeserver anderer Matrix Messenger Anbieter sind ausgeschlossen.“ bedeutet: Keine öffentliche Föderation und keine offene Interoperabilität in der Praxis. Also etwas ganz anderes als das, was auf der Startseite mehrfach angepriesen und von unbedarften Lesern so verstanden wird.
Interoperabilität ist so nicht möglich und wird dadurch auch nicht verbessert. Vorsicht also, wenn Interoperabilität versprochen wird!
Oft sind große Installationen von Messengerlösungen für eine rein interne Kommunikation gedacht und so konfiguriert, daß keine öffentliche Föderation erlaubt ist. Ganz zu schweigen von einer echten Interoperabilität, denn theoretisch mögliche Schnittstellen zum Standardprotokoll werden in der Praxis oft nicht aktiviert.
Sektoruntersuchung des Bundeskartellamts
Interoperabilität bei Messengern betrifft jeden und wird auch auf Bundesebene Thema. 2021 hat das Bundeskartellamt eine Sektoruntersuchung hierzu durchgeführt. Der Fragebogen (extern) ist öffentlich einsehbar und manche Fragen des Bundeskartellamts sind insbesondere in Bezug auf Standards sehr interessant.
Jedoch sind Befürchtungen oder gar Ängste, Interoperabilität auf der Basis von Standards würde den Datenschutz oder die Privatsphäre gefährden/aushöhlen, unbegründet!
Denn die Verwendung von gemeinsamen Regeln für die Kommunikation (=Interoperabilität) bedeutet nicht, daß die Daten auch allen zugänglich sind. Kein Anbieter hat Zugriff auf den Datenbestand und den Nachrichtenverlauf von anderen Anbietern. Solche Gerüchte sind das Ergebnis von Halbwahrheiten oder Falschmeldungen und können nur durch sachliche Informationen aufgeklärt werden.
Zusammenfassung/Fazit
Interoperabilität ist die Fähigkeit, sich unabhängig von Anbietern über standardisierte Schnittstellen austauschen zu können. |
Interoperabilität ist dann vorhanden, wenn z.B. bei Kontaktdaten auf Internetseiten oder auf Visitenkarten neben der Postadresse, der Telefonnummer und E-Mail-Adresse auch noch die Chatadresse steht.
Die einfachste, schnellste und kostengünstigste Art, am Markt eine Interoperabilität bei Messengern zu erreichen ist es , selbst Produkte einzusetzen, die internationale Standards einhalten und z.B. bei Ausschreibungen das ebenfalls zu berücksichtigen und zu fordern. |
Man sollte sich bewußt sein:
- „Föderation“ bedeutet nicht automatisch „öffentliche Föderation!“
- Föderation ist NICHT mit Interoperabilität gleichzusetzen!
- Wenn „Interoperabilität“ versprochen wird, muß hinterfragt werden, was darunter verstanden wird!
- Interoperabilität muß öffentlich sein!
Anerkannte Standards sind der Garant für Innovation und Zukunftssicherheit und nur durch das Einhalten von internationalen Standards wird tatsächliche Interoperabilität ermöglicht. |
Die Politik/Verwaltung muß ihrer öffentlichen Vorbildfunktion gerecht werden. Noch wird bei Messengern zu viel auf Lobbyisten und vermeintliche Spezialisten der Softwarehersteller gehört - digitale Souveränität, Nachhaltigkeit und Freiheit sollten jedoch auch beim Chatten Einzug halten.
Künftig sollte es nicht mehr heißen „Ich schicke dir das per WhatsApp/Threema/Signal/…“ sondern wie bei E-Mail ganz normal „Ich schicke dir das per Chat“.
Ergänzende Informationen:
Datum: 16.04.2024
Rechte: CC BY-SA
Autoren: Diverse (Initiative Freie Messenger)
Alle Artikel/Gedanken rund um das Thema Messenger:
Digital Markets Act (DMA)
Gedanken
Vorwort
Auf Bundes- als auch auf europäischer Ebene gibt es Bestrebungen, vor allem die großen Messenger-Anbieter zu einer gewissen Offenheit (nicht Interoperabilität) zu zwingen. Auf EU-Ebene ist das das Gesetz über digitale Märkte - der sogenannte „Digital Markets Act (DMA)“ (extern). Auch hier hören Verantwortliche gerne auf Lobbyisten und in der Folge wird gerne auf Spezialisten, Technikexperten oder spezielle Ausschüsse verwiesen - vermutlich, nur um nicht selbst in der Verantwortung stehen zu müssen …
Dabei sind Standards sind in allen Bereichen (Technik, Produktion, Bildung, Kommunikation, IT, Landwirtschaft, Ernährung, Logistik, Transport, …) elementar, akzeptiert und unbestritten erforderlich - aber ausgerechnet bei der Messenger-Kommunikation meinen viele, daß man kann auf internationale Standards verzichten kann.
Wer hat hier schon wieder erfolgreich Lobbyarbeit betrieben?!
Denn so wie es aktuell aussieht, möchte die EU keinen (existierenden) Standard zur Verbesserung der Interoperabilität nutzen oder fördern, sondern nur einzelne große Anbieter dazu verpflichten, lediglich sogenannte “APIs” zur Verfügung zu stellen. Eine “API“ ist die Möglichkeit, anbieterspezifisch gewisse Daten auszutauschen. Ein gemeinsamer Standard ist das jedoch leider nicht! In der Folge wird es für jedes Großunternehmen, das von dem DMA im Visier ist eine eigene „kleine Schnittstelle“ geben und die vielen anderen Anbieter müssen ihre Programme/Apps für die „Großen“ individuell anpassen.
Inhalt
“Der DMA erfasst in seinem Anwendungsbereich nur die großen Unternehmen, die 7,5 / 75 Mrd EUR Jahresumsatz / Marktkapitalisierung sowie zusätzlich 45 mio monatlich End-User sowie 10.000 jährliche Business user in der EU haben. Interoperabilitätsschnittstellen müssen nur von den Unternehmen im Anwendungsbereich zur Verfügung gestellt werden, nicht aber von allen anderen Messengern genutzt werden (ein Verpflichtung, diese Interoperabilitätmöglichkeit zu nutzen, gibt es also für Messenger nicht per se).“
Der Digital Marktes Act ist somit lediglich auf spezielle Konzerne zugeschnitten und das bringt die grundsätzliche Interoperabilität nicht wirklich weiter. Vermutlich deshalb wird der DMA von manchen als Papiertiger angesehen.
Eine „allgemeine Interoperabilität“ auf der Basis von Standards geht jedoch weit über den ‘Digital Markets Act’ hinaus (ließe sich jedoch durch Eigeninitiative relativ einfach erreichen).
Technische Details
Im Zusammenhang mit dem DMA wird auch immer gleich sehr tief in technische Details eingestiegen, auf eine gemeinsame Verschlüsselung bestanden, diese zur Bedingung gemacht oder gar als Bedrohung angesehen (zur Verschüsselung gibt es mit „MLS“ entsprechende Überlegungen). Wie bei anderen Kommunikationsformen auch, sollte erst der unabhängige Nachrichtenaustausch standardisiert werden und darauf aufbauend eine für den Nutzer je nach Bedarf optionale Verschlüsselung. Auch sind Brücken generell und von jedem System aus zwar ein Teilschritt in Richtung Interoperabilität, jedoch nicht die Lösung.
Der sehr technisch geprägte Gesetzesentwurf ist somit auch keine Lösung für eine Interoperabilität bei Messengern sondern nur der Zwang zur individuellen Öffnung für Großkonzerne.
Übersetzung
Leider gibt es noch keine öffentlich einsehbare deutsche Übersetzung des Entwurfs (extern).
Die [deutsche] Übersetzung wird voraussichtlich zur Plenarabstimmung kurz vor oder nach der Sommerpause (d.h. entweder Juli oder September [2022] vorliegen).
Und der aktuelle Entwurf selbst ist ebenfalls nicht öffentlich verfügbar (falls doch, bitte ich um eine kurze Information >> Kontakt <<). Es wurde jedoch mal von ca. 400 Seiten gemunkelt, weshalb eine konkrete Quelle zur Bestätigung/Korrektur sehr interessant wäre.
Schon der Vorschlag für die Verordnung des europäischen Parlaments und des Rates über wettbewerbsfähige und faire Märkte im digitalen Sektor (Gesetz über digitale Märkte) von 15.12.2020 war schon 89 Seiten (extern) lang - genauso wie der Vorschlag vom 01.06.2021 zu Änderungen am Gesetzesenwurf mit 90 Seiten (extern) …
An technisch umfangreichen Beschreibungen zur gesetzlichen Verpflichtung zur Interoperabilität Öffnung mittels DMA mangelt es also nicht. Trotzdem wird von “keine Überregulierung” gesprochen.
Zudem sind Texte, die nicht in der eigenen Muttersprache vorliegen, deutlich schwerer zu verstehen, man muß sich auf irgendwelche unverbindlich übersetzte Zusammenfassungen verlassen und Mißverständnisse sind vorprogrammiert.
Sichtweise
Man kann Interoperabilität aus der Position von geschlossenen Messengern sehen oder - und das ist eine Überlegung wert - aus einer gesellschaftlichen Position und dem Blick auf unterschiedliche Kommunikationsformen, von denen „Chat“ lediglich eine davon ist.
Denn bezüglich der anbieterunabhängigen Kommunikation sollte es keinen Unterschied geben. Egal ob Telefon, E-Mail, Briefpost, Telefax, Mobilfunk oder eben auch „Chat“ – bei allen ist echte Interoperabilität nur auf der Basis von internationalen Standards möglich! Der einzige tatsächliche Systemunterschied zwischen beispielsweise „E-Mail“ und „Chat“ ist die mögliche Status-Übermittlung (z.B. Online, tippt gerade).
Auf alle Fälle wäre das dann mit einem entsprechend hohen bürokratischen Aufwand verbunden und eine eigentlich unnötige Überregulierung (wieviele Seiten hat das Papier?). Der Bundestagsabgeordnete und EU-Parlamentarier Andreas Schwab (extern) geht jedoch vom Gegenteil aus:
… Vor allem aber vermeidet das Gesetz jede Form der Überregulierung für kleine Unternehmen. …
Was zu folgenden Fragen führt:
Fragen
Wenn nun lediglich wenige große Konzerne jeweils individuelle Schnittstellen öffnen müssen, unzählige kleine Anbieter weiterhin ihre in sich geschlossenen und nach außen hin abgeschotteten Systeme verwenden und die Politik kein Vorbild in der Nutzung von Standards ist – muss der Bürger dann in der Folge zig verschiedene, geschlossene Messenger nutzen? Kann man dann erst nur den Umweg „über die Großen“ nehmen? Welche Messenger-Anbieter wären das konkret neben Meta/Facebook?
Es gibt schon viele voneinander getrennte Messenger-Inseln für:
- Beruf/Arbeitgeber,
- als Mitglied einer BOS (Feuerwehr, Polizei, Rettungsdienst, …),
- als Elternteil für die Schule (ggfs. mehrere),
- für Bankgeschäfte,
- für die Bundeswehr,
- als Kirchenmitglied,
- für die Korrespondenz mit dem Rechtsanwalt,
- als Patient,
- für das Finanzamt,
- für das Rathaus
- und dann noch Privat …
Wäre es deshalb nicht sinnvoll, einen gemeinsamen Kommunikationsweg auf unterschiedliche Arten und je nach Bedarf zu nutzen?
Also genau so, wie das bei allen anderen Kommunikationsformen wie Telefon, E-Mail, Browser, Telefax oder sogar der Briefpost ganz selbstverständlich -mal mit und mal ohne Identifizierung des Gegenübers- genutzt wird? Es werden Einschreiben versendet, es gibt die Möglichkeit für PGP-verschlüsselte E-Mails, verschlüsselte PDF-Dateien, Post-Ident, gegenseitiges Verifizieren per QR-Code, Geheimnummern, Schlüsseldateien, …
So kann auch „Chat“ (der standardisierte Kommunikationskanal) für viele Zwecke und Nachrichten verwendet werden, ohne daß der Datenschutz oder die Sicherheit leiden müssen. Auch bei dieser Kommunikationsform kann man unverschlüsselt, verschlüsselt (geräte- oder auch nutzerbezogen) sowie auf unterschiedliche Arten authentifiziert bzw. identifiziert Schreiben – oder Chat auch organisationsintern für spezielle Zwecke z.B. als Teammessenger nutzen.
Neben den anvisierten Großkonzernen wie Meta & Co. gibt es auch noch viele nicht betroffene Anbieter wie Threema, Signal, Wire - aber auch kleinere Serverbetreiber, die zum Beispiel von Unternehmen, Bildungseinrichtungen, Vereinen oder auch Privatpersonen selbst betrieben werden.
Wird durch den DMA angestrebt oder zumindest gefördert, daß Nutzer von nicht von den Regelungen betroffenen Anbietern direkt miteinander kommunizieren können?
Welche Wettbewerbsvorteile/-nachteile werden bei vom DMA nicht betroffenen Anbietern gesehen?
Ist „Chatten über E-Mail“ von der angestrebten EU-Regelungen betroffen?
Wenn ja: Warum? Denn bei E-Mail werden internationale Standards großteils eingehalten und es gibt dadurch schon Interoperabilität … ?
Wenn nein: Warum nicht? Was sind die technischen Unterschiede zwischen E-Mail (IMAP) und Chat (XMPP) außer Statusangaben wie “online” oder “tippt gerade”?!
Unterschiedliche Meinungen
Zum Thema Interoperabilitätsverpflichtung / Digital Markets Act (DMA) gibt es sehr unterschiedliche Meinungen und Gedanken:
Fazit
Aus der gesellschaftlichen Sicht scheint weniger die „Öffnung für andere Messenger“ als das Problem, sondern eher die fehlende Bereitwilligkeit zur Nutzung von vorhandenen Standards.
Eine politisch verordnete (gesetzliche) Verpflichtung zur Öffnung wäre bei cleverem Vorgehen seitens der Politik gar nicht erforderlich. Statt dessen sollte besser eine Selbstverpflichtung der Politik/Verwaltung zum Verwenden internationaler Standards das Ziel sein.
Denn die Kernfrage bleibt:
Was unterscheidet „Chat“ technisch oder rechtlich von anderen elektronischen Kommunikationsformen (außer dem zusätzlichen Merkmal „mögliche Statusübertragung“)?!
Man kann an alle verantwortlichen Politiker also lediglich appellieren, hier ihrer öffentlichen Vorbildfunktion gerecht zu werden und über den DMA hinaus anbieterunabhängigen Chat auf der Basis des internationalen Standards (XMPP) zumindest als Kontaktmöglichkeit anzubieten. Die Lösung liegt auf dem Tisch – man muß nur zugreifen und selbst aktiv werden.
Ergänzende Informationen:
Datum: 14.06.2024
Rechte: CC BY-SA
Autoren: Diverse (Initiative Freie Messenger)
Alle Artikel/Gedanken rund um das Thema Messenger:
- Lesezeit: ca. 2 Minuten / ganze Rubrik: 10 Minuten - |
Unter Verschlüsselung verstehen viele nur die “Ende-zu Ende”-Verschlüsselung, die dafür sorgt, dass niemand außer den jeweiligen Teilnehmern die ausgetauschten Inhalte (mit)lesen kann. Verschlüsselung ist jedoch viel mehr, denn zu einer sicheren und nachvollziehbaren Verschlüsselung (Kryptografie) gehören sogenannte Schutzziele:
- Vertraulichkeit (Daten dürfen lediglich von Berechtigten gelesen bzw. modifiziert werden. Dies gilt sowohl beim Zugriff auf gespeicherte Daten, wie auch während der Datenübertragung
- Integrität (Daten dürfen nicht unautorisiert und unbemerkt verändert werden. Alle Änderungen müssen nachvollziehbar sein.)
- Authentizität (Nachweis der Echtheit und Glaubwürdigkeit von Daten oder Subjekten, anhand eindeutiger Identität oder Eigenschaften)
- Verbindlichkeit (Schutz vor unzulässigem Abstreiten durchgeführter Handlungen bzw. Subjekt kann nicht abstreiten, dass eine Aktion durchgeführt wurde)
Über diese Schutzziele der Kryptografie hinaus jedoch ist je nach Anforderung auch die Folgenlosigkeit gegenüber Dritten ein sehr wichtiger Punkt. Sie soll mittels “Perfect Forward Secrecy” (extern) erreicht werden. Zu deutsch bedeutet dies in etwa: “perfekte, in die Zukunft gerichtete Geheimhaltung”. Hierdurch wird sichergestellt, dass auch jemand, der die verschlüsselte Kommunikation abhört und speichert, diese nicht entschlüsseln kann, wenn er später einen Schlüssel in Erfahrung bringt.
Doppelte Ratsche
… oder „double ratchet“ ist die als „Axolotl“ (extern; PDF-Datei) von Signal entwickelte Verschlüsselungstechnik. Zwischen zwei Endstellen (deshalb „Ende-zu-Ende-Verschlüsselung“) wird für jeden neuen Verschlüsselungsvorgang der vorherige als Ausgangsbasis genommen - und die Ratsche quasi ein Stück weiter gedreht.
Die Signal-Verschlüsselungstechnik mit der doppelte Ratsche ist Grundlage für viele andere Implementierungen wie z.B. bei OMEMO (XMPP), OLM/MEGOLM (Matrix) oder andere.
Post-Quanten-Kryptografie
Im Moment versuchen die ersten Messenger (z.B. Signal) eine Verschlüsselung zu verwenden, die angeblich auch von Quantencomputern nicht in absehbarer Zeit geknackt werden kann.
Wie sicher sind unsere Daten vor künftigen Quantenhackern? Darüber streiten sich aktuell einige Kryptografen. Manche befürchten, der US-Geheimdienst NSA könnte versuchen, künftige Verschlüsselungen zu schwächen. Der US-Geheimdienst NSA hat in der Vergangenheit schon Hintertüren in Verschlüsselungssysteme eingebaut. Wiederholt sich die Geschichte? …
Quelle: spektrum.de (extern)
Eine tolle Seite mit Einführung und Spezialwissen zur Kryptografie: https://kryptografie.de/kryptografie/index.htm (extern)
Super Secreto (Buch)
Geschichtlich wird wird lt. Wikipedia (extern) in drei Epochen der Kryptographie unterschieden:
- Verschlüsselung von Hand
- Verschlüsselung mit (mechanischen) Maschinen
- Verschlüsselung mit Computern
Zur dritten Epoche der Kryptographie hat der Autor Theo Thenzer das Buch „Super Secreto“ geschrieben.
Bei Freie Messenger gibt es >> hier << (PDF-Datei; 6,4 MB) die englische Version zum Herunterladen, die der Autor freundlicherweise zur Verfügung gestellt hat.
Vielen Dank dafür!
Beschreibung:
“Super Secreto - Die Dritte Epoche der Kryptographie” gibt eine Einführung in die »streng-geheime« Kommunikation und integriert gesellschaftlich-politische Sichtweisen mit technischen Innovationen sowie Hinweisen zu praktischen Programmen und Werkzeugen zur Verschlüsselung:
Multiple, exponentielle, quantum-sichere und vor allen Dingen einfache und praktische Verschlüsselung für alle
Mit der sog. »Ende-zu-Ende«-Verschlüsselung für alle kann die Privatsphäre gesichert bleiben: nicht nur mit »GPG«, aufgrund der wachsenden Rechenkraft von Quanten-Computern idealerweise auch mit Algorithmen wie »McEliece« oder »NTRU« - oder gar einer Multi-Verschlüsselung, bei der sog. »Cipher-Text« noch weitere Male verschlüsselt wird.
Die weltweite Krise der Privatsphäre im 21. Jahrhundert umfasst zugleich die Diskussionen um ein Recht auf Verschlüsselung sowie um Einschränkungen der sog. Ende-zu-Ende-Verschlüsselung. Um vertraulich und abhörsicher zu kommunizieren, bedarf es einfacher und praktischer Verschlüsselung für alle. Doch wie kann diese wirklich allen zur Verfügung stehen?
Die Magie, lesbare Zeichen durch andere, anscheinend zufällige und damit unlesbare Zeichen zu ersetzen, hatte seit Jahrhunderten fast schon etwas Religiöses: Nur Eingeweihte in die Erfindung einer Geheimsprache konnten die Botschaften knacken. Verschlüsselung blieb Super Secreto - Top Secret - Streng Geheim!
Im Zeitalter der Smartphone- und Taschen-Computer steht sie nun allen zur Verfügung: immer raffiniertere Mathematik berechnet in unseren Messengern den sog. Cipher-Text mit entsprechenden Schlüsseln. Und beides - Schlüssel wie der verschlüsselte Text - musste früher zum Empfänger übertragen werden. In der heutigen Epoche der Kryptographie ist die Übertragung der Schlüssel nicht mehr notwendig: Der riskante Transportweg für die Schlüssel kann sogar entfallen!
Von der Faszination, wie Kryptographie abstinent wurde in der Übermittlung von Schlüsseln - welche Auswirkung es auf den Wunsch der Interessierten nach Zweitschlüsseln hat - und wie mehrfache sowie exponentielle Verschlüsselung resistent machen gegen die Entschlüsselungsversuche von Super-Quanten-Computern, … erzählt Theo Tenzer in diesem spannenden politischen, technischen und gesellschaftsrelevanten Innovations- und Wissenschaftsportrait zur Dritten Epoche der Kryptographie.
Aus dem Inhaltsverzeichnis:
…
7 Digitale und kryptografische Souveränität: Nationale, persönliche und unternehmerische ● 252
8 Apps, Programme und Tools - mit denen Lernende lernen, zum Verschlüsselungsmeister Nr. 1 ● 264
8.1 Festplattenverschlüsselung mit Veracrypt ● 264
8.2 Smoke Crypto Chat: Mobiler McEliece-Messenger ● 267
8.3 Spot-On - Bekannte Suite für Verschlüsselung ● 274
8.4 Rosetta-Crypto-Pad - Mit Konvertierungen zum Gespräch ● 278
8.5 GoldBug Messenger - Zeig uns dein GUI ● 280
8.6 Delta-Chat: POPTASTISCH beliebt ● 283
8.7 Silence - Eine SMS-App mit Ende-zu-Ende-Verschlüsselung ● 286
8.8 Conversations-App: Der alte Dinosaurier in der Mauser? ● 286
8.9 Hacker’s Keyboard: Tippen im Klartext verhindern ● 289
8.10 Föderation ohne Konten: Echo Chat Server & XMPP Server & Matrix Server & Co● 290
8.11 Netcat & Socat: Terminal-Befehle als Telekommunikationssystem? ● 299
8.12 RetroShare: Was war nochmal Turtle Hopping? ● 300
8.13 Vier Mailboxen von Freunden ohne menschliche Nummer erhalten Identifikation: Institution, Care-Of, Ozone und BitMessage ● 303
8.14 Im unsichtbaren DHT-Netz mit Briar ● 316
8.15 Verschlüsselte Dateifreigabe: Freenet & Offsystem ● 318
8.16 OnionShare - Übertragung ohne Chat ● 325
8.17 Web-Suche und P2P-URL-Sharing mit YaCy & Spot-On ● 326
8.18 Webbrowsing mit Dooble, Iron und einem Cookie-Washer● 332
8.19 Tor-Browser: Die IP-Adresse verschleiern ● 334
8.20 Ein Netzwerk mit Perspektive zum Surfen: Hallo Echo… ● 336
8.21 I2P-Netzwerk: Unsichtbar im Netzwerk-Mix ● 337
8.22 Wenn Sie UNIX können, können Sie auch GNUnet ● 338
8.23 OpenVPN - ein aufgebauter Tunnel zur Gegenstelle? ● 338
8.24 Checkpoint CryptPad ● 340
8.25 OpenStego - Ich sehe nichts, was Sie sehen können ● 341
8.26 Tails - Amnesie am Kiosk ● 342
8.27 Mumble Audio sowie Jitsi, Nextcloud und BigBlueButton Video Chat ● 343
8.28 Telegram, Threema und Wire ● 343
8.29 Mastodons dezentrales Chat-Servernet ● 345
8.30 Staatsfeinde Nr. 1: Bargeld und mikrofonfreie Räume verhindern gläserne Menschen ● 346
8.31 Kryptographische Cafeteria ● 348
9 Interoperabilität, Kongruenz und Interkonnektivität von schottischen Eiern ● 350
9.1 Interoperabilität: nicht nur technisch ein hoffnungsloses Unterfangen? ● 350
9.2 Big-7-Studie: Open-Source Messenger im Vergleich ● 354
9.3 Messenger Scorecards: Zur Vollständigkeit der kryptographischen Kriterien ● 361
9.4 Mögliche Empfehlungen für die Standardisierung und Interoperabilität von Messengern ● 367
9.5 Technischer Ausblick: Das Fell des schottischen Eies - Staatsserver als Overlay-Netz? ● 372
…
Gedanken zur „Ende-zu-Ende-Verschlüsselung“
Dieses Thema füllt Bibliotheksregale - mit diesen Gedanken sollen jedoch keine Handlungsanweisungen oder Lösungsvorschläge gemacht werden, sondern sie sollen eine Anregung zum weiteren Nachdenken sein.
Bevor man über die Ende-zu-Ende-Verschlüsselung spricht, muß jedoch kurz auf „Sicherheit“ eingegangen werden, da das miteinander zu tun hat. Allerdings ist Sicherheit/Pseudosicherheit ein so großes und wichtiges Thema, daß es hierzu separate „Gedanken“ gibt - hier die kurze Zusammenfassung:
Wichtig zu wissen:
1. Verschlüsselung und Sicherheit dürfen nicht gleichgesetzt werden!
2. Jeder kann etwas anderes unter Sicherheit verstehen!
3. Verschlüsselung ist nur ein Teil von Sicherheit!
Ende-zu-Ende-Verschlüsselung
Die „Ende-zu-Ende-Verschlüsselung” ist eine Übertragungsweise von verschlüsselten Daten in Netzwerken. Dabei wird die vom Absender verschlüsselte Nachricht unverändert auch über mehrere Rechner bis zum Empfänger übertragen. Abgekürzt findet man oft auch „E2E“ oder „E2EE“ (aus dem englischen: „end-to-end“ bzw. „end-to-end-encryption“).
Einsatzzweck
Auf der einen Seite scheint der Einsatz kompliziert - ja. Auf der anderen Seite jedoch ist eine Ende-zu-Ende-Verschlüsselung sehr gut und sinnvoll, denn Beispiele/Argumente gibt es sowohl für geschäftliche als auch private Zwecke:
„Ich möchte E2EE, da ich den Server nicht selbst betreibe.“
(Wenn man fremden Leuten die Inhalte nicht zugänglich machen möchte.)
„Ich möchte E2EE, da ich den Server selbst betreibe.“
(In einer Familie, bei der ein Familienmitglied gleichzeitig der Serveradministrator ist und ohne Verschlüsselung die Nachrichten der anderen Familienmitglieder mitlesen könnte und das nicht will.)
Es spricht also auch vieles (außer die Bequemlichkeit) dafür. Grundsätzlich sollte jeder eine Ende-zu-Ende-Verschlüsselung nutzen, wenn das sinnvoll ist - aber nur, wenn das Prinzip verstanden wurde.
Verifizierung
Unabhängig davon, ob eine Verschlüsselung aktiviert ist oder nicht, die größte Schwachstelle und das schwächste Glied ist im Regelfall das jeweilige Endgerät bzw. der Mensch, der dieses bedient. Und eine Ende-Zu-Ende-Verschlüsselung ist nur dann sinnvoll, wenn die jeweiligen Schlüssel ausschließlich auf den Endgeräten liegen. Wenn die privaten Schlüssel auf Servern sind, ist es noch nicht einmal erforderlich, Hintertüren (sog. “backdoors”) in Programme einzubauen, um Daten unbemerkt auszuspähen.
Leider verstehen viele nicht, daß bei einer echten Ende-zu-Ende-Verschlüsselung jedes eingesetzte Gerät von den anderen verifiziert werden muss - das ist wichtig!
Genau diese erforderliche Überprüfung wird von Herstellern/Verkäufern oft verschwiegen und von Nutzern oft nicht gemacht. Hauptsache im Prospekt oder im Chat steht „Ende-zu-Ende-verschlüsselt“: Dann ist alles gut - und alles andere plötzlich nicht mehr wichtig und wird verdrängt.
Dazu kommt, daß „E2E“ in den letzten Jahren immer mehr zu einem Hauptargument und Marketinginstrument (u.a. auch von WhatsApp/Facebook) gemacht wurde. Man könnte den Eindruck bekommen, daß der Hype um die „E2E“-Verschlüsselung von der Messengerindustrie verursacht wurde und daß versucht wird, den Leuten zu suggerieren „Ihr braucht das unbedingt zum Leben!“.
Aber wer lautstark eine „sichere“ Verschlüsselung anpreist, kann und will oft andere blenden und dadurch kaum bemerkt und nebenbei wertvolle Metadaten gewinnen. Das heißt, dadurch werden Datenschutz und Privatsphäre in den Hintergrund gerückt.
Auf der anderen Seite entspricht das manuelle Nichtverifizieren von Schlüsseln dann dem „TOFU“-Prinzip (trust on first use = Vertrauen bei der ersten Nutzung). Und das hat einen ganz eigenen Charm: Wenn beim initialen Verbindungsaufbau kein Angreifer dazwischen war, dann funktioniert alles ohne manuellen Aufwand nämlich sehr gut. Für normale Sicherheitsansprüche reicht das auf alle Fälle aus - aber wer weiß schon, was normal ist.
Erwartet und braucht ein WhatsApp-Nutzer tatsächlich eine echte und geprüfte Ende-zu-Ende-Verschlüsselung!? Braucht man die wirklich oder hat man die zu wollen?
Transportverschlüsselung
Unabhängig von der „Ende-zu-Ende-Verschlüsselung“ gibt es auch noch die „Transport-/Leitungsverschlüsselung“ (oder auch „Punkt-zu-Punkt-Verschlüsselung“). Bei dieser Übertragungsweise wird die Nachricht nur jeweils für den jeweiligen Nachbarrechner verschlüsselt. Dieses Verfahren wird beispielsweise auch beim Aufruf von „sicheren“ Internetseiten angewendet.
Beide Übertragungsarten haben Stärken und Schwächen - aber sie können auch kombiniert eingesetzt werden. Eine bildhafte Beschreibung der Unterschiede sowie die Kombinationsmöglichkeit folgt weiter unten.
Wird die Ende-zu-Ende-Verschüsselung überbewertet?
Warum werden Geschäftsunterlagen, vertrauliche und sensible Dokumente usw. oft ohne Verschlüsselung (z.B. PGP/GPG (extern)) per E-Mail versendet und bei Geplapper (Chat) sind auf einmal „In die Zukunft gerichtete Sicherheit“ und „Abstreitbarkeit“ so wichtig? Da war doch was? Stimmt:
Alle haben eine Ende-zu-Ende-Verschlüsselung „zu wollen“!
Hauptsache, es steht „verschlüsselt“ drauf. Bequemlichkeit und Pseudosicherheit ist vielen wichtiger - oder es liegt einfach an der Unwissenheit.
Vergessen darf man in diesem Zusammenhang aber nicht, daß es neben „Verschlüsselungs-Sicherheit“ auch noch andere Kriterien für die Wahl eines Messenger(systems) gibt, die individuell und unterschiedlich bewertet/gewichtet werden können:
- Freiheit,
- Privatsphäre,
- Unabhängigkeit,
- Datenschutz,
- Sicherheit,
- Funktionsumfang,
- Kosten, …
Mit diesem Wissen kann die die Frage …
„Wird die Ende-zu-Ende-Verschlüsselung überbewertet?“
… beantwortet werden: Ja, oft!
Verschlüsselungsarten und Kombinationsmöglichkeiten
Die Erläuterungsgrafik kann auch als Druckdatei heruntergeladen werden: Verschlüsselung.PDF (ca. 0,4 MB)
Der Bundesdatenschutzbeauftragte dazu:
Die Grafiken stellen die Unterschiede zwischen Transport- und Ende-zu-Ende-Verschlüsselung meines Erachtens treffend dar.
Angriffsszenarien
Was die „Sicherheit“ betrifft, kann die echte (verifizierte) Ende-zu-Ende-Verschlüsselung lediglich ein Schutz gegen ganz bestimmte Angriffsszenarien sein.
Und die in der Praxis meist verwendete unverifizierte Ende-zu-Ende-Verschlüsselung deckt noch weniger Szenarien - nämlich nur dieses:
- „Angreifer“ interessiert sich nicht (nur) für Metadaten
- sondern (auch) für Inhalte,
- hat lesenden Zugriff auf die Inhalte aber
- keinen schreibenden Zugriff auf die Inhalte und
- keinen Zugriff auf die Endgeräte.
Und daß insofern das typische Marketing der geschlossenen Messengersysteme („Datensilos“) wie WhatsApp, Signal, Threema & Co. irreführend sein kann wenn suggeriert wird, daß eine (wir nennen es mal „unechte“) Ende-zu-Ende-Verschlüsselung der entscheidende Aspekt zur Beurteilung von Lösungen ist.
- OHNE manuelle Überprüfung (Verifikation) schützt E2EE nur gegen passive Angriffe - Dritter will unbemerkt mitlesen.
- MIT manueller Überprüfung (Verifikation) jedoch auch gegen aktive Angriffe - Dritter will sich in/zwischen die Kommunikation schalten, ohne daß das die Beteiligten merken; „MITM“-Attacke („man in the middle“).
Keine Ende-zu-Ende-Verschlüsselung
Es gibt auch Fälle, bei denen keine Ende-zu-Ende-Verschlüsselung (E2EEE) sinnvoll ist und die Transportverschlüsselung vollkommen ausreicht.
Im Geschäftsumfeld sind z.B. die Stichworte „Vertretung“, „Notfall“, „Mitarbeiterwechsel“, „Sicherung“ oder auch „Nachweisbarkeit“ Hinweise auf solche Anwendungsfälle.
Was macht z.B. eine Firma, wenn wichtige Geschäftskorrespondenz nur noch von „Gekündigten“ oder „Ehemaligen“ geöffnet werden kann? Es gab schon Fälle, da wurde ein wichtiges Passwort einfach vergessen oder noch vor dem Ausscheiden versehentlich geändert.
Im privaten Umfeld praktizieren viele versierte Nutzer in der Zwischenzeit bei der Mehrheit ihrer Kontakte keine „echte“ (verifizierte/authentisierte) Ende-zu-Ende-Verschlüsselung und machen einen tatsächlichen Abgleich der Schlüssel nur bei wenigen Kontakten:
Bei denen, die verstanden haben, daß eine manuelle Verifizierung jedes Geräts/Clients erforderlich ist und z.B. ein Gerätewechsel natürlich entsprechende Folgen hat. Denn vor welchem „Angriff“ möchte man sich mit welchem Aufwand schützen?
Zusammenfassung/Fazit
Die Ende-zu-Ende-Verschlüsselung ist ein gutes Werkzeug und oft sinnvoll - aber:
Wichtig zu wissen:
1. Verschlüsselung und Sicherheit dürfen nicht gleichgesetzt werden!
2. Jeder kann etwas anderes unter Sicherheit verstehen!
3. Verschlüsselung ist nur ein Teil von Sicherheit!
Die Frage “Wird die Ende-zu-Ende-Verschlüsselung überbewertet?” kann mit einem „JA!“ beantwortet werden.
Als Teilaspekt von Sicherheit ist die Ende-zu-Ende-Verschlüsselung wichtig, wird aber oft falsch verstanden oder überbewertet! |
Ergänzende Informationen:
Datum: 14.06.2024
Rechte: CC BY-SA
Autoren: Diverse (Initiative Freie Messenger)
Alle Artikel/Gedanken rund um das Thema Messenger:
- Lesezeit: ca. 4 Minuten / ganze Rubrik: 37 Minuten - |
Bei Chat wird unter diesem Begriff allgemein eine „messengerübergreifende Kommunikation“ verstanden. Besser ist jedoch diese Definition:
Interoperabilität ist die Fähigkeit, sich unabhängig von Anbietern über standardisierte Schnittstellen und Protokolle austauschen zu können. |
Analogie:
Das System „E-Mail“ ist beispielsweise interoperabel, da jeder Nutzer einen anderen Anbieter und ein anderes E-Mail-Programm wählen kann und trotzdem alle untereinander und anbieterübergreifend kommunizieren können.
Auf europäischer Ebene gibt es mit dem Digital Markets Act Bestrebungen, vor allem die großen und bisher geschlossenen Anbieter von Messengersystemen zu einer gewissen Offenheit (nicht Interoperabilität) zu zwingen.
Unterschiede
Unter dem Wort „Netzwerk“ versteht man die technische Verbindung verschiedener Teilnehmer untereinander. Technisch gibt es eine vielzahl von möglichen Netzwerken, die auch gemischt vorkommen:

(Grafik: Wikipedia)
Grundsätzlich wird bei der nachfolgenden Unterscheidung von Messengersystemen in drei verschiedene Netzwerkstrukturen unterschieden:
Zentrale Systeme = sternförmig vernetzt
Föderale Systeme = föderal vernetzt
Verteilte Systeme = vermaschte Vernetzung (Direktverbindungen)
Zentrale Messengersysteme
Es gib einen zentrales Rechenzentrum, in dem alle Daten aller Benutzer gespeichert, vorgehalten und zur Verfügung gestellt werden:

Beispiele
Prominente Beispiele von Messengern, die jeweils ihr eigenes Netzwerk betreiben und sich von anderen abschotten:
Föderale Messengersysteme
Es gib nicht nur ein Rechenzentrum, sondern mehrere/viele/unzählige. Die Datenspeicherung ist auf die beteiligten Unternetzwerke verteilt und somit dezentral.

Beispiele
Beispiele von föderalen Messenger-Netzwerken mit Messengern, die offen sind:
Verteilte Messengersysteme
Dezentrale, vermaschte Netzwerke ergeben sich aus Direktverbindungen verschiedener Nutzer ohne zwischengeschaltete Server.
Es werden ausschließlich Verbindungen zwischen gleichberechtigten Teilnehmern des Netzwerks hergestellt.

Beispiele
Beispiele von vermaschten (Rechner-zu-Rechner-)Netzwerken mit Messengern, die alle unabhängig von irgendwelchen zentralen Stellen sind:
Spezialwissen: Netzwerkprotokolle
In jedem Netzwerk müssen die Regeln für den Datenaustausch festgelegt sein. Hierfür gibt es Protokolle, die genau dies festlegen. Eine Übersicht verschiedener Protokolle ist hier zu finden:
https://de.wikipedia.org/wiki/Liste_von_Instant-Messaging-Protokollen (extern)
https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols (extern; englisch)
Grundsätzlich gilt: |
Man muß den Menschen vertrauen, denen man Informationen zusendet - nicht einer technischen Funktion beim Empfänger, die dem Absender nur Pseudosicherheit suggeriert. |
Gedanken zur „Sicherheit/Pseudosicherheit bei Messengersystemen“
Bevor man Pseudosicherheit versteht und erkennen kann, muß man sich zunächst kurz mit Sicherheit bei der Kommunikation und der damit zusammenhängenden Funktionalität auseinandersetzen …
Sicherheit
Immer wieder wird in Berichten, Übersichten und Empfehlungen zu Messengersystemen „Sicherheit“ als besonderes Merkmal hervorgehoben. Durch „beste“ Sicherheit sollen Nutzer oft dazu bewegt werden, ein bestimmtes System zu nutzen. Aber:
- Was ist „Sicherheit“?
- Ist „Sicherheit“ für jeden das Selbe?
- Benötigt jeder eine verordnete Dosis „Sicherheit“ z.B. in Form von Ende-zu-Ende-Verschlüsselung?
Um diese Fragen beantworten zu können, sollte man kurz in sich gehen und überlegen, was man selbst unter Sicherheit überhaupt versteht. Ganz allgemein kann man Sicherheit unterscheiden in:
- Informationssicherheit/Kriminalprävention (=Security) bei der Maschinen/Technik vor Menschen geschützt werden soll und
- Betriebssicherheit / Unfallvermeidung (=Safety). Hier geht es darum, Maschinen/Technik so einzurichten und zu betreiben, um Menschen zu schützen.
Verschiedene Beispiele aus der Praxis:
- Sicherheit im Datenschutz (z.B. Hochladen von Adressbüchern, Risiken durch Link-Vorschau(extern), …) ?
- Sicherheit und Respektieren der Privatsphäre (Geheimnisse)?
- Sicherung des freien und freiheitlichen Denkens und Entscheidens?
- Rechtssicherheit?
- Übertragungssicherheit?
- Technische Sicherheit (Rückfallebenen, Datensicherungen, …)?
- Physische (z.B baulich) oder organisatorische Sicherheit (z.B. Benutzerrechte)?
- Sicherheit vor anlasslosem Mitlesen von staatlichen Stellen?
- Kompromittierte Sicherheit durch menschliche Fehler/Irrtümer?
- Ausfallsicherheit von Systemen?
oder einfach
* Zukunftssicherheit?
Denn sollte letztendlich nicht alles Handeln darauf ausgerichtet sein!?
Wichtig zu wissen:
1. Sicherheit und Verschlüsselung dürfen nicht gleichgesetzt werden!
2. Jeder kann etwas anderes unter Sicherheit verstehen!
3. Verschlüsselung ist nur ein Teil von Sicherheit!
Pseudosicherheit
In der Kürze:
Pseudosicherheit entsteht, wenn (technische) Sicherheit nur vorgegaukelt oder versprochen wird.
Viele Maßnahmen und Funktionen, die den Zugriff auf gesendete/empfangene Informationen regeln wollen bzw. die Anzeige und Weiterverarbeitung technisch beschränken sollen, gaukeln „Sicherheit“ nur vor oder sind kaum einhaltbare Versprechungen. Sie haben nichts mit Übertragungssicherheit (Verschlüsselung) oder tatsächlicher Zugriffssicherheit (Passwörter, Zutrittssysteme, …) zu tun.
Funktionen die technisch versuchen, dem Empfänger Nachrichten nur eingeschränkt zur Verfügung zu stellen sind beispielsweise:
- Bildschirmkopie-Sperre in Apps
- keine Weiterleitung von Nachrichten ermöglichen („Weiterleitung verbieten“)
- keine Speicherung auf Datenträger ermöglichen
- „selbstzerstörende“ Nachrichten
- automatische Nachrichtenlöschung nach bestimmter Zeit („Auto-Zerstörungs-Timer“)
- „Autolöschen“ bei Abmeldung
Manche dieser Funktionen können jedoch für die eigene Speicherplatzorganisation sehr hilfreich sein.
Erklärung
„Mission-Impossible“-Funktionen wie z.B. selbstzerstörende Nachrichten werden gern geglaubt und lassen sich gut verkaufen! Allerdings können alle genannten technischen Möglichkeiten dem Absender nur gefühlte Sicherheit geben können. Das bedeutet, daß eine gefährliche Pseudosicherheit suggeriert und vermarktet wird!
Es liegt in der Natur der Sache, daß einmal versandte Informationen zumindest kurz im Einflußbereich des Empfängers sind (deshalb werden sie schließlich auch versendet!). Und da der Absender in der Regel keinerlei Kontrolle über den Empfänger, dessen Umfeld und das Endgerät selbst hat, gibt es viele Möglichkeiten, durch die die genannten Funktionen in Punkto Sicherheit wirkungslos bleiben oder wirkungslos werden:
Gruppe |
Methode |
Normalnutzer |
Mitlesen durch Dritte (wird oft unterschätzt!) Weiterleiten Bildschirmkopie |
Für Clevere |
Fotografieren Kopieren über Zwischenspeicher Sicherungskopie in Cloud Kopie/Zugriff per „Fremdapp“ |
Für Spezialisten |
Sicherungsvorgänge am Gerät („Backup“) Sicherung auf 2. Gerät (Parallelinstallation) Für Android: Sicherungen am/auf PC mittels ADB (Android Debug Bridge) auch ganz schön - und ganz schön einfach - ist das Deaktivieren der Sperre für Bildschirmkopien (extern) Zitat: „This lets you take screenshots and do screen capture in apps that normally won’t let you.“ |
Für Experten/Forensiker |
Direktes Auslesen von Speicherinhalten Erstellen von gerichtsfesten Speicherabbildern für Analysezwecke |
Es ist deshalb nicht nur schwierig, sondern unmöglich einen Messenger zu finden, der einen funktionierenden Schutz vor Informationsweitergabe bieten soll und bei dem der Absender die Kontrolle über einmal versendete Inhalte behält. Wenn Inhalte angezeigt werden sollen, müssen sie an den Empfänger übertragen werden - und wenn sie einmal angekommen sind, findet sich wie aufgezeigt mindestens ein Weg …
Nachrichtenkorrektur
Ein Sonderfall ist die Nachrichtenkorrektur, denn selbst hierdurch kann Sicherheit suggeriert werden. Die Funktion ist eigentlich für eine nachträgliche Korrektur z.B. von Rechtschreibfehlern oder inhaltlichen Änderungen vorgesehen. Einmal gesendete Nachrichten können aber auch durch eine Nachrichtenkorrektur nicht gelöscht werden.
Funktionsweise:
Die ursprüngliche (erste) Nachricht bleibt auch beim Empfänger weiterhin erhalten, und die zuletzt nachfolgende „Korrektur“-Nachricht kann dann an Stelle der vorherigen angezeigt werden. Das hängt jedoch von den jeweiligen Einstellungen und Möglichkeiten der verwendeten Programme/Apps ab. Je nachdem werden beim Empfänger also alle vom Absender gesendeten Nachrichten angezeigt oder bei der Nachricht erscheint eine optische Kennzeichnung, daß diese korrigiert wurde.
Das kann weitreichende Folgen haben wie dieses Beispiel zeigt:
Man steht gemeinsam in einer Gruppe, erhält eine Nachricht und sagt: „Hey schaut mal, was xy verbreitet!“ Der Absender löscht die Nachricht und denkt „Das hat zum Glück keiner gesehen …“
Diese Funktion ist also nett und praktische, um beispielsweise Rechtschreibfehler in versendeten Nachrichten optisch zu „korrigieren“. In Verbindung mit Sicherheit sollte dies jedoch nicht gebracht werden.
Lesebestätigungen
Ergänzend noch der Hinweis, daß es oft relativ einfach ist, die äußerst praktischen Lesebestätigungen zu unterdrücken oder zu verfälschen: Einfach nach dem Nachrichtenempfang die Internetverbindung trennen und dann erst lesen.
Wenn also ein „Gelesen“-Haken noch nicht zu sehen ist, hat das gar nichts zu bedeuten und man hat diesbezüglich auch keine Sicherheit.
Entscheidungsträger
Werbeaussagen, die Pseudosicherheit versprechen, sind wie Blendgranaten. Solche „Sicherheitsfunktionen“ sollten wenn überhaupt, dann nur mit größter Vorsicht als Entscheidungskriterium verwendet werden. Denn je nach Standpunkt kann eine solche Funktion als Vorteil oder auch als Nachteil gesehen werden. Auf alle Fälle darf ein solches Kriterium nicht überbewertet werden.
Zusammenfassung/Fazit
Wichtig zu wissen:
1. Sicherheit und Verschlüsselung dürfen nicht gleichgesetzt werden!
2. Jeder kann etwas anderes unter Sicherheit verstehen!
3. Verschlüsselung ist nur ein Teil von Sicherheit!
Grundsätzlich gilt: |
Man muß den Menschen vertrauen, denen man Informationen zusendet - nicht einer technischen Funktion beim Empfänger, die dem Absender nur Pseudosicherheit suggeriert. |
Ergänzende Informationen:
Datum: 14.06.2024
Rechte: CC BY-SA
Autoren: Diverse (Initiative Freie Messenger)
Alle Artikel/Gedanken rund um das Thema Messenger:
- Lesezeit: ca. 2 Minuten / ganze Rubrik: 10 Minuten - |
Unter Verschlüsselung verstehen viele nur die “Ende-zu Ende”-Verschlüsselung, die dafür sorgt, dass niemand außer den jeweiligen Teilnehmern die ausgetauschten Inhalte (mit)lesen kann. Verschlüsselung ist jedoch viel mehr, denn zu einer sicheren und nachvollziehbaren Verschlüsselung (Kryptografie) gehören sogenannte Schutzziele:
- Vertraulichkeit (Daten dürfen lediglich von Berechtigten gelesen bzw. modifiziert werden. Dies gilt sowohl beim Zugriff auf gespeicherte Daten, wie auch während der Datenübertragung
- Integrität (Daten dürfen nicht unautorisiert und unbemerkt verändert werden. Alle Änderungen müssen nachvollziehbar sein.)
- Authentizität (Nachweis der Echtheit und Glaubwürdigkeit von Daten oder Subjekten, anhand eindeutiger Identität oder Eigenschaften)
- Verbindlichkeit (Schutz vor unzulässigem Abstreiten durchgeführter Handlungen bzw. Subjekt kann nicht abstreiten, dass eine Aktion durchgeführt wurde)
Über diese Schutzziele der Kryptografie hinaus jedoch ist je nach Anforderung auch die Folgenlosigkeit gegenüber Dritten ein sehr wichtiger Punkt. Sie soll mittels “Perfect Forward Secrecy” (extern) erreicht werden. Zu deutsch bedeutet dies in etwa: “perfekte, in die Zukunft gerichtete Geheimhaltung”. Hierdurch wird sichergestellt, dass auch jemand, der die verschlüsselte Kommunikation abhört und speichert, diese nicht entschlüsseln kann, wenn er später einen Schlüssel in Erfahrung bringt.
Doppelte Ratsche
… oder „double ratchet“ ist die als „Axolotl“ (extern; PDF-Datei) von Signal entwickelte Verschlüsselungstechnik. Zwischen zwei Endstellen (deshalb „Ende-zu-Ende-Verschlüsselung“) wird für jeden neuen Verschlüsselungsvorgang der vorherige als Ausgangsbasis genommen - und die Ratsche quasi ein Stück weiter gedreht.
Die Signal-Verschlüsselungstechnik mit der doppelte Ratsche ist Grundlage für viele andere Implementierungen wie z.B. bei OMEMO (XMPP), OLM/MEGOLM (Matrix) oder andere.
Post-Quanten-Kryptografie
Im Moment versuchen die ersten Messenger (z.B. Signal) eine Verschlüsselung zu verwenden, die angeblich auch von Quantencomputern nicht in absehbarer Zeit geknackt werden kann.
Wie sicher sind unsere Daten vor künftigen Quantenhackern? Darüber streiten sich aktuell einige Kryptografen. Manche befürchten, der US-Geheimdienst NSA könnte versuchen, künftige Verschlüsselungen zu schwächen. Der US-Geheimdienst NSA hat in der Vergangenheit schon Hintertüren in Verschlüsselungssysteme eingebaut. Wiederholt sich die Geschichte? …
Quelle: spektrum.de (extern)
Eine tolle Seite mit Einführung und Spezialwissen zur Kryptografie: https://kryptografie.de/kryptografie/index.htm (extern)
Super Secreto (Buch)
Geschichtlich wird wird lt. Wikipedia (extern) in drei Epochen der Kryptographie unterschieden:
- Verschlüsselung von Hand
- Verschlüsselung mit (mechanischen) Maschinen
- Verschlüsselung mit Computern
Zur dritten Epoche der Kryptographie hat der Autor Theo Thenzer das Buch „Super Secreto“ geschrieben.
Bei Freie Messenger gibt es >> hier << (PDF-Datei; 6,4 MB) die englische Version zum Herunterladen, die der Autor freundlicherweise zur Verfügung gestellt hat.
Vielen Dank dafür!
Beschreibung:
“Super Secreto - Die Dritte Epoche der Kryptographie” gibt eine Einführung in die »streng-geheime« Kommunikation und integriert gesellschaftlich-politische Sichtweisen mit technischen Innovationen sowie Hinweisen zu praktischen Programmen und Werkzeugen zur Verschlüsselung:
Multiple, exponentielle, quantum-sichere und vor allen Dingen einfache und praktische Verschlüsselung für alle
Mit der sog. »Ende-zu-Ende«-Verschlüsselung für alle kann die Privatsphäre gesichert bleiben: nicht nur mit »GPG«, aufgrund der wachsenden Rechenkraft von Quanten-Computern idealerweise auch mit Algorithmen wie »McEliece« oder »NTRU« - oder gar einer Multi-Verschlüsselung, bei der sog. »Cipher-Text« noch weitere Male verschlüsselt wird.
Die weltweite Krise der Privatsphäre im 21. Jahrhundert umfasst zugleich die Diskussionen um ein Recht auf Verschlüsselung sowie um Einschränkungen der sog. Ende-zu-Ende-Verschlüsselung. Um vertraulich und abhörsicher zu kommunizieren, bedarf es einfacher und praktischer Verschlüsselung für alle. Doch wie kann diese wirklich allen zur Verfügung stehen?
Die Magie, lesbare Zeichen durch andere, anscheinend zufällige und damit unlesbare Zeichen zu ersetzen, hatte seit Jahrhunderten fast schon etwas Religiöses: Nur Eingeweihte in die Erfindung einer Geheimsprache konnten die Botschaften knacken. Verschlüsselung blieb Super Secreto - Top Secret - Streng Geheim!
Im Zeitalter der Smartphone- und Taschen-Computer steht sie nun allen zur Verfügung: immer raffiniertere Mathematik berechnet in unseren Messengern den sog. Cipher-Text mit entsprechenden Schlüsseln. Und beides - Schlüssel wie der verschlüsselte Text - musste früher zum Empfänger übertragen werden. In der heutigen Epoche der Kryptographie ist die Übertragung der Schlüssel nicht mehr notwendig: Der riskante Transportweg für die Schlüssel kann sogar entfallen!
Von der Faszination, wie Kryptographie abstinent wurde in der Übermittlung von Schlüsseln - welche Auswirkung es auf den Wunsch der Interessierten nach Zweitschlüsseln hat - und wie mehrfache sowie exponentielle Verschlüsselung resistent machen gegen die Entschlüsselungsversuche von Super-Quanten-Computern, … erzählt Theo Tenzer in diesem spannenden politischen, technischen und gesellschaftsrelevanten Innovations- und Wissenschaftsportrait zur Dritten Epoche der Kryptographie.
Aus dem Inhaltsverzeichnis:
…
7 Digitale und kryptografische Souveränität: Nationale, persönliche und unternehmerische ● 252
8 Apps, Programme und Tools - mit denen Lernende lernen, zum Verschlüsselungsmeister Nr. 1 ● 264
8.1 Festplattenverschlüsselung mit Veracrypt ● 264
8.2 Smoke Crypto Chat: Mobiler McEliece-Messenger ● 267
8.3 Spot-On - Bekannte Suite für Verschlüsselung ● 274
8.4 Rosetta-Crypto-Pad - Mit Konvertierungen zum Gespräch ● 278
8.5 GoldBug Messenger - Zeig uns dein GUI ● 280
8.6 Delta-Chat: POPTASTISCH beliebt ● 283
8.7 Silence - Eine SMS-App mit Ende-zu-Ende-Verschlüsselung ● 286
8.8 Conversations-App: Der alte Dinosaurier in der Mauser? ● 286
8.9 Hacker’s Keyboard: Tippen im Klartext verhindern ● 289
8.10 Föderation ohne Konten: Echo Chat Server & XMPP Server & Matrix Server & Co● 290
8.11 Netcat & Socat: Terminal-Befehle als Telekommunikationssystem? ● 299
8.12 RetroShare: Was war nochmal Turtle Hopping? ● 300
8.13 Vier Mailboxen von Freunden ohne menschliche Nummer erhalten Identifikation: Institution, Care-Of, Ozone und BitMessage ● 303
8.14 Im unsichtbaren DHT-Netz mit Briar ● 316
8.15 Verschlüsselte Dateifreigabe: Freenet & Offsystem ● 318
8.16 OnionShare - Übertragung ohne Chat ● 325
8.17 Web-Suche und P2P-URL-Sharing mit YaCy & Spot-On ● 326
8.18 Webbrowsing mit Dooble, Iron und einem Cookie-Washer● 332
8.19 Tor-Browser: Die IP-Adresse verschleiern ● 334
8.20 Ein Netzwerk mit Perspektive zum Surfen: Hallo Echo… ● 336
8.21 I2P-Netzwerk: Unsichtbar im Netzwerk-Mix ● 337
8.22 Wenn Sie UNIX können, können Sie auch GNUnet ● 338
8.23 OpenVPN - ein aufgebauter Tunnel zur Gegenstelle? ● 338
8.24 Checkpoint CryptPad ● 340
8.25 OpenStego - Ich sehe nichts, was Sie sehen können ● 341
8.26 Tails - Amnesie am Kiosk ● 342
8.27 Mumble Audio sowie Jitsi, Nextcloud und BigBlueButton Video Chat ● 343
8.28 Telegram, Threema und Wire ● 343
8.29 Mastodons dezentrales Chat-Servernet ● 345
8.30 Staatsfeinde Nr. 1: Bargeld und mikrofonfreie Räume verhindern gläserne Menschen ● 346
8.31 Kryptographische Cafeteria ● 348
9 Interoperabilität, Kongruenz und Interkonnektivität von schottischen Eiern ● 350
9.1 Interoperabilität: nicht nur technisch ein hoffnungsloses Unterfangen? ● 350
9.2 Big-7-Studie: Open-Source Messenger im Vergleich ● 354
9.3 Messenger Scorecards: Zur Vollständigkeit der kryptographischen Kriterien ● 361
9.4 Mögliche Empfehlungen für die Standardisierung und Interoperabilität von Messengern ● 367
9.5 Technischer Ausblick: Das Fell des schottischen Eies - Staatsserver als Overlay-Netz? ● 372
…
Vorwort
Was wird unter „Anonymität“ verstanden?
- Eine Telefonnummer, die nicht mehr als Klartext lesbar ist?
- Keine Telefonnummer als Identifizierungsmerkmal?
- Keine Identifizierung der eigenen Adresse durch Dritte?
- Verwendung eines Alias’ statt des Klarnamens?
- Vermeidung oder Reduzierung von Metadaten?
- Nicht alle Chatkonten/Kontakte bei dem selben Serverbetreiber?
- Eigener Serverbetreiber sieht die Kontakte?
- Nutzung auch ohne Internet möglich?
- Verschleierung von IP-Adressen?
- Empfänger weiß nicht, von wem eine Nachricht stammt?
Man muß sich also selbst fragen, welchen Grad von Anonymität man mit welchem Aufwand (und entsprechenden Einschränkungen des Komforts) erreichen möchte. Zum Vergleich und zur Einschätzung hilft hier oft der gedankliche Vergleich zu z.B. E-Mail.
P2P-Systeme
Bieten beispielsweise alle P2P-Systeme automatisch komplette Anonymität? Nein!
Das Projekt Briar beschreibt das sehr gut und versucht Mißverständnissen vorzubeugen:
Briar verbirgt Ihre Identität nicht vor Ihren Kontakten. Es bietet Unverknüpfbarkeit, aber keine Anonymität. Das bedeutet, dass niemand sonst herausfinden kann, wer Ihre Kontakte sind, aber Ihre Kontakte könnten herausfinden, wer Sie sind.
Quelle: Briar-FAQ (extern; englisch)
Server-Systeme
Wie bei E-Mail ist eine komplett anonyme Nutzung bei serverbasierten Systemen nicht wirklich möglich - auch nicht bei XMPP oder bei Matrix. Hier steht vielmehr die Datenhoheit (wo möchte man welche Daten haben, wer darf welche Daten einsehen) im Vordergrund.
Aber durch die Nutzung unterschiedlicher Server eines Systems können Chatkonten und dazugehörige Kontakte voneinander getrennt werden. Somit sieht ein Serverbetreiber nicht, welche Metadaten bei einem anderen Serverbetreiber anfallen. Das bewußte Verteilen von Metadaten ist relativ einfach und hat auch praktische Vorteile. So kann man beispielsweise ein geschäftliches Chatkonto an Arbeitstagen aktivieren und am Wochenende deaktivieren - ist jedoch privat weiterhin per Chat erreichbar.
Push-Benachrichtigungen
Die Push-Technik bei Android- oder iOS ermöglicht eine Ent-Anonymisierung und Zuordnung auch bei angeblich „anonymen“ Messengern.
Viele Messenger werben damit, keine Kommunikationsinhalte sowie nur wenige Meta- und Bestandsdaten ihrer Nutzer:innen zu kennen. Doch die Messenger-Anbieter haben zu fast jedem Nutzer-Account einen „Push-Token“. Und die Push-Anbieter verknüpfen diese Push-IDs mit einem Nutzerkonto bei ihnen. So wird aus einer pseudonymen Messenger-ID ein Google- oder Apple-Account. Und die beinhalten jede Menge personenbezogene Daten.
… dass Ermittlungsbehörden bei Messenger-Anbietern explizit nach Push-Tokens fragen. Er bezeichnet sie als „langlebige Nutzer-IDs“. Mit dieser Information können sie dann zu Apple und Google, um weitere Nutzerdaten zu erhalten.
Quelle: https://netzpolitik.org/2023/push-dienste-behoerden-fragen-apple-und-google-nach-nutzern-von-messenger-apps/ (extern)
Weiterführende Information: https://www.kuketz-blog.de/google-firebase-verlockend-fuer-entwickler-datengrab-fuer-nutzer/ (extern)
Fazit
- Das Schlagwort „anonym“ hört sich toll an und wird deshalb auch sehr gerne im Marketing verwendet.
- Im Alltag wird anonym oft mit pseudonym verwechselt - Unterschied lt. Wikipedia (extern).
- Für Journalisten, Aktivisten, Geheimnisverräter, Terroristen usw. wichtig - für die Masse ist Anonymität im Bereich Chat jedoch nicht wirklich erforderlich.
Genauso wie die Ende-zu-Ende-Verschlüsselung ist Anonymität wichtig, wird jedoch oft überbewertet und unterschiedlich verstanden.
API
Eine Schnittstelle zur Programmierung von Anwendungen wird als „API“ (Application Programming Interface) bezeichnet. Also eine Programmierschnittstelle. Bei einer „REST API“ handelt es sich aber nicht um eine übriggebliebene Schnittstelle, sondern auch „REST“ ist eine Abkürzung für „Representational State Transfer“. „REST API“ ist quasi eine Bezeichnung dafür, wie die Kommunikation zwischen Client und Server (also zwei Maschinen) typischerweise aussieht/abläuft.
… wer noch mehr Theorie nachlesen möchte, ist bei Wikipedia (extern) und friendventure.de - was ist REST API? sehr gut aufgehoben - aber wie sieht das technisch aus, wenn die Jugend von heute Client-Server-Dienste baut, und dafür gern HTTP verwendet?
Praxisbeispiel „Bestellsystem im Café“:
Die Bedienung nimmt eine Bestellung auf, ihre App sendet dann z.B. folgende JSON-Daten per HTTP an https://das-cafe.de/api/bestellung:
{"id": 12345,
"table": 42,
"items": [
{ "name": "cappucino",
"decaf": true},
{ "name": "cheesecake",
"cream": false}]}
Typischerweise antwortet der Server dann mindestens mit “ok” oder “fehlgeschlagen, weil […]“. Je nach Dienst (z.B. Matrix) kommen ggf. auch weitere (JSON)-Daten zurück.
Am Ende zahlt man und die App sendet entsprechende Daten an https://das-cafe.de/api/bezahlung.
Auf Seite des Webservers gibt es also Code, der unter /api/bestellung
und /api/bezahlung
jeweils JSON-Daten mit bestimmten Feldern erwartet und schlaue Dinge damit tut. Das ist vergleichbar zu Funktionen einer Bibliothek in irgendeiner Programmiersprache. Die “API” (= Schnittstelle) einer solchen Bibliothek wäre, daß sie die Funktionen bestellung(42, ["cappucino", ...])
, bezahlung(42)
etc. anbietet. Wenn der Aufruf stattdessen wie im Café per HTTP passiert, nennt man’s “REST-API”. Der Anbieter der Café-Lösung bastelt einnen Dienst, denkt sich einne REST-API aus und dokumentiert sie für App-Entwickler auf der Anbieter-Webseite.
Anders als bei Schnittstellen (APIs), die quasi jeder für sein Produkt und seine Software beschreiben und veröffentlichen kann, ist das bei international standardisierten Protokollen wie sie von der IETF erarbeitet werden und dann publizierte Internetstandards sind.
In der Kürze:
„Electron“ ist eine Entwicklugsumgebung für Anwendungen, die dann letztendlich in einen „eigenen“ Browser eingebettet sind.
Vorteil: Praktisch - Eine App als Browser, funktioniert quasi überall
Nachteil: Bietet Angriffspotential - überfrachtet, großer Speicherbedarf, nicht barrierefrei
Mit Electron sind sehr viele Anwendungen realisiert: Atom, DeltaChat-Desktop, Discord-Desktop, Element-Desktop, Mattermost-Desktop, Signal-Desktop, Slack-Desktop, Threema-Desktop, Visual Studio, WhatsApp-Desktop usw.
Nachfolgend mehr zur Kritik an der unbestritten sehr erfolgreichen Entwicklungsplattform.
Barrierefreiheit
Electron ist nicht barrierefrei (“accessible”), was z.B. bedeutet, daß Sehbehinderte benachteiligt werden.
„Als blinder Benutzer habe ich Probleme bei der Verwendung von Electron-Anwendungen mit dem Orca Screenreader …“ - übersetzt von:
Injecting a Chromium Add-On in to Electron
As a blind user, I am having problems using Electron apps with the Orca screenreader for Linux. This is because Chromium, my primary browser, doesn’t support using Orca by default. It does, however, have an extension called ChromeVox to serve as a screenreader. Since both Chrome and Chromium use this screenreader, and Electron uses Chrome to function, I wonder if it then is possible to “inject” the ChromeVox screenreader in to my apps. I use inject losely, as there are some apps that I can’t readily get access to the source code of; Spotify and Slack serve as primary examples. Does anyone have some experience in this matter?
Quelle: Reddit (2017)
Über eine Information, ob/wie das heute ist, würde ich mich sehr freuen: >> Kontakt <<
Sicherheit und Datenschutz
Electron ist quasi ein vollständiger Chromebrowser mit eingebauter Zusatzfunktion (der App). Im Grunde sind Electron Apps also keine wirklichen Apps sondern ein Chromebrowser mit nur einem Tab, nämlich der App. Das bedeutet, für jede Electron App installiert man sich einen kompletten Chrome-Browser.
Es täuscht quasi ein sauber für das jeweilige Betriebssystem entwickeltes Programm vor indem es eigentlich nur die Webapplikation in Chrome bündelt. Eigentlich könnte man dann gleich die reguläre Webapplikation der App nutzen.
Problem:
Bei Browsern ist auf Grund der komplexität die Angriffsfläche entsprechend größer als bei klassischen Programmen/Apps.
Auch kommt es bei Electronapps häufiger vor, dass die Entwickler zwar ihre Software aktuell halten, aber das verwendete Electronframework nicht regelmäßig aktualisieren. Oftmals liegen Wochen oder Monate zwischen der verwendeten und verfügbaren Electronversionen. Niemand der verantwortungsvoll handelt würde jedoch seinen Browser monatelang nicht aktualisieren, unabhängig ob Chromium, Firefox oder einem anderen Browser. Bei Electronapps denken manche Entwickler leider anders.
Regelmäßige Updates sind zum Schließen von Sicherheitslücken jedoch elementar wichtig.
Ein eindrucksvolles Beispiel dafür ist bei debian (extern) zu finden.
Electron ist also weder aus Sicherheits- noch aus Datensparsamkeitsgründen (Datenschutz) zu empfehlen.
Wenn sich Apps auf „Sicherheit“ fokusieren und sich damit rühmen - gleichzeitig jedoch Electron verwenden, beißt sich das etwas. Manche empfehlen deshalb, Electron-Anwendungen nicht direkt auszuführen, sondern ausschließlich abgeschottet z.B. in einer „Sandbox“. Auch ist Electron laut dem Free Software Directory (extern) unfreie Software.
Sehr guter Artikel zum Thema: 'Electron-Apps haben eine gefährliche Achilles-Ferse'
Skype, Slack, VS Code, Atom: Electron-Apps haben eine gefährliche Achilles-Ferse
Programme, die auf dem Electron Framework basieren, können von lokalen Angreifern trojanisiert und als Angriffsplattform missbraucht werden.
Auf der Sicherheitskonferenz BSides Las Vegas hat Pavel Tsakalidis von der Sicherheitsfirma Context eine Schwachstelle in GitHubs Software-Entwicklungs-Framework Electron offengelegt, über die sich Electron-Apps mit Hintertüren und Schadcode versehen lassen. Zwar braucht der Angreifer dafür lokalen Zugriff auf ein System – Angriffe aus der Ferne sind also schwierig – unter Windows genügen allerdings einfache Nutzerrechte. Das Electron-Framework bildet die Grundlage für GitHubs Text-Editor Atom und Microsofts Visual Studio Code. Auch die Messenger Skype, WhatsApp, Signal, Wire, Cryptocat, Discord und Slack setzen es für ihre Desktop-Apps ein. Die Desktop-Clients von GitHub und Twitch sind ebenfalls potenziell betroffen.
Electron ist vor allem deshalb beliebt, weil es Entwicklern ermöglicht, mit einer Version ihrer App gleichzeitig auf Windows, macOS und Linux präsent zu sein. Es basiert auf JavaScript und Node.js und speichert Applikations-Daten unter anderem in einem Archivformat namens ASAR. Und genau hier befindet sich die Schwachstelle, die Tsakalidis nun öffentlich gemacht hat. Die ASAR-Achive einer Electron-App sind weder verschlüsselt noch digital signiert. Das erlaubte es dem Sicherheitsforscher, ein Python-Tool namens BEEMKA zu entwickeln, mit dem er diese Archive entpacken und den darin enthaltenen Code manipulieren kann. Das führt dazu, dass ein Angreifer bösartigen Code in legitimen Prozessen der App verstecken kann. Unter macOS und Linux benötigt BEEMKA dazu Administrator-Rechte, bei Windows genügt eine Anmeldung als normaler Nutzer.
Zugriff aufs Dateisystem und die Webcam
Der in die ursprünglichen Apps eingeschmuggelte Code kann auf die Webcam des Systems und das lokale Dateisystem zugreifen. Da das Betriebssystem der Applikation vertraut – die in der Regel mit einem gültigen Zertifikat des Entwicklers signiert ist – könnte ein Angreifer so sensible Daten auf dem System auslesen. In einem Video zeigt Tsakalidis, wie eine trojanisierte Version des Passwort-Managers Bitwarden Passwörter verrät, die der Code von Tsakalidis dann an einen beliebigen Webserver schicken könnte. Außerdem zeigte der Sicherheitsforscher in seinem Vortrag, wie eine manipulierte Version von Visual Studio Code den Inhalt jedes geöffneten Code-Tabs ins Internet leaken kann. So ließen sich etwa Betriebsgeheimnisse von Software-Entwicklern ausspionieren.
Die Schwachstelle ermöglicht es laut Tsakalidis aber auch, Code in interne Prozesse des Electron-Frameworks einzuschleusen. Etwa dessen eingebaute Chrome-Erweiterungen. So könnte ein Angreifer zum Beispiel Zertifikats-Checks aushebeln und mit HTTPS-verschlüsselte Kommunikation von Electron-Apps abhören. Außerdem könnte ein Angreifer still und heimlich die Update-Features von Electron-Apps manipulieren, damit sein bösartiger Code nicht von einer neuen App-Version überschrieben wird.
Electron sieht keinen Grund zum Handeln
Laut Tsakalidis wissen die Electron-Entwickler von dem Problem, da Electron-Entwickler in der Vergangenheit im Bug-Tracker des Open-Source-Projektes darum gebeten hätten, die ASAR-Archive kryptografisch abzusichern. Diese Anfragen seien von den verantwortlichen Projektentwicklern abgeblockt worden. Auf seine Kontaktversuche im Vorfeld der Veröffentlichung habe Electron nicht reagiert, so Tsakalidis. Auch auf Anfragen von heise online antwortete das Projekt bisher nicht. Der Sicherheitsforscher befürchtet, dass außer den von ihm beschriebenen lokalen Angriffen auch die Möglichkeit besteht, anderen Nutzern manipulierte Electron-Apps unterzuschieben. Wenigstens unter macOS müsste die Sicherheitsfunktion Gatekeeper allerdings die Δnderungen an der App erkennen und Alarm schlagen.
In einer Diskussion im Electron-Bug-Tracker erklärt Tsakalidis, wie er die Lücke ursprünglich entdeckt hatte. Als Teil eines Red Teams hatte er im Netz eines Kunden seiner Sicherheitsfirma die Aufgabe, Schadcode auf einem System zu verankern (Sicherheitsfoscher sprechen auch von persistence). Das gelang dem Red Team mit einem Powershell-Exploit, den sie in den ASAR-Dateien des Firmenmessengers Slack versteckten. "Jedes mal wenn Slack beim Windows-Start ausgeführt wurde, hatten wir wieder Zugriff zum internen Netz", so Tsakalidis.
Fabian A. Scherschel / (fab) / 09.08.2019 / Quelle:
https://www.heise.de/security/meldung/Skype-Slack-VS-Code-Atom-Electron-Apps-haben-eine-gefaehrliche-Achilles-Ferse-4493195.html (extern)
Mehr Infos im Netz:
In der Kürze:
Flutter ist eine Entwicklungsumgebung von Google für Anwendungen, mit der man ein und das selbe Programm für unterschiedliche Betriebssysteme entwickeltn kann. Mit Flutter sind Anwendungen realisiert wie z.B. FluffyChat (Matrix-Client).
Vorteile Grundsätzlich: Praktisch - Schnelle Entwicklung für verschiedene Betriebssysteme / funktioniert quasi überall
Vorteile gegenüber Electron: Bessere Performance, weniger Angriffspotential, weniger Speicherbedarf
Nachteile:
- barrierefrei??
- Offizieller Sicherheitshinweis (extern):
Die Entwickler sollten immer auf die aktuellste Flutter-Version verwenden (was leider nicht immer zeitnah gemacht wird). Nur so werden gefundene und behobene Sicherheitslücken in Flutter dann auch in der Flutter-Anwendung geschlossen.
Aktuelle Flutter-Version: >> hier << (extern)
Beschreibung
Flutter erschien Ende 2018 erstmals als Open-Source-Projekt und vereinfacht den Prozess der Appentwicklung von Google. Flutter ist eine Entwicklungsumgebung von plattformübergreifenden Anwendungen mit der Programmiersprache Dart. In erster Linie wird Flutter für die Entwicklung von iOS und Android Apps verwendet. Auch für macOS, Windows, Linux und Google Fuchsia lassen sich hiermit Apps entwickeln.
Für mit Flutter entwickelte Apps muss man als Programmierer nicht auf die Besonderheiten der verschiedenen Systeme achten, da diese mit nur einer Codebase entwickelt werden können.
Schnelle Ausführungsgeschwindigkeit und kurze Entwicklungszeiten sind der vorrangige Fokus von Flutter.
Aufbau
Flutter selbst verwendet die Dart Virtual Machine (Dart-VM), sowie die Grafikbibliothek Skia. Das Programm Flutter wurde in C++ geschrieben.
Dart
Die von Google entwickelte Programmiersprache Dart läuft wie JavaScript direkt als Web App im Browser und soll daher zu einem modernen Nachfolger der klassischen Web-Skriptsprache werden.
Während Flutter-Programme mit dem Transcompiler Dart2js nach JavaScript übersetzt werden und so direkt in modernen Webbrowsern laufen, lassen sie sich auf einem Server direkt ausführen.
Widget
Die objektorientierte Programmierung wird konsequent bis in die Benutzeroberfläche umgesetzt.
Die Oberfläche eines Flutter Programms besteht im Wesentlichen aus Widgets. Diese können ineinander Geschachtelt sein. Jeder angezeigte Text oder Button ist ein Widget mit unterschiedlichen Eigenschaften, die verändert werden können. Diese können sich gegenseitig beeinflussen und auf Statusänderungen von außen mit eingebauten Funktionen reagieren. Diese können darüber hinaus beliebig um zusätzliche Funktionen erweitert werden.
Vorteile
Die Programmiersprache Dart weist viele Ähnlichkeiten zu anderen Sprachen in grundlegenden Entwicklungsmechaniken auf. Die Entwicklung mit Flutter wird erheblich beschleunigt, da es zusammen mit Dart von Google entwickelt wurde und die beiden somit aufeinander aufbauen, was die Entwicklung enorm beschleunigt.
Weitere Vorteile sind, dass Flutter und Dart Open-Source sind und Flutter frei verwendbar ist.
Außerdem werden eine umfangreiche Dokumentation und Community-Support geboten.
Auch dass nur eine Codebasis für alle wichtigen Betriebssystem entwickelt werden muss, ist ein Vorteil von Flutter, ebenso wie die vorgefertigten UI-Elemente, welche feste Bestandteile der Software sind.
Quelle: https://www.twigbit.com/glossar/flutter (extern)
Mehr Infos im Netz:
Beim Thema „P2P“ ist grundsätzlich anzumerken, daß bei „serverlosen“ Systemen in der Regel das Nutzerprogramm (client) die Aufgaben eines Servers übernimmt. Der Server ist quasi das Endgerät selbst wo auch die entsprechenden Einstellungen gemacht werden müssen - es gibt lediglich keine dritte Stelle, die diese Aufgabe als Dienstleister („Server“) übernimmt.
‘Serverlos’ gibt es nicht
Eigentlich ist P2P sogar eine falsche Bezeichnung, denn auch ohne den Server/Relay, der Teil der Kommunikationsplattform ist, gibt es immer noch eine große Anzahl von Servern in der P2P-Kommunikation:
- Der eigene Internetserviceprovider (ISP),
- der der Kontakte,
- die Server von verwendeten VPN-Anbietern,
- alle zwischengeschalteten Switches/Router sowie
- alle Tor-Relays, …
… die für die Verbindung verwendet werden. Und alle diese zwischengeschalteten Knoten sind in der Lage, den gesamten Datenverkehr aufzuzeichnen und für eine spätere Entschlüsselung auf unbestimmte Zeit zu speichern. Relais, die Teil der Kommunikationsplattform sind, fügen nur ein paar zusätzliche Knoten zu einer bereits recht großen Anzahl von Vermittlungsknoten hinzu und verbessern im Gegenzug sowohl die Privatsphäre als auch den Komfort.
„P2P“ ist quasi ein Marketingtrick, der den Menschen vorgaukelt, dass ihre Geräte auf magische Weise direkt miteinander verbunden sind. Für die meisten Nutzer ist Technologie Magie, die sie nicht verstehen können, also vertrauen sie auf Expertenmeinungen, und viele Experten ziehen es vor, falsche Ideen zu verkaufen, einfach weil sie leichter zu verkaufen sind oder weil es ihren Arbeitgebern nützt: “P2P gut, Server schlecht” oder “Non-Profit gut, Unternehmen schlecht” oder andere Ideen dieser Art, auch wenn sie schädlich und falsch sind, sind für die Öffentlichkeit attraktiv.
Selbst einige Experten glauben leider wirklich an die Richtigkeit von “P2P”.
Quelle (etwas umformuliert): reddit.com (extern)
P2P lt. Wikipedia
In einem reinen Peer-to-Peer-Netz sind alle Computer gleichberechtigt und können sowohl Dienste in Anspruch nehmen, als auch zur Verfügung stellen.
Jami (extern) formuliert das beispielsweise so:
Jami works as a server and gets new ports for each connections (randomly binded). These are the ranges that can be used for each component …
This documentation states that Jami works as a server. So, it is a distributed system where peers are both clients and servers. Servers exist.
What is pure P2P? The very name suggests that nothing issues accept() nor listen(). However, that is unlikely. Most implementations I’ve seen of P2P have nodes which behave as clients (they connect to things) and servers (they accept() and listen() for connections). The definitions are intentionally ambiguous. A peer is defined as something that cannot be connected to while a server is something that things connect to. In P2P networks, this is most likely the behavior regardless of the model (coordinated or distributed or whatever (perhaps magic cosmic dust)). P2P: clients accept() / listen() and / or connect(). Those are hybrid peers. Some are pure peers because they only connect(). As this is not my investigation, I would inquire about the specifics of the projects you list.
Above is an implementation which will be released soon demonstrating a model where two clients connect to each other without issuing accept() and listen(). They both bind to local addresses and repeatedly issue connect() every millisecond.
Anonymität
P2P ist nicht mit Anonymität gleichzusetzen!
Bei Push-Benachrichtigungen geht es generell darum, inaktiven Apps über einen Umweg mitzuteilen, daß sie sich bei Ihrem Server melden sollen um neue Nachrichten abzuholen. Hierfür werden spezielle Server sowie Verteiler-Apps („Distributoren“) benötigt, die diese Aufgabe übernehmen.
Grundsätzlich kann bei Android-Systemen in „Firebase Cloud Messaging“ (FCM) von Google und das davon unabhängige „Unified Push“ (UP) unterschieden werden, die beide dafür das selbe Protokoll nutzen.
Die Vorteile von Stromsparpotentialen durch Apps, die nicht permanent aktiv sein müssen gehen aber auch mit Nachteilen im Datenschutz und der Sicherheit einher. Mehr dazu >> hier <<.
Unified Push
Mit „Unified Push“ (UP) ist es somit möglich, Push-Funktionalität unabhängig von Google und ohne Google-Server zu realisieren. Dazu müssen Apps jedoch „UP“ explizit unterstützen. Beispiele für Mastodon dafür sind die Apps „Tusky“ und „Fedilab“. Letztere App ist darüber hinaus auch noch für Pleroma, Friendica und Pixelfed.
Man kann sich dann sowohl den push-Server als auch die Verteiler-App („Distributor“) frei aussuchen.
Ausgangssituation
… am Beispiel von Mastodon und Conversations:
Die Mastodon-App ist auf Android nicht immer aktiv. Man will aber sofort informiert werden, wenn Nachrichten eingehen (push) - auch wenn „im Hintergrund ausführen“ deaktiviert ist.
Voraussetzung
Die Mastodon-App registriert sich bei einer Verteiler-App („Distributor app“), die sowieso eine dauerhafte Verbindung ins Internet offen hält. Diese App muss immer aktiv sein und kann somit immer mit dem push-Server verbunden sein. Da das Standardprotokoll XMPP hierfür sehr gut geeignet ist, kann diese Informations-/Verteil-Funktion aktuell z.B. durch Conversations erfüllt werden.
Ablauf
- Bei Mastodon geht eine Nachricht ein
- Mastodon sendet eine Information darüber an den eingerichteten push-Server
- Der push-Server sendet eine Nachricht an Conversations
- Conversations gibt ein Aufwachsignal an Android bzw. die Mastodon-App
- Die Mastodon-App startet und ruft die Nachrichten dann bei Mastodon ab
Quelle der (ergänzten) Grafik: unifiedpush.org
Expertenwissen
Es gibt Push-Verteiler die verschiedene Technologien verwenden. So gibt es „Websockets“, „HTTP“ oder „XMPP“. Allerdings ist XMPP überlegen, wenn Verbindungen lange gehalten werden sollen und in der Effizienz.
Conversations-FAQ
In den häufig gestellten Fragen (HGF/FAQ) zu Conversations finden sich verschiedene Informationen zur Push-Benachrichtigung:
Wie funktionieren XEP-0357: Wie funktionieren Push-Benachrichtigungen?
Sie müssen die Play Store-Version von Conversations verwenden und Ihr Server muss Push-Benachrichtigungen unterstützen.¹ Da Googles Firebase Cloud Messaging (FCM) mit einem API-Schlüssel an eine bestimmte App gebunden ist, kann Ihr Server die Push-Nachricht nicht direkt initiieren. Stattdessen sendet Ihr Server die Push-Benachrichtigung an den (von uns betriebenen) Conversations-App-Server, der dann als Proxy fungiert und die Push-Nachricht für Sie initiiert. Die Push-Nachricht, die von unserem App-Server über FCM gesendet wird, enthält keine persönlichen Informationen. Es handelt sich lediglich um eine leere Nachricht, die Ihr Gerät aufweckt und Conversations auffordert, sich erneut mit Ihrem Server zu verbinden. Die Informationen, die von Ihrem Server an unseren App-Server gesendet werden, hängen von der Konfiguration Ihres Servers ab, können aber auf Ihren Kontonamen beschränkt sein. (In jedem Fall wird der Conversations App-Server keine Informationen über FCM weiterleiten, selbst wenn Ihr Server diese Informationen sendet.)
Zusammenfassend lässt sich sagen, dass Google niemals in den Besitz von persönlichen Informationen kommt, außer dass etwas passiert ist. (Was nicht einmal eine Nachricht sein muss, sondern auch ein automatisiertes Ereignis sein kann.) Wir - als Betreiber des App-Servers - erhalten lediglich Ihren Kontonamen (ohne diesen mit Ihrem spezifischen Gerät in Verbindung bringen zu können).
Wenn Sie das nicht wollen, wählen Sie einfach einen Server, der keine Push-Benachrichtigungen anbietet, oder bauen Sie selbst Konversationen ohne Unterstützung für Push-Benachrichtigungen. (Dies ist über ein gradle build flavor möglich.) Nicht-Playstore-Quellen von Conversations wie der Amazon App Store bieten auch eine Version ohne Push-Benachrichtigungen an. Conversations wird wie bisher funktionieren und seine eigene TCP-Verbindung im Hintergrund aufrechterhalten.
Übersetzt aus Quelle: github.com/iNPUTmice/Conversations (extern)
Aber warum brauche ich eine permanente Benachrichtigung, wenn ich Google Push verwende?
FCM (Google Push) ermöglicht es einer App, aus dem Ruhezustand aufzuwachen. Dies ist (wie der Name schon sagt) eine Ruhezustandsfunktion des Android-Betriebssystems, die die Netzwerkverbindung unterbricht und auch die Anzahl der Male reduziert, die die App aufwachen darf (z. B. um den Server anzupingen). Die App kann beantragen, vom Ruhezustand ausgeschlossen zu werden. Nicht-Push-Varianten der App (von F-Droid oder wenn der Server dies nicht unterstützt) werden dies beim ersten Start tun. Wenn Sie also von Doze ausgenommen werden oder wenn Sie regelmäßig Push-Ereignisse erhalten, sollte Doze keine Gefahr für die ordnungsgemäße Funktion von Conversatons darstellen. Aber auch mit Doze ist die App immer noch im Hintergrund geöffnet (im Speicher gehalten); sie ist nur in den Aktionen eingeschränkt, die sie ausführen kann. Conversations muss im Speicher bleiben, um bestimmte Sitzungszustände zu halten (Online-Status von Kontakten, Beitrittsstatus von Gruppenchats, …). Mit Android 8 hat Google dies jedoch wieder geändert und nun muss eine App, die im Speicher bleiben will, einen Vordergrunddienst haben, der für den Benutzer über die lästige Benachrichtigung sichtbar ist. Aber warum muss Conversations diesen Status halten? XMPP ist ein zustandsbehaftetes Protokoll, das viele Informationen pro Sitzung enthält; Pakete müssen gezählt werden, Präsenzinformationen müssen festgehalten werden, einige Funktionen wie Message Carbons werden nur einmal pro Sitzung aktiviert, MAM Catch-up geschieht nur einmal, Service Discovery geschieht nur einmal; die Liste geht weiter. Als Conversations Anfang 2014 entwickelt wurde, war dies alles kein Problem, da die Anwendungen einfach im Speicher bleiben durften. Im Grunde hält jeder XMPP-Client diese Informationen im Speicher, weil es viel komplizierter wäre, sie auf der Festplatte zu speichern. Ein komplettes Neuschreiben von Conversations im Jahr 2019 würde versuchen, dies zu tun und wäre wahrscheinlich erfolgreich, aber es würde genau das erfordern; ein komplettes Neuschreiben, das im Moment nicht machbar ist. Das ist übrigens auch der Grund, warum es schwierig ist, einen XMPP-Client auf iOS zu schreiben. Oder allgemeiner ausgedrückt ist dies auch der Grund, warum andere Protokolle als zustandslose Protokolle (oft auf der Grundlage von HTTP) konzipiert oder zu diesen migriert wurden; nehmen Sie zum Beispiel die Migration von IMAP zu JMAP.
Übersetzt aus Quelle: github.com/iNPUTmice/Conversations (extern)
Conversations Push-Proxy
Aufgrund von Einschränkungen in Firebase Cloud Messaging (und den meisten anderen Push-Diensten) kann nur der Entwickler Push-Benachrichtigungen für seine Anwendungen erstellen. Aus diesem Grund kann der Server eines Benutzers das Gerät des Benutzers nicht direkt aufwecken, sondern muss das Aufwecksignal über die Infrastruktur des App-Entwicklers weiterleiten.
Hier ist eine kurze Beschreibung, wie diese Beziehung aufgebaut ist.
Alle Beispiele unten verwenden reale Werte von meinem persönlichen Gerät mit einem Testkonto. Die Tatsache, dass ich mich damit wohlfühle, diese Daten öffentlich zugänglich zu machen, kann als Hinweis darauf dienen, wie wenig datenschutzsensibel diese Daten sind …
Übersetzt aus Quelle: github.com/iNPUTmice/Conversations (extern)
Vorwort
Bei der Internettelefonie (Audio-/Videotelefonie) über Messenger/Browser sind bestimmte technische Voraussetzungen erforderlich. Ansonsten kann nur in bestimmten Konstellationen wie zum Beispiel nur im selben WLAN untereinander telefoniert werden. Im Zusammenhang mit der Internettelefonie fallen immer wieder Begriffe wie „WebRTC“, „STUN“ und „TURN“ die hier erläutert und die grundsätzliche Funktionsweise erklärt werden …
Funktionsweise/Erklärung
Für den Austausch von Ton- und Videoinformationen wird das Protokoll „Web Real-Time Communication“ (WebRTC) (extern) genutzt, was ein offener Standard zur direkten Kommunikation zwischen Rechnern ist. Auch aktuelle Browser unterstützen dieses Protokoll, so daß damit Videokonferenzen problemlos möglich sind - zumindest innerhalb eines lokalen Netzes (LAN/WLAN).
Sind die beteiligten Geräte in verschiedenen Netzen, so taucht ein Problem auf: Die Programme/Apps müssen ihre eigene IP-Adresse und die IP-Adresse der Gegenstelle wissen. Dies ist leider oft nicht der Fall, wenn sie hinter einem NAT-Router sitzen, z.B. einer Fritzbox. Hier kennen die Geräte nur ihre netzinterne IP-Adresse, z.B. 192.168.1.52, aber nicht die offizielle IP-Adresse nach außen, die nur der Router kennt.
Dieses Problem lässt sich mit einem STUN-Server (Session Traversal Utilities for NAT) lösen. Die beteiligten Rechner melden sich bei dem STUN-Server; dabei lernt er ihre öffentlichen IP-Adressen kennen und kann sie an die Gesprächspartner weitergeben. Mit diesen Informationen können die Geräte dann direkt miteinander kommunizieren.
Der Betrieb eines STUN-Servers ist relativ problemlos, da nur sehr geringe Datenmengen anfallen. Es gibt daher auch öffentliche STUN-Server.
Leider reicht der STUN-Server heutzutage nicht mehr. Ein Router, wie die Fritz!Box, macht nämlich nicht nur NAT, sondern stellt auch eine Firewall zur Verfügung. Verbindungen von außen, aus dem Internet, auf die Rechner innerhalb des lokalen Netzes sind so nicht möglich, ohne auf dem Router Ports freizugeben und auf den Zielrechner weiterzuleiten. Das wäre eine recht aufwändige Vorgehensweise. Es sind nur Verbindungen aus dem Inneren des jeweiligen Netzes zu öffentlich zugänglichen Rechnern möglich.
Hier kommt der TURN-Server ins Spiel (Traversal Using Relays around NAT), er ermöglicht es den Clients Daten ohne eine direkte Verbindung auszutauschen (Relay Server). Sämtlicher Datenverkehr läuft dann durch diesen Server:
In der Regel wird man öffentliche TURN-Server nicht finden, da rechte hohe Datenvolumina anfallen. Für eine ordentliche Videoqualität werden 500 kbit/s angegeben. Bei 3.600 Sekunden in einer Stunde macht das dann 500×3.600 = 1.800.000 kbit (was fast 1.800 mbit entspricht), also schon ein erhebliches Datenvolumen.
WebRTC und TOR
Eine gleichzeitige Nutzung von TOR (The Onion Routing) und WebRTC schließt sich eigentlich aus. Denn bei der Nutzung von TOR sind die IP-Adressen den beteiligten Endstellen nicht bekannt und durch die Nutzung von WebRTC würde der Sinn und Zweck von TOR ausgehebelt.
Zusammenfassung
- WebRTC ist das internationale Protokoll zum Austausch der Daten bei Internettelefonie (Audio-/Video-Kommunikation)
- STUN (für NAT) und TURN (für Firewalls) helfen bei der Aushandlung/Vereinbarung des hierzu erforderlichen, direkten AV-Übertragungswegs zwischen zwei Endstellen
- Sind keine STUN-/TURN-Server verfügbar, kann evtl. nur im selben Netzwerk telefoniert werden
- Wird TOR zur Verschleierung von IP-Adressen verwendet, ist keine Internettelefonie möglich
Übernommen aus Quelle: debacher.de (extern) und leicht angepasst/ergänzt - Danke Uwe!
Weitere Informationen und technische Anleitung für WebRTC in HTML-Clients: https://www.baeldung.com/webrtc (extern; englisch)
Querverweis: Übersicht externer Messengervergleiche
Freie Messenger
Alternativen zu WhatsApp mit Vor- und Nachteilen: https://digitalcourage.de/digitale-selbstverteidigung/messenger (extern)
Datensammelei
Interessante und gute externe mediale Quellen zur Privatsphäre und zum Datenschutz:
Bäckerei (Video)
Schönes Video (mit deutschem Untertitel), in dem eine Bäckerei-Verkäuferin sich genauso dreist (freundlich aber unverschämt) verhält, wie viele beliebte Apps:
https://yewtu.be/watch?list=RDwHo755bxByI&v=wHo755bxByI (extern)
Kostenloses Eis (Video)
Auch Threema hat hierzu ein nettes Video (‘kostenloses’ Eis gegen Bezahlung mit Daten): https://threema.ch/content/video/threema_icecream_en.mp4 (extern, englischer Untertitel)
Made to measure (Film und interaktive Seite - sehr lohnenswert)
“Zeig mir deine Daten und ich sag dir, wer du bist” - ein crossmediales Datenexperiment macht auf eindrucksvolle Weise erlebbar, welche Einblicke Google, Facebook & Co. in unsere intimsten Geheimnisse haben.
Viele Infos und Föderung: Kulturstiftung des Bundes (extern)
Je nach Sendedatum eventuell abrufbar in der Mediathek von ARD und SRF: Film (extern)
Internetseite: https://www.madetomeasure.online/de/ (extern)
Sicherheit
Sicherheitsvergleich von Messengern und e-Mail:
https://www.digitale-gesellschaft.ch/messenger/bewertung.html (extern)
Aus dem Sicherheitshandbuch:
https://www.privacy-handbuch.de/handbuch_62.htm (extern)
„Sichere“ Messenger:
https://www.kuketz-blog.de/conversations-sicherer-android-messenger/ (extern)
Überprüfung von Programmen/Apps auf „Tracker“:
https://reports.exodus-privacy.eu.org/en (extern)
Mythen
Sonstiges
Freie und offene Programme für Android:
F-Droid: https://www.f-droid.org (extern)
Hintergrundinformationen: https://mobilsicher.de/hintergrund/verbraucherfreundlich-f-droid (extern)
Freie Software:
https://fsfe.org/index.de.html (extern)
Föderation (engl. „federation“):
Nutzung/Übersicht zum “Föderationsuniversum” (engl. „fediverse“): https://the-federation.info (extern)
Warum hat nicht jeder die selben Emoji?
http://www.unicode.org/emoji/charts/full-emoji-list.html (extern)
- Lesezeit: 1 Minute / ganze Rubrik: 7 Minuten - |
In der Presse / im Internet werden immer wieder neue Artikel zum Thema “Messenger” veröffentlicht, bei denen freie Messengersysteme überhaupt nicht erwähnt werden. Aber auch Firmen, Unternehmen, Organisationen, Vereine, Behörden usw. bieten immer öfter WhatsApp oder andere Insellösungen als Kontaktmöglichkeit an. Diesen ist in der Regel nicht bekannt, daß es freie Systeme gibt.
Deshalb kann mit nachfolgenden Textvorschlägen auf den Bedarf nach freier Kommunikation hingewiesen werden.
Kommentare für Onlineartikel
Auf alle Fälle den Text vor dem Absenden nochmals durchlesen und die markierten Textstellen ändern/anpassen (Produktname sowie eigenen Namen einsetzen)!
Betreff: WhatsApp-Alternativen / Freie Messenger
Sehr geehrte Redaktion,
im Internet haben Sie im Artikel “ARTIKELNAME VOM DATUM” verschiedene WhatsApp-Alternativen aufgeführt.
Zu diesem Thema gibt es informative Inhalte auf der Seite des ehrenamtlichen Projektes „freie-messenger.de“. Insbesondere der Systemvergleich sowie der Abschnitt “warum” bzw. “warum nicht” sind erwähnenswert:
https://www.freie-messenger.de/systemvergleich
https://www.freie-messenger.de/warum
Für Rückfragen stehe ich gerne zur Verfügung.
Mit freundlichen Grüßen
VORNAME NAME
Vorlage 'WhatsApp Business'
Betreff: DSGVO / Messenger: Anregung und Bitte
Mit der Bitte um Weiterleitung an:
- die Geschäftsleitung
- die Marketing-Abteilung
- die Organisation
- die IT-Abteilung
Sehr geehrte Dame, sehr geehrter Herr,
mit Freude habe ich vernommen, daß Ihr Unternehmen in der
Kundenkommunikation einen Messenger einsetzt und somit aktiv dem
Bedürfnis nach schneller Information und Kommunikation nachkommt.
Hierbei haben Sie sich für „WhatsApp Business“ entschieden, da hier
eine große Nutzerbasis vorhanden ist.
In diesem Zusammenhang ist anzumerken, daß WhatsApp allgemein zwar sehr
verbreitet ist, jedoch nicht auf einem offenen und freien Standard
(technisch: “Protokoll”) basiert. Es ist ein geschlossenes System, das
bewusst keine offenen Schnittstellen hat.
Bei anderen Kommunikationsmedien wäre eine solche anbieterabhängige
Kommunikation unvorstellbar: Stellen Sie sich vor, Sie könnten nur
innerhalb eines Telefonanbieters telefonieren oder E-Mails nur mit
Kunden des selben Providers austauschen!
Deshalb bitte ich Sie zu überlegen, Ihren Kunden ergänzend das
standardisierte Messengersystem “Jabber/XMPP” anzubieten.
Ein paar Vorteile in Kürze:
- DSGVO-konform - auch auf der Kundenseite!
- anbieterunabhängig, dezentral
- firmeneigener Server möglich
- mehrere Nutzerkonten möglich
- gleichzeitige Nutzung von mehreren Geräten
- öffentliche Gruppen
- moderierte Räume mit über 256 Teilnehmern
- …
Selbstverständlich ist eine Ende-zu-Ende-Verschlüsselung möglich.
Folgende konkrete Inhalte der Seite www.freie-messenger.de könnten für
Sie diesbezüglich interessant sein:
Nicht ohne Grund hat der Continental-Konzern WhatsApp aus
Datenschutzgründen für eine betriebsinterne Nutzung verboten.
Für die betriebsinterne Kommunikation bietet sich statt dessen ein
freies Messengersystem an:
Es würde mich freuen, wenn Sie das Thema “Freie Messenger” offen
aufnehmen und als Anregung für eventuelle künftige Entscheidungen
mit einbeziehen könnten.
Für Rückfragen stehe ich gerne zur Verfügung.
Mit freundlichen Grüßen
VORNAME NAME
Betreff: DSGVO / Messenger: Anregung und Bitte
Mit der Bitte um Weiterleitung an:
die Geschäftsleitung
die Marketing-Abteilung
die Organisation
die IT-Abteilung
Sehr geehrte Dame, sehr geehrter Herr,
mit Freude habe ich vernommen, dass Ihr Unternehmen in der
Kundenkommunikation einen Messenger einsetzt und somit aktiv dem
Bedürfnis nach schneller Information und Kommunikation nachkommt.
Hierbei haben Sie sich für „PRODUKTNAME“ entschieden, da hier eine DSGVO-konforme Nutzung ermöglicht werden soll.
In diesem Zusammenhang ist anzumerken, dass PRODUKTNAME zwar
sicher ist, jedoch nicht auf einem offenen und freien Standard
(technisch: “Protokoll”) basiert. Es ist ein geschlossenes System, das
bewusst keine offenen Schnittstellen hat.
Bei anderen Kommunikationsmedien wäre eine solche anbieterabhängige
Kommunikation unvorstellbar: Stellen Sie sich vor, Sie könnten nur
innerhalb eines Telefonanbieters telefonieren oder E-Mails nur mit
Kunden des selben Providers austauschen!
Deshalb bitte ich Sie zu überlegen, Ihren Kunden ergänzend das
standardisierte Messengersystem “Jabber/XMPP” anzubieten.
Ein paar Vorteile in Kürze:
DSGVO-konform - auch auf der Kundenseite!
anbieterunabhängig, dezentral
firmeneigener Server möglich
mehrere Nutzerkonten möglich
gleichzeitige Nutzung von mehreren Geräten
öffentliche Gruppen
moderierte Räume mit über 256 Teilnehmern
…
Selbstverständlich ist eine Ende-zu-Ende-Verschlüsselung möglich.
Folgende konkrete Inhalte der Seite www.freie-messenger.de könnten für
Sie diesbezüglich interessant sein:
- Warum nicht nur WhatsApp:
https://freie-messenger.de/warum
https://freie-messenger.de/systemvergleich
Nicht ohne Grund hat der Continental-Konzern WhatsApp aus
Datenschutzgründen für eine betriebsinterne Nutzung verboten.
Für die betriebsinterne Kommunikation bietet sich statt dessen ein
freies Messengersystem an:
https://freie-messenger.de/geheimnisse/geheimnistraeger
- Entscheidungsgrundlage für betriebliche Nutzung:
https://freie-messenger.de/messenger/entscheidungsgrundlage
Es würde mich freuen, wenn Sie das Thema “Freie Messenger” offen
aufnehmen und als Anregung für eventuelle künftige Entscheidungen
mit einbeziehen könnten.
Für Rückfragen stehe ich gerne zur Verfügung.
Mit freundlichen Grüßen
VORNAME NAME
Vorlage 'Volkshochschule'
Betreff: KURSNR / Freie Messenger
Sehr geehrte Dame, sehr geehrter Herr,
an der VHS XY findet am DATUM ein Kurs zum Thema “KURSNAME” statt (Kursnummer XXXXX).
Hierzu gibt es auf „freie-messenger.de“ sehr interessante Inhalte:
https://www.freie-messenger.de/systemvergleich
https://www.freie-messenger.de/warum
Zum Hintergrund: Das ehrenamtliche Projekt “Freie Messenger” informiert über praxistaugliche, freie Alternativen zu WhatsApp. Insofern würde dies inhaltlich zu dem aufgeführten Kurs passen und die Dozenten evtl. interessieren. Ich bitte Sie deshalb, diese E-Mail an den Dozenten weiterzuleiten.
Für Rückfragen stehe ich gerne zur Verfügung.
Mit freundlichen Grüßen
VORNAME NAME
WICHTIG:
Fast alle Verweise hier auf dieser Seite sind NICHT extra mit „(extern)“ gekennzeichnet - werden dafür jedoch ausnahmslos alle mit der kompletten Adresse im Klartext angezeigt!
Vorwort
Dem Gedanken/Grundsatz „öffentliche Gelder - öffentlicher Code“ bzw. „öffentliche Gelder - öffentliche Daten“ folgend gibt es nicht nur für Messenger entsprechende Alternativen zu bekannten Lösungen von Weltkonzernen. Da ich immer wieder danach gefragt werden, hier ein paar Vorschläge zu datenschutzfreundlicheren und/oder quelloffenen Alternativen aus den verschiedensten Bereichen, die bei diversen Serverbetreibern genutzt oder selbst gehostet werden können:
Anmerkungen:
Sofern vorhanden, sind in der Spalte „Nutzbar bei z.B. …“ Listen oder Übersichten für verfügbare Angebote einzelnen Anbietern vorzuziehen.
Anregungen/Ergänzungen sind wie immer gerne willkommen: >> Kontakt <<
Externe Übersichten:
Chat
Teamchat
Statt „Slack“ …
Dateiablage
Statt „Dropbox“ …
Mitgliederversammlungen
MS-Büropakete
Statt „MS-Office“ …
Statt „MS Outlook/Office 365“ …
Name |
Kurzbeschreibung/Quelle |
Nutzbar bei z.B. … |
ClawsMail |
E-Mail-Client / https://claws-mail.org |
|
Kopano |
|
|
OpenXchange |
|
|
Statt „MS Active Directory“ …
Name |
Kurzbeschreibung/Quelle |
Nutzbar bei z.B. … |
Univention Corporate Server |
als IDM-Lösung |
|
Onlinetabellen/-Umfragen
Statt “doodle” …
Onlinetexte/-Tabellen
Statt „Google Docs“ …
Name |
Kurzbeschreibung/Quelle |
Nutzbar bei z.B. … |
HedgeDoc (ehem. CodiMD) |
Formatierte Texte und einfache Tabellen (Markdown) / privat und öffentlich möglich. Empfehlung der KultusMinisterKonferenz (KMK). |
https://doc.adminforge.de |
Cryptpad |
Wie Büropakete (Texte, Tabellenkalkulation, …) mit Verschlüsselung und umfangreichen Formatierungsmöglichkeiten; auch mit Passwortschutz möglich. |
https://cryptpad.adminforge.de https://cryptpad.ffmuc.net https://cryptpad.fr |
Etherpad |
Einfache formatierte Texte / alle, die den Zugangslink haben, sehen den Text und alle Änderungen. Keine Tabellen möglich Ablaufzeit nach letzter Änderung (Löschung nach Inaktivität) möglich. |
https://pad.adminforge.de (7 Tage Ablaufzeit) https://pad.systemli.org (Ablaufzeit: 1, 30, 360 Tage) https://yopad.eu (Ablaufzeit: 7, 30, 360 Tage) |
Ethercalc |
Tabellen, einfache Rechnungen, formatierte Zellen. |
https://www.systemli.org/service/ethercalc.html |
Only Office |
http://onlyoffice.org |
|
Privatebin/Pastebin |
Eine Art Zwischenablage ohne spätere Bearbeitungsmöglichkeit. Ablaufdatum möglich, mit Löschen-nach-Lesen, mit Passwort möglich, mit Verschlüsselung. Achtung: bei Ablaufdatum wenn möglich _niemals “nie” wählen, da eine spätere Löschung dann nicht möglich ist. |
https://notebin.de |
Bei den Alternativen gibt es teilweise auch einen einstellbaren Löschzeitraum!
Soziale Medien
Statt „Facebook“ …
Statt „Instagram“ …
Name |
Kurzbeschreibung/Quelle |
Nutzbar bei z.B. … |
Pixelfed |
|
Liste verfügbar? |
Videokonferenzen
Informationen zu Warum nicht Zoom?
Whiteboard
- - - - - Internes - - - - -
Motivation
Regelmäßig werde ich nach dem „Warum“ und dem Anfang gefragt - hier die Antwort:
Alles begann mit einer Veranstaltung an der Schule, bei der über den Einsatz von WhatsApp, Sicherheit und Messenger an Schulen referiert wurde. Allerdings wurden dort einige offensichtlich falsche bzw. nicht nachvollziehbare und widersprüchliche Informationen gegeben, so daß ich mich im Anschluß selbst im Netz über Alternativen zu WhatsApp informieren wollte.
Leider gab es damals (2017) keine wirklich brauchbare Übersicht - also musste ich mir meine eigene erstellen. Diese Informationen wurden irgendwann umfangreicher und ich habe diese ursprünglich private Sammlung dann im April 2018 auf der Seite “www.freie-messenger.de” veröffentlicht. Seither betreibe ich ehrenamtliche Aufklärungsarbeit und Öffentlichkeitsarbeit für “anbieterunabhänige Systeme” und die Internetseite „Freie Messenger“ ist die aktuell größte Sammlung dieser Art im deutschsprachigen Raum.
Mir macht es Spaß, Dinge zu hinterfragen, zu sammeln und aufzubereiten. Auch ist mir ehrenamtliche Arbeit und soziales Engagement sehr wichtig. Ich mag keine „alternativen Fakten“ (Fake News) und erst recht nicht, angelogen zu werden. Freie Messenger ist für mich somit eine optimale Kombination und ein interessantes Betätigungsfeld.
Selbsttest
Nach einem Test von (dem in der Zwischenzeit eingestellten) Hoccer ist mir der gravierende Unterschied zwischen Insellösungen und freien Systemen erst bewußt geworden.
WhatsApp habe ich 2 Jahre passiv benutzt, um hier Erfahrungen zu sammeln. Seit 2019 habe ich das Konto bei WhatsApp sowie die App gelöscht. Das ist jedoch „normalen“ WhatsApp-Nutzern nicht wirklich zu empfehlen: Die soziale Ausgrenzung ist enorm. Besser ist ein „sanfter“ Weg durch ergänzende Nutzung von anbieterunabhängigem Chat: https://www.freie-messenger.de/messenger/empfehlung
Problem Lobbyarbeit
Leider gibt es sehr viel Halbwissen und falsche Informationen. Der bisher sehr erfolgreichen Lobbyarbeit der IT-Konzerne und Herstellerfirmen ist schwer entgegenzutreten; es mangelt sowohl bei der Software-Entwicklung als auch bei der Öffentlichkeitsarbeit an den Finanzen und prominenten Mentoren und Fürsprechern.
Teilweise wird selbst von der Politik durch Einsatz von Insellösungen und Produkten aus der Wählerschaft eine Art “regionale Wirtschaftsförderung” (Zitat einer Partei) gemacht, was der Forderung nach interoperabler Chat-Kommunikation sowie dem Grundgedanken “Öffentliche Gelder -> öffentliche Standards” widerspricht.
Auch wird i.d.R. “Sicherheit” als Verkaufs- und Totschlagargument aufgeführt, obwohl hierunter Verschiedenstes verstanden werden kann und Datenschutz, Privatsphäre und vor allem Freiheit teils gar nicht mit berücksichtigt werden.
Ich versuche hier vor allem über die Schlüsselbereiche “Bildung” und “Berufsgeheimnisträger” - zu sensibilisieren und aufzuklären.
Tätigkeiten und Aufgaben
Hier einen kleiner Einblick in die Tätigkeitsfelder und Aufgaben:
- Sammeln von Informationen
- Pflege und Aktualisierung der Internetseite
- Internationalisierung (Übersetzungen) der Inhalte
- Vorbereitung der Aktualisierung der Seiteninhalte
- Betreuen diverser öffentlicher Chaträume
- Anschreiben von Politik, Institutionen, Vereinen, …
- Erstellen von Leserbriefen und Kommentaren
- Werben um Spenden, Stiftungsanfragen
- Querlesen von Artikeln und Veröffentlichungen
- Kurz-Beratung und Hilfe bei Anfragen
- Anregung zu Entwicklungsaufträgen, deren Ergebnisse wieder der Allgemeinheit zu Gute kommen
- Fortbildung und Schulung z.B. über Online-Angebote des HPI
- Suchen nach Referenzschulen
- Suche nach prominenten Fürsprechern/Schirmherrschaften/Partnern
- Kontaktpflege und -vermittlung
- Erstellung von Übersichten und Tabellen
- ‘nebenher’ zig E-Mails und Korrespondenz
- Hoffnung auf Erklärvideos
- und und und …
Vision
Künftig sollte es irgendwann nicht mehr heißen “Ich schicke dir das per WhatsApp/Threema/Signal/…“sondern wie bei E-Mail ganz normal: “Ich schicke dir das per Chat”.
Danke
Ohne eine große und tatkräftige Unterstützung von vielen Seiten wären diese Seiten (kleines Wortspiel) nie entstanden und würden auch nicht stetig wachsen. Anfangs waren mir Begriffe wie statischer Seitengenerator, HTML, Markdown usw. neu - und genauso wenig Ahnung hatte ich von der Einrichtung einer Domain, dem eigentlichen Erstellen von Internetseiten und den Möglichkeiten, die es hier gibt.
Danke auch an die Gemeinschaft, die uns (der Allgemeinheit) sehr gute freie Software für die verschiedensten Zwecke zur Verfügung stellt. Jeder mit der finanziellen Möglichkeit zu Spenden ist dazu aufgerufen, dieses Engagement zu unterstützen und zu fördern.
Genauso ist es für eine einigermaßen gute Strukturierung und natürlich auch für die Inhalte selbst enorm wichtig, Ideengeber und gute Korrekturleser zu haben.
Herzlichen Dank also an alle, die mir es ermöglicht haben, diese Internetseite zu erstellen und zu betreiben. Danke auch an meine großartige Familie - die vielleicht auch manchmal unter meinem Engagement hierfür gelitten hat!
Diese Internetseiten wurden übrigens mit der ebenfalls freien Software „Hugo“ (extern) erstellt.
Unterstützung bekomme ich inhaltlich und technisch oft durch andere Engagierte, die sich in der Zwischenzeit zusammengefunden haben. Darüber hinaus freue ich mich über jede noch so kleine Aufmerksamkeit:
Empfehlung
Natürlich ist es sehr hilfreich, wenn die Seite “www.freie-messenger.de” mehr Personen und Institutionen erreicht. Hier kann eine Empfehlung im persönlichen Umfeld (egal ob privat oder beruflich) viel bewirken!
Überweisung
Für eine einmalige oder eventuell sogar regelmäßige finanzielle Unterstützung kann folgende Bankverbindung genutzt werden:
Bei der Bank: 1822direkt (Frankfurter Sparkasse)
Kontoinhaber: Mar tin Ge ke ler
Kontonummer : 1 253 921 758 / Bankleitzahl: 500 502 01
(IBAN: DE54 50050201 1253921758 / BIC: HELADEF1822)
Verwendungszweck: Freie Messenger - … - ggfs. ergänzt um einen Zusatz zwecks Veröffentlichung des Namens
… Der Name wird nur öffentlich auf der Seite genannt, wenn das aus dem Verwendungszweck eindeutig hervorgeht oder mir per E-Mail oder Chat mitgeteilt wird. Es wird dann der jeweils angegebene Name verwendet. Beispiele:
- Freie Messenger / MIT Nennung Nachname und Vorname
- Freie Messenger / MIT Nennung NUR Nachname
- Freie Messenger / MIT Nennung Nachname und V.
- Freie Messenger - Nennung mit Name OHNE Betrag (Name = Absendername)
Eine Spendenbescheinigung kann nicht ausgestellt werden, da dies eine rein private Initiative ist.
Spende
Natürlich ist auch eine Sach- oder Bargeldspende mit oder ohne Absender (anonym) möglich. Bitte diese einfach an folgende Adresse senden:
Mart¡n GekeIer
M¡chæl—Herr–Straße 1O
D-7²555 Me†z¡ngen
Die Verwendung der Kontaktdaten zur gewerblichen Nutzung/Werbung ist ausdrücklich nicht gestattet (vgl. „Eigener Datenschutz“)
Damit die Post auch ankommt, Banknoten oder Einkaufsgutscheine bitte zwischen zwei Blatt Papier oder Karton legen.
Auch ist eine auf den ersten Blick etwas ausgefallenere (aber nicht unübliche) Art der Unterstützung im Rahmen einer testamentarischen Berücksichtigung möglich.
Kosten
Mein Engagement kostet nicht nur viel Zeit (und Nerven) sondern auch regelmäßig Geld. Um eine langfristige Finanzierung zu ermöglichen wäre ein Spendenziel von 3.000-3.500 Euro (monatlich) das Minimum. Warum? Es gibt:
- Unkosten für die Internetadresse,
- das Hosting der Seite und Dienste bei (Uberspace),
- Unterstützung von Chatserverbetreibern (diverse Chatkonten),
- Reise-/Fahrtkosten, Parkgebühren,
- Rechner, Drucker, Verbrauchsmaterial,
- App-Entwickler, die bezahlt werden sollten,
- von der Arbeitszeit gar nicht zu reden.
Was neben einem festen Budget auch noch fehlt, sind Testgeräte und Werbemittel.
Bezüglich der Kosten der verschiedenen Serverbetreiber, Entwickler und des Hosting möchte ich diese mittelfristig natürlich entsprechend unterstützen und nicht nur deren Leistung in Anspruch nehmen. Darüber hinaus nutze ich auch viele “kostenlose” Dienste/Projekte/Produkte - die genauso finanziell unterstützt werden sollten. Auch Autoren von freier Software würden sich freuen …
Sollte sich eine Stiftung oder ein Mäzen mit einem größeren Betrag beteiligen, würde ich mehr Zeit für Inhalte, Kontaktpflege usw. haben und auch die iOS-Entwicklung könnte gefördert werden. Ideen sind viele da. Es fehlt wie überall an der Zeit - ein Sekretariat wäre super! ;-)
Aber es handelt sich noch um freiwilliges, “ehrenamtliches” Engagement: Deshalb beklage ich mich nicht, sondern freue mich über jeden Hinweis zu den Inhalten, denn das ist auch eine große Unterstützung!
Danke
Auch konstruktive Rückmeldungen oder ein paar nette Worte motivieren und sind mir eine große Freude. (>> Kontakt <<)
Datenschutz
Die Verwendung der Kontaktdaten zur gewerblichen Nutzung/Werbung ist ausdrücklich nicht gestattet (vgl. „Eigener Datenschutz“)
Chat
Selbstverständlich bin ich per „normalem“, anbieterunabhängigem Chat erreichbar. „Normal“ bedeutet hier, daß internationale Internetstandards eingehalten werden. Das System ist kein Firmeneigentum/-geheimnis und durch die Föderation der Betreiber gibt es eine sogenannte „Interoperabilität“ (Zusammenarbeit).
Chatadresse: im@openim.de
Alias/Spitzname: *IM*
E-Mail
Adresse: info@freie-messenger.de
Öffentlicher PGP-Schlüssel: >> gültig bis 2025 <<
Fingerabdruck: 24D1 6BC5 A482 0D27 00DE 2F9F EAD0 A340 D47D A0CC
E-Mail-Info
Wenn jemand über wesentliche Änderungen/Ergänzungen von “Freie Messenger” per E-Mail informiert werden will, ist das möglich. Einfach eine Nachricht an „info@freie-messenger.de“ mit dem Betreff „Änderungsinfo“ und einem formlosen Kommentar senden. Zum Austragen: “Löschen” oder ein entsprechender Hinweis.
Ich gebe mein Bestes - aber keine Garantie, dass das jedesmal und auf Dauer funktioniert. Wird der Aufwand für die (manuelle) Pflege des Verteilers zu groß, wird die E-Mail-Info wieder beendet.
Öffentliche Räume/Gruppen
Fragen, die über die Inhalte dieser Seiten nicht beantwortet werden, einfach im öffentlichen Chatraum zu Freie Messenger stellen. Chaträume können ohne Anmeldung und unter Verwendung eines beliebigen Aliases/Spitznamens pseudonymisiert betreten/besucht werden. Eine Antwort läßt meist nicht lange auf sich warten!
Matrix
Es gibt keinen offiziellen öffentlichen Chatraum von Freie Messenger bei Matrix - hier habe ich einfach noch kein gutes Bauchgefühl und nicht genug Vertrauen bezüglich dem Datenschutz (dezentrale Architektur der Chaträume). Auch ist es schwieriger sicherzustellen, daß bößwillig eingestellte strafrechtliche Inhalte auf allen (ab dem Zeitpunkt der Veröffentlichung) beteiligten Servern tatsächlich gelöscht werden.
Brücken zu Matrix sind experimentell und können Nachrichteninhalte verändern. Ich übernehme keine Verantwortung für geteilte Inhalte außerhalb der offiziellen Chaträume und auf von mir nicht gewählten Servern, da ich mögliche Folgen nicht abschätzen kann.
Schutz der Privatsphäre
Auf diesen Seiten werden keinerlei persönliche Daten erfragt, gespeichert oder ausgewertet.
Datenschutz der Seitenbesucher
Bei jedem Besuch der Internet-Seiten und bei jedem Aufruf einer Datei werden
beim Serverbetreiber (uberspace) jedoch Daten über diesen Vorgang vom System
protokolliert. Diese Daten gehören nicht zu den personenbezogenen Daten,
sondern sind anonymisiert. Sie werden ausschließlich zu statistischen Zwecken
ausgewertet. Eine Weitergabe an Dritte, zu kommerziellen oder nichtkommerziellen
Zwecken, findet nicht statt.
Folgende technische Verbindungsdaten werden gespeichert:
Die unvollständige IP-Adresse (gekürzt),
das Datum und die Zeit der Anfrage,
die Seiten/Verknüpfungen, die angeklickt werden (die HTTP-Anfrage) sowie
der hinterlegte Browsertyp (z.B. Browser, Betriebssystem)
Für die Zustellung von Änderungsinformationen ist es möglich, eine E-Mail-Adresse mitzuteilen. Weitere oder persönliche Daten sind nicht erforderlich. Die E-Mail-Adresse wird lediglich für diesen Zweck verwendet. Sie wird aus dem Verteiler gelöscht, sobald die Bitte zur Zusendung zurückgezogen wird oder der Zweck der Speicherung entfällt. Ein Recht auf Eintragung besteht nicht.
Eigener Datenschutz
Die Verwendung der Kontaktdaten des Impressums zur gewerblichen Werbung ist
ausdrücklich nicht erwünscht, es sei denn der Betreiber hatte zuvor seine
schriftliche Einwilligung erteilt oder es besteht bereits eine Geschäftsbeziehung.
Der Betreiber und alle auf dieser Website genannten Personen widersprechen
hiermit jeder gewerblichen oder kommerziellen Verwendung und Weitergabe ihrer Daten.
Sonstiges
Rechtlich nicht zu erwähnen - aber dennoch erwähnenswert - ist, dass auch auf den Seiten von „freie-messenger.de“ der Grundsatz der **Datensparsamkeit gilt (nur erforderliche Daten sollen tatsächlich erfasst werden). Deshalb kann auf eine große Liste von „Diensten“ verzichtet werden:
- keine Cookies (Textdateien zum Speichern von Informationen )
- kein Google (kein Einsatz von Google-Analytics)
- kein Einbinden externer (z.B. Google-) Schriften
- keine Verbindungen zu “sozialen Medien” (z.B. Facebook, Google+, Instagram, LinkedIn, Myspace, Pinterest, SlideShare, Tumblr, Twitter, Xing, …)
- keine Analysetools (z.B. Adobe Analytics (Omniture) / Adobe Marketing Cloud, Google Analytics, econda, etracker, Matomo, Webtrekk, …)
- keine Werbung (ADITION, Adcell, AdJug, Adgoal, Google AdSense, Google AdWords, Google Remarketing, …)
- kein Online-Marketing (affilinet, Amobee, Belboon, DoubleClick, Oracle Eloqua / Oracle Marketing Cloud, Tradedoubler, TradeTracker, YieldKit, Awin, …)
- kein Wordpress und somit auch keine WP-Plugins (AddThis, Jetpack für Wordpress, Shariff, …)
- keine sonstigen Dienste (Funktionen des Amazon-Partnerprogramms, Flattr, Bloglovin, Getty Images Bilder, LiveZilla, Lotame, WiredMinds, …)
Das kann gerne selbst geprüft werden unter der sehr zu empfehlenden Seite „webbkoll“ von „dataskydd.net“ (extern) (schwedisch/englischssprachig)

Ergänzendes
Weitere unterstützenswerte Grundsätze bei der Erstellung von Seiten für das Internet (WWW):
Diese Seiten sind rein privat und ohne kommerzielles Interesse - auch wird auf diesen Seiten weder ein Produkt noch eine Dienstleistung verkauft!
Ein Impressum ist nach § 5 Telemediengesetz (TMG) vorgeschrieben für „geschäftsmäßige Online-Dienste“. Das TMG stellt also darauf ab, ob die Inhalte, Waren oder Leistungen auf der Website üblicherweise gegen Entgelt angeboten werden. Dies betrifft also zunächst einmal sämtliche Seitenbetreiber, die Waren (Online-Shops) oder Dienstleistungen (Webhoster, Softwarevermietung) anbieten. Somit besitzen sie eine Impressumspflicht.
Die Vorschrift des § 55 Rundfunkstaatsvertrages (RstV) stellt für die Impressumspflicht hingegen auf die Inhalte der Website ab. Danach benötigt ein Impressum, wer regelmäßig journalistisch-redaktionell gestaltete Inhalte online stellt, die zur Meinungsbildung beitragen können.
„Verantwortlich“ nach § 5 TMG / § 55 RStV ist demnach „niemand“; es ist keine sog. „Anbieterkennzeichnung“ erforderlich.
Dennoch hier meine Daten, deren Verwendung zur gewerblichen Nutzung/Werbung jedoch ausdrücklich nicht gestattet ist (vgl. Punkt 4):
MART¡N GEKeLER
M¡çhæl—Herr–S†raße 1O
D-7²555 Me†z¡ngen
1. Haftungsbeschränkung
Die Inhalte dieser Website werden mit größtmöglicher Sorgfalt erstellt. Es wird keine Gewähr für die Richtigkeit, Vollständigkeit und Aktualität der bereitgestellten Inhalte gegeben. Die Nutzung der Inhalte der Seite erfolgt auf eigene Gefahr des Nutzers. Namentlich gekennzeichnete Beiträge geben die Meinung des jeweiligen Autors und nicht immer die Meinung von „freie-messenger“ wieder. Mit dem Aufruf bzw. der reinen Nutzung der Seite kommt keinerlei Vertragsverhältnis zwischen dem Nutzer und dem Seitenbetreiber zustande.
2. Externe Verknüpfungen
Diese Seite enthält Verknüpfungen zu Seiten Dritter (engl.: „links“). Externe Seiten unterliegen der Haftung der jeweiligen Betreiber. Bei der erstmaligen Verknüpfung von externen Seiten sind wurden deren Inhalte daraufhin überprüft, ob etwaige Rechtsverstöße bestehen. Zu diesem Zeitpunkt waren keine Rechtsverstöße ersichtlich. Der Betreiber hat keinerlei Einfluss auf die aktuelle und zukünftige Gestaltung und auf die Inhalte der verknüpften Seiten. Das Setzen von externen Verknüpfungen bedeutet nicht, dass sich der Anbieter die dort liegenden Inhalte zu Eigen macht. Eine ständige Kontrolle der externen Verknüfpungen ist dem Bereiber ohne konkrete Hinweise auf Rechtsverstöße nicht zumutbar. Bei Kenntnis von Rechtsverstößen werden jedoch derartige externe
Verknüpfungen unverzüglich gelöscht.
3. Urheber- und Leistungsschutzrechte
Eigene Inhalte werden unter „CC BY-SA“ veröffentlicht, davon ausgenommen sind als Zitat gekennzeichnete Stellen oder Beiträge in denen ausdrücklich auf eine andere Lizenz hingewiesen wird.
Die Darstellung oder Einbindung der Inhalte dieser Seiten in fremden Seiten ist nur mit schriftlicher Erlaubnis zulässig.
Externe Erläuterung von „CC BY-SA“:
https://creativecommons.org/licenses/by-sa/3.0/de/
http://www.cc-your-edu.de/die-cc-idee/die-cc-lizenzen/
4. Eigener Datenschutz
Die Verwendung der Kontaktdaten des Impressums zur gewerblichen Nutzung/Werbung ist ausdrücklich nicht gestattet, es sei denn der Betreiber hatte zuvor seine schriftliche Einwilligung erteilt oder es besteht bereits eine Geschäftsbeziehung. Der Betreiber und alle auf dieser Website genannten Personen widersprechen hiermit
jeder kommerziellen Verwendung und Weitergabe ihrer Daten.
5. Besondere Nutzungsbedingungen
Soweit besondere Bedingungen für einzelne Nutzungen dieser Seiten von den vorgenannten Nummern 1. bis 4. abweichen, wird an entsprechender Stelle ausdrücklich darauf hingewiesen. In diesem Falle gelten im jeweiligen Einzelfall die besonderen Nutzungsbedingungen.