Beiträge von CFP

Soweit ich das sehe, lag das an diesem Commit: https://review.lineageos.org/#/c/193183/

Die Builds der letzten beiden Wochen haben das Problem, jetzt sollte es in allen Versionen wieder ganz normal gehen (bei mir kann ich das bestätigen).

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.

Zitat von Julia

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

Zitat von Miaz

@"lgrahl" : Aaaaah... Da hatte ich Dich je bisher immer falsch angesprochen! :oh: :tränenlachen:

Nie auf seine Seite geschaut oder einen Blick in seine Arbeit geworfen?

Zitat von rugk

Genau deswegen prüft man so etwas auch auf dem Server und nicht in der App - da ist das ziemlich sinnfrei, jetzt mal egal ob (FL)OSS* oder Closed Source.

* Wer "FLOSS" nicht kennt: https://de.wikipedia.org/wiki/Free/Libr…Source_Software

Richtig. "Ich kontrolliere das Gerät und darum entscheide ich, was in der App passiert".
Sowas kann man als Abschwächung nutzen, aber nicht als Schutz.

Zitat von andyg

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

Zitat von andyg

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

Zitat von andyg

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.

Zitat von andyg

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.

Zitat von andyg

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?

Zitat von Kenny_Butters

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

Zitat von Mogli

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.

Zitat von Balder

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/congress/2016/…inal/slides.pdf

Zitat von patrick

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.

Zitat von lgrahl

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

Zitat von lgrahl

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.

Zitat von lgrahl

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.

Zitat von lgrahl

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

Zitat von lgrahl

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

Zitat von lgrahl

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

Zitat von lgrahl

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.

Das ganze ist leider nur ein Pseudo-"Multi"-Device. Ohne dass das Handy permanent online ist, funktioniert nichts. Echtes Multi-Device wäre wichtig gewesen, stattdessen gibt es nur eine Web-Version, mit der man (technisch gesehen) via Handy am PC lesen und schreiben kann. Sehr schade.

Die Kritik hatte ich vorhin formuliert, passt aber ggf. besser in diesen Thread: https://threema-forum.de/thread-1340-po…3.html#pid27793