Threema mit einer ID parallel auf mehreren Geräten | Multidevice

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.800 Mitglieder helfen dir weiter. > Frage stellen <

  • Die Daten selbst werden ja schon auf dem Server gepuffert, bis der Adressat wieder online kommt. Sieht man schön wenn man für die eigenen Geräte eine Gruppe baut für je einen der wichtigen Adressaten. Dann kommen sie im Block rein. Verbindungsdaten werden wohl nicht gespeichert. Aber was hält Threema davon ab den Benutzer entscheiden zu lassen:
    1 vollständig anonym - keinerlei Datenresidenz auf dem Server
    2 verknüpft mit mail/tel Nr - kurzzeitig ID-Daten auf dem Server
    3 Multi Device - permanente Threema-ID Relationen auf dem Server

    1. Wie du schon angemerkt hast, müssen die Daten für einen kurzen Zeitraum auf dem Chat Server gespeichert werden. Insofern gibt es die Option keinerlei Datenresidenz nicht, zumindest nicht für den genannten Zeitraum. Auch verstehe ich nicht, welchen Zusammenhang dies mit 2. und 3. hat.

    2. Verstehe ich nicht. Diese Verknüpfung existiert doch bereits (auch wenn sie anonymisiert erfolgt)?

    3. Welche Relation meinst du?

    Du sprichst von ID-Daten und ID-Relationen. Aus der Bezeichnung ergibt sich für mich nicht, welche Daten das denn nun sein sollen. Die Chat-Historie auf dem Server zu speichern ist ausgeschlossen und stellt allein technisch eine riesige Hürde dar. Wenn auch nur 1/10 der Threema-User sich dazu entscheiden würden, die Chat-Historie, Kontakte und Gruppen auf dem Server liegen zu lassen, wäre es ein erheblicher Aufwand diese Daten zu verwalten. Das ist nämlich der nette Nebeneffekt der temporären Speicherung - es müssen keine riesigen Datenbanken gepflegt werden, wie dies z.B. bei Facebook der Fall ist. Mal abgesehen davon, wie teuer der Spaß wäre und welch gravierende architekturtechnische Veränderungen das zur Folge hätte.

    Ex-Threema Software Engineer

    Einmal editiert, zuletzt von Lenny (29. Oktober 2015 um 13:00)

  • Ich habe in der Liste den Tradeoff zwischen Anonymität und Komfort knapp skizziert. Und über den Status Quo hinaus fortgesetzt. Natürlich ist Nummer 2 der Status Quo. Nummer 3 bedeutet nicht die Historie zu speichern, sondern bezieht sich auf den Kontext Multidevice. Da wurde argumentiert dass dies persistente Daten bei Threema bedeuten würde. Meine Antwort: so what, WENN es für alle Beteiligten transparent ist, inkl. der Konsequenzen. Das ist der Unterschied zwischen Bevormunding und Mündigkeit.

    Gesendet von meinem SM-N9005 mit Tapatalk

    Einmal editiert, zuletzt von Chris (31. Oktober 2015 um 16:31)

  • Sinnvoll wäre es, dass die Nachrichten nur für eine maximale Zeit zwischengespeichert werden, die bei Messengern meiner Ansicht nach nicht sehr lange sein sollte. Was bis dahin nicht ausgeliefert ist, wird gelöscht. In Kombination mit einer "selbstzerstörenden", zeitgesteuerten Nachricht wäre es auch denkbar, dass der User das aufgrund seiner Sicherheitsüberlegungen mitbestimmen kann.

  • Gibt es schon Neuigkeiten für das im Sommer 2014 geplante Multi-Device Feature? Ich bin mir bewusst, dass man es auf mehreren Geräten kaufen und nutzen kann. Das Problem darin sehe ich nicht beim Senden, sondern beim Empfangen von Nachrichten: Wenn ich mehrere Geräte habe und mich mein Kontaktpartner separat eingespeichert hat (Android Smartphone, Android Tablet, iOS Smartphone, iOS Tablet), woher soll er dann wissen, an welchem Gerät ich am ehesten erreichbar bin? Benötigt wird ein "echtes" Multi-Device Feature analog anderer Anbieter.

  • Da die letzten Beiträge sich eher auf alternative Clients bezogen hier nochmal die Bitte endlich die Threema-ID Multidevice-fähig nutzen zu können.

    Ist echt kein Spass wenn man 6 Geräte in der Familie hat, jeder ein Smartphone und Tablet und mit zig ID's hantieren soll.... und wenn man Threema im Bekanntenkreis verteilen will geht der irre Aufwand weiter.


  • Multidevice wäre echt genial!
    Außerdem fehlt eine Windows10-App für den Laptop ;)


    Kann ich beides nur Unterschreiben.
    Gerade für Geschäftskunden im Bereich Threema-Work wäre das höchst produktiv. PC im Büro, Handy, Notebook... alle unter einer ID erreichbar. Genial.

    Aus genau diesen Gründen nutze ich für manche Kontakte mittlerweile Wire (https://wire.com/?hl=de). Ist für alle Plattformen nutzbar und hat seltsamerweise seinen Sitz in der Schweiz...


  • Aus genau diesen Gründen nutze ich für manche Kontakte mittlerweile Wire (https://wire.com/?hl=de). Ist für alle Plattformen nutzbar und hat seltsamerweise seinen Sitz in der Schweiz...

    Dafür speichert Wire aber auch alle Chats in der Cloud (verschlüsselt oder unverschlüsselt sei jetzt mal dahingestellt).
    Die meisten Leute hier (mich eingeschlossen) möchten das aber nicht.

  • Hallo zusammen, ich bin neu hier, warte aber schon ziemlich lange auf MD-Support und hab mich deshalb jetzt doch mal angemeldet. Dass sich das ganze so lange hinzieht ist wirklich schade.
    Ja, Krypto ist nicht einfach, aber MultiDevice sollte man eigentlich relativ unproblematisch und ohne Sicherheitsprobleme lösen können, allerdings muss man dafür (erstmal) etwas Abzüge bei der Usability hinnehmen. Will man das nicht halte ich es für unlösbar, will man die Sicherheit nicht gefährden. (genau deshalb wird es wahrscheinlich auch so lange dauern bisher...).


    Mein Ansatz wäre da gleiche ID auf zwei Devices (Wie die dahin kommt ist erstmal Sache des Users, s.u. Ich würde MultiDevice einfach erstmal als "Advanced Feature - Nur für erfahrene Anwender" deklarieren.), neue Nachrichten dann "einfach" serverseitig an beide Geräte senden.
    Das sollte erstmal nur eine serverseitige Änderung sein, die Clients muss man wahrscheinlich nur wenig anpassen (Anmelde-/Subscribe-Token) und die Verschlüsselung bleibt komplett unangetastet.
    Man muss dafür wahrscheinlich die Übertragungslogik am Server und evtl. die Anmelde-Logik ändern, aber die sind ja nicht kritisch für die Verschlüsselung.

    Bestehende Nachrichten (und Nachrichten, die ankamen während das Gerät offline war) ist natürlich schwieriger und aufwändiger aber egtl. auch nicht das Riesen-Problem. Da wäre mein Ansatz, dass der Server weiß, wie viele Geräte an der ID hängen (Subscribe-Token) und die Nachrichten wie bisher puffert, einzige Änderung, er puffert bis alle Devices, nicht nur eins, sie bekommen haben. Dazu ein Threshold, dass Nachrichten z.B. max. 14 tage lang gepuffert werden und Geräte die sich länger nicht angemeldet haben werden automatisch ausgeschlossen und müssen neu angemeldet werden.

    Mein Vorgehen zum Anmelden eines zweiten Device wäre jetzt:
    - Erstes Device offline nehmen (Flugmodus/Threema Internet-Berechtigung entziehen)
    - ID-Backup des ersten Device erstellen
    - Daten-Backup des ersten Device erstellen
    - Backups auf zweitem Device wiederherstellen, zweites Device anmelden
    - Erstes Device wieder online nehmen

    Den Anmeldevorgang würde ich die User jetzt auch erstmal manuell durchführen lassen, später kann man das ja automatisieren (z.B. mit 'ner Art vier-wege-handshake, ähnlich wie TCP das macht, doppelte Nutzerinteraktion zur Überprüfung des Partnergeräts).

    Sicherheitsmäßig sehe ich da jetzt nicht die Bedenken. Ändert sich ja nichts, außer etwas längere Pufferzeit, wenn ein Gerät sich länger nicht anmeldet. Aber die Verschlüsselung hält ja und Nachrichten müssen ja auch jetzt schon bis zur Zustellung gepuffert werden.


    Zusammengefasst bräuchte man im ersten Schritt "nur" eine Änderung der Übertragungslogik (und wahrscheinlich des Anmeldevorgangs der Clients), dass sie mit mehreren Clients unter der selben ID klar kommt. Und das halte ich für lösbar.
    Den Rest kann ja erstmal der User übernehmen, vernünftige Usability kann man später hinzufügen...


    Ja, das ist etwas Aufwand, aber weit entfernt von prinzipbedingt nicht realisierbar. Oder mache ich jetzt grade 'nen fundamentalen Denkfehler? /discuss

    Einmal editiert, zuletzt von la_fayette (25. Juli 2016 um 12:47)

  • Ich denke, dass es zwei Dinge in einem solchen System gibt, die das Team von Threema nicht gerne möchte.

    1. Sie möchten, denke ich, nicht speichern wie viele Geräte man benutzt. Zudem müsste jedes der Geräte eine eigene (Zusatz-)ID erhalten, da sich die Geräte die Nachricht sonst mehrmals abholen.

    2. Durch die mehr Geräte verlängert sich die Speicherzeit, wie gesagt. Das ist zu einem ein großerer Serveraufwand für sie und sie müssen wahrscheinlich oft die Nachrichten bis zu 2 Wochen speichern was sie auch nicht möchten.

    Das von dir beschriebene System bildet ja im Prinzip zwischen jeden Kontakten eine Art Gruppe in der alle Geräte drin sind.
    So funktioniert es bei Wire. Dort kann man alle Geräte des Gegenüber sehen und auch die Nachrichten werden lange gespeichert.

    Ich persönlich möchte lieber ein System, in dem ein Hauptdevice die Nachrichten an Subdevices weitergibt. Das wird dann vermutlich mit unteranderem SaltyRTC realisiert.

  • Ich denke auch das eine Realisierung mittels Sub-IDs gesammelt in einer "ID-Gruppe" der einfachste weg wäre.

    Sollte ein solches feature tatsächlich mehr Kosten verursachen - oder mehr Finanzen benötigen, wäre ich auch bereit es extra zu bezahlen. Ob über in App Kauf oder Add On wäre dann egal.

    Ohne zu weit OT zu gehen - denke ich wenn es an der Finanzierung hapert soll Threema entweder Spenden zulassen oder Crowdfunding durchführen.

    Gruß TheDeckie


  • 1. Sie möchten, denke ich, nicht speichern wie viele Geräte man benutzt. Zudem müsste jedes der Geräte eine eigene (Zusatz-)ID erhalten, da sich die Geräte die Nachricht sonst mehrmals abholen.

    Die Entscheidung überlasen sie aber ja mir als Anwender, ich kann ja weiter eine ID pro Device nutzen. Wenn ich es nutze ist diese Information technisch notwendig. Der Unterschied ist aber ja, dass diese Information bei Threema bleibt und eben nicht an deine Gesprächspartner geht.
    Die Zusatz-ID ist meiner Vorstellung nach aber kein Keypair sondern einfach eine zufällige Kennung, die die Subscription identifiziert. Wenn du das Gerät abmeldest und wieder anmeldest bekommst du eine neue.


    2. Durch die mehr Geräte verlängert sich die Speicherzeit, wie gesagt. Das ist zu einem ein großerer Serveraufwand für sie und sie müssen wahrscheinlich oft die Nachrichten bis zu 2 Wochen speichern was sie auch nicht möchten.

    Aber Speicherplatz kostet heute quasi nix mehr. Außerdem sind die meisten Geräte heute doch sowieso mehr oder minder 24/7 online und komplett ungenutzte fliegen ja automatisch raus. Der Punkt ist natürlich valide, aber für ausschlaggebend halte ich ihn nicht. So hoch werden die Mehrkosten nicht sein, und wenn doch muss man für MD halt 'nen € im Monat zahlen, hätte ich jetzt auch nicht die Schmerzen mit. Wobei sich das wahrscheinlich auch schon durch Mehrkäufe locker deckt...


    Das von dir beschriebene System bildet ja im Prinzip zwischen jeden Kontakten eine Art Gruppe in der alle Geräte drin sind. So funktioniert es bei Wire. Dort kann man alle Geräte des Gegenüber sehen und auch die Nachrichten werden lange gespeichert. Ich persönlich möchte lieber ein System, in dem ein Hauptdevice die Nachrichten an Subdevices weitergibt. Das wird dann vermutlich mit unteranderem SaltyRTC realisiert.

    Nein, genau das verhindert das ja, du siehst keine Gräte deines Gegenübers. Alles wie bisher, sobald er die Nachricht auf einem Gerät gesehen hat gilt sie als gelesen. Als Gesprächspartner merkst du keinen Unterschied. Das Prinzip ist ein anderes als bei Gruppen. Bei Gruppen kommunizieren mehrere Geräte pro Partner, bei meinem Vorschlag läuft die Kommunikation zwischen zwei ID's, die Gräte dahinter sind transparent für den Gesprächspartner und syncen unabhängig von der Gruppe.

    Ein lokales Sync-System hat den Nachteil, dass es nicht mehr funktioniert, wenn das Hauptdevice kein Netz, Strom o.ä. hat. Außerdem entsteht auf diesem Device massiv upstream, denke nur an Videos und mehrere Client-Devices. Grade im Mobilfunknetz ziemlich unschön. Daher tendiere ich zu einer Server-Lösung. Was spricht für dich gegen der Server? Die Daten hat er ja ohnehin und die Verschlüsselung bleibt die gleiche.


    Ich denke auch das eine Realisierung mittels Sub-IDs gesammelt in einer "ID-Gruppe" der einfachste weg wäre.

    Das bedeutet aber entweder hast du keine echte End-to-end Verschlüsselung mehr oder der Sender muss alle Nachrichten mehrfach verschicken. Das bedeutet Probleme mit Datenvolumen, Performance, Zuverlässigkeit, usw. Außerdem ist dann grade nicht vermeidbar, dass dein gegenüber sieht, wie viele Geräte du hast und welche davon grade online sind, etc. Daraus lässt sich u.U. z.B. ablesen, ob du grade Zuhause, auf der Arbeit oder unterwegs bist.

    Einmal editiert, zuletzt von Chris (15. September 2016 um 13:06)

  • Das Argument mit serverseitigen Problemen geht meiner Meinung nach in eine ganz falsche Richtung.

    Warum muss überhaupt ein Server Ende-zu-Ende verschlüsselte Nachrichten speichern? Vor allem kostet das Perfect Forward Secrecy! Spart das Akku (weil man Push-Notification-Frameworks nutzen kann)?

    Man würde doch erwarten, dass die Geräte häufig (jede Stunde?) einen (über den ID-key abgesicherten) Schlüsselaustausch machen und man PFS und deniability dafür kriegt.

    Bei mehreren Geräten mit gleicher ID und demzufolge gleichem Schlüsselpaar würden die sich einfach die fehlenden Nachrichten gegenseitig schicken. Da muss ein Server überhaupt nichts machen, ausser frames relayen (wo z.b. die Schlüsselaustauschdaten und später die verschlüsselten Nutzdaten drin stehen). Bei Gruppen reicht es, wenn einer online ist, der kann dann allen Mitgliedern die jeweils fehlenden Nachrichten schicken. Wenn man akzeptiert, dass man eh einen zentralen Server (nämlich den Threemaserver in der Schweiz) hat (was ja schon eine große Schwäche des Schutzes ist, dezentral wäre stärker), sollte es auch keine Probleme mit "Netsplits" geben.

    Dann bräuchte man übrigens auch keine gesicherte Verbindung zum Server. Dass man den Server bei Threema braucht, zeigt ja, dass es eben nicht strikt Ende-zu-Ende sonder "ein-bisschen-Ende-zu-Ende-aber-doch-noch-mit-zentralem-Server-in-der-Mitte" ist. Vermutlich braucht man den Server technisch nur, weil Smartphones nicht direkt kommunizieren können (wozu man eigentlich auch nur gratulieren kann). Wenn man ein starkes End-to-End Protokoll hätte, wäre definitionsgemäß der Server (und alles andere dazwischen) egal. Damit könnte man dann statt Threema-Server auch ein beliebiges Datenrelay nehmen, solange alle Partner darauf zugreifen können. Damit könnte man sich einen gemeinsamen DropBox / Drive / IMAP Account / WebDav als Datenaustausch vorstellen (muss ja nichtmal sicher sein!) und sogar mischen. Allerdings wird man dann wohl pro Nachricht eine Sekunde oder zwei warten müssen, selbst wenn beide online sind (weil man nicht nur ein Nachrichtendatenpaket über den Server weiterleiten kann, sondern in jede Richtung mehrere).

    (daher ärgert mich immer ein bisschen, wenn diese Server-basierten Messagener "End2End" heißen, denn wie soll man denn eine App nennen, die irgendwann vielleicht wirklich mal End2End unterstützt?)

    Einmal editiert, zuletzt von einbyte (15. September 2016 um 01:07)

  • einbyte: Ich kann dir das Crypto-Whitepaper (https://threema.ch/press-files/cryptography_whitepaper.pdf) empfehlen.

    Die Transportverschlüsselung wäre strikt gesehen nicht nötig, da die Nachrichten alle Ende-zu-Ende verschlüsselt sind. Der Server *ist* ein einfacher Relay. Normale Nachrichten werden sofort nach der Zustellung gelöscht. Die Transportverschlüsselung der TCP-Pakete gibt der Verbindung aber zusätzlich noch PFS, für den Fall dass der Netzwerkstrom aufgezeichnet würde.

    Gruppennachrichten können aber nicht einfach nach Zustellung gelöscht werden, weil der Server die Gruppenzusammensetzung nicht kennt und somit auch nicht weiss, ob alle Gruppenteilnehmer die Nachricht erhalten haben. Darum werden die Nachrichten in dem Fall einfach 2 Wochen aufbewahrt, in denen sie jedes Gruppenmitglied abholen kann.

    Wichtig ist noch, zu verstehen, dass Threema kein P2P-System ist. Das wäre heutzutage mit den ganzen Home-NAT, CGNAT, IPv4/IPv6 Geschichten usw viel zu Fehleranfällig und vor allem Resourcenintensiv. Deshalb braucht es den Server als (unvertrauten) Relay für die verschlüsselten Nachrichten, sowie zum Auslösen von Push-Notifications.


  • ..(daher ärgert mich immer ein bisschen, wenn diese Server-basierten Messagener "End2End" heißen, denn wie soll man denn eine App nennen, die irgendwann vielleicht wirklich mal End2End unterstützt?)

    Deswegen bezieht sich das "End2End" ja auch auf die Verschlüsselung und nicht auf die Verbindung.


    Zitat

    ...Alle Nachrichten, auch Gruppenchats, Medien, Dateien sowie Statusmeldungen sind bei Threema Ende-zu-Ende verschlüsselt....

    Siehe: https://threema.ch/de