Beiträge von lgrahl

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

    Ignorier erstmal was Threema Web da erzählt.

    Push-Token konnte nicht aktualisiert werden. Bitte versuchen Sie es später erneut.

    Das hier ist dein Hauptproblem und alle weiteren Probleme sind nur die Folge daraus. Offensichtlich gibt es ein Problem mit den auf deinem Smartphone installierten Google Play Services, welche die Push-Tokens verwalten. Was das genaue Problem mit jenen Services ist, kann ich dir nicht beantworten, aber es ist nicht wahrscheinlich, dass es etwas mit Threema selbst zu tun hat. Falls du den Support kontaktieren möchtest, mach dies am Besten über die Threema App direkt.


    Vielleicht hat hier aber noch jemand im Forum eine Idee.

    Ich will nicht ausschliessen, dass es keine Lösung gibt, aber ich wüsste nicht wie das gehen soll. Wenn nicht du das Passwort hast, dann muss es der Server haben. Und das ist naheliegendermassen inakzeptabel. Vielmehr ist es wohl ein Gewohnheitsproblem: Würde man nicht davon ausgehen, dass man den Zugang über Email oder Telefonnummer wiederherstellen kann, so wie quasi überall üblich (und absolut grenzwertig - wenn das Passwort zum Email-Account abhanden kommt, dann gute Nacht), dann wäre klar, dass man sich Passwörter gut merken (oder eine Merkhilfe verwenden) muss.

    Einen Passwortmanager verwenden, dabei nicht nur an Login-Seiten diverser Dienste denken.

    Auch Apps, welche irgendwelche PINs, IDs etc. benötigen (Threema: ID), im Passwortmanager anlegen.

    Wenn es aus meinem Beitrag nicht klar geworden ist: Du sprichst hier die falsche Person an. Mir und vermutlich einem Grossteil der Leute im Forum ist das und auch die Konsequenz bewusst, 99% der anderen User aber nicht.

    Ich halte es für vollkommen normal, dass man Passwörter vergisst, die man nicht ständig benutzt. Und Threema Safe ist genau so ein Ding. Man richtet das genau einmal ein und braucht es dann ggf. erst Jahre später. Viele Möglichkeiten hat man ja nicht:

    • Ein mehrfach genutztes Passwort nutzen (schlecht)
    • Ein einfach zu merkendes Passwort nutzen (je nach Passwort vermutlich schlecht)
    • Ein Passwort im Passwortmanager machen (muss man erstmal auf dem Smartphone haben und auch in dem Moment drauf kommen)
    • Ein Supermind sein, was sich selbst viele gute Passwörter sehr gut merken kann, die man ggf. jahrelang nicht verwendet (unrealistisch für 99%)

    Da ist das Risiko einfach extrem hoch, dass man das Passwort im Falle des Falles nicht mehr hat. Ich rechne hier mit weit über 50%.


    Lösungsvorschläge, die das UX nicht negativ beeinträchtigen sind willkommen.

    Würd mich an deiner Stelle mal an den OnePlus Support wenden und das melden. Threema wäre dir sicher dankbar dafür. Die traurige Wahrheit ist nämlich, dass für solche Dinge dann häufig der Threema Support konsultiert wird und Bugs der Hersteller Threema in die Schuhe geschoben werden. Für Threema sind das dann Mehrkosten, die nicht an die eigentlichen Verursacher (in dem Fall vermutlich OnePlus) weitergegeben werden können.

    Das ist ein Trugschluss. Die Feature Mask ist nicht dafür gedacht, Features zu aktivieren/deaktivieren, sondern die unterstützten Features der App wiederzuspiegeln. Das ist ein signifikanter konzeptioneller Unterschied. Beispiel: Wenn ich weiss, dass du Video-Calls letztes Mal konntest, dann frage ich beim nächsten Mal nicht nochmal. Das "Fragen" kostet nämlich Zeit.


    Aber mal unabhängig davon, bin ich kein Fan von eurer Idee. Wenn ich Umfragen nervig finde, dann kann ich das der Person sagen. Wenn die Person das dann nicht schnallt, ist das ein eben ein Konflikt, aber ob ich den jetzt technisch unterbinde oder nicht macht es nicht weniger zu einem Konflikt.

    Ich kann dir die Frage nicht gut beantworten - bin kein Experte in dem Gebiet und ganz besonders nicht bzgl. Quantenkryptographie.


    Was ich aber sagen kann, ist, dass Threema fast im selben Boot wie alle anderen gängigen Messenger sitzt. Wire hat 2018 mal was dazu geschrieben: https://wire.com/en/blog/post-quantum-resistance-wire/


    Mit dem Unterschied, dass Threema keinen Ratcheting-Algorithmus für Forward Secrecy auf E2E-Ebene nutzt.


    Ich würd vorschlagen, mal über den Threema Support um eine Stellungnahme zu bitten?

    Na, ich würde vermuten, dass die Nutzung von Threema in der EU dann verboten wäre. Selbst dann könnte man wohl klagen. Aber IANAL. Wie das mit OSS Software auf privaten Servern aussieht, kann ich auch nicht beantworten. Aber ich würde nicht zu sehr auf der Ebene dieses (vollkommen absurden) Gesetzesvorschlags entscheiden, weil der, wie erwähnt, vollkommen absurd ist: Kriminelle könnten problemlos den jetzigen Source Code von Signal/Threema/Matrix/Whatever nehmen, einen Walled Garden aufbauen und dann unbehelligt verschlüsselt kommunizieren, während die ehrlichen Bürger anlasslos durchleuchtet werden. Dagegen könnte kein Server der Welt etwas tun. Das ist so, als würde man Mathematik verbieten. Vollkommener Quatsch.

    Die große Sorge die jetzt aufkommt ist folgendes: die EU will das mit lesen von Nachrichten erlauben, um so Inhalte auf Kinderpornografie zu überprüfen. Im zuge dessen kommt oft, dass auch Threema und Signal gezwungen werden sollen ihre Verschlüsselung "aufzuheben". Das ist ein weiteres Argument für die, Elememt zu nutzen. Was sagt ihr dazu?

    Das würde ja genauso für Element gelten, insofern verstehe ich die Argumentation nicht. Threema hat sich in Vergangenheit zudem klar gegenüber weit weniger weitreichenden Massnahmen positioniert (siehe BÜPF) und damals gesagt, man würde eher noch ins Ausland ziehen, als bei so etwas mitzumachen. Nicht zu vergessen ist auch, dass die Schweiz bzgl. EU eine Sonderrolle hat und das gar nicht 1:1 übertragbar ist. Und da die Clients Open Source sind, könnte jeder sehen was für ein Blödsinn veranstaltet wird (das "Server sind aber Closed Source" Argument zieht hier nicht, da bei Threema keine Möglichkeit besteht, die Nachrichten zu entschlüsseln, ohne den Key der Clients zu kennen; es braucht daher zwingend eine Modifikation der Clients). Jetzt noch meine persönliche Note als Entwickler: Ich würde wohl eher schweren Herzens den Job wechseln, als meine eigens mitentwickelte Software und Protokolle zu sabotieren.

    Das Gesetz wäre in der Form jedenfalls eine Katastrophe für alle sicheren Messenger und muss auf jeden Fall verhindert werden.

    "- pro Server entstehen viel weniger Metadaten, da einzelne Server gar nicht das ganze Netzwerk kennen

    - es gibt keinen technischen Grund, warum bei federierten Systemen mehr Metadaten anfallen sollten"

    Ist das wirklich so??

    Prinzipiell sehe ich weder Vor- noch Nachteile bei föderierten Systemen, was die Metadaten betrifft. Die Metadatendebatte würde ich weniger bzgl. der Menge und eher bzgl. welcher konkreten unverschlüsselten Daten führen. Tatsächlich bin ich nicht im Detail mit den anfallenden Metadaten vertraut, habe aber damals in meiner Bachelorarbeit (zu dem Zeitpunkt hatte Matrix noch gar keine E2EE-Encryption) und jetzt letztens nochmal kurz ins Matrix Protokoll geschaut. Wenn die Gruppenkonstellation und solche Dinge wie Name, Avatar, Beschreibung von Rooms, wie stark vermutet, nicht verschlüsselt sind, wäre das für mich persönlich ein Ausschlusskriterium, da es insb. kleine geschlossene Gruppen exponiert. Man müsste sich für einen besseren Überblick mal im Detail damit beschäftigen, was Matrix konkret verschlüsselt überträgt und was nicht.
    Auf jeden Fall kann man aber sagen, dass Matrix auf Protokollebene eher zentral organisiert und Threema eher dezentral. Konkret erkennbar ist das an der Art und Weise wie Gruppen (bei Matrix Rooms) implementiert sind, wo bei Matrix die Gruppe auf dem Server organisiert wird und bei Threema auf den Clients. Ein weiteres Beispiel ist die Art und Weise wie Multi-Device in Threema integriert wird und wie sie in Matrix funktioniert. Das resultiert dann zwangsläufig in mehr Metadaten bei Matrix.

    Wie viele Server sind in einer Kommunikation beteiligt? Wenn alle über den selben Server schreiben, kann das bei dem richtigen Server doch gut und sicher sein oder?

    Die Sicherheit der Metadaten ist hier durch den kleinsten gemeinsamen Nenner definiert. Ein User Account als Mitglied eines Rooms bei einem "falschen" Server reicht aus, dass die Metadaten des Rooms abfliessen.

    Und zur Antwort das der Server die IP-Adresse speichert, kam die Antwort, das dies nicht der fall sei und deshalb die DATEN Anonymisiert werden und daher nicht zurückzuführen sind.

    Es hat niemand behauptet, dass sie gespeichert werden. Sie fallen aber technisch an, d.h. sie sind zum Zeitpunkt einer Verbindung zwangsläufig existent. Threema speichert sie auch nicht, daher gibts bzgl. dieser konkreten Anonymitätsfrage keine Gewinner.

    Vielleicht mal eine generrelle Frage, kann man einen Matrix/Element Server so gestalten, dass er Threema, was Datenschutz und Sicherheit betrifft, schlägt?

    Du müsstest die genauen Kriterien schon gezielt aufstellen.

    Ich hab mal wieder im Matrix Protokoll gegraben und konnte keinen Hinweis darauf finden, dass Rooms und dessen Teilnehmer verschlüsselt sind. Kann das jemand bestätigen oder widerlegen? Das wäre noch ein signifikanter Unterschied (im Vergleich zu Threema Gruppen) falls korrekt.

    Klar kann man auch Threema (Consumer) statt Threema Work nutzen. Hat dann eben entsprechende Nachteile bzgl. Verwaltung: Keine Vorkonfiguration möglich, Scanparty in der Firma für neue Angestellte notwendig, etc., konkret kann man ja die Vorzüge von Threema Work hier nachlesen).


    Threema (Consumer) und Threema Work sind zwei verschiedene Apps und daher auch parallel betreibbar.


    In Threema Work kann man einstellen, dass man ausserhalb der Arbeitszeiten nicht gestört werden möchte. In Threema (Consumer) gibt es das derzeit noch nicht, wäre aber schön, wenn es das als Tandemfunktion mit Threema Work gäbe.

    Selbst wenn ich 40TB Threema-Daten hätte wäre mir das egal, solange ich die auf ein Backupmedium bekomme ;)

    Und darüber hat wohl noch niemand nachgedacht...

    Mit gesplitteten Archiven machst du dann wieder direkt die nächste Büchse der Pandora für den Support auf. "Ach, ich musste hier beide Dateien kopieren? Jetzt sind alle meine Daten weg!"

    Die Datenmengen nehmen konstant zu, daher haben die neuen Handies auch deutlich mehr internen Speicher.

    Vollkommen korrekt und deswegen ist FAT32 hierfür ja auch ungeeignet. Ist es Threemas Verschulden, dass Android (in der von dir genutzten Version) kein exFAT kann? Ich denke nicht.


    Ich verstehe aber dein Dilemma und die Backupfunktion finde ich auch nur mässig zufriedenstellend (insb. Performance und die damit zusammenhängende fehlende Automatisierung). Was das Auswählen des Speicherorts angeht, wäre es spannend herauszufinden, was hier der limitierende Faktor ist und ob der sich beheben lässt (kann es mir schon vorstellen, die Dateisystemabstraktion in Android ist eine Katastrophe).

    Der wohl grösste Vorteil von Threema Work/Education für Schulen ist, dass Kontakte vorkonfiguriert werden und nicht erstmal eine grosse "Scanparty" veranstaltet werden muss, wo die Schüler sich jeweils gegenseitig scannen müssen. Zudem können (z.B. zwecks Jugendschutz) noch diverse Optionen direkt für alle aktiviert/deaktiviert werden. Das ginge mit Threema für normale Nutzer nicht - dort muss man alles von Hand einstellen. Unter Umständen lohnt sich da der Aufpreis durchaus. Und jetzt mal ehrlich: Jedes noch so kleine Schulbuch kostet weiter über 8€. :)


    Edit: Ah, aber hier geht's ja hauptsächlich um Eltern! Ich denke, die möglichen Vorteile kann man sich dennoch aus obigem Kontext ableiten. Für die Lehrer selbst macht's jedenfalls sicher Sinn, je nachdem wie gross die Schule ist.