@kuketzblog

"XMPP-Unterbau ist nicht für die Vermeidung bzw. Schutz von Metadaten konzipiert." Was genau soll das heißen?

Ich würde ja sagen ein föderiertes/dezentrales Protokoll ist automatisch für den Schutz von Metadaten konzipiert, schließlich kann ich als Nutzer selbst entscheiden, wo Metadaten anfallen und sie somit schützen.

@larma Du kannst bei XMPP nur dann selbst entscheiden, wenn du einen eigenen XMPP-Server betreibst - und das auch nur eingeschränkt, da beim Föderieren wiederum Metadaten (von dir) bei anderen Servern auftauchen.

Freiheit ja, Vermeidung von Metadaten eingeschränkt bis schwierig.

@kuketzblog

Natürlich fallen Metadaten bei anderen Servern an, aber eben nur auf meinen Wunsch hin. Wenn ich nicht möchte, dass der Server cia.gov Metadaten von mir erhält, darf ich halt mit friend@cia.gov nicht schreiben. Ich habe also durchaus uneingeschränkt Kontrolle, wo Metadaten anfallen.

XMPP Server kann man theoretisch überall betreiben, zum Beispiel auch auf dem Endgerät selbst. Machen das beide Seiten so, fallen keine Metadaten bei Dritten an (außer ISPs).

@larma Diese Szenarien sind in der Praxis beide kaum relevant.

@kuketzblog
Bei welchem in der Praxis relevantem Messenger-System würdest du diesen Negativ-Punkt (Metadaten fallen an) denn nicht anbringen?

@larma Es gibt Messenger wie Threema oder Signal die einiges dafür tun, das wenig bis kaum Metadaten dauerhaft anfallen bzw. gespeichert werden. Der Artikel zu Signal kommt noch, der von Threema ist hier: kuketz-blog.de/threema-instant

@larma
Das scheint mir der springende Punkt zu sein. Nur zu sagen, dass da viel Metadaten anfallen ohne zu vergleichen, rückt xmpp in eine komische Ecke
@kuketzblog

@mrwsl @larma Ihr könnt gerne die aktuelle Artikelserie zum Thema Messenger lesen bzw. verfolgen. Da wird das Thema "Metadaten" bei jedem Messenger beleuchtet.

@Arco @Bubu

Beides in Sachen Metadaten und praktischer Relevanz ungefähr auf dem Niveau von XMPP oder e-Mail mit Server auf dem Endgerät.

Föderiert ist eben auch nur peer-to-peer mit der (optionalen) Möglichkeit, Aufgaben an andere Geräte und somit Drittparteien abzugeben um damit den Komfort zu erhöhen.

@kuketzblog

@larma @Arco @kuketzblog

Briar geht tendentiell schon noch einen schritt weiter. Selbst beim ISP fallen dort keine metadaten an (da alles über tor oder lokales Netwerk/BT geht).

@Bubu
XMPP Server kann man auch auf .onion Adressen betreiben. Und XMPP im lokalen Netzwerk ist auch spezifiziert. Bluetooth-Funktionalität ist in XMPP afaik derzeit nicht standardisiert.

@larma Ja, aber dann ist es an der stelle halt (viel) einfacher Briar zu verwenden.

@Bubu
Absolut. Eingangs ging es aber um die Metadaten in XMPP. Ich wollte nur anführen, dass diese genausogut auf dem Niveau von Briar angesehen werden könnten. Kommt eben nicht nur auf das Protokoll an, sonden auch darauf, wie man es nutzt.

@larma Bezüglich der praktischen relevanz/Benutzbarkeit stimme ich dir aber wohl zu.

(Auf dem Camp hatte ich auch Synapse auf meinem Handy laufen und darüber mit jemandem geschrieben... ging auch... grade so :D)

@kuketzblog

Natürlich ist das Server-auf-Endgerät-Modell weniger komfortabel (Nachrichten können zum Beispiel nur zugestellt werden, wenn beide Endgeräte Internet-Zugang haben).

Es bleibt aber die Entscheidung des Nutzers eben diese (Meta-)daten einem Dritten anzuvertrauen um Komfort zu gewinnen. Das ist auch konzeptuell notwendig (wer möchte dass Nachrichten offline empfangen werden können muss jemand haben der das für ihn tut) und lässt sich gar nicht weiter verbessern.

@larma Ein herkömmlicher Nutzer wird sich einen Account bei einem XMPP-Server erstellen - und vertraut bei XMPP dann eine ganze Menge an (Meta-)Daten diesem einen Anbieter an.

Ein fachlich versierter Nutzer wird vielleicht einen eigenen Server aufsetzen. Aber das ist eine verschwindend geringe Minderheit. Lies bitte nochmal Ziffer 4 - dort steht alles relevante - auch der Hinweis auf Self-Hosting.

@kuketzblog
Bei jedem serverbasiertem System fallen Metadaten an, das Moxie zB. behauptet bei Signal sind es weniger, kann niemand prüfen. Anonyme Identitäten sind dagegen bei vielen Messengern unmöglich. XMPP mit .onion und ohne httpupload ist fast auf briarniveau. Wer noch mehr Sicherheit braucht, nimmt Brieftauben.
@larma

@kuketzblog Ich habe XMPP (self-hosted mit ejabberd) irgendwann nach vielen Jahren den Rücken zugekehrt. Nachrichtenverlust, oft nicht mal halbgare Clients mit teils abenteuerlichen Abhängigkeiten, von denen keiner alle drei eingesetzten Verschlüsselungsmethoden (GnuPG, OTR, OMEMO) unterstützt hatte, UIs aus dem letzten Jahrtausend, und und und... Bei allem Respekt bzgl. Föderation/Dezentralität but... no. 😋

@datensalat @kuketzblog Das ist aber bestimmt schon einige Jahre her. Nachrichtenverluste treten seit Jahren bei mir nicht mehr auf, und OMEMO hat sich durchgesetzt. Bitte nicht mit veraltetem Wissen funktionierende Dinge kaputt reden.

@sven222 @datensalat Ich muss dich enttäuschen. Das ist aktuelles Wissen aus der Praxis. Ich nutze XMPP täglich selbst.

Es geht mir übrigens nicht ums "Kaputtreden", sondern um eine objektive und ausgewogene Darstellung von Messengern - siehe die ganze Artikelserie dazu.

@kuketzblog @datensalat Meine Antwort war auf den Beitrag von Datensalat, nicht auf Deinen.

@sven222 @kuketzblog Mein Beitrag war ein subjektiver Erfahrungsbericht und hat mit Kaputtreden nichts zu tun. Vor 2 Jahren habe ich für mich begründet Konsequenzen gezogen. XMPP hat meine Anforderungen nicht erfüllt. Matrix/Element tut es.

@kuketzblog
Danke Mike. Dieser Artikel ist für mich als reiner Endnutzer sehr erhellend, weil umfassend und tiefgehend.

Steht auf Deiner Liste der zu testenden #Messenger auch Jami? Und: wird es am Ende dieser Serie eine Art „Wunschliste“ geben, wie aus Deiner Sicht der optimale Messenger aussehen sollte?

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!