Beiträge von CFP

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

    Ich muss mich korrigieren, denn es liegt nicht an der Threema-App. Auch andere apks lassen sich nicht ohne Deinstallation installieren (es sei denn, sie werden via F-Droid heruntergeladen und installiert).


    Liegt wohl irgendwo am Betriebssystem.


    Vermutlich hast du eine Dimmer-App installiert.


    Auf den ersten Blick scheint keine App solche Funktionalität zu haben.

    Bei mir lässt sich Threema 3.21 nicht installieren. "Beim Parsen des Paketes ist ein Fehler aufgetreten" erscheint, sobald ich es über die app-interne Updatefunktion updaten will; wenn ich das apk aus dem Shop herunterlade, kann ich mir die Informationen anzeigen lassen, aber "Installieren" ist ausgegraut und kann nicht angeklickt werden.


    Hat jemand ähnliche Probleme?

    Nutze Linphone, funktionierte bisher tadellos.


    Die Nachrichten, die man schicken kann, sind glaube(!) ich nicht verschlüsselt, bei Telefonaten und Video-Anrufen kann man Ende-zu-Ende-Verschlüsselung (ZRTP) aktivieren. Klappt wunderbar. :)

    Bezüglich Tor ein kurzer Einwurf: Ich weiß ja nicht, wie das mit SaltyRTC aussieht, aber WebRTC leakt deine lokale(!) IP-Adresse. Deswegen wurde auch der WebRTC-Kram aus dem Tor-Browser entfernt (bzw. nicht aufgenommen).


    Gute Idee, nur eine Frage: Wie soll denn in dem Beispiel wirkungsvoll überprüft werden, ob der Nutzer der Aufforderung tatsächlich nachgekommen ist, die alte ID zu löschen/deaktivieren?



    Ich meine über diese Seite: https://myid.threema.ch/revoke



    schon haben wir eine Verbindung zwischen zumindest der alten ID und dem Lizenzschlüssel.


    Übertragung != Speicherung.
    Sofern Threema sicherstellt, dass die Daten nicht gemeinsam gespeichert werden, sehe ich das als wenig problematisch an.
    Szenario:
    1) User: Id-Widerruf → Absenden.
    2) Threema (intern): Id entfernen. Success.
    3) Threema: user, bitte sag uns einen Lizenzschlüssel, den wir für dich freischalten sollen.
    4) User: xyz-xyz
    5) Threema: Freigeschaltet.


    Aber immer bedenken: Wir reden hier schon über den Sonderfall im Sonderfall. Die absolute Masse benutzt den Playstore und da stellt sich diese Frage nicht. Und bei denen, die es im Shop gekauft haben, müssen auch mehrere Nebenbedingungen eintreten, damit wir überhaupt bei dem Fall landen. Am Ende dürfte man die Fallzahl, die wirklich davon betroffen sind, sogar händisch abarbeiten können ;)



    Bitcoin ist alles andere als anonym, siehe Blockchain. Um eine Zuordnung zwischen Bitcoin-Adresse und Nutzer sicher auszuschließen sein ein erheblicher Aufwand und Kenntnisstand vonnöten.


    Bitcoin ist deutlich privatsphäreschonender als die übrigen Zahlungsmethoden. Nichtsdestotrotz kann man mit hinreichend großem Aufwand auch bei BTC in manchen Fällen deanonymisieren – das ist dann aber wirklich ein Aufwand, der enorm ist und sich auch auf Einzelfälle beschränken dürfte. Auch hier gäbe es für Bitcoin-User aber Lösungen, die allerdings komplexer sind. Ein anonymeres Zahlungsmittel als Bitcoin, das auch einen gewissen Verbreitungsgrad hat, dürftest du aber kaum finden.



    Spam tritt immer dann in Massen auf, wenn der Missbrauch einfach ist. Und das ist in der derzeitigen Situation - Closed-Source Client, nur mobil, und eher geringe Nutzerbasis - eher nicht gegeben, so dass der Nutzen in keiner Relation zum Aufwand steht. Oder wie soll es "ein Kinderspiel sein", den Android/iOS/WP-Client dazu zweckzuentfremden?


    Ob OpenSource oder ClosedSource macht hierfür (zumindest für Android, bei iOS kenne ich mich nicht genügend aus) keinen Unterschied. Ich könnte auch die App als Spamschleuder missbrauchen, von einem technischen Standpunkt aus wäre das möglich (wie gesagt: Wer unbedingt Quatsch machen will, schafft das). Das einzige, was das abschwächen könnte, wäre wenn in der App ein Spamschutz eingebaut wäre (indem z.B. die Nachrichten pro Zeiteinheit gemessen werden und ab einem bestimmten Schwellwert gewisse Zeitverzögerungen eingebaut würden), aber auch das ließe sich – dann mit erheblich mehr Aufwand – umgehen. Absoluten Schutz wird es nie geben, aber ich würde sagen, dass sich das Spamrisiko bei einer Quellcodeoffenlegung signifikant erhöht (zumal ohnehin seit Jahren genügend bekannt ist, um sich einen eigenen Client zu basteln). Das „Kinderspiel“ ist vielleicht etwas salopp gesagt gewesen – 99,999% der Nutzen kriegen das natürlich nicht hin. Aber wer das technische Knowhow hat, der würde es schaffen.

    Wo ist denn bitte das Problem bei Fremdclients? Soll doch jeder seinen eigenen Client schreiben, wenn er will?!


    Es ist völlig egal, ob ich jetzt die Nachricht via (offizieller) Threema-App oder via Drittclient schreibe – es entsteht derselbe Traffic.
    Viele kritisieren doch, dass Threema wenige Nutzer hat, wenn durch Drittclients mehr Leute Threema nutzen, wäre das doch auch gut?


    Und genau dann wäre es ja umso sinnvoller, eine einmalige Nutzungspauschale zu verlangen, anstatt das (Bezahlung/Id-Erstellung) entkoppelt zu lassen.


    Und für die Zweit-Ids: Wenn es legitime Gründe gäbe, ließen sich auch hierfür Wege finden. Beispielvorschlag: Man kann Ids widerrufen – wer also glaubt, er müsse seine Id wechseln, dessen Lizenzcode kann man ja wieder freischalten sobald die andere Id entfernt wird [aka: "Ich will meine Id wechseln." – "Sag mir deinen Lizenzcode." – "xyz-xyz" – "Bitte deaktiviere die Id" – *id-deaktivieren/löschen* – "okay, Lizenzcode ist wieder für Id-Generierung freigeschaltet (das ist ein simpler Boolean von False auf True)." // Nur, um jetzt mal ein Beispielszenario zu entwickeln. Prinzipiell könnte man das schlicht über ein weiteres Feld auf der Seite "Id-Widerruf" einrichten.] Faktisch wäre der Aufwand gleich Null und man hätte dieses Problem schon gelöst.


    Bezüglich Privatsphäre: Solange Threema keine Verknüpfung von konkretem Lizenzschlüssel und konkreter Id bei der Speicherung vornimmt, ist alles okay. (Sprich für jeden Lizenzschlüssel wird nur abgespeichert, ob(!) damit schon eine Id erzeugt wurde oder nicht – aber keinesfalls, welche Id das ist.)


    Bezüglich Bezahlung: Bitcoin :-)


    Bezüglich Spam: Es wäre ein Kinderspiel, auch bei der offiziellen Threema-App eine Spam-Schleuder einzurichten. ;) Wer Quatsch machen will, schafft das immer.


    aber was genau für ein Problem wird durch die Regel "1 Lizenzschlüssel = 1 ID" gelöst


    Die Befürchtung, durch Offenlegung des Codes würde keiner mehr einen Lizenzschlüssel kaufen, sondern sich einfach so Ids generieren lassen.
    (Die Befürchtung an sich ist ja schon nicht konsistent, da auch so schon – eben durch die fehlende Bindung von Lizenz/Id – jeder sich "kostenlos" ne Id generieren lassen könnte). Aber mit einer solchen Regelung könnte man das Bezahlmodell auf ein halbwegs ordentliches Fundaments stellen, das auch bei Quellcodeoffenlegung Einnahmen weiterhin (einigermaßen) gesichert sind (eben eine einmalige Nutzungspauschale in Form eines Lizenzschlüsselkaufs).

    Wunderbar, dann habe ich das richtig angenommen. Somit könnte bei PlayStore-Kunden (und das ist die große Masse) alles beim alten bleiben und nur bei den Shop-Käufen (denn nur da gibt es Lizenzschlüssel) die Regel "1 Lizenzschlüssel == 1 Id" eingeführt werden.


    Und ich wage zu behaupten: 99 %, die eine apk aus dem Shop runterladen und installieren, sind auch in der Lage, ein Backup zu erstellen. ;)

    Das weiß ich schon, aber ich vermute, dass es derzeit (und damit auch bei einem alternativen Zahlungsmodell) Unterschiede bei der Registrierung gibt.


    Wenn man Threema im Playstore kauft, bekommt man keinen Lizenzschlüssel zugeschickt, oder?


    Ein zweites Mal bezahlt wohl kaum jemand für Threema. Man wendet sich halt dann ab und dropt vorher noch eine miese Bewertung im Store.


    Das Problem betrifft die PlayStore-Kunden eigentlich nicht. Denn da wird ja via Playstore abgerechnet, also sollte es keinen Lizenzschlüssel im klassischen Sinne geben. "Bezahlt via Playstore-Id xy" und dann wird die Id erstellt.



    Lizenzschlüssel ist für die, die im Shop kaufen (oder dann die App selbst bauen würden) und ich würde wagen zu behaupten, dass von denen die wenigsten unfähig sind, ein Backup anzulegen ;)


    Verzeih bitte, aber das ist so nicht korrekt. Ich kann auch mit Einer Lizenz mehrere IDs (im Prinzip x-beliebige IDs) erstellen.


    Pardon, da war ich etwas unsauber in der Formulierung.
    Du hast diesbezüglich natürlich recht – und das ist eben ein weiterer Grund, warum nichts gegen OpenSource spricht. Denn theoretisch könnte ich auch jetzt beliebig viele „kostenlose“ IDs erzeugen.
    Threema benötigt diesbezüglich die Umgestaltung "pro Lizenzcode == 1 Id erzeugen", sprich wer eine Id erzeugt und (automatisch) auf die Server hochläd, muss einen Lizenzschlüssel (automatisch) mitschicken und nur wenn bisher damit noch keine Id erzeugt wurde, wirds zugelassen.


    Das Argument "dann kauft keiner mehr" zieht nicht, wenn man sich vor Augen führt, dass schon jetzt ein simples „Angriffsszenario“ gegen die Bezahlung exisitert. Vielmehr muss Threema den eigentlichen Fehler beheben – mit OpenSource hat das ganze aber nichts zu tun.

    Ins blaue geschossen: Passiert möglicherweise dann, sofern du im Kontaktbuch „Ich“ erstellt hast (mit deiner Nummer) und bei Threema ebenfalls deine Telefonnummer angegeben hast und Threema dann das Kontaktbuch synchronisiert.


    Kann jemand einmal eine kurze Zusammfassung darüber schreiben
    Da ich leider momentan nicht das Internet habe über 400 MB Videos herunter zu laden :)


    Du kannst dir hier die Folien ansehen: https://fahrplan.events.ccc.de…3/121/original/slides.pdf



    Für mich stellt sich allerdings die Frage, wer dann in Zukunft die Serverkosten trägt, wenn keine mehr Geld für die APP entrichten muss?



    Das ist schon immer ein Irrglaube und ein Kardinalfehler von Threema. Open Source bedeutet nicht, dass ich kein Geld mehr für die Appnutzung bezahlen muss. Open Source bedeutet Quelloffenheit und die schadet in keinster Weise – ganz im Gegenteil, sie wäre dringend notwendig (und ist eigentlich eine unverhandelbare Voraussetzung für ein sicheres Produkt!). Threema kann weiterhin Geld für die Ids verlangen, denn man bezahlt doch nicht für die App. Man bezahlt für die Nutzung. Jeder kann sich die App selbst bauen – aber noch nicht nutzen, solange man keine Id hat. Und die Id-Erstellung geht nur mit Lizenzcode. Insofern waren und sind das schon immer zwei Paar Schuhe.


    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.

    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 ;)