Beiträge von Relatable2273

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 3.000 Mitglieder helfen dir weiter. Los gehts!
Unterstützung von offizieller Seite erhältst du direkt bei Threema: Zum offiziellen Threema-Support

    u meinst a) 3MA sollte sozusagen umstellen auf bspw. XMPP oder Matrix?

    wären 2 Optionen - zumindest verschlüsselungstechnisch sowie Nachrichtenformat.

    Eventuell bahnt sich auch MLS als Option an, auch wenn noch recht dürftig: RFC, Elektroshuttle, Tuxedo: Wire-Messenger liefert erste Vorschläge zu Interoperabilität - Golem.de


    Und b) warum provoziert 3MA solche Lösungen geradezu?

    Indem es bzgl. Interoperabilität keinen Schritt auf andere zugeht und dadurch die einzige Möglichkeit für Interoperabilität solche Hacks sind. Logischerweise fehlt dadurch nativen Threemanutzern auch jegliche Transparenz bzgl. Interoperabilität, weil Threema selbst in der Software das Konzept nicht kennt.

    Ja, der Serverbetreiber muss die Zeit aktiv mitschneiden, ansonsten geht die Information verloren. Das ist ein signifikanter Unterschied dazu, wenn es auch später noch nachvollziehbar ist, wie bei Matrix, weil Nachrichten an irgendwelche Rooms gebunden sind.

    Es reicht, wenn die Nachrichten einfach nicht wie geplant aktiv gelöscht werden, dann ist es auch später noch nachvollziehbar.


    Zitat

    Daten fallen immer an, nur bei Matrix eben nicht zwingend immer am selben Ort.

    Richtig. Das ist doch der Knackpunkt. Bei Matrix kannst es dir aussuchen. Wenn du da keine Lust hast, dass der eigene Geheimdienst rankommt, dann meldet ihr euch an Servern in Russland an.

    Bei Threema wird einfach bei der Firmenzentrale geklopft und los geht's.

    Wird bei z.B. FluffyChat angeklopft, zeigen die dir einfach nur die Tür xD


    Du übersiehst hier meinen Punkt: Es ist ganz offensichtlich besser, wenn Metadaten gar nicht oder so wenig wie möglich anfallen, dann braucht man sich nämlich darum auch überhaupt keine Gedanken machen. Ausserdem muss man die Qualität der Metadaten unterschiedlich gewichten. Hier steht Matrix momentan einfach nicht sonderlich gut da.

    Wer, Wann mit Wem - das leaked Threema wie Matrix. Man ist also weit davon entfernt sich keine Gedanken machen zu müssen. Da hilft es nun auch nicht damit anzukommen, dass doch bei Matrix z.B. eine eventuelle Raumbezeichnung/thema (zumindest aktuell noch) geleaked wird.


    Faktisch stehen beide nicht gut da.

    Bei Threema ist es sogar noch total unnötig, weil sie ohne Probleme z.B. den Sender der Nachrichtmit in die verschlüsselten Inhalte bringen könnten.

    Auf Grund der Zentralisierung kann man sogar ähnlich guten Metadatenschutz wie Signal implementieren, oder gar darüber hinausgehen:

    Improving Signal’s Sealed Sender – NDSS Symposium (ndss-symposium.org)

    Warum wird das nicht gemacht?



    Distribution List. Zug fährt durch Tunnel. Internet war kurz weg. Führt alles gleichermassen zu Bursts.

    Selbst in diesem Szenario kann man sie auseinanderhalten durch die Timestamps, oder nicht?

    threema-android/MessageBox.java at 065fc5736dff8aa9ad24d75f2cf0619317248148 · threema-ch/threema-android (github.com)


    Nein, aber scheinbar ist es für dich unvorstellbar, dass der Begriff Dezentralität kontextuell verwendet werden kann und nicht immer nur der Serverstandort gemeint ist.

    Der Serverstandort kam bisher doch nichtmal ins Spiel, oder? Bisher wolltest du uns verklickern, dass das Protokoll von Threema dezentral wäre, weil der Server sich nicht um Gruppenmanagement kümmert.

    Nein, alle Nachrichten an Gruppenteilnehmer (A, B, C) sind ganz normale E2EE-Nachrichten für den Server und sehen so aus, als hätte A etwas an B und dann A etwas an C geschickt.

    Ahja, und der Serverbetreiber stellt sich dann dumm und tut so als würde er nicht wissen, dass ein Batch von gleich großen Nachrichten vom gleichen Absender an x Ziele an die selbe Gruppe geht?


    Deine Aussage ist in etwa gleichbedeutend zu, "wenn man nicht kommuniziert, ist auch nichts sichtbar". Ja, natürlich fallen dann auch keine Daten an.

    Bei Threema ist das so. Bei Matrix nicht.


    die Information transparent über eine dezentrale Instanz senden.

    Was ist eine dezentrale Instanz?


    aber Dezentralität führt nicht etwa zu weniger Metadaten, sondern maximal zu verteilteren Metadaten.

    Stimmt, aber es ist durchaus relevant WER Metadaten sieht.


    Sind die Metadaten von allen Nutzern an einer Stelle einsehbar (Threema)?

    Können Nutzer bestimmen wer Zugriff auf die Metadaten hat (Matrix)?

    Können Nutzer komplett vermeiden, dass Metadaten überhaupt bei einem festen Dienst landen (P2P Matrix)?


    Es gibt Indikatoren dafür, dass etwas eine Gruppennachricht sein könnte (z.B. zeitlicher Abstand zwischen Nachrichten), aber keine Garantie. Das war jetzt auch mein letzter Versuch, dir das zu erklären.

    Nenn mir ein realistisches Szenario, in dem es keine Garantie ist.

    Ich denke mal die vermeintliche Dezentralität ist sowieso schon vom Tisch.

    Du hast Threema offenbar nicht verstanden

    Es geht nicht darum Threema zu verstehen, sondern die Bedürfnisse der Nutzer.


    Zitat

    Nutzt Du es überhaupt?

    Nicht mehr.

    Habs deinstalliert, nachdem Element offiziell E2EE released hatte, weil es meine Bedürfnisse besser befriedigen konnte.

    Dort kann man übrigens einstellen

    1) wer Nachrichten löschen darf oder nicht

    2) ob und wann Nachrichten automatisch vom Server und/oder Endgeräten gelöscht werden


    Das hat z.B. sicherheitstechnische und kommunikationstechnische Vorteile und erlaubt auch bessere Moderation.

    und es ist für den Server nicht ersichtlich, dass diese überhaupt existiert.

    Das stimmt so nicht.

    Sobald du an eine Gruppe eine Nachricht schickst, weiß der Server, dass diese existiert. In der Tat kann die Gruppe nicht existieren, ohne eine Nachricht über den Server zu senden.


    Was ein Threema-Server sieht, sind Nachrichten von A nach B. Ein Matrix-Server kennt wesentlich mehr, z.B. dass Kommunikation in Room XY stattfindet.

    Ein Matrix Server kennt ohne weitere Informationen erstmal nichts. Damit ein Matrix Server Informationen über die Kommunikation einer Gruppe erfährt, muss sich mindestens ein Teilnehmer der Gruppe auf diesen Server registriert haben.

    Das steht im Gegensatz zu Threema, wo die Nachrichten IMMER über den einen Server gehen.

    Fazit: Threema weiß über jegliche Kommunikation Bescheid.


    Was Threema nur nicht weiß ist wie ihr eure Gruppe genannt habt ;)


    Hier mal ein Schaubild zu Dezentralität vs Zentralität:

    Matrix, a decentralized communication platform | Linux Addicts

    Vielleicht mal eine generrelle Frage, kann man einen Matrix/Element Server so gestalten, dass er Threema, was Datenschutz und Sicherheit betrifft, schlägt?

    Bei Sicherheit kann man bei Matrix generell punkten im Bezug auf PFS, das Threema fehlt.

    Außerdem ist Interoperabilität mit durchgängiger E2EE möglich. Die einzige Threema-Bridge, dich bisher kenne, bricht zweimal E2EE auf (einmal durch die Bridge selbst, einmal durchs Threema Gateway).


    Bei Datenschutz kann man argumentieren, dass man selbst in der Hand hat, wer Zugriff auf die Daten hat (der eigene gewählte Server sowie diejenigen der Kommunikationsteilnehmer).

    Ansonsten (Datenschutz -> Metadaten) muss man erst weitere Entwicklungen beim Protokoll abwarten, z.B.

    - P2P Matrix: In diesem Szenario wären gehostete Server entweder gar nicht mehr nötig, oder nur als Store&Forward-System nötig: Introducing the Pinecone overlay network | Matrix.org

    - Verschlüsseln von z.B. der Raumbeschreibung (State-Events): matrix-spec-proposals/3414-encrypted-state.md at travis/msc/encrypted-state · matrix-org/matrix-spec-proposals (github.com)


    Bis dahin gilt, dass es allemal besser ist die Leute nutzen einen verschlüsselten Messenger (z.B. Element) statt unverschlüsselte wie z.B. Telegram, weil Matrix einem halt die Welt bietet.


    Auf jeden Fall kann man aber sagen, dass Matrix auf Protokollebene eher zentral organisiert und Threema eher dezentral. Konkret erkennbar ist das an der Art und Weise wie Gruppen (bei Matrix Rooms) implementiert sind, wo bei Matrix die Gruppe auf dem Server organisiert wird und bei Threema auf den Clients.

    Bei Matrix gibt es nicht DEN Server. Schon alleine beim Lesen von Threema dezentraler als Matrix steigen einem die Haare zu Berge

    Stichwort: lokale Speicherung. Threema sichert/kopiert unsere Daten nicht auf eigenen Servern!


    Anders formuliert: Threemas Server dienen ausschließlich als Relaisstationen.

    Und der Private Key befindet sich ebenfalls ausschließlich lokal auf dem Kundengerät.

    Fazit: wir Kunden haben wirklich die Verfügungsgewalt über unsere eigenen Daten.


    Ja, kann in einer Gruppe mit schwarzem Schaf sehr unangenehm sein.

    Nur, weil die Daten nicht (langfristig, tatsächlich werden die Nachrichten temporär auf dem Server gespeichert) auf einem Server gespeichert werden, heißt das nicht, dass nicht ein Mechanismus zur Löschung der Daten implementiert werden könnte.


    Daten nicht löschen können und die Verfügungsgewalt über die eigenen Daten zu haben widerspricht sich außerdem etwas.

    Aber ehrlich gesagt hoffe ich, dass auch in Zukunft nur eine Kommunikation Threema <-> Threema möglich ist und Threema auch der einzige Messenger bleibt, mit dem Threema-Nutzer erreichbar sind

    Das ist Wunschträumerei.

    Je mehr sich Messenger gegen Kommunikation mit anderen Messengeranbietern wehren, desto ekliger wird.


    Im Idealfall unterstützt Threema einen offenen Standard für Messaging. Am sichersten und bequemsten für alle.

    Geht das nicht, gibts ne Bridge zu Threema. Die kann entweder relativ gut umgesetzt werden (z.B. offene API wie Telegram), oder muss hingefrickelt werden (closed source, z.B. iMessage).

    Im ersteren Fall kann die Bridge noch lokal mit auf dem Smartphone laufen - taugt also für einen datenschutzfreundlichen Einsatz, da E2EE quasi erhalten bleiben könnte)

    Im letzteren Fall muss zwangsweise einen (fremden) Server laufen, der sich um die Frickellösung kümmert, weil sich ein normaler Benutzer sich das nicht antun kann geschweige denn antut (z.B. gejailbraiktes IPhone oder iMac in der Cloud verwalten).


    Man sieht auf jeden Fall, dass immer eine Lösung gefunden wird, egal wie interoperabilitätsfeindlich ein Messenger/Anbieter (haha Apple) ist.


    Während man im ersten Fall noch weiß mit welchem Gegenüber man es zu tun hat (z.B. würde mit der aktuellen Version von Matrix immer die Domain des anderen Benutzers bekannt sein), bekommt der Nutzer bei der letzten Variante absolut nichts mit, weil der Messenger selbst kein Konzept von Interoperabilität hat.


    Achja, es gibt auch für Matrix eine Threema Bridge, die sich anbahnt, obwohl der Messenger so unbekannt ist: bitbetterde/Threematrix at v0.1.0 (github.com)

    Und das obwohl Threema der härteste Lobbyist gegen das Öffnen von Big Tech Silos in der ganzen EU ist. Respekt. Richtig konsumentenfeindlich. Das muss man erstmal hinbekommen.


    Wird spannend

    Threema sagt aber, dass die Wahrscheinlichkeit, dass ein Angreifer den vollständigen Datenstrom direkt aus den Servern ableiten kann, extrem gering ist im Vergleich zu einem MITM-Szenario [1].

    Diese Aussage ergibt keinen Sinn, weil "den vollständigen Datenstrom direkt aus den Servern ableiten" ebenfalls ein MITM Szenario ist.

    Nee, das geht nur schon deshalb nicht, weil Schlüsselverwaltung, Schlüsselaustausch, Cyphers, Protokolle, Identitätsmanagement usw. total unterschiedlich sind.

    Doch, das geht, und passiert bereits in der Praxis. Matrix ist ein offener Standard für dezentrale, sichere Kommunikation. Element, und z.B. FluffyChat sind zwei verschiedene Messenger, die den Standard nutzen, und somit auch die standardisierte Schlüsselverwaltung, etc.

    Der Nutzer kann also mit anderen Nutzern, die verschiedenste Messenger nutzen können, kommunizieren, ohne sich in einen Walled Garden wie Threema einzuschließen


    Matrix funktioniert z.B. wie zu Großvaters Zeiten mit einem Konto auf einem Server, bei dem man sich mit Nutzername/Passwort anmelden muss, während beispielsweise Threema sich beim Server lediglich mittels Schlüsselableitung identifiziert.

    und weiter?

    Nutzername = Threema ID

    Passwort = private key

    Nur, weil man das bei Threema nicht Konto nennt, heißt es nicht, dass es kein Konto ist:

    Zitat

    Um abzufragen, welche Bestandsdaten auf dem Threema-Server zu Ihrer ID gespeichert sind, senden Sie einfach «info» an die Threema-ID *MY3DATA, und Sie erhalten umgehend eine Antwort in maschinenlesbarer Form (JSON-Format).