Beiträge von f09fa681

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

    Als Anmerkung: Wie ich auch schon hier versucht habe zu erklären, ist mein Repository kein Fork sondern die Weiterführung des offiziellen Gateway SDKs für Python. Das Ganze ist mit Threema abgesprochen und die Gateway-Webseite wird demnächst entsprechend aktualisiert.


    Edit: Natürlich werden alle drei SDKs weiterhin von Threema offiziell supported und gepflegt - nur eben für Java und PHP nicht mehr über GitHub.

    Warum sollte dies das Aus für Messenger wie Threema darstellen? Man müsste schon Google/Apple dazu bekommen, die App im App Store oder allgemein die Android/iOS-Geräte zu kompromittieren, um an die Daten zu kommen. Ansonsten können die 100 Mitarbeiter dieser neuen Behörde ja gerne versuchen, das Problem des diskreten Logarithmus in elliptischen Kurven zu lösen. Ein Armutszeugnis, dass wir sowas nötig haben, ist es dennoch.

    Wenn auf dieser Seite das Feld dataChannels für den jeweiligen Browser grün hinterlegt ist, wird SaltyRTC mit hoher Wahrscheinlichkeit laufen und damit auch der Web Client. Edge wird mit ORTC (WebRTC 1.1) einsteigen und was Apple macht, weiß ich nicht. Für Browser ohne Support, also IE und Safari, gibt es Plugins, die WebRTC-Support ermöglichen.


    Das Betriebssystem spielt keine Rolle. Ich habe letztens sogar mit ein paar Kommilitonen ausprobiert, ob der Web Client auch auf Android im Chrome-Browser funktioniert. Die Antwortet lautet: Ja, funktioniert. :)


    1) Es wurde häufig "Android" geschrieben. Das heißt iOS ist anders zu beurteilen?


    Damit hab ich mich in der Arbeit nicht beschäftigt. Google's WebRTC-Library gibt's auch für iOS. Technisch ist es möglich. Scheitern könnte es also an Apple's Policies. Wenn dich das Thema mehr interessiert, kannst du ggf. recherchieren warum WhatsApp so lange für den Web Client Support in der iOS-Variante gebraucht hat.



    2) Der "Hauptdevice" muss online sein, damit die Nummer funktioniert, aber im Grunde ist es auch möglich, dass ich diesen nicht permanent bei mir trage?


    Ja, es ist egal wo das Gerät rumliegt, solange es Internet hat.



    [...] da [iOS-]Apps nicht permanent im Hintergrund laufen dürfen (Ausnahme: Streamingdienste wie Webradio etc.). Damit wäre der Node nicht permanent erreichbar und unter iOS folglich zweckfrei... [...]


    Kannst dir ja schon mal was ausdenken, warum Threema plötzlich Streaming in der App braucht. ;)


    Was ich etwas nervig finde ist, dass es keine Möglichkeit gibt, eine eMail oder Telefonnummer manuell auf die Schnelle zu suchen. Man muss also jeden Kontakt erstmal im Adressbuch anlegen und dann den Suchlauf durchführen lassen, bevor man weiß ob derjenige Threema benutzt.


    Vielleicht hat ja mal jemand Lust, mit Hilfe eines Threema Gateway Accounts einen Online-Dienst aufzubauen, der sowas auf die Schnelle ermöglicht. Ein Gateway-Account ohne Guthaben dürfte dafür reichen. Beispielsweise aus dem Python SDK:


    Code
    ./threema-gateway lookup <from> <secret> -e <email>
    ./threema-gateway lookup <from> <secret> -p <phoneNo>


    Ob Threema das so toll finden würde, weiß ich aber nicht. ;)


    Besteht die Möglichkeit, eine deutsche Version der Arbeit zu bekommen?


    Leider nicht, es sei denn, du findest jemanden, der sie vollständig übersetzt. ;)



    Multi Device-unterstützung?


    Ich sag mal so viel: Es macht technisch keinen Unterschied, ob sich da ein Browser oder sich eine App zur Threema App verbindet. Und man kann natürlich auch mehrere solcher Clients haben, die gleichzeitig mit der Threema App verbunden sind.



    Uii! Hat @Igrahl vor, den Source Code zu veröffentlichen? Oder will das Threema nicht?


    SaltyRTC wird demnächst (ich definiere das mal nicht genauer, denn da muss noch einiges aufgearbeitet werden) auf GitHub veröffentlicht. Wer sehr interessiert daran ist, wird vermutlich vorher eine Version auf unserem VCS-Server finden.


    [...] Viele wissen gar nicht was es für Methoden gibt. Ich denke im Moment an PGP. Und das ist wirklich nichts
    neues. In meinem Umfeld kennt es leider keiner. [...]


    Selbst wenn sie es kennen... und das ist in meinen Augen das Hauptproblem. Eines, was Threema im Bereich der Messenger sehr gut gelöst hat. Wir können unsere Freunde und Bekannte noch so mit PGP nerven. Solange die Usability scheiße ist, bleibt es für sie unbenutzbar.

    Wird Case-sensitiv überprüft?
    Emails werden lowercase verglichen.


    Wird z.B. gmail.com und googlemail.com als gleich angesehen oder müsste man einen exakten Treffer haben?
    Für Gmail werden beide Varianten ausprobiert.

    Threema will sich damit gegen das ständige Nachfragen und schlechte Bewertungen schützen ("Ihr habt doch Feature X angekündigt - wann kommt denn das jetzt endlich?!"). Davon kann man halten was man will und ob die Taktik aufgeht, sei mal dahingestellt. Aber natürlich muss man sich nicht für etwas verteidigen, was man nicht angekündigt hat. Darüber hinaus will man eben nichts ankündigen, was eventuell nichts wird oder wobei man so gar nicht abschätzen kann, wie viel Zeit das in Anspruch nehmen wird. Ergo: Man kündigt Features nur dann an, wenn sie nur noch etwas Feinschliff benötigen. Das ist in der Softwareentwicklung gar nicht so unüblich und erlaubt es den Entwicklern das zu tun, was sie am Besten können, nämlich Entwickeln. Außerdem: Das Forum hier zeigt doch, dass trotzdem munter spekuliert wird. ;)

    Bist du zufällig bei Unitymedia? Ich habe seit dem Umzug Probleme mit dem Empfang von Push-Nachrichten (allgemein, nicht nur auf Threema beschränkt) und habe die Vermutung, dass DS-Lite dahinter stecken könnte (zumindest die Path MTU Discovery funktioniert so überhaupt nicht und könnte daher bei langen Push-Nachrichten potentiell zu Problemen führen; habe mir Googles Push Service allerdings nicht genauer angeschaut). Bisher bin ich allerdings auf keine weiteren Threema-Nutzer gestoßen, die das gleiche Problem haben.


    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.


    Wenn du deine Emails verschlüsseln willst, schau dir mal PGP an. Ist in Thunderbird ziemlich einfach einzurichten, siehe hier:
    http://lifehacker.com/180878/how-to-encrypt-your-email


    Was man wissen sollte: Die Verschlüsselung exkludiert standardmäßig den Betreff einer Mail. Zudem können nur wenige Clients überhaupt mit verschlüsselten Betreffzeilen umgehen. Für das grobe bestimmen von Inhalten reicht das für einen Angreifer durchaus aus und gibt deutlich mehr als nur Metadaten preis.

    Worauf ich vielleicht noch hinweisen sollte: KDE Connect bitte nur in einem vertrauenswürdigen LAN nutzen.


    Hintergrund: Das von den KDE Connect Entwicklern eigens entwickelte Protokoll verschlüsselt zwar Ende-zu-Ende, hat aber keinerlei Schutz gegen Replay-Attacken. Zudem kann man durch den geschickten Einsatz von MAC-Flooding den Public Key abfangen (der Public Key eines Teilnehmers ist gleichzeitig eine Art Secret) und eine Unpair-Anfrage fälschen und eine Man-in-the-Middle-Attacke beim erneuten Pairing durchführen.


    Kurz gesagt: Spätestens wenn ein Gerät aus unerfindlichen Gründen nicht mehr Paired ist, sollten beim Benutzer die Alarmglocken schrillen.