THREEMA WEB CLIENT PROTOTYPE mittels SaltyRTC

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.600 Mitglieder helfen dir weiter. > Frage stellen <
  • Erst einmal Danke für das Engagement.

    Ich möchte allerdings ein paar Kritikpunkte nennen, die mir auffallen. Wenn ich das richtig verstanden habe, wurde letztlich nur ein Workaround für etwas, das (bezüglich dieses Usecases) „broken by design“ ist, entwickelt – das ursprüngliche Problem wird dabei allerdings nicht beseitigt, sondern eher verfestigt.

    Denn es passiert ja bei der Umsetzung dieses Features Folgendes: Es gibt dann zwei verschiedene Funktionen innerhalb der App. Die eine Funktion ist die eigentliche Funktion, die es bisher ausschließlich innehat, nämlich die Kommunikation mit dem Threema-Server und der Austausch von Nachrichten. Dieser Austausch ist designmäßig nur mit einer einzigen Appinstanz pro ID möglich – das bleibt auch in Zukunft so. Was neu hinzukommt, ist die zweite Funktion, nämlich eine Serverfunktionalität (SaltyRTC), mit dem sich alle Clients (z.B. Webapp) syncen können. Das ist klassischerweise eine Kompositionsbeziehung, denn die App/Serverinstanz kann ("wie bisher") alleine verwendet werden, eine Clientinstanz (z.B. Webapp) ist ohne App, die als Server fungiert, nicht überlebensfähig. Und das heißt: Threema bleibt weiterhin (und dann wohl für immer) ausschließlich geeignet für single-device, es gibt keinen echten Multi-Device-Support, sondern nur pseudo-"Multi"-Device-Support. [An dieser Stelle noch eine Nachfrage: Beim Senden von Nachrichten muss dann ja letztlich via RTC an den Server(=App) geschickt werden und von dort an den Threema-Server – das erzeugt doch dreifachen Traffic (2x up, 1x down)? Ich schicks erst "an mich selbst" und dann "raus" an Threema für den Empfänger.]

    Denn ohne dieses Single-Device, das permanent online sein muss, funktioniert nicht. Und das ist eigentlich ein elementares Kriterium. Ich will unabhängig vom Handy (denn das ist 98% offline) am PC schreiben können (und auch vice versa, denn wenn das Handy online ist, ist zu 99,999% der PC offline). Bei Signal funktioniert das zum Beispiel, dort werden Websockets benutzt. Sollte ich etwas an der Funktionsweise missverstanden haben, wäre es nett, wenn die Stelle meiner fehlerhaften Interpretation aufgezeigt würde, aber ich denke schon, dass ich das nach Durchsicht von Thesis und Code richtig verstanden habe.

    Und nach der Generalkritik bringe ich einen Lösungsvorschlag, das Posting soll ja auch konstruktiv sein. Ohne näher drin zu sein, könnte ich mir einen Multi-Device-Support wie folgt feststellen:

    • Gleichberechtigte Endgeräte, initial – selbstverständlich offline – synchronisiert per Backup-Funktion (Import private key)
    • Serverseitig wird statt einer einzelnen Verbindung pro ID, eine Liste von Verbindungen pro ID verwaltet
    • Clientseitig kann eine Policy festgelegt werden – Server schickt an den/die Geräte, die den Einstellungen folgend bedient werden müssen (z.B. einige Vorschläge – 0: Nachrichten immer an beide Geräte schicken (puffern bis von allen abgerufen, ggf. mit Timeout (z.B. länger als 3 Tage wird es nicht aufm Server gepuffert, wenn mit mind. 1 Gerät schon abgerufen)), 1: An Gerät schicken, das sich zuletzt gemeldet hat (bei Start der Verbindungsaufbau bzw. App-Öffnung Syn/ack mit dem Server), 2: Prioritätsliste der Geräte; usw. da gäbe es einige Möglichkeiten)


    Im Übrigen wäre – um den Kreis zu schließen – sowas letztlich auch ähnlich mit der Idee des SaltyRTC. Eigentlich müsste es nur auf anderer Abstraktionsebene laufen. Statt den Server zwingend an eine App-Instanz zu binden, müsste sie abstrahiert von allen Clients sein (wenn man will dann Id-gebunden, aber eben nicht Instanz gebunden – aber auch das wäre nicht nötig). Und dann könnte man sie letztlich in den Threema-Server zur Nachrichtenverteilung integrieren. Wohlgemerkt hat der Server dann natürlich nicht die alten Daten gespeichert, aber die Clients könnten hier untereinander (via diesen Server) kommunizieren und ggf. austauschen (was ja auch SaltyRTC machen will) – nur eben, dass Server und feste Appinstanz getrennt sind. Da alle Appinstanzen dann nur Clients wären, könnten sie beliebig offline sein und alles würde trotzdem gehen. Hier war schon das Gespräch von einem Raspi, der als Server fungiert, eigentlich könnte man das gleich bei der Serverseite von Threema integrieren. Dann ginge es auch ;)

    Einmal editiert, zuletzt von Chris (15. Dezember 2016 um 12:25)

  • Vorweg: Wenn du deine Kritik dem Threema-Team mitgeben willst, bin ich die falsche Adresse, denn ich habe dort nur meine Bachelorarbeit geschrieben und seitdem nicht mehr am Web-Client direkt mitgearbeitet. Also kann ich nur wiedergeben, was ich so nebenbei mitbekomme, bzw. was meine Idee war.

    Es ist kein klassisches Multi-Device und das will es auch nicht sein, daher auch kein Workaround für "broken by design". Die Idee war, den Server so schlank zu lassen, wie er ist. Das kommt auch deinen Daten zugute, denn sie werden nur einmal über den Server ausgetauscht und nicht n-mal.

    Ja, die Daten fallen im schlimmsten Fall 2x an, aber dafür liegen die Daten nicht an n Orten sondern an einem einzigen, von dir kontrollierbaren Ort, z.B. auf deinem Smartphone. Diesen Aspekt halte ich für stark unterschätzt. Darüber hinaus fallen die Daten eben als Kostenfaktor nur selten 2x an, denn in vielen Fällen sind PC und dein Smartphone im gleichen lokalen Netzwerk und dann kostet es dich monetär nichts.

    Kurze Frage: Warum ist dein Handy offline, wenn du am PC arbeitest? Ich habe damals eine Idee bei Threema eingeworfen, alternativ eine Headless-App auf einem Raspberry Pi oder auf dem heimischen NAS zu betreiben - nennen wir es Threema Node. Die Daten bleiben bei dir und alle Geräte würden über den Node kommunizieren. Klar, gibt es noch nicht und ob das umgesetzt wird, kann dir auch niemand sagen. Letztendlich kommt das deiner Idee aber sehr nahe, ohne die Server-Komplexität, die klassisches Multi-Device mit sich bringt, ohne dem Problem, dass deine Daten plötzlich überall verteilt oder auf Servern, wenn auch nur kurzzeitig, herumliegen und ohne dass dabei seitens Threema ~1 Jahr Arbeitszeit für die Katz war. Und wenn du Lust hast, kannst du dir als Workaround ja schon mal einen Android-Emulator mit Threema aufsetzen. Nur das Scannen des QR-Codes wird spannend. :)

    Ich behaupte nicht, dass es bei dir auch so ist, aber für viele, so glaube ich, existiert das Problem letztendlich nur im Kopf. Was spielt es für eine Rolle, dass es technisch gesehen kein klassisches Multi-Device ist? Für mich überwiegen die Vorteile.

    (Um Verwirrung zu vermeiden: Ich arbeite bei Threema, spreche hier aber für mich.)


  • Vorweg: Wenn du deine Kritik dem Threema-Team mitgeben willst, bin ich die falsche Adresse, denn ich habe dort nur meine Bachelorarbeit geschrieben und seitdem nicht mehr am Web-Client direkt mitgearbeitet. Also kann ich nur wiedergeben, was ich so nebenbei mitbekomme, bzw. was meine Idee war.

    Das weiß ich, die Kritik ist auch weitestgehend an Threema gerichtet und nicht an dich ;) Ich bin durch den gestrigen Blogpost auf diesen Thread aufmerksam geworden und habe dann einfach die komplette Kritik zusammengefasst (wobei ich natürlich weiß, dass SaltyRTC und Threema erst einmal nichts miteinander zu tun haben, da du ein Webprotokoll aufgesetzt hast und entsprechende Server-/Clientstrukturen implementiert. Und dieses Protokolls bedient sich dann Threema. Und so wie ich das gestern gesehen habe, hast du sehr sauber gearbeitet :daumen: Meine Kritik ist vielmehr die Frage, ob SaltyRTC in dieser Form die Lösung für Threema ist – was ich bezweifelt habe, da es in erster Ausführung einen netten Workaround bietet, aber am Single-Device-Konzept von Threema selbst nichts ändert. Wenn man das aber weiterentwickelt, kann es zu einer Lösung werden.)


    Es ist kein klassisches Multi-Device und das will es auch nicht sein, daher auch kein Workaround für "broken by design". Die Idee war, den Server so schlank zu lassen, wie er ist. Das kommt auch deinen Daten zugute, denn sie werden nur einmal über den Server ausgetauscht und nicht n-mal.


    "das will es auch nicht sein" – richtig, das sieht man am Design. Viele Nutzer – inkl. mir – würden sich aber freuen, wenn man diese Instanzunabhängigkeit schaffen würde und somit echtes Multi-Device bieten könnte (wie das z.B. Signal hat).

    Bzgl n-mal austauschen: Grundsätzlich schafft man ja einen für jede Id einen eigenen ("zweiten") Server, der die Nachrichten verwaltet, in der Threema-Konstruktion ist das dann die Appinstanz auf dem Handy. Wo dieser zweite Server dann hinverlagert wird, ist eben genau die Frage (Option 1: Zwingend Handy-App, Option 2: Beliebiges Servergerät (aka raspi), Option 3: Gehostet auf den Threema-Servern). Die Argumentation mit dem n-mal austauschen bezieht sich ja aber nur auf den Threema-Nachrichten-Server, der individuelle "eigene" Server (SaltyRTC) muss ja trotzdem n-mal austauschen – nur dass das jetzt der "eigene" Server tut und nicht der Threema-Server. Was aus Datenschutz- und Anonymitätsgründen sicherlich gut ist.


    Ja, die Daten fallen im schlimmsten Fall 2x an, aber dafür liegen die Daten nicht an n Orten sondern an einem einzigen, von dir kontrollierbaren Ort, z.B. auf deinem Smartphone. Diesen Aspekt halte ich für stark unterschätzt. Darüber hinaus fallen die Daten eben als Kostenfaktor nur selten 2x an, denn in vielen Fällen sind PC und dein Smartphone im gleichen lokalen Netzwerk und dann kostet es dich monetär nichts.


    Dabei ging es mir weniger um das monetäre als vielmehr um den Traffic. Bei einzelnen Nachrichten mag das egal sein, aber jetzt sei doch in verschiedenen Netzwerken und schick mal 10 20-MB-Videos und schon hast du statt 200 MB Traffic nun 600 MB Traffic (400 up, 200 down). Gäbe es eine direkte Verbindung vom Zweitgerät (Webapp) zum Threemaserver könnte man sich dieses doppelt/dreifache halt sparen, indem man z.B. eine Option "Videos/Dokumente nicht syncen" einführt. Das wäre dann aber wieder echtes Multi-Device. Da dreht sichs dann aber wieder im Kreis ;) War auch nur als Nachfrage gedacht, da mir das mit dem Traffic halt aufgefallen ist.


    Kurze Frage: Warum ist dein Handy offline, wenn du am PC arbeitest?


    Weil das Handy normalerweise 95 % des Tages offline ist. Schon alleine zum Akkusparen. Man kann Internet anmachen, wenn man es braucht und dann sofort wieder ausschalten.
    Und für fast alle Dienste braucht man kein Handy, das permanent online ist. Egal ob jetzt klassische Messenger wie Signal (!!) oder dann XMPP/Jabber, Telegram-Gruppen bzw. soziale Netzwerke Facebook, Google+, Diaspora* usw. Ist der Rechner an, kann das Handy aus. Schließlich geht alles am PC.

    (Kurzer Einwurf: openMittsu würde ja diesbezüglich sogar funktionieren, da ein Requirement ist, dass das jeweils andere offline ist :exfreude: )


    Ich habe damals eine Idee bei Threema eingeworfen, alternativ eine Headless-App auf einem Raspberry Pi oder auf dem heimischen NAS zu betreiben - nennen wir es Threema Node. Die Daten bleiben bei dir und alle Geräte würden über den Node kommunizieren. Klar, gibt es noch nicht und ob das umgesetzt wird, kann dir auch niemand sagen. Letztendlich kommt das deiner Idee aber sehr nahe, ohne die Server-Komplexität, die klassisches Multi-Device mit sich bringt, ohne dem Problem, dass deine Daten plötzlich überall verteilt oder auf Servern, wenn auch nur kurzzeitig, herumliegen und ohne dass dabei seitens Threema ~1 Jahr Arbeitszeit für die Katz war.

    Richtig. Self-hosted Empfangs- und Sendeserver, der sich nach außen um die Kommunikation mit Threema-Servern und intern um die Kommunikation mit allen Clientgeräten kümmert – das wäre perfekt. Dann wäre Option 2 oben möglich (statt raspi natürlich auch jeder andere selbst gehostete Server) und alles wäre gut (natürlich per Einstellungen auch Option 1 weiterhin möglich).


    Und wenn du Lust hast, kannst du dir als Workaround ja schon mal einen Android-Emulator mit Threema aufsetzen. Nur das Scannen des QR-Codes wird spannend. :)

    Da kann ich dir aus Erfahrung sagen, dass das überhaupt kein Problem ist ;)


    Ich behaupte nicht, dass es bei dir auch so ist, aber für viele, so glaube ich, existiert das Problem letztendlich nur im Kopf. Was spielt es für eine Rolle, dass es technisch gesehen kein klassisches Multi-Device ist? Für mich überwiegen die Vorteile.


    Sofern man eine Stufe weiter abstrahiert (Empfangs-/Sendeserver nicht zwingend App-Instanz) wäre das ja eine Lösung. Kein klassisches Multi-Device, aber vom Funktionsumfang her sehr, sehr nahe dran.

    Einmal editiert, zuletzt von CFP (15. Dezember 2016 um 13:44)


  • "das will es auch nicht sein" – richtig, das sieht man am Design. Viele Nutzer – inkl. mir – würden sich aber freuen, wenn man diese Instanzunabhängigkeit schaffen würde und somit echtes Multi-Device bieten könnte (wie das z.B. Signal hat).

    Hat Signal wirklich echtes Multi-Device? Kann ich auf der Chrome-App meine ganzen bisherigen Chatverläufe sehen? Werden die Daten nach der Sitzung wieder gelöscht oder bleiben Sie in Chrome gespeichert?

    Ich erwarte, dass ich sämtliche Chats auf allen Clients einsehen kann und gleichzeitig möchte nicht, dass überall Kopien von meinen Chats, Bildern, Kontaktlisten, Gruppen usw. herumliegen, schon gar nicht auf einem Server der sich irgendwo ausserhalb meiner Kontrolle befindet.

    Von dem her gesehen scheint die Lösung von Threema meine Bedürfnisse besser abzudecken als die Ansätze von Signal und Wire (von Telegram ganz zu schweigen).

    Das Handy hat sich inzwischen zur zentralen Kommunikationsdrehscheibe entwickelt, von dem her gesehen finde ich es logisch, dass meine Daten an diesem Ort zentralisiert sind und nicht irgendwo in der Cloud.

  • Zitat


    Hat Signal wirklich echtes Multi-Device? Kann ich auf der Chrome-App meine ganzen bisherigen Chatverläufe sehen? Werden die Daten nach der Sitzung wieder gelöscht oder bleiben Sie in Chrome gespeichert?


    Soweit ich weiss speichert Signal die Chatverläufe im Browser. Ich musste kein Passwort angeben, keine Ahnung womit diese Inhalte sowie die Keys verschlüsselt werden. Die Chatverläufe werden nur synchronisiert, wenn beide Geräte gleichzeitig online sind. Dabei kann es meiner Erfahrung nach aber auch geschehen, dass die Nachrichten-Reihenfolge auf den verschiedenen Geräten plötzlich nicht mehr die selbe ist.

    Einmal editiert, zuletzt von dbrgn (15. Dezember 2016 um 15:13)

  • Ist zwar ein selbstgemachtes Problem, aber vielleicht kann jemand helfen.

    Habe ein Firefox Profil mit einer "gehärteten" user.js angelegt. In diesem Profil funktioniert aber Threema Web nicht mehr. Ladebalken bleibt immer bei 60% hängen.

    Die user.js ist die moderate Version vom privacy handbuch ( https://www.privacy-handbuch.de/handbuch_21u.htm)

    https://www.privacy-handbuch.de/download/moderat/user.js


    Vielleicht hatte jemand schon ähnliche Probleme mit einer eigenen user.js. Irgendwo wird dort wohl das WebRTC geblockt. Nur finde ich im Moment nicht wo dies sein könnte.


  • Hallo,

    welche Bedeutung hat das Threema Web Passwort? Auf die Web-Sitzung kann doch nur zugreifen, wer Zugriff auf den entsprechenden Browser hat, oder? Von daher müsste das Passwort ja nicht besonders sicher sein?

    [font="Roboto, sans-serif"]Um Threema Web zu verwenden, ohne jedes Mal einen QR-Code zu scannen, kann ein Sitzungspasswort festgelegt werden.[/font]

    iPhone 7Plus, iOS 14.x - Threema 4.6.4 (2602)

    Lumia 950 - WP10 (10.0.15254.597) ohne Tracing Apps

    Seit Threema 1.3 sicher


  • Hallo,

    welche Bedeutung hat das Threema Web Passwort? Auf die Web-Sitzung kann doch nur zugreifen, wer Zugriff auf den entsprechenden Browser hat, oder? Von daher müsste das Passwort ja nicht besonders sicher sein?

    Es geht darum, dass man nicht durch Auslesen des Local Storage gleich Zugriff auf dein Gerät erhält. Die Schlüssel im Local Storage (wo die Sitzung gespeichert wird) sind zusätzlich mit dem Sitzungspasswort verschlüsselt.

  • Also im Endeffeckt ja, z.B. gegen jemanden der die Daten des Browsers (von der Festplatte) auslesen kann, also Offline-Angreifer z.B. Oder eben gegen jemanden, der irgendwie Zugriff auf den Browser hat.

    Ein sicheres Passwort schadet niemals. Generiere dir einfach eines und speichere es in einem Passwortmanager – wenn du keinen anderen hast/benutzt dann geht es auch im Browser-eigenen, dann hast du zumindest eine erleichterte Bedienung und musst das Passwort nicht immer eingeben.

  • Sicher ja, wobei ich behaupten würde, es ist auch ohne dieses Master-Passwort noch besser, wenn die Alternative stattdessen gewesen wäre, "1234" als Passwort da direkt einzutragen…
    [hr]
    @"Simon G." @"Chris" Ich glaube man könnte diesen alten "Thread" auch mal wieder abpinnen… Threema Web ist ja nun schon lange kein Prototyp mehr. :)