Ich arbeite schon sehr lange bei #Threema und sehe, dass hier gerade eine Panikwelle durchzieht, man die App jetzt plötzlich boykottiert, weil Threema verkauft wird.
-
@thoralf @missqarnstein @f09fa681 Nicht auf die von mir angebrachten Aspekte, denn Matrix kann das nicht.
Die Bundesbehörden haben radikal andere Anforderungen an Chats als Privatmenschen. Bspw. Transparenzpflichten. Übrigens nutzen die Bundesbehörden kaum die föderalen Aspekte des Bundesmessengers, bzw. haben eine zentrale Verwaltung ihrer Server. Also ziemlich anders als Matrix in-the-wild.
Also nein, Matrix ist wirklich nicht die Antwort. Nicht auf diese Fragen. Einen Tod muss man sterben, und man kann natürlich Resilienz wichtiger sehen als PFS+Multi-Device+... . Das ist absolut legitim. Dann ist auch Matrix die richtige Wahl. Aber manchmal ist PFS & Co. wichtiger, dann ist Matrix die falsche Wahl.
Die Diskussion über Dezentral vs. Zentral ist so absurd, weil Dezentral immer als das klar Bessere dargestellt wird. Aber die eigentliche Diskussion sollte ja auch über die "Kosten" von dezentral gehen, also Abstriche in der Kryptographie bspw. Und die sind real.
@ljrk @thoralf @missqarnstein @f09fa681
Matrix hat PFS (Sitzungserneuerung variabel einstellbar) und Multidevice.
-
@thoralf @missqarnstein @f09fa681 Nicht auf die von mir angebrachten Aspekte, denn Matrix kann das nicht.
Die Bundesbehörden haben radikal andere Anforderungen an Chats als Privatmenschen. Bspw. Transparenzpflichten. Übrigens nutzen die Bundesbehörden kaum die föderalen Aspekte des Bundesmessengers, bzw. haben eine zentrale Verwaltung ihrer Server. Also ziemlich anders als Matrix in-the-wild.
Also nein, Matrix ist wirklich nicht die Antwort. Nicht auf diese Fragen. Einen Tod muss man sterben, und man kann natürlich Resilienz wichtiger sehen als PFS+Multi-Device+... . Das ist absolut legitim. Dann ist auch Matrix die richtige Wahl. Aber manchmal ist PFS & Co. wichtiger, dann ist Matrix die falsche Wahl.
Die Diskussion über Dezentral vs. Zentral ist so absurd, weil Dezentral immer als das klar Bessere dargestellt wird. Aber die eigentliche Diskussion sollte ja auch über die "Kosten" von dezentral gehen, also Abstriche in der Kryptographie bspw. Und die sind real.
@ljrk @missqarnstein @f09fa681 Doch, die Bundesbehörden nutzen sehr wohl Föderation, sogar sehr intensiv.
Das ist im BundesMessenger auch explizit so vorgesehen. -
@ljrk @missqarnstein @f09fa681 Doch, die Bundesbehörden nutzen sehr wohl Föderation, sogar sehr intensiv.
Das ist im BundesMessenger auch explizit so vorgesehen.@thoralf @missqarnstein @f09fa681 Nochmal: Auf technischer Ebene, ja. Auf Verwaltungsebene nein.
Es gibt zentrale Vorgaben und Organisationen. Es ist nicht so, dass ich von meinem Matrix damit einfach kommunizieren kann. Das reduziert diverse Probleme die damit einhergehen. Matrix mit Threema hier zu vergleichen ist absurd.
-
@f09fa681 Es gibt eine "einfache" Lösung: Nicht auf Firmen setzen, deren Ziel Gewinnerzielung ist.
Egal wie hehr die Ziele des Unternehmens vorgeblich sind - das Hauptziel von AGs, GmbHs und co. ist Gewinnerzielung. Wenn es also hart auf hart kommt, werden die gutklingenden Werte immer zurückstehen müssen.Nehmt stattdessen Genossenschaften, Stiftungen, Vereine, wenn's sein muss gGmbHs. Da sind die sogenannten Werte eben nicht nur Papiertiger, sondern mit in die Organisationsform eingebunden.
Und: So manche der genannten Organisationsformen haben auch noch den Vorteil, unverkäuflich zu sein, so dass es das vorliegende Szenario gar nicht erst gibt.
-
@ljrk @thoralf @missqarnstein @f09fa681
Matrix hat PFS (Sitzungserneuerung variabel einstellbar) und Multidevice.
@kitkat @thoralf @missqarnstein @f09fa681 Aber nicht föderiert. Also es gibt immer den Server in dem der Room fest angeordnet ist der die atomare Ordnung vorgibt. Das meinte ich mit "Matrix ist nicht die Lösung", weil eben Föderation in sich inkompatibel ist mit dem PFS requirement (nach aktuellem Stand der Forschung).
-
Ich arbeite schon sehr lange bei #Threema und sehe, dass hier gerade eine Panikwelle durchzieht, man die App jetzt plötzlich boykottiert, weil Threema verkauft wird. Vielleicht darf ich das mal einordnen:
Ich habe viele Jahre mit den drei Gründern zusammen an Threema gearbeitet. Ich habe den Verkauf an Afinum 2020 miterlebt und später den Rückzug der Gründer in 2024. Derzeit wird Threema an Comitis verkauft - auch ein Private Equity Unternehmen, genau wie Afinum damals. Wenn's also nur um den Verkauf geht, gibt es erstmal eigentlich keinen Grund zur Panik.
Aber: Es ist eine Änderung. Auf jeden Fall gilt es, das kritisch zu betrachten und zu beobachten. Auf jeden Fall sollte laut geschrien werden, sobald Enshittification stattfindet! Bitte, macht das! Und ich wäre mit Sicherheit unter den ersten Personen, die aus Protest gehen würden, sollte Threema mal die eigenen Werte aufgeben.
Aber warum diese Aufregung jetzt, weil Threema gerade von Private Equity A an Private Equity B verkauft? Das verstehe ich nicht.
> Auf jeden Fall sollte laut geschrien werden, sobald Enshittification stattfindet!
Dann ist es doch bereits zu spaet.
Und durch die Silowirkung von IM ist es auch super schwer die Menschen dann wieder weg zu bekommen.
Es waere schon besser wenn auf Threema under die DSA und Interoperability fallen wuerde, dann koennte man Threema mehr empfehlen.
-
@Morgunin Ich kenne die Dudes nicht persönlich und bin auch kein Fan der Branche, die vornehmlich Reiche noch reicher macht, wäre aber auch vorsichtig mit guilty by association.
Du hast Recht, dass es auf der Webseite scheinbar keine Infos zu den Geldgebern gibt. Hatte es falsch in Erinnerung. Ich hab sie aus interner Kommunikation und müsste erst fragen ob das geteilt werden darf.
Last but not least: Die Clients von Threema sind source available und auf die kommt es bei E2EE vornehmlich an. Fehlt dir etwas an grundlegender Transparenz darüber hinaus?
-
-
@kitkat @thoralf @missqarnstein @f09fa681 Aber nicht föderiert. Also es gibt immer den Server in dem der Room fest angeordnet ist der die atomare Ordnung vorgibt. Das meinte ich mit "Matrix ist nicht die Lösung", weil eben Föderation in sich inkompatibel ist mit dem PFS requirement (nach aktuellem Stand der Forschung).
@ljrk @thoralf @missqarnstein @f09fa681
> Aber nicht föderiert.
doch
> Also es gibt immer den Server in dem der Room fest angeordnet ist der die atomare Ordnung vorgibt.
nein, das trifft auf Matrix nicht zu.
Vielleicht verwechselst du das mit XMPP oder MLS.Darf ich fragen, woher du deine Informationen beziehst?
-
@ljrk @thoralf @missqarnstein @f09fa681
> Aber nicht föderiert.
doch
> Also es gibt immer den Server in dem der Room fest angeordnet ist der die atomare Ordnung vorgibt.
nein, das trifft auf Matrix nicht zu.
Vielleicht verwechselst du das mit XMPP oder MLS.Darf ich fragen, woher du deine Informationen beziehst?
@kitkat @thoralf @missqarnstein @f09fa681 E2E Gruppenchats haben entweder:
1. Kein PFS at all (Shared Key)
2. Synchronous Continuous Group Key Agreement (mpOTR): Alle müssen permanent online sein:
3. N-Times Client-Side oder Server-Side Fan-Out (Signal IIRC, Threema): Viel Traffic
4. Centrally Coordinated Asynchronous Continuous Group Key Agreement (TreeKEM/MLS/Wire): Zentraler atomarer Server
5. Abgestimmte Synchronisationsintervalle (Megolm): Nur Partial Forward SecrecyJa, ich habe mich dabei auf MLS bezogen, weil Matrix da gerade hinmigrieren will. Matrix ohne MLS hat kein Perfect Forward Secrecy, sondern Megolm hat nur Partial Forward Secrecy, mit den rotierenden Key-Intervallen die du schon angesprochen hast.
Wie gesagt, irgendeinen Kompromiss muss man machen, es gibt zwar aktuell Forschung auch das Asynchron/Unkoordiniert zu machen, aber so weit sind wir nicht in der Forschung.
Mein Punkt war aber kein Matrix-Bashing. Matrix macht tolle, wichtige Dinge. Aber es legt andere Schwerpunkte als Threema & Signal und ist daher "nicht die Lösung" auf deren Probleme. Möchte man Perfect Forward Secrecy in E2E Gruppenchats ist *aktuell* nur eine der Option 2-4 oben möglich. Matrix entscheidet sich für 4 (MLS-basiert) bzw. 5 (Megolm-basiert), Threema für 4, Signal für 3 (AFAIK).
-
Ich arbeite schon sehr lange bei #Threema und sehe, dass hier gerade eine Panikwelle durchzieht, man die App jetzt plötzlich boykottiert, weil Threema verkauft wird. Vielleicht darf ich das mal einordnen:
Ich habe viele Jahre mit den drei Gründern zusammen an Threema gearbeitet. Ich habe den Verkauf an Afinum 2020 miterlebt und später den Rückzug der Gründer in 2024. Derzeit wird Threema an Comitis verkauft - auch ein Private Equity Unternehmen, genau wie Afinum damals. Wenn's also nur um den Verkauf geht, gibt es erstmal eigentlich keinen Grund zur Panik.
Aber: Es ist eine Änderung. Auf jeden Fall gilt es, das kritisch zu betrachten und zu beobachten. Auf jeden Fall sollte laut geschrien werden, sobald Enshittification stattfindet! Bitte, macht das! Und ich wäre mit Sicherheit unter den ersten Personen, die aus Protest gehen würden, sollte Threema mal die eigenen Werte aufgeben.
Aber warum diese Aufregung jetzt, weil Threema gerade von Private Equity A an Private Equity B verkauft? Das verstehe ich nicht.
@f09fa681 Panik nicht, aber Sorge doch. Enshittification ist ein reales Thema, das gerade das Threema-Zielpublikum umtreibt. Insofern hätte Threema der Diskussion eine Menge Wind aus den Segeln nehmen können, indem sie auf ihrem eigenen News-Feed und auch hier aktiv informiert hätten, statt nur zu reagieren. Dann hätte sich meiner Ansicht nach die Sache auch gar nicht so hochgeschaukelt.
-
@f09fa681 Panik nicht, aber Sorge doch. Enshittification ist ein reales Thema, das gerade das Threema-Zielpublikum umtreibt. Insofern hätte Threema der Diskussion eine Menge Wind aus den Segeln nehmen können, indem sie auf ihrem eigenen News-Feed und auch hier aktiv informiert hätten, statt nur zu reagieren. Dann hätte sich meiner Ansicht nach die Sache auch gar nicht so hochgeschaukelt.
@achso Ich bin mir nicht sicher, ob die Kommunikation so geplant war. Hätte auf jeden Fall besser koordiniert sein können. Wenn du allerdings bei @threemaapp in die Antworten schaust, wirst du sehen, dass sehr schnell reagiert wurde.
Und hochgeschaukelt hätte sich das mMn sowieso. PE und VC wird (vielfach auch zu Recht) extrem skeptisch betrachtet. Aber das Doomsaying auf dem Niveau war dann doch unerwartet.
-
@missqarnstein @thoralf @f09fa681 Nein, das definitiv nicht!
Aber aus irgendwelchen Gründen ist das ja auch beim letzten Investor irgendwie gut gegangen -- und das liegt auch daran, dass Threema sich unter dem Investor von einem Produkt auf dem absteigenden Ast, zu einem aufsteigenden entwickelt hat. Jetzt verkauft der PE (5 Jahre sind eine übliche Holding Time), natürlich mit Gewinn.
Es gibt PEs die sind auf reine Extraktion aus. Was passiert, werden wir sehen. Aber ich behaupte, es ergibt bei Threema wenig Geld daraus zu schlagen, Threema zu Enshittifien. Ich persönlich sehe eher potentiale (sowohl gut als auch schlecht) bei Threema.Work und werde insbesondere das privat sehr stark beobachten. Bei Threema B2C bin ich recht entspannt.
-
@kitkat @thoralf @missqarnstein @f09fa681 E2E Gruppenchats haben entweder:
1. Kein PFS at all (Shared Key)
2. Synchronous Continuous Group Key Agreement (mpOTR): Alle müssen permanent online sein:
3. N-Times Client-Side oder Server-Side Fan-Out (Signal IIRC, Threema): Viel Traffic
4. Centrally Coordinated Asynchronous Continuous Group Key Agreement (TreeKEM/MLS/Wire): Zentraler atomarer Server
5. Abgestimmte Synchronisationsintervalle (Megolm): Nur Partial Forward SecrecyJa, ich habe mich dabei auf MLS bezogen, weil Matrix da gerade hinmigrieren will. Matrix ohne MLS hat kein Perfect Forward Secrecy, sondern Megolm hat nur Partial Forward Secrecy, mit den rotierenden Key-Intervallen die du schon angesprochen hast.
Wie gesagt, irgendeinen Kompromiss muss man machen, es gibt zwar aktuell Forschung auch das Asynchron/Unkoordiniert zu machen, aber so weit sind wir nicht in der Forschung.
Mein Punkt war aber kein Matrix-Bashing. Matrix macht tolle, wichtige Dinge. Aber es legt andere Schwerpunkte als Threema & Signal und ist daher "nicht die Lösung" auf deren Probleme. Möchte man Perfect Forward Secrecy in E2E Gruppenchats ist *aktuell* nur eine der Option 2-4 oben möglich. Matrix entscheidet sich für 4 (MLS-basiert) bzw. 5 (Megolm-basiert), Threema für 4, Signal für 3 (AFAIK).
@ljrk @thoralf @missqarnstein @f09fa681
"Matrix ohne MLS hat kein Perfect Forward Secrecy, sondern Megolm hat nur Partial Forward Secrecy, mit den rotierenden Key-Intervallen die du schon angesprochen hast."
setz das Intervall auf 1 und du hast 100% FPS
"Ja, ich habe mich dabei auf MLS bezogen, weil Matrix da gerade hinmigrieren will. "
Bis jetzt gibt es noch keine konkreten Pläne, sondern lediglich Ideen. Vor allem gibt es aber auch dMLS, was extra für Matrix entwickelt wurde, was vermeidet, dass ein zentralen Server notwendig ist.
Der Tradeoff hier ist aber nicht PFS, sondern algorithmische Komplexität/Performance.
"Möchte man Perfect Forward Secrecy in E2E Gruppenchats ist *aktuell* nur eine der Option 2-4 oben möglich. "
Ist eben falsch.
-
@ljrk @thoralf @missqarnstein @f09fa681
"Matrix ohne MLS hat kein Perfect Forward Secrecy, sondern Megolm hat nur Partial Forward Secrecy, mit den rotierenden Key-Intervallen die du schon angesprochen hast."
setz das Intervall auf 1 und du hast 100% FPS
"Ja, ich habe mich dabei auf MLS bezogen, weil Matrix da gerade hinmigrieren will. "
Bis jetzt gibt es noch keine konkreten Pläne, sondern lediglich Ideen. Vor allem gibt es aber auch dMLS, was extra für Matrix entwickelt wurde, was vermeidet, dass ein zentralen Server notwendig ist.
Der Tradeoff hier ist aber nicht PFS, sondern algorithmische Komplexität/Performance.
"Möchte man Perfect Forward Secrecy in E2E Gruppenchats ist *aktuell* nur eine der Option 2-4 oben möglich. "
Ist eben falsch.
@kitkat @thoralf @missqarnstein @f09fa681 Klar, aber halt auch alle Nachteile die ein desync mit sich trägt, die du eben bei Signal/Threema nicht hast. Klar, ich kann auch PFS mit E2EE in Gruppenchats so bauen, dass ich's nicht nutzen will, das wäre dann Option 0. Finde ich aber keine gute Option.
Wie dMLS das lösen will weiß ich nicht, vielleicht schaffen sie ja wirklich das, was die anderen Top-Forscher*innen nicht hinbekommen... Bisher habe ich kein Paper im cryptography eprint gesehen, welches eine solche Architektur sinnvoll unterfüttern könnte.
-
@kitkat @thoralf @missqarnstein @f09fa681 Klar, aber halt auch alle Nachteile die ein desync mit sich trägt, die du eben bei Signal/Threema nicht hast. Klar, ich kann auch PFS mit E2EE in Gruppenchats so bauen, dass ich's nicht nutzen will, das wäre dann Option 0. Finde ich aber keine gute Option.
Wie dMLS das lösen will weiß ich nicht, vielleicht schaffen sie ja wirklich das, was die anderen Top-Forscher*innen nicht hinbekommen... Bisher habe ich kein Paper im cryptography eprint gesehen, welches eine solche Architektur sinnvoll unterfüttern könnte.
Aber nochmal zur Einordnung, ich finde die Arbeit hinter Matrix toll und wichtig. Es geht mir auch gar nicht darum, das niederzumachen. Es geht mir eher darum, dass man die Komplexität sowas auch föderiert und dezentral zu machen nicht unterschätzt. Und "einfach Signal/Threema in dezentral" ist eben nicht so leicht und bringt auch viele andere Fragen mit: Auch welche die weniger mit Krypto zu tun haben. Was ist mit Admin-Rechten in Räumen, Gruppenzugehörigkeiten, etc.? Da bietet Matrix viel mehr Features als Threema/Signal, aber auch mehr Angriffsfläche.
Es ist einfach ein anderer Dienst, mit einem anderen Fokus. Ich nutze beides, für unterschiedliche Zwecke. Aber die Aussage "Matrix ist so wie Threema/Signal + dezentral und daher besser" ist verkürzt.
-
@kitkat @thoralf @missqarnstein @f09fa681 Klar, aber halt auch alle Nachteile die ein desync mit sich trägt, die du eben bei Signal/Threema nicht hast. Klar, ich kann auch PFS mit E2EE in Gruppenchats so bauen, dass ich's nicht nutzen will, das wäre dann Option 0. Finde ich aber keine gute Option.
Wie dMLS das lösen will weiß ich nicht, vielleicht schaffen sie ja wirklich das, was die anderen Top-Forscher*innen nicht hinbekommen... Bisher habe ich kein Paper im cryptography eprint gesehen, welches eine solche Architektur sinnvoll unterfüttern könnte.
@ljrk @thoralf @missqarnstein @f09fa681
"Klar, aber halt auch alle Nachteile die ein desync mit sich trägt"
die wären?
1) Mehr statt weniger Ressourcennutzung
2) ... ?"Wie dMLS das lösen will weiß ich nicht"
Wird hier beschrieben: https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentralised2/decentralised.org
Hab auch gehört, dass Wire da auch einen Entwurf hat.
-
@ljrk @thoralf @missqarnstein @f09fa681
"Klar, aber halt auch alle Nachteile die ein desync mit sich trägt"
die wären?
1) Mehr statt weniger Ressourcennutzung
2) ... ?"Wie dMLS das lösen will weiß ich nicht"
Wird hier beschrieben: https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentralised2/decentralised.org
Hab auch gehört, dass Wire da auch einen Entwurf hat.
@kitkat @thoralf @missqarnstein @f09fa681 Inkonsistenter Chat, primär. Darauf gehen sie auch in der Beschreibung (Danke für den Link) recht früh ein. Das Problem hatte Megolm ja auch z.T. (also fehlende Nachrichten etc.) und IIRC war das kein reines Implementationsproblem. Wenn man hier die Anforderungen etwas aufweicht, kriegt man das auch ohne atomic ordering hin, aber ich finde die ersten Absätze haben es an "Annahmen" ziemlich in sich.
-
@kitkat @thoralf @missqarnstein @f09fa681 Inkonsistenter Chat, primär. Darauf gehen sie auch in der Beschreibung (Danke für den Link) recht früh ein. Das Problem hatte Megolm ja auch z.T. (also fehlende Nachrichten etc.) und IIRC war das kein reines Implementationsproblem. Wenn man hier die Anforderungen etwas aufweicht, kriegt man das auch ohne atomic ordering hin, aber ich finde die ersten Absätze haben es an "Annahmen" ziemlich in sich.
@ljrk @thoralf @missqarnstein @f09fa681
"Inkonsistenter Chat, primär. Darauf gehen sie auch in der Beschreibung (Danke für den Link) recht früh ein. Das Problem hatte Megolm ja auch z.T. (also fehlende Nachrichten etc.) und IIRC war das kein reines Implementationsproblem. "
Das eine hat mit dem anderen nichts zu tun.
Die Nachrichtenverteilung läuft unabhängig vom Schlüsselmanagement.
Wenn letzteres Probleme macht, gibt's ein "unable to decrypt".Inkonsistenter Chat deutet entweder auf Netzwerkprobleme oder Föderationsprobleme (entweder bugs oder inherent durch dezentrale Natur) hin.
-
@ljrk @thoralf @missqarnstein @f09fa681
"Inkonsistenter Chat, primär. Darauf gehen sie auch in der Beschreibung (Danke für den Link) recht früh ein. Das Problem hatte Megolm ja auch z.T. (also fehlende Nachrichten etc.) und IIRC war das kein reines Implementationsproblem. "
Das eine hat mit dem anderen nichts zu tun.
Die Nachrichtenverteilung läuft unabhängig vom Schlüsselmanagement.
Wenn letzteres Probleme macht, gibt's ein "unable to decrypt".Inkonsistenter Chat deutet entweder auf Netzwerkprobleme oder Föderationsprobleme (entweder bugs oder inherent durch dezentrale Natur) hin.
@kitkat @thoralf @missqarnstein @f09fa681 Ich hätte jetzt "unable to decrypt" bei manchen TN als inkonsistenten Status bezeichnet, aber das war vllt. auch unpräzise ausgedrückt.