Diskussion:Liste von mobilen Instant-Messengern/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Liste von mobilen Instant-Messengern/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Liste_von_mobilen_Instant-Messengern/Archiv/1#Thema_1

Fehlende Verschlüsslung als Teilweise Feld

Bei Messengern, die Ende-zu-Ende und Transport-Verschlüsslung unterstützen wurden die Felder Gruppenchat und Asynchrone Kommunikation Gelb gemacht, wenn da keine Ende-zu-Ende-Verschlüsslung mehr stattfand.

Bei Messengern, die gar keine Ende-zu-Ende Verschlüsslung konnten wurde das Feld Grün gemacht.

Das passt irgend wie nicht zusammen. Ich habe das mal vereinheitlicht bei Gruppenchat (wo Ende-zu-Ende gut zu implementieren wäre, wenn auch mit etwas mehr aufwand) Teilweise und bei Asynchron grün mit kommentar.

Finde das aber durchaus diskussionswürdig. Gerade bei Asynchroner Kommunikation ist Ende-zu-Ende und PFS oder Abstreitbarkeit eigentlich unmöglich. (Glaube ich zumindest.) Auf jeden Fall sollte es finde ich einheitlich sein. Deswegen die Frage was meint ihr welche Verschlüsslung soll bei welchem Chat möglich sein, damit man welches Feld mit welchem Kommentar bekommt? (nicht signierter Beitrag von Fabiwanne (Diskussion | Beiträge) 12:50, 12. Jan. 2014 (CET))

Woher stammt eigentlich die Information, dass Threema bei asynchroner Kommunikation keine Ende-zu-Ende-Verschlüsselung unterstützt? Nach meinem Verständnis geht das ja durchaus, indem z.B. der Public Key des Empfängers vom Threema-Server abgerufen und dann zur Verschlüsselung benutzt wird. Bei Telegram scheint es so zu sein dass Nachrichten mit der höchsten Sicherheitsstufe ("secure chat") nicht auf den Servern gespeichert werden, aber bei Threema finde ich keine solche Information... (nicht signierter Beitrag von 80.153.62.152 (Diskussion) 13:08, 17. Feb. 2014 (CET))

Soweit ich weiß wird bei Threema immer verschlüsselt, auch bei asynchroner Kommunikation. Habe das geändert... (nicht signierter Beitrag von 92.196.42.151 (Diskussion) 17:53, 22. Feb. 2014 (CET))

Glauben ist nicht wissen. Ist nämlich nciht so. Siehe [1]. Bitte lasse solche Edits in Zukunft. --Fabiwanne (Diskussion) 21:06, 22. Feb. 2014 (CET)

Edit: Sorry habe Telegram und Threema verwechselt hier behauptet der Entwickler tatsächlich dass Threema das macht. Überprüfen kann das natürlich keiner. --Fabiwanne (Diskussion) 21:23, 22. Feb. 2014 (CET)

Soweit ich weiß ist es zum Erstellen des secret chats bei telegram notwendig, dass beide personen gleichzeitig online sind. Danach sollte aber auch asynchrone Kommunikation möglich sein (zumindest laut deren krypto docs). Ich konnte es noch nicht testen. Weiß da jemand genaueres?--92.196.42.151 01:17, 23. Feb. 2014 (CET)

Eigenentwicklungen für Client-Server Crypto

Sollte man bei Client-Server eigententwicklungen nicht vielleicht auch gelb machen? (nicht signierter Beitrag von Fabiwanne (Diskussion | Beiträge) 22:47, 24. Jan. 2014 (CET))

Gute Idee, ich habe mal damit angefangen. --Tanjeff (Diskussion) 08:05, 7. Feb. 2014 (CET)

Führe dein Schema mal zu ende. Weiß aber nicht ob es wirklich sinnvoll ist SSL3.0 gelb zu markieren. In aktuellen implementierungen ist es ungebrochen. Und es gibt durchaus auch attakten auf schlchte TLS implementierungen. ([2] ist seht gut.) Ob eigenentwicklungen rot werden sollen ist auch zu diskutieren. --Fabiwanne (Diskussion) 18:28, 7. Feb. 2014 (CET)

SSL 3.0 hat die gleichen probleme wie TLS 1.0, es waere interessant, welche TLS-versionen verwendet werden. --Mario d 14:27, 11. Feb. 2014 (CET)

"Anmeldung mit Telefonnummer zwecks Telefonbuchabgleich erforderlich" fehlt mir als Kriterium

Gibt es Einwände das hinzuzufügen? --Zulu55 (Diskussion) _Unwissen 14:15, 3. Feb. 2014 (CET) Ich war mal mutig und habs umgesetzt. --Zulu55 (Diskussion) _Unwissen 14:23, 3. Feb. 2014 (CET) Ich würde vorschlagen die Farbkodierung zu ändern. "Ja" ist eindeutig die am wenigsten wünschenswerte Option, daher sollte das Rot bleiben, allerdings finde ich "Nein" restriktiver als "Optional", da der User im letzteren Fall wenigstens die Wahl hat. Daher würde ich "Nein" gelb unterlegen und "Optional" grün. Das Hochladen des Telefonbuchs kann auch als Vorteil gewertet werden, da dies u.U. den Komfort erhöht. --77.2.229.67 14:04, 20. Feb. 2014 (CET)

Ich denke auch, dass bei den meisten Nutzern das Hochladen des Telefonbuchs als wünschenswert erachtet wird. Optional sollte desshalb grün sein. Ja können wir ja auf rot lassen (obwohl man darüber auch streiten kann) und Nein kommt gelb...--195.37.234.90 11:38, 24. Feb. 2014 (CET)

Sollte zumindest bei Open-Source Anwendungen nicht einwandfrei feststellbar sein, ob diese das Telefonbuch mit übertragen? Mir ist nämlich aufgefallen das dort überall "Unbekannt" steht. (nicht signierter Beitrag von 46.115.114.169 (Diskussion) 18:32, 20. Feb. 2014 (CET))

Es gibt auch (evtl. optional) den Adressbuchabgleich per email Adresse (bekannt aus Skype, aktuell bei BMM genutzt). Durchaus ein Kreterium für Komfort ohne die Telefonnummer angeben zu müssen. 178.11.225.99 19:08, 20. Feb. 2014 (CET)

Pro Forma möchte ich protestieren, dass die optionale Übertragung als die "beste" Form dargestellt wird. Ja, das wird möglicherweise sogar von der Mehrheit gewünscht. Dennoch finde ich, dass damit das Recht auf Informationelle Selbstbestimmung des Einzelnen eingeschränkt wird. Meine Telefonnummer hat niemand beiläufig irgendeinem Dienst anzugeben. Die ursprüngliche Farbcodierung hatte das wiedergespiegelt.--Amenthes (Diskussion) 23:35, 25. Feb. 2014 (CET)

Du hast es selbst gesagt, die Mehrheit erachtet die Übertragung als positiv. Insofern ist die Farbkodierung denke ich richtig. Es wäre wahrscheinlich besser auf die Kritik der Übertragung unten im Artikel weiter einzugehen. Also dass z.B. auch Daten von Nutzern übertragen werden, welche die App nie installiert haben. --92.196.77.237 09:46, 26. Feb. 2014 (CET)

Man muss der Mehrheit ja nicht nach dem Schnabel reden. Man könnte ihnen vielleicht auf dem Weg auch aufzeigen, dass das eben nicht die beste (weil bequemste) sondern zweitbeste (weil respektvolle) Variante ist.--92.50.69.42 13:27, 26. Feb. 2014 (CET)

"respektvoll"? Für einen automatischen Abgleich MÜSSEN NUR (ohne Name, Adresse oder irgendwelche anderen Angaben) per opt-in Telefonnummern und email Adressen aus dem Adrssbuch auf den Server geladen werden. Und beides ist ohne weitere Angaben nix wert. Wenn dann max. die email Adressen für Spammer. Aber wenn das bei einem Messenging Server ein problem ist dann hat man ganz andere Probleme ;) Wenn der Hersteller das anderst implementiert (z.B. weil er die Namen dazu auch hoch läd) dann ist das ein seperater Kritikpunkt (man darf das System an sich nicht kritisieren nur weil es einige falsch umsetzen). Für mich taugen Messenger ohne optionalen Adressbuchabgleich über Telefonnummer/eMail Adresse schlichweg nix. Weil so was ist nicht praxistauglich in der realen Welt wo auch Leute rumlaufen die keine Freaks sind. 178.11.87.107 15:37, 26. Feb. 2014 (CET)

Was heißt nichts wert? Dadurch, dass alle Telefonnummern des Adressbuches hochgeladen werden lässt sich schon einmal schließen, dass der Nutzer diese Personen kennt (zumindest mit hoher Wahrscheinlichkeit). Alleine ergeben die Daten natürlich keinen Sinn, aber veknüpft mit wieder anderen Daten kann das schon ganz anders aussehen. Das ist eben das Problem von Big Data. Nur als Beispiel: Wenn du die Telefonummer von einem bekannten Psychologen für Pädophile oder von Prostituierten in deinen Kontakten hättest willst du bestimmt nicht, dass dies öffentlich gemacht wird oder du damit vielleicht später erpresst wirst, oder?--92.196.77.237 18:17, 26. Feb. 2014 (CET)

Deswegen opt-in ;) Das darf der Nutzer dann selber entscheiden (hast recht, nichts Wert ist zu absolut). Aber WhatsApp wurde halt nur so schnell erfolgreich weil man da keine sepp. ID weitergeben musste der der andere dann manuell... Ist halt nunmal so. Das ist das was "die Leute" wollen, also ist es "gut" wenn Messenger das optional können. Es muss dir nicht gefallen, es ist hal nunmal so. Und WP ist kein Instrument zur Erziehung der Massen zum guten ;) Aber wünschenswert wäre natürlich auch wenn sich der Abgleich optional auf bestimmte Gruppen/Tags beziehen würde und nicht auf das gesamte Adressbuch. Man will ja auch nicht seinen Chef in der Kontaktliste für den privaten Chat ;) Aber das sind dann Implementationsdetails der einzelnen Apps 178.11.87.107 20:16, 26. Feb. 2014 (CET)

Also sorry, aber ich sehe absolut keinen Vorteil daran, dass die Telefonnummer auf den Server von WhatsApp übertragen wird. Die Hashingverfahren von Threema und Co zeigen, dass auch ein abgleich mit Telefonnummern ohne direkte übremittlung geht. Mit typischen hashes ist das noch zimelich nutzlos. Aber wenn man da z.B. 24Bit SHA-3 Hashes und einen Salt übermitteln würde, und dann der server die clients mt passendem Hash veranlassen würde einen gesalzenen Hash zu an den absenden Client verschicken würde hätte das den gleichen effekt, wie ein Abgleich auf Serverseite. Nur ohne dass die Nummern zum server übertragen würde und mit etwas verzögerung (Wen dergegenüber das erstem mal on kommt). Ist nur was mir so auf anhieb einfällt. Da geht bestimmt mehr und das gienge wahrscheinlich sogar vollständig verteilt ohne irgend was preiszugeben. Die behauptung das gewisse fatures daran hängen, dass eine Firma alles weiß und alles kontrolliert mag einigen App-Herausgeben zar passen stimmt aber schlicht nicht. --Fabiwanne (Diskussion) 23:58, 27. Feb. 2014 (CET)

Ich verstehe nicht, warum das Adressbuch überhaupt übertragen werden muss? Die app kann ja zB meine Nummer (opt in) an den Server übertragen (optimalerweise natürlich nicht im klartext). Danach würde es reichen zB für *den Kontakt, den ich jetzt gerade anschreiben will* auf dem server mal nachzufragen. Dabei würde nur ein Bruchteil meines Adressbuchs überhaupt auf dem Server landen. Wie viele Leute habt ihr im Adressbuch? 200? 300? Wie viele kontaktiert ihr regelmäßig? 10%? Ja, ich bin der Meinung dass die (auch optionale) Übertragung des gesamten Adressbuches keine gute Funktion ist. Wir machen diese Liste hier ja nicht nach dem Kriterium "wie sehr es wie Whatsapp ist" oder "wie gut es massentauglich ist" sondern danach, was wir für positiv und negativ halten. Wenns um Massentauglichkeit ginge dann fehlt da die Spalte "Anzahl der Smileys".--Amenthes (Diskussion) 00:23, 28. Feb. 2014 (CET)

Der Benutzer möchte aber wissen wit wem er kommunizieren kann. Er möchte nicht erst schreiben und dann eine Fehlermeldung erhalten. Also bitte seid nicht so engstirnig und konzentriert euch nicht nur auf den Datenschutz. Probiert euch auch in "Tante Emma" hineinzuversetzen. Die Wikipedia ist für alle da! Dass die Übertragung des Telefonbuchs keinen Vorteil bringt, ist faktisch einfach falsch! Als Hash ist natürlich etwas besser, aufgrund des des kleinen Datenraums aber auch keine große Verbesserung. Hier noch ein guter Link zu der Problematik von den sehr kompetenten Whispersystems Leuten: https://whispersystems.org/blog/contact-discovery/ --42Agrajag (Diskussion) 01:28, 28. Feb. 2014 (CET)

Ließ dir einfach mal meinen Beitrag durch. Und Hash ist nicht Hash. Ließ dir dazu den Beitrag, den ich zu den Hashes geschrieben habe. --Fabiwanne (Diskussion) 02:53, 1. Mär. 2014 (CET)

Weitere Spalten für andere Betriebsysteme

Ich schlage vor, folgende Spalten einzufügen: "Andere mobile Platformen", "Mac", "PC". --77.2.229.67 14:04, 20. Feb. 2014 (CET)

finde ich prinzipiell gut, nur die Unterscheidung Mac gg PC halte ich nicht für korrekt. Wenn dann Mac gg Windows, denn ein Mac ist auch ein Personal Computer (im heutigen Sprachgebrauch, nicht natürlich im Sinne der früheren IBM-kompatiblen), genauso wie ein iPhone auch ein Smartphone und ein iPad auch ein Tablet ist (auch wenn das Apple Marketing seine Produkte gerne als eigene Gattungen anpreist). Zum Vergleich wäre das so wie wenn man bei den Mobilen Geräten eine Spalte mit iPhones und eine mit Smartphones machen würde.--BSI (Diskussion) 16:05, 21. Feb. 2014 (CET) Nachtrag: mein Vorschlag wären die Spalten "Windows Phone", "Blackberry", "PC".

So ich hab mal WP ergänzt, Blackberry mach ich noch --Dark-Water (Diskussion) 11:59, 23. Feb. 2014 (CET)

PC/Mac/Linux nochmal jweils getrennt aufzuführen würde mir zu weit gehen. Die Tabelle ist jetzt schon umfangreich. Dazu kommt, dass (nach oberflächlicher Recherche) nur sehr wenige der Messenger hier überhaupt punkten könnten. _wenn_ das kommt, würde ich höchstens für eine Zusammenlegung der drei Plattformen in eine Spalte votieren. Aber sogar das (finde ich) geht am Titel und am Thema des Artikel etwas vorbei. --Amenthes (Diskussion) 14:01, 23. Feb. 2014 (CET)

Es fehlen noch Messenger / Auswahlkriterien

Gerade die grossen fehlen hier: Hangouts, Facebook Messenger, BBM. Ferner fehlt noch mysms (sowas wie iMessage für Android). Und viele weitere mehr... Wenn jemand schon so eine Liste anfängt dann aber richtig sammeln. (nicht signierter Beitrag von 178.11.225.99 (Diskussion) 18:53, 20. Feb. 2014 (CET))

Hast recht. Imho ist die Liste eh schon zu weit gefasst: Es fehlen dort noch dutzende "mobile Instant Messenger"... Ich persönlich wäre (gerade in der aktuellen Situation) für eine Einschränkung auf OSS-Messenger. Diese besitzen durch ihre Transparenz schon eine höhere Sicherheit. edit: Vllt die drei populärsten Proprietären und ansonsten OpenSource? (siehe [3]). --MilesTeg (Diskussion) 09:15, 23. Feb. 2014 (CET)

Das hier ist ja keine Liste der "guten Messanger" sondern eine Liste von "mobilen Instand-Messengern". Und da sollten Dinge wie Transparenz kein Kreterium für die Aufnahme sein. --92.76.123.147 19:13, 23. Feb. 2014 (CET)

Der Kik Messenger sollte aber doch auf jeden Fall mit rein, oder? Und da das der offizielle Nachfolger des Windows Live Messenger ist, müßte man doch auch Skype hier aufnehmen? --Zopp (Diskussion) 14:28, 27. Feb. 2014 (CET)

Fehlende Messenger können doch einfach nachgetragen werden. Das muss der Initiator des Artikels ja nicht alleine machen. Ich bin dagegen, einzelne Messenger auszuschließen. --Tanjeff (Diskussion) 21:11, 9. Nov. 2014 (CET)

den IM whistle.im noch hinzufügen (nicht signierter Beitrag von 195.200.70.49 (Diskussion) 09:51, 21. Feb. 2014 (CET))

Eher keine Gute Idee. whistle.im ist schon durch mangelhafte Umsetzung des Sicherheitskonzepts aufgefallen [4]. Hier würde sich auch die Frage stellen, ob man für gefundene Sicherheitslücken bzw. erhebliche, begründete Bedenken eine neue Spalte einfügt. --77.179.77.176 01:51, 23. Feb. 2014 (CET)

Hier würde ich gerne mal die Frage aufstellen, ob es nicht besser wäre, auch mal Auswahlkriterien zu formulieren. Ich persönlich würde mich z. B. aktuell gegen Heml.is in der Liste aussprechen. Dieser wurde noch nicht veröffentlicht, was aber aus der Liste gar nicht deutlich wird, viel mehr wird davon ausgegangen, dass es der Leser schon weiß. Im gegenwärtigen Zustand ist der Informationsgehalt zu Hemlis relativ gering, der Mehrwert seiner Aufnahme in die Liste erschließt sich mir deshalb (im jetzigen Zustand) nicht. Im Gegensatz dazu fehlen, wie über mir schon angesprochen, bereits veröffentlichte Messenger, die jedoch allesamt öffentlich Beachtung finden.--BSI (Diskussion) 17:22, 21. Feb. 2014 (CET)

Hemlis wird in der aktuellen Diskussion (nach dem Whatsapp verkauf an Facebook) immer wieder ins Feld geführt. Da finde ich es ganz praktisch, dass er hier schon (mit aktueller Informationslage) drauf ist.--Amenthes (Diskussion) 14:05, 23. Feb. 2014 (CET)

Welche aktuelle Informationslage denn? Wenn in jeder Spalte nur "unbekannt" oder "nicht" zu lesen ist, bringt das dem Leser eher einen Desinformationswert (weil er glauben könnte, der Messenger bietet bestimmte Funktionen nicht, obwohl einfach noch nicht bekannt ist ob er sie bei VÖ bieten wird). --BSI (Diskussion) 17:36, 24. Feb. 2014 (CET)

Nach einem kurzen Ausflug in die Welt der Megakonzerne (bäh!):

• Facebook
• Tencent Holdings Limited
• Google
• Microsoft

Das sind eindeutig die großen Player und Marktführer. Deren offizielle (aktuellen) Clients:

• Facebook Messenger, (+WhatsApp)
• WeChat, Tencent QQ
• Google+
• Skype

Das sind einfach die großen Communities und man kann davon ausgehen, dass deren Software am weitesten verbreitet ist. Alle gut über 200 mio. aktive Nutzer (nach eigenen Angaben zumindest)--MilesTeg (Diskussion) 16:15, 23. Feb. 2014 (CET)

Spielt Skype als IM überhaupt eine Rolle? Kann man da jetzt überhaupt Nachrichten an jemanden senden der gerade offline ist? Meine Versuche zeigen das solche Nachrichten nicht ankommen. IMHO ist Skype eher ein Chatprogramm und kein IM. --92.76.123.147 19:10, 23. Feb. 2014 (CET)

Es fehlt in der Tabelle die Spalte Cloudfähigkeit

ob der Messenger Cloudfähig ist. D.h. ist er gleichzeitig an meheren Endgeräten (und auch im Web Browser) nutzbar? (nicht signierter Beitrag von 178.11.225.99 (Diskussion) 18:53, 20. Feb. 2014 (CET))

Es gibt weiter oben eine Diskussion zu "weitere Spalten", die das ebenfalls ins Feld führt.--Amenthes (Diskussion) 14:06, 23. Feb. 2014 (CET)

Das hier meint nicht auf welchen Plattformen er lauffähig ist. Sondern es meint ob es möglich ist einen Chat, den man z.B. am Handy bekommen hat nahtlos am PC (oder auf dem Tablet) fortzusetzen. Also es geht nicht um Clienten für mehere Plattformen sondern die gleichzeitige Nutzung auf allen Plattformen (vergleichbar mit IMAP bei eMail) --92.76.123.147 19:07, 23. Feb. 2014 (CET)

Cloudfähig ist so ein Gummibegriff, dass ich ihn falsch verstanden habe, sorry. Ja, das wäre in der Tat eine interessante Frage. Alledings würde ich das nur in den Tabellen haben wollen, wenn - wild aus der Luft gegriffen - zwei, drei Messenger dieses Kriterium überhaupt erfüllen. --Amenthes (Diskussion) 00:17, 26. Feb. 2014 (CET)

Threema Übertragung des Telefonbuchs nur als hashes

Das "nur als hashes" sollte entfernt werden weil es ein falsches Gefühl von Sicherheit vermittelt. Zu allen theoretisch existierenden Telefonnummern die hashes zu berechnen sollte nicht zu aufwendig sein. Und dann bekommt man mit dieser Tabelle leicht die Telefonnummer zum hash. Und falls ich hiermit falsch liege, dann liegt es daran das mir der Artikel nicht erklärt was ich da falsch verstanden habe ;) --178.11.225.99 19:23, 20. Feb. 2014 (CET)

Korrekt, wird auch genauso explizit in den Threema FAQ beschrieben. Hab das Feld auf „Teilweise“ gesetzt, wie die anderen „Optional“ in der Spalte auch sind. --188.174.95.120 01:28, 24. Feb. 2014 (CET)

Wenn da Hashes steht dann werden die Telefonnummern eben nicht übertragen. Deswegen finde ich Ja grundsätzlich falsch. Allerdngs hast du natürlich schon recht: Eine Telfonnummer hat so ca. 9 effektive Stellen (ohne 0 bzw. ohne 01 bei Mobilfunk) (=>30Bit) + nochmal 9Bit für den Ländercode (=> ca. 40Bit insgesammt). Von denenen man viele schon raten kann, weil gewiesse Provider bei bestimmten kontakten weiter verbreitet sind. Wenn man da die wiederherstellung unmöglich machen will muss man mit der Hashlänge deutlich drunter bleiben. => 32Bit hashes oder so. Kollissionen für 32Bit hashes gibt's aber im schnitt ab 2^16=65536 Benutzern (Für 40Bit Hashes währen es aber schon 1.048.576). => Die sind für größere Nutzerzahlen ziemlich ungeeignet.

Außerdem bleibt natürlich die Frage ob man die Telefonnummer oder die Kontakte in seinem Telefonbuch nicht breisgeben will. Letzteres tut man mit den Hashes genauso. --141.70.9.239 05:59, 27. Feb. 2014 (CET)

Farben Telfeonbuchübertragung

habe die Farbmarkierung geändert, siehe oben unter ""Anmeldung mit Telefonnummer zwecks Telefonbuchabgleich erforderlich" fehlt mir als Kriterium" --195.37.234.90 11:38, 24. Feb. 2014 (CET)

So ganz leuchtet mir jetzt deine Farbwahl nicht ein??? Sollte nicht "Nein" ein Grün bekommen und "Teilweise" / "Optional" ein Gelb ??? Sollte man auch noch unterscheiden ob Optional bedeutet, "nach der Installation an" und "nach der Installation aus" MfG --Dark-Water (Diskussion) 11:59, 24. Feb. 2014 (CET)

Grün soll doch die positive Variante sein oder? Und optional ist doch das beste für den Nutzer. Der Sicherheitsfanatiker kann das deaktivieren und 95% der normalen Nutzer werden es aus Bequemlichkeit zum Finden ihrer Freunde aktivieren. Ob jetzt "Ja" oder "Nein", gelb oder rot sein soll ist denke ich Sache des Standpunktes (Datenschutz vs. Bequemlichkeit/Komfort) --92.196.14.246 01:53, 25. Feb. 2014 (CET)

Genau, Grün = best variante = garkeine übertragung des Telefonbuches oder der eigenen nummer (also z.b. separater account wie es z.b. surespot macht). Dann gibt es z.b. noch variante, wie es Textsecure macht, da wird nur mit der eigenen Telefonummer registiert und bei versand einer nachricht an einen kontakt wird geprüft, ob dieser auch beim dienst registiert wird. Ich nenne es dann mal teilweise adressebuch übermittlung (und nicht gleich immer alle!). Bei Threema ist es ja optional, aber auch Standard.

Das überschneidet sich jetzt mit http://de.wikipedia.org/w/index.php?title=Diskussion:Liste_von_mobilen_Instant-Messengern#.22Anmeldung_mit_Telefonnummer_zwecks_Telefonbuchabgleich_erforderlich.22_fehlt_mir_als_Kriterium Evtl. sollten wir von den wertenden Farben (gut/schlecht) wegkommen und neutrale "das ist so!" Farben wählen? Der mündige Nutzer darf durchaus selber entscheiden was er davon hält. Über die Gefahren diverser Features darf man ja gerne im folgenden Text informieren. 178.11.87.107 20:42, 26. Feb. 2014 (CET)

Eine Optionale Übertragung sollte nur grün sein so lange es ein Opt-In Features ist. Bei Opt-Out muss die App zunächst gestartet werden und bereits da wird zumindest einmal das Telefonbuch übertragen! WolfspiritM (Diskussion) 00:44, 27. Feb. 2014 (CET)

Vielleicht sollte man einen anderen Spalten Titel wählen. "Übertragung persönlicher Daten" vielleicht? und in der Zelle dann kurz beschreiben was übertragen wird? -- (nicht signierter Beitrag von 92.79.168.180 (Diskussion) 14:00, 25. Feb. 2014 (CET))

Zuerstmal es hier gar nicht mehr um hashes geht, habe ich das mal abgetrennt. Das Optional grün wird finde ich richtig und wollte ich auch schon verändern. Aber dass man nein gelb gemacht hat ist quatsch. So grenzt man Messanger aus, die nich auf die schwachsinnige Idee gekommen sind Telefonnummern als ID zu nehmen. E-Mail, appsotre oder eigene accounts oder ähnliches sind wesentlich langlebiger und bieten nebebei die Möglichkeit mehrere unterschiedliche geräte zu nutzen. --141.70.9.239 05:19, 27. Feb. 2014 (CET)

Die möglichkeit mehrere Geräte gleichzeitig zu nutzen bietet z.B. Telegram auch mit Telefonnummer. Das ein Messenger die Telefonnummer als "ID" benutzt ist daher kein Grund darauf zu verzichten. Auch TextSecure plant die gleichzeitige Nutzung auf mehreren Geräten WolfspiritM (Diskussion) 07:34, 27. Feb. 2014 (CET)

@WolfspiritM: Wo hast du das denn her? Warum sollte bei der Opt-Out Lösung beim Start der App das Telefonbuch syncronisiert werden? Bei Threema kann man das z.B. beim ersten Start der App wählen. Also dort ist es ganz klar optional. Dann schrieb da oben noch jemand, dass Textsecure nicht das ganze Telefonbuch (als Hashes) abgleicht. Bist du dir da sicher? Wenn Ich bei Textsecure eine neue Konversation starte werden meine Kontakte angezeigt und oben stehen welche in grün, ich denke mal das sind ebenfalls Textsecure Nutzer. Also wird wohl doch das ganze Telefonbuch abgeglichen. --92.196.47.35 10:04, 27. Feb. 2014 (CET)

Bei Threema mag es so sein. Dann zählt das ganze aber nicht als Opt-Out. Grundsätzlich heißt Optional aber erst einmal nicht sicher und damit grün. WolfspiritM (Diskussion) 11:31, 27. Feb. 2014 (CET)

Optional heißt, dass man wählen kann ob die Kontakte synronisiert werden oder nicht. Wenn man erst nach der ersten Syncronisation wählen kann, ist dies schlicht "ja" und nicht "optional". Also bleibt optional die beste Variante. Kennt sich hier denn jemand anders mit Line aus? Wie ist das dort? Was passiert wenn man die Syncronisation ausschaltet, muss man die Kontakte dann selbst hinzufügen? Und hat man beim ersten Start die Möglichkeit die Syncronisation auszuschalten? --92.196.47.35 12:34, 27. Feb. 2014 (CET)

Aber mal ganz Allgemein: Wikipedia ist nicht zur Umerziehung der Menschen da! Optional ist ganz eindeutig die beste Variante! Da kann der mündige Nutzer selbst entscheiden. Wir können die "Ja" und "Nein"-Felder ja grau machen, dann wären diese Wertungsfrei. Es gibt nunmal für beide Varianten Vorteile: Komfort vs. Datenschutz. Im Text sollten beide Vorteile erklärt werden! --92.196.47.35 10:04, 27. Feb. 2014 (CET)

Eine Wertungsfreie Farbgebung ist für Wikipedia definitiv besser. Ggf. vielleicht auch mit einem kleinen Absatz bzgl. Vor- und Nachteile, wobei hier wieder die Frage ist ob das zur Liste der Messenger gehört. WolfspiritM (Diskussion) 11:31, 27. Feb. 2014 (CET)

Was haltet ihr von gelb für Ja und Nein? Hat beides Vor und Nachteile... --92.196.47.35 12:36, 27. Feb. 2014 (CET)

Entweder so oder ganz ohne farbliche Hervorhebung. Stimme deinem vorletzten Kommentar voll und ganz zu, wir sollten hier nicht Oberlehrern spielen. Die Aufgabe eines Listenartikels ist nun mal Informationen aufzulisten (und ggf vergleichbar zu machen) und nicht sie subjektiv zu bewerten. Ob für einen Nutzer Komfort oder Datenschutz wichtiger und damit besser ist, sollte er immer noch selbst entscheiden. Dass aber die optionale Übertragung für die Mehrheit die beste Möglichkeit darstellt, dürfte wohl recht unstrittig sein (außer natürlich bei den jeweiligen Hardlinern). Daher befürworte ich die von dir vorgeschlagene Option (ja/nein->gelb; optional->grün).--BSI (Diskussion) 14:35, 27. Feb. 2014 (CET)

Übertragung des Telefonbuches ist auf jeden Fall erstmal negativ. Wenn sich dadurch auch Vorteile ergeben, wie das wiedererkennen von Kontakten ist eine andere Frage und kann in eine extra spalte. Prinzipiell geht sowas wie IP 178.11.225.99 schon angemerhkt hat auch ohne ist aber wohl etwas schwiriger in der implementierung bzw. hätte andere Nachteile. Deswegen ist ein Nein erstmal grün. --Fabiwanne (Diskussion) 19:49, 27. Feb. 2014 (CET)

"Übertragung des Telefonbuches ist auf jeden Fall erstmal negativ."
Klingt so als wärst du der Entscheider der von der Weltbevölkerung einstimmig gewählt wurde um über richtig und falsch zu bestimmen ;) Du hast das "IMHO" vergessen.
Und die Erkennung über eMail ist nicht schwieriger (oder gar eine Notlösung). Es ist einfach die Frage über was ich (als Nutzer des Messengers) identifiziert werden will (wenn ich es will), will ich das mich die Leute über meine private oder geschäftliche eMail Adresse finden dann gebe ich diese an, genauso wie bei der Telefonnummer. Beides ist gleichwertig. Es geht ja nur darum irgendeinen weltweit eindeutigen (und verifizierbaren) String anzugeben den die Chatpartner eh von einem in ihrem Adressbuch haben. Und will ich das nicht dann gebe ich nix an und verteile meine nichtssagende (mir zufällig zugeordnete) ID --88.70.34.149 20:36, 27. Feb. 2014 (CET)

So einfach ist das nicht. Optional ist die beste Variante, da sind wir uns hoffentlich einig. Aber, dass die Übertragung erstmal negativ ist, ist einfach falsch! Es ist und bleibt Ansichtssache. Es hängt von den Prioritäten ab: Komfort vs Datenschutz! Also Ja/Nein sollte grau oder gelb (meiner Meinung nach besser) werden und im Text sollte auf die Vor- und Nachteile eingegangen werden. --42Agrajag (Diskussion) 01:19, 28. Feb. 2014 (CET)

Könnt ihr euch bitte erst die vollständige Antwort durchlesen (und verstehen) bevor ihr wiedersprecht? Es geht eben nicht um Datenschutz vs. Komfort sondern ausschließlich um Datenschutz. Die varianten von Threema oder meines sind für den Nutzer absolut nicht von denen von WhatsApp zu unterscheiden ohne dass er sich mit der Funktionsweise des Programms auseinandersetzt. => Sie können garantiert auch nicht Komfortabler sein --Fabiwanne (Diskussion) 00:39, 1. Mär. 2014 (CET)

Warum soll es nur um Datenschutz gehen? Es geht natürlich auch um Komfort! Ohne Übertragung der Telefonnummern (oder meinetwegen Mail-Adressen), lässt sich nicht ohne weiteres mit den eigenen Kontakten kommunizieren! Die Farbmarkierung in der Spalte sollte beide Aspekte (Komfort und Datenschutz) wiederspiegeln. Deshalb ist Optional die für den Nutzer beste Variante und bei Ja bzw. Nein hängt es von den Prioritäten des Nutzers ab. Zu sagen die eine Variante (Ja oder Nein) ist eindeutig die bessere oder schlechtere zeugt von ziemlicher Arroganz und wenig Verständnis für andere Nutzer und deren Bedürfnisse! Da wir hier in der Diskussion ja sehen, dass das Thema nicht so eindeutig ist, spricht viel mehr dafür die Ja und Nein Felder neutral (sei es nun grau, oder gelb) zu kennzeichnen und auf die Problematik im Text einzugehen. Wir können die Spalte auch in "Übertragung des Telefonbuchs zum Finden der Kontakte" umbenennen, dann wäre es vielleicht eindeutiger, allerdings ist das etwas zu lang. --42Agrajag (Diskussion) 02:28, 1. Mär. 2014 (CET)

Zusätzliche Spalte: Dezentrale Nutzung

Wie schon im Artikel vermerkt, wird von (zumindest einem) IT-Sicherheitsexperten bemängelt, dass Threema nicht auf einem eigenen Server installiert werden kann. Laut Artikel ist dies bei allen genannten Messengern der Fall, was aber meines Wissens nicht zutrifft. Xabber zum Beispiel ist ein Jabber-Client, und Jabber-Server können in der Tat individuell betrieben werden. --77.179.77.176 02:04, 23. Feb. 2014 (CET)

Uff, das größte Problem wäre erst einmal herauszufinden welche den überhaupt dezentral laufen. Die Tabelle hat noch viel zu viele Einträge mit "Unbekannt", erst einmal sollten wir uns darum kümmern! MfG --Dark-Water (Diskussion) 12:56, 24. Feb. 2014 (CET)

Ach du heilige Spalte

Langsam wird's eng ;-D Also entweder spalten wir die Tabelle in mehrere Tabelle auf (Allgemein, Verschlüsslung, Plattformen, Sonstiges) oder wir nutzen wenigstens Dicke Ränder für die Kategorien und schreiben rechts nochmal den Namen des Messangers hin. Aktuell muss ich schon ziemlich weit raus zoomen um die gesamte Tabelle zu sehen. MfG --Dark-Water (Diskussion) 12:02, 23. Feb. 2014 (CET)

Ja fände das auch gut. Zumindesst den Verschlüsslungskram sollte man rausnehmen. Da könnte man danna auch besser unterscheiden. --141.70.9.239 15:57, 23. Feb. 2014 (CET)

Da ich noch weiter BS ergänzen will, werde ich jetzt mal die BS in ne separate Tabelle packen. MfG --Dark-Water (Diskussion) 12:01, 24. Feb. 2014 (CET)

Wenn nicht relativ schnell jemand wiederspricht werde ich auch die Verschlüsslung rausnehmen So ne extra Tabelle:

!Messenger | Ende-zu-Ende | Client-Server | Authen­tifizierung | Abstreit­barkeit | PFS | unverschlüsselte Funktionen

Dann würde ich bei Bild­nachrichten, Gruppenchat und Asynchrone Kommunikation die gelben Felder raus machen und die fehrlende Verschlüsslung in der letzten oben genannten spalte eintragen. (nicht signierter Beitrag von Fabiwanne (Diskussion | Beiträge) 23:27, 27. Feb. 2014 (CET))

Zumindest Ende-zu-Ende verschlüsselung sollte in der Haupttabelle bleiben denke ich. Details wie Client-Server, Authen­tifizierung, Abstreit­barkeit und PFS kann man sicherlich ausgliedern --42Agrajag (Diskussion) 01:30, 28. Feb. 2014 (CET)

Finde ich gut, damit wird's insgesamt wieder übersichtlicher und auch die Pflege der Tabellen wird leichter, da nicht immer der gesamte Artikel angefasst werden muss. Wieso steht eigentlich das Inhaltsverzeichnis immer noch soweit unten ? MfG --Dark-Water (Diskussion) 13:16, 28. Feb. 2014 (CET)

Also Ende-zu-Ende und Client-Server Verschlüsselung würde ich in der Haupttabelle lassen und auch die Info, ob etwa Bildnachrichten ebenfalls verschlüsselt sind. Denn dies ist ja eine Einschränkung gegenüber der generellen Angabe der Verschlüsselung. Insgesamt sollten mE möglichst die wichtigsten Dinge in der großen Tabelle stehen nur Details ausgelagert werden. Die Verfügbarkeit für verschiedene Platformen finde ich sehr wichtig. Was nützt eine funktionale App, wenn ich mit iOS-Freunden nicht kommunizieren kann? Da ist es umständlich, erst in der weiteren Tabelle schauen und vergleichen zu müssen. Könnte man nicht eine Spalte für OS in ganz kleine Zellen teilen und dort einige OS, deren Unterstützung nur mit Farben kenntlich gemacht wird, aufführen? Falls es vom Platz her zu knapp wird, nur die OS, die am meisten verbreitet sind und Details dann in weiterer Tabelle. --95.91.226.167 15:07, 22. Mär. 2014 (CET)

Ich finde halt entweder man sortiert oder man lässt's sein. Aber Ende-zu-Ende Verschlüsslung und Transport verschlüsslung in verschiedene Spalten finde ich ziemlich unübersichtlich. --Fabiwanne (Diskussion) 17:59, 22. Mai 2014 (CEST)

VoIP Software

Da wurde etzt ne ganze Menge VoIP software hinzugefügt. Der übergang mag auch da fließend sein, ich weiß aber nicht wie sinnvoll das ist. (nicht signierter Beitrag von Fabiwanne (Diskussion | Beiträge) 16:13, 23. Feb. 2014 (CET))

Auch die Idee das unter "mobile Instant Messenger" abzulegen ist suboptimal ;) Schließlich gibts auch mobile Linux-Handys usw usf....--MilesTeg (Diskussion)

Mach' einen konkreten Vorschlag was du für sinnvoller hälst, und dann können wir darüber diskutieren. Aber hier nur einzuwerfen "das ist doof so" steht dem tatsächlichen Nutzen entgegen, den einige aus der aktuellen Auflistung ziehen. --Amenthes (Diskussion) 00:19, 26. Feb. 2014 (CET)

Ich verstehe nicht, was gegen eine Auflistung solcher Software spricht. Ist ein größerer Funktionsumfang und eine Plattformunabhängigkeit nicht eher von Vorteil? --LordOider (Diskussion) 22:22, 26. Feb. 2014 (CET)

Webseite von TextSecure

Bitte den Link zu Textsecure mit folgendem ersetzen: TextSecure (nicht signierter Beitrag von 77.5.191.71 (Diskussion) 00:05, 24. Feb. 2014 (CET))

Wer soll auch darauf kommen ;-) MfG --Dark-Water (Diskussion) 12:54, 24. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Dark-Water (Diskussion) 12:54, 24. Feb. 2014 (CET)

erledigtErledigt FeuRenard (Diskussion) 23:52, 21. Nov. 2015 (CET)

Third Party / Drittanbieter Apps abwerten?

Momentan sind in der Tabelle die Betriebssysteme gelb hinterlegt, die "nur" eine App eines Drittanbieters haben. Besonders bei den Open Source Lösungen mit spezifizierter API finde ich das aber gar nicht weiter schlimm? Ich finde es richtig, dass Offiziell/Inoffiziell getrennt aufgeführt wird, allerdings impliziert die Farbcodierung für mich schlechtere Qualität. Wie seht ihr das?--Amenthes (Diskussion) 00:26, 26. Feb. 2014 (CET)

Das Problem bei eigenen API's ist(hier geht es ja um Sicherheit) das sie erst einmal jemand intensiv und unabhänig prüfen müssten. Bei den bekannt Sachen OTR, SSL, TLS usw. wurde das ja schon ausreichend getan bzw. gibt es laufende Untersuchungen. Somit ist die Gelbe Farbwahl durchaus berechtigt. MfG --Dark-Water (Diskussion) 13:15, 28. Feb. 2014 (CET)

Hashes

Nachdem mir jetzt mehrmals wieder bei TextSecure und Threema eingefügt wurde, dass die Telefonbücher übertragen würden: Bitte lest euch das nochmal duch: Hashfunktion Hashfunktionen sind eben nicht bijektiv Deswegen kann garantiert nicht von einer übertragung die rede sein. Wenn die Anbieter (aus anderen grüden) Hashes nutzen anhand derer sich die Telefonnummern doch wieder raten (nicht bestimmen) lassen dann ist das ein anderes Problem. Und meinetwegen kann das Feld auch gleich bleiben. Aber man überträgt einfach nichs als Hash sondern dessen Hash.

Das ist wie ich jemanden mitbringe oder dessen Namen nenne. Natürlich kann von dem Namen mitunter auf die Person geschlossen werden. Aber der name ist nicht die Person. --Fabiwanne (Diskussion) 00:50, 1. Mär. 2014 (CET)

In der Theorie hast du mit Hashfunktionen Recht, allerdings nur bei einer genügend großen Menge an Eingabewerten. Das ist hier in der Praxis bei den Telefonnummern nicht der Fall. Der Datenraum der Telefonnummern ist viel zu klein, ca. 10^10 (https://whispersystems.org/blog/contact-discovery/). Das lässt sich per Bruteforce locker knacken. Da kein salt möglich ist, lassen sich sogar Rainbowtables bauen. Das heißt in der Praxis nunmal, dass es ein leichtes ist zu dem Hash auch wieder die Telefonnummer zu finden.

Und zu der Formulier: "dessen Hashes", klingt für mich einfach komisch. Ich wäre weiterhin für "als Hash" und habe das schon oft so gelesen. Und bei Textsecure wäre ich aus oben genanntem Grund für ein "Ja, " vor dem "hashes". Was sagen die anderen? --42Agrajag (Diskussion) 02:15, 1. Mär. 2014 (CET)

Also ich habe sowas noch nie gehört. Hier mal 2 Seiten, die mir google liefert: [5], [6] beide reden natürlich von Hashes von irgend was. (nicht signierter Beitrag von Fabiwanne (Diskussion | Beiträge) 03:21, 1. Mär. 2014 (CET))

Google liefert ebenso Ergebnisse für "als Hash": [7], [8] --42Agrajag (Diskussion) 11:29, 1. Mär. 2014 (CET)

Ja, wenn man ausdrücklich danach sucht. Insgesamt 9k Ergebnisse "hash des" OR "hash der" OR "hash von" dagegen über 30k. Edit: Such einfahc mal nur nach hash. Und gucke was da genutzt wrude. --Fabiwanne (Diskussion) 16:08, 2. Mär. 2014 (CET)

Es kommt auf die Sichtweise an. Die Übertragung erfolgt als Hashes (und nicht als (plain)text). Die Hashes werden jedoch von den Telefonnummern erzeugt (dessen Hashes). In diesem Fall ist "dessen Hashes" aber definitiv falsch, da "dessen Hashes" in der Tabelle sich auf die "Übertragung des Telefonbuchs" bezieht und daher impliziert, dass das komplette Telefonbuch als Hash übertragen wird (der Hash des Telefonbuchs). Das ist aber nicht der Fall. Jeder Kontakt wird "als Hash" bzw. der Hash des Kontaktes übertragen und somit ist diese Formulierung (als Hash) meiner Meinung nach um einiges sinniger. 188.193.252.141 01:17, 3. Mär. 2014 (CET)

Sehe ich auch so. Man könnte auch schreiben: "Ja, als Hashes der Kontakte" aber "Ja, als Hashes" ist halt kürzer.... --42Agrajag (Diskussion) 19:06, 3. Mär. 2014 (CET)

Wenn niemand was dagegen hat, würde ich das Problem lösen indem ich "Übertragung des Telefonbuchs" durch "Übertragung der Kontakte" ersetze. --Fabiwanne (Diskussion) 20:40, 7. Mär. 2014 (CET)

Ist doch alles vollkommen egal. Fakt ist das Hashes keinerlei Schutz bieten, man kann aus dem Hash die Nummer ermitteln. Also sollte das gar nicht erwähnt werden. Es verwirrt nur den Leser mit vollkommen überflüssigen Informationen. 88.70.33.162 15:01, 3. Mär. 2014 (CET)

PS: Selbst die Macher von TextSecure/Threema scheiben auf ihrer Webseite das Hashes nix Wert sind, also was soll das hier? Weg damit, das müllt nur die Tabelle voll. Ich denke wir haben hier das Problem das technisch interresierte sich gerne mal in Details verrennen die für den Normalnutzer absolut uninteresannt sind.
Es kann ja im Text noch nen kurzer Absatz über Hashes kommen, weil man liest ja öfter mal davon in Artikeln zu sicheren Messengern (dort fehlt dann oft der notwendige Hinweis das das nicht wirklich sicherheit bringt) und as würde dann als Aufklärung Mehrwert bringen. 88.70.33.162 15:15, 3. Mär. 2014 (CET)

Du hast Recht, man könnte die Art der Übertragung auch unten bei den einzelnen Messengern erwähnen. Das Problem ist, dass es keine praktikable Variante für mobile Messenger gibt das Telefonbuch abzugleichen um die Kontakte zu finden, ohne dass man dem Anbieter sein Telefonbuch anvertrauen muss (auch wenn die Kontakte bei einigen Messengern wahrscheinlich nicht gespeichert werden...) --42Agrajag (Diskussion) 19:06, 3. Mär. 2014 (CET)

Ja, ohne optionale Übertragung geht es nun mal nicht den komfort einer Kontaktliste zu bieten. Deswegen finde ich die Frage was übertragen wird viel interessannter (auch/gerade für die Leser des Artikels) als die Hashsache.
Werden nur die notwendigen Daten übertragen (je nach Feature eMailadresse und/oder (Mobil-)Telefonnummer) oder wird unnötigerweise mehr (Name (kann bei multi Client Messengern aber auch zu den notwendigen Daten gehören), Festnetznummer (wenn garnicht zur Identifikation unterstützt) usw.) übertragen. Wobei man hier bei Closed Source den Angaben des Herstellers vertrauen muss. 88.70.33.162 21:30, 3. Mär. 2014 (CET)

Natürlich geht das auch ohne. (Habe ich oben beschrieben.) Man muss nur von der relativ einfachen (und für den Hersteller angenehmen) Client-Server Infrastruktur weg. --Fabiwanne (Diskussion) 20:40, 7. Mär. 2014 (CET)

Egal ist das nicht. Der Server kann ggf. über Rainbowtables die Nummer ermitteln, dass ist richtig. Ich fühle mich dennoch trotz SSL wesentlich sicherer, wenn meine Kontakte nicht im Plaintext an die Server übertragen werden. Allein schon um möglichen MIM-Attacken nicht gleich mit Plaindaten zu beliefern (wir wissen ja alle wie "sicher" SSL ist, wenn eine CA gehackt oder ganz freiwillig dubiose Zertfikate ausliefert). Natürlich sind Hashes nicht sicher (und das sollte vielleicht in einem abschnitt als referenz erläutert werden) aber immer noch besser als das ganze im Plaintext zu senden. 188.193.252.141 23:27, 3. Mär. 2014 (CET)

Ja, aber das ist einfach zu irrelevant/technisch für die Tabelle. Weil sonst kann ja auch noch rein mit welcher Entwicklungsumgebung das Projekt übersetzt ist, weil das hat vermutlich auch Einfluss auf die Sicherheit. Und in welcher Sprache es geschrieben ist (Unterschiedlich anfällig für bestimmte Atacken). Und welche frenden Klassen/Units/usw. genutzt werden und und und. Interessiert hier doch nicht wirklich. Das ist was für nen Fachartikel über einen Messenger und nix für eine Übersichtstabelle.
BTW SSL: Dann muss aber unbedingt noch in die tabelle von welcher CA das genutzte Zertifikat ist und ob der System Zertifikatespeicher genutzt wird oder ob das Zertifikat im Programm gespeichert ist ;) Viel wichtiger als die Hashfrage, oder? ;) 178.3.131.156 15:34, 6. Mär. 2014 (CET)

Interessant, dass du dahinter einen Smiley setzt, denn Zertifikats-Pinning ("festnageln" auf das erwartete Zertifikat) ist in der Tat ein Sicherheitsfeature, das relativ wichtig und viel zu unbekannt ist. --Amenthes (Diskussion) 18:52, 6. Mär. 2014 (CET)

Das Smily war weil ich das jetzt keine ernsthafte Diskusion zum Thema wollte.
Mir geht es nur darum das es albern ist die Tabelle an einem Punkt mit uninteresannten technischen Details vollzumüllen. Wenn man damit anfängt... Ja, z.B. halt die Sicherheit für den Weg zum Server. Da nur zu schreiben SSL ist halt auch zu einfach (aber durchaus wichtiger als die Hashfrage)
Ich wäre für eine Spalte "Verschlüsselung" und darin "unbekannt", "von/zum Server", "Ende zu Ende" und "Ende zu Ende mit Schlüsselprüfung" (d.h. kann der Nutzer den Schlüssel des Gegenüber prüfen und passend markieren, sehr wichtig und auch oft übersehen). Dabei ne Fußnote bei allen Tabelleneinträgen "laut Herstellerangabe" dort wo man es nicht prüfen kann. Das ist doch erstmal das was dem Nutzer zur Sicherheit (d.h. welches Sicherheitskonzept verfolgt der Messenger) interessiert. Der Rest sind implementionsdetails die die Tabelle sprengen
Und zum Telefonbuch halt "Ja", "Ja, nur das minimal notwendige", "Nein", "Optional" und "Optional, nur das minimal notwendige". Weil das interessiert dem Leser doch erst mal. 178.3.131.156 21:09, 6. Mär. 2014 (CET)

Wenn du nur ja und nein hin machst muss bei TextSecure eben ein nein hin. Es bleibt nun mal schlicht so, dass das Telefonbuch nicht übertragen wird. Nur weil hier die Autoren finden, dass die Übertragung von Hashes ähnlich problematisch ist kann man doch nicht einfach falsches Zeug hier rein zu schreiben. --Fabiwanne (Diskussion) 20:40, 7. Mär. 2014 (CET)

TextSecure ist "Ja" oder "Ja, nur das minimal notwendige", muss man prüfen. TextSecure überträgt das Telefonbuch ja. 178.11.227.245 11:14, 8. Mär. 2014 (CET)

Nein, tut es nicht. --Fabiwanne (Diskussion) 12:26, 8. Mär. 2014 (CET)

Es spielt in der Praxis keine große Rolle ob die Nummern als Hash übertragen werden oder nicht. Die Textsecure Macher sind übrigens gleicher Ansicht, und die sollten es ja wohl wissen: https://twitter.com/whispersystems/status/440517660682366976 --42Agrajag (Diskussion) 15:48, 8. Mär. 2014 (CET)

Doch tut es. Und da der Quellcode offen liegt braucht man da gar nicht drüber streiten, das kann jeder sehen.
Und genau deswegen sollte der Technobabbel (z.B. so was wie "Hash" wo die meisten gar nicht wissen was das ist und deswegen die Infos falsch intepretieren) hier raus. TextSecure überträgt Daten aus dem Telefonbuch zum Server - Punkt, das ist die Info, alles andere ist Marketing BlahBlah und etwas über das sich die Freaks streiten können (Ist ja durchaus sinnig das als Hash zu übertragen, aber das ist ein unwichtiges (eines von vielen unwichtigen Dingen die man halt einfach machen sollte (aber das alleine nichts über die Sicherheit das gesamten Systems aussagt)) technisches Detail was den Rahmen der Tabelle sprengt). 178.11.227.245 20:33, 8. Mär. 2014 (CET)

--Konrad.reif (Diskussion) 11:14, 16. Sep. 2016 (CEST)== Es fehlen noch Messenger: ==

Unter anderem fehlt noch: eBuddy XMS (Link: http://xms.me/). Besonders hervor zu heben ist das man hier auch über ein https gesichertes Webfontend (Link: https://web.xms.me/#login-step1) komunizieren kann.

Mir fehlen in der Tabelle die Funktionen: Videotelefonie, Telefonie, sowie eine Abgrenzung in wie weit man darüber Daten tauschen kann. Einige Messenger begrenzen ja z.B. Größen oder Dateitypen. Bzw. eben eine kurze Liste der speziellen Besonderheiten. Wichtig wäre nämlich: Ich will eigentlich nicht jeden Messenger ausprobieren müssen, denn um die Messenger zu testen müsste ich diese installieren und dann hätten Sie schon meine Kontaktdaten. Selbst wenn ich die App dann wieder löschen würde.

Das Hangouts fehlt haben andere ja schon bemerkt. Da das der Google default Messenger ist der auf neuen Geräten meist vorinstalliert ist unbedingt nachtragen. Denn Google hat ja eh schon meist die Kontakte, warum dann nicht gleich diesen Messenger verwenden? Vorteile/Nachteile?

Weiterhin wäre interessant welche Messenger können Nachrichten zu mehreren Geräten parallel senden. Also das ich diese auf Smartphone & Tablet je nach Aufenthaltsort empfangen kann. Das das die Sicherheit aufweicht ist klar. Aber so lange der Transportweg sicher ist wäre mir das egal. Komfort kostet halt auch etwas Sicherheit.

Bitte alles mal aktualisieren gerade im WhatsApp Umschwung schauen viele auf die Seite. Da ich mich nicht groß weiter hier auskenne bitte an die entsprechende Stelle schieben. Danke! (nicht signierter Beitrag von 80.153.75.166 (Diskussion) 14:30, 11. Mär. 2014 (CET))

Wire ist in letzter Zeit ziemlich stark in den Medien präsent! (nicht signierter Beitrag von 130.239.188.95 (Diskussion) 22:46, 17. Mär. 2016 (CET))

Warum ist imessage nicht in der Liste enthalten? Ich beantrage die Aufnahme.--Konrad.reif (Diskussion) 11:14, 16. Sep. 2016 (CEST)

Es fehlen noch Messenger:

Unter anderem fehlt noch: eBuddy XMS (Link: http://xms.me/). Besonders hervor zu heben ist das man hier auch über ein https gesichertes Webfontend (Link: https://web.xms.me/#login-step1) komunizieren kann.

Mir fehlen in der Tabelle die Funktionen: Videotelefonie, Telefonie, sowie eine Abgrenzung in wie weit man darüber Daten tauschen kann. Einige Messenger begrenzen ja z.B. Größen oder Dateitypen. Bzw. eben eine kurze Liste der speziellen Besonderheiten. Wichtig wäre nämlich: Ich will eigentlich nicht jeden Messenger ausprobieren müssen, denn um die Messenger zu testen müsste ich diese installieren und dann hätten Sie schon meine Kontaktdaten. Selbst wenn ich die App dann wieder löschen würde.

Das Hangouts fehlt haben andere ja schon bemerkt. Da das der Google default Messenger ist der auf neuen Geräten meist vorinstalliert ist unbedingt nachtragen. Denn Google hat ja eh schon meist die Kontakte, warum dann nicht gleich diesen Messenger verwenden? Vorteile/Nachteile?

Weiterhin wäre interessant welche Messenger können Nachrichten zu mehreren Geräten parallel senden. Also das ich diese auf Smartphone & Tablet je nach Aufenthaltsort empfangen kann. Das das die Sicherheit aufweicht ist klar. Aber so lange der Transportweg sicher ist wäre mir das egal. Komfort kostet halt auch etwas Sicherheit.

Bitte alles mal aktualisieren gerade im WhatsApp Umschwung schauen viele auf die Seite. Da ich mich nicht groß weiter hier auskenne bitte an die entsprechende Stelle schieben. Danke! (nicht signierter Beitrag von 80.153.75.166 (Diskussion) 14:30, 11. Mär. 2014 (CET))

Wire ist in letzter Zeit ziemlich stark in den Medien präsent! (nicht signierter Beitrag von 130.239.188.95 (Diskussion) 22:46, 17. Mär. 2016 (CET))

Warum ist imessage nicht in der Liste enthalten? Ich beantrage die Aufnahme.--Konrad.reif (Diskussion) 11:15, 16. Sep. 2016 (CEST)

Übersetzer für Artikel TextSecure gesucht

Benutzer:Dodi 8238 sucht einen Deutschsprachigen, der den englischsprachigen Artikel TextSecure ins Deutsche übersetzt. Original-Post --Trustable (Diskussion) 00:16, 16. Mär. 2014 (CET)

„Hello! I am looking for someone who can help me translate the TextSecure article from English to German. I saw your activity on Liste von mobilen Instant-Messengern and thought you might be interested. If you are not interested, could you please help me find someone who might be? There seems to be a demand for information about TextSecure in Germany.[9] I have already added the article to Wikipedia:Übersetzungswünsche. Thank you! en:TextSecure de:TextSecure“

– Benutzer:Dodi 8238

Mittlerweile existiert der Artikel zum TextSecure-Nachfolger Signal (Software)

erledigtErledigt FeuRenard (Diskussion) 23:57, 21. Nov. 2015 (CET)

Abkürzung »verm.«

Wofür steht »verm.«? vermittelt, vermeintlich, vermutlich, ... (nicht signierter Beitrag von 88.73.54.122 (Diskussion) 16:07, 6. Apr. 2014 (CEST))

Vermutlich, denke ich. Wir können es durch "vermtl." oder "vmtl." ersetzen, oder? --92.196.2.126 11:45, 7. Apr. 2014 (CEST)

Threema/ECC

aus dem faq: "Die asymmetrische ECC-basierende Verschlüsselung, die Threema verwendet, hat eine Stärke von 255 Bits. Gemäss einer Schätzung des NIST (Seite 64) entspricht dies mindestens der Stärke von RSA mit 2048 Bits. Mittels ECDH (Curve25519) und einer Hashfunktion sowie einer Nonce wird für jede Nachricht ein einmaliger, 256 Bits langer symmetrischer Schlüssel hergeleitet, und die Stromchiffre XSalsa20 wird dann für die eigentliche Verschlüsselung der Nachricht verwendet. Zudem wird ein 128 Bits langer Message Authentication Code (MAC) zur Entdeckung von Manipulationen/Fälschungen hinzugefügt.

Für weitere Informationen über die Verschlüsselungsalgorithmen in Threema siehe Cryptography in NaCl."

NaCl ist eine offene library, die algorithmen sind standard. warum steht in der tabelle "eigenentwicklung"? --Mario d 18:31, 7. Mai 2014 (CEST)

Bitte ließ dier die definitition zu Eigententwiklcun durch:

„Das Verfahren wurde vom Hersteller selbst entworfen. Je nachdem, ob es überprüft wurde und was die Überprüfung ergeben hat, ist das Feld grün (kann als sicher gelten), gelb (keine Überprüfung) oder rot (Sicherheitsmängel wurden festgestellt) hinterlegt.“

Passt genau auf NaCl Kann überprüft werden wurde aber nicht. --Fabiwanne (Diskussion) 15:02, 22. Mai 2014 (CEST)

"Das Verfahren wurde vom Hersteller selbst entworfen." - das passt doch genau nicht. NaCl wurde nicht von Threema entworfen. wo ist der unterschied, ob jemand eine OTR- oder die NaCl-library einsetzt? --Mario d 15:21, 22. Mai 2014 (CEST)

Das DJB crypto bauen kann glaubt jeder. Ob threema das auch benutzen kann ist eine andere Frage. Oder: Ich nutze die glibc. => Da die glibc garantier eine der am sorgfältisgten geschriebenen libs ist is mein Programm sicher. (Such den fehler. :-) ) --Fabiwanne (Diskussion) 17:32, 22. Mai 2014 (CEST)

glibc ist keine krypto-lib. dass OTR sicher ist, glaube ich gerne. ob die apps OTR richtig benutzen, ist eine andere frage. wo ist da der unterschied? was ich damit sagen will: weder NaCl noch OTR sind eine gerantie dafuer, dass das fertige produkt etwas taugt. das koennen wir auch gar nicht beurteilen, wir koennen nur feststellen, dass standardbibliotheken verwendet wurden, was qualitativ etwas anderes ist als selbstgestricktes. darum geht es bei "Das Verfahren wurde vom Hersteller selbst entworfen." --Mario d 18:25, 23. Mai 2014 (CEST)

Die glibc stellt genau wie NaCl kryptografische primitiva zur Verügung (encrypt) aber eben keine fertigen verfahren. Verstehe nicht warum die glibc schlechter sein soll, nur weil sie noch andere nicht cryptografische Verfahren breit stellt. Im Gegenteil dazu ist OTR ein vollständiges Verfahren unabhängig von der Programmiersprache oder gar der verwendeten lib. Oder um es anders zu sagen wenn das Verfahren stimmt und de OTR, GPG oder TLS nimmt ist mir erstmal egal ob der OpenSSL, GNUTLS, Sodium, NaCl nimmt oder das selbst implementiert hat. (Solange es nicht bekanntermaßen Fehler enthält.) Wenn das Verfahren aber selbst erfunden ist, hilft es absolut nichts wenn das gut implementiert ist. Oder kurz auch ein noch so sauber implementierter Cäsar ist nicht sicher. Zumindest einen Autokey-Vigenère bekommst du garantiert auch mit NaCl implementiert aber dadurch wird das nicht sicher. --Fabiwanne (Diskussion) 22:25, 26. Mai 2014 (CEST)

was meinst du mit "fertigen verfahren"? NaCl hat crypto_box, ich weiss nicht, was du noch erwartest. wo ist da der unterschied zu GPG? hat glibc irgendwas ausser DES-CBC? was soll denn vigenere damit zu tun haben? --Mario d 15:38, 27. Mai 2014 (CEST)

crypto_box ist tatsächlich relativ Fehlerunanfällig. Aber mehr oder weniger alle Typischen Fehler können mit NaCl weiterhin gemacht werden: Ich kannte in erster Linie das Angebot an stream ciphers. (bzw. block cipher im ctr mode) Und die sind nicht ganz einfach zu Handhaben: Man kann die Authentifizierung weglassen, Schlüssel mehrfach verwenden... Defakto, kann man noch jede Menge falsch gemacht werden. Und vor allem: Threema sagt z.B. über Bilder dass sie AES-CBC nutzen. CBC gibt's in NaCl direkt nicht. => Threema nutzt eben nicht schlicht crypto_box sondern baut sich zumindest teilweise selbst was zusammen. --Fabiwanne (Diskussion) 02:16, 14. Jul. 2014 (CEST)

das mit AES-CBC ist interessant, hast du fuer die aussage von threema einen link? gilt das nur fuer bilder? wir muessen aufpassen, dass wir kein OR betreiben und klar formulieren, was wir aussagen. man kann auf vielen verschiedenen ebenen fehler machen, die benutzung von standardprodukten statt eigenentwicklungen schliesst davon nur einige aus. was sind die kriterien fuer "eigenentwicklung"? wir koennen nicht die sicherheit oder unsicherheit von produkten beurteilen, wir koennen nur die aussagen der hersteller und die von anabhaengigen experten wiedergeben. --Mario d 17:21, 14. Jul. 2014 (CEST)

ich bin eben ueber die seite https://threema.ch/validation/ gestolpert. mit den tools dort soll man ueberpruefen koennen, ob die nachrichten verschluesselt sind. ueber den schluesselaustausch steht dort nichts.

laut dieser beschreibung http://blog.jan-ahrens.eu/files/threema-protocol-analysis.pdf soll Threema etwas aehnliches tun wie CurveCP. was das genau bedeutet, kann ich noch nicht sagen, dazu muesste ich mir das mal genauer anschauen. --Mario d 14:26, 5. Aug. 2014 (CEST)

in entwicklung

in der tablle sind einige versionen als "in Entw." gekennzeichnet und gelb unterlegt. hat das noch einen anderen zweck als werbung? wenn es die version nicht gibt, dann ist es egal ob sie in entwicklung ist oder nicht. aus WP:WWNI #8: "Bei der Ankündigung künftiger Ereignisse ist grundsätzlich ein strenger Maßstab anzulegen, in der Regel sind solche Informationen für die Wikipedia nicht geeignet. Ankündigungen, die in absehbarer Zukunft liegen und von besonderer Relevanz sind, können aufgenommen werden, sofern sie durch besonders zuverlässige Informationsquellen (zum Beispiel Berichterstattung in Fachzeitschriften) belegt sind." ich sehe nicht, dass davn etwas zutrifft. --Mario d 21:52, 21. Mai 2014 (CEST)

Ich finde das eigentlich interessant. Aber die de.wikipedia handhabt es eigentlich so wie du es willst. Und es gab auch schon einige Streichungen. Deswegen schmeiße ich's mal wieder raus. --Fabiwanne (Diskussion) 17:46, 22. Mai 2014 (CEST)

feldfarben

ich finde die farbcodierung der felder irrefuehrend.

---

Die Spalte "Ende-zu-Ende" benutzt die folgende Klassifizierung:

• Nicht überprüfbar: Der Quelltext des Messengers steht der Öffentlichkeit nicht zur Verfügung, daher ist die Sicherheit der Verschlüsselung nicht überprüfbar und wird als unsicher betrachtet. Das Feld ist rot hinterlegt.
• Eigenentwicklung: Das Verfahren wurde vom Hersteller selbst entworfen. Je nachdem, ob es überprüft wurde und was die Überprüfung ergeben hat, ist das Feld grün (kann als sicher gelten), gelb (keine Überprüfung) oder rot (Sicherheitsmängel wurden festgestellt) hinterlegt.
• OTR: Das Off-the-Record-Protokoll kommt zum Einsatz. Das Feld ist grün hinterlegt.
• Keine: Der Messenger unterstützt keine Verschlüsselung. Das Feld ist rot hinterlegt.

---

"Nicht überprüfbar" ist also farblich so codiert wie "Keine". das ist natuerlich unfug. ob ein programm open- oder closed-source ist, wird bereits in einer eigenen spalte dargestellt. einem closed-source programm mit standardbibliotheken bringe ich mehr vertrauen entgegen als einem open-source mit selbstgebastelten algorithmen. hier sollte es darum gehen, was fuer verfahren anwendung finden.

---

Die Spalte "Client-Server-Verschlüsselung" benutzt die folgende Klassifizierung:

• Eigenentwicklung: Das Verfahren wurde vom Hersteller selbst entworfen. Je nachdem, ob es überprüft wurde und was die Überprüfung ergeben hat, ist das Feld grün (kann als sicher gelten), gelb (keine Überprüfung) oder rot (Sicherheitsmängel wurden festgestellt) hinterlegt.
• TLS: Das TLS-Protokoll kommt zum Einsatz. Das Feld ist grün hinterlegt.
• SSL: Das veraltete SSL-Protokoll kommt zum Einsatz. Das Feld ist gelb hinterlegt.
• Keine: Der Messenger unterstützt keine Verschlüsselung. Das Feld ist rot hinterlegt.

---

wo ist denn der grosse sicherheitsunterschied zwischen TLS 1.0 und SSL 3? das wurde bereits oben unter #TLS/SSL vs. SSL? angesprochen, allerdings ohne etwas zu bewirken. ich finde, wir sollten in beiden faellen einheitliche kriterien anwenden. mein vorschlag ist

---

• Keine: Der Messenger unterstützt keine Verschlüsselung. Das Feld ist rot hinterlegt.
• Eigenentwicklung: Das Verfahren wurde vom Hersteller selbst entworfen. Je nachdem, ob es überprüft wurde und was die Überprüfung ergeben hat, ist das Feld grün (kann als sicher gelten), gelb (keine Überprüfung) oder rot (Sicherheitsmängel wurden festgestellt) hinterlegt.
• Standardverfahren Standardisierte Verfahren (OTR, TLS) kommen zum Einsatz. Das Feld ist grün hinterlegt.

---

in beiden faellen anzuwenden. --Mario d 13:02, 3. Jun. 2014 (CEST)

ja, sehe ich genauso! --42Agrajag (Diskussion) 08:20, 4. Jun. 2014 (CEST)

ich habe das jetzt umgesetzt und dabei "Nicht überprüfbar" als "Unbekannt" klassifiziert. --Mario d 17:10, 14. Jul. 2014 (CEST)

Unterstützte Plattformen

da es dafuer einen eigenen abschnitt und eine eigene tabelle gibt, wuerde ich diese info aus der ohnehin sehr breiten ersten tabelle entfernen. ist jemand anderer meinung? --Mario d 17:55, 14. Aug. 2014 (CEST)

Deiner Meinung - sollte entfernt werden da redundant --Ulfb (Diskussion) 18:10, 14. Aug. 2014 (CEST)

erledigtErledigt FeuRenard (Diskussion) 12:53, 22. Nov. 2015 (CET)

Eigener Server?

Um sicher zu gehen: Diese Spalte bedeutet, das der Dienst einen eigenen Server betreibt, und nicht, das jemand anderes seinen eigenen Server einrichten könnte. Oder? --WichtelGnome (Diskussion) 23:24, 29. Mär. 2015 (CEST)

Habe ich mich letztens auch schon gefragt, als die Spalte hinzugefügt wurde (diff).

Ich nehme aber eher an, dass damit gemeint ist, dass jeder seinen eigenen Server betreiben kann. Die allermeisten Dienste verwenden so oder so ihre eigenen Server. Wohl eher nur wenige benutzen Angebote wie bspw. Google Cloud Messaging, wie es z.B. TextSecure tut. Daher wäre die andere Interpretationsmöglichkeit eher wenig sinnvoll.

Aber hat jemand eine bessere Idee, wie man diese Spalte benennen könnte? Mir fällt da nichts treffenderes ein. Grüße, --#Reaper (Diskussion) 20:18, 30. Mär. 2015 (CEST)

Wie wäre es mit "freie Server-Wahl" oder "freie Wahl des Servers"? Ich würde die Spalte mittlerweile so interpretieren, dass man seinen Server unabhängig von der Messaging-App wählen kann, so wie eben bei XMPP oder auch E-Mail. Der Logik folgend wäre bei Signal z.B. dann ein "nein" in dieser Spalte zu markieren. Um die Quelloffenheit eines Servers zu markieren, wäre dann eine weitere Spalte nötig. FeuRenard (Diskussion) 09:43, 18. Nov. 2015 (CET)

WhatsApp Verschlüsselung Gruppenchat

In der Tabelle ist angegeben, dass der Gruppenchat in WhatsApp nichtmal Client-Server-verschlüsselt ist. Ich denke, dass das nicht richtig ist, finde aber keinen Beleg dafür (oder dagegen). Oder wurde es vielleicht so angegeben, weil WhatsApp das gebrochene RC4-Verfahren benutzt? --Relantalant (Diskussion) 13:27, 26. Aug. 2015 (CEST)

Wenn alle die aktuelle Version haben ist der Gruppenchat genauso Ende-zu-Ende-Verschlüsselt wie die Einzel-Chats. --2003:73:CE24:6300:60BD:E828:5CE5:5221 11:24, 18. Mai 2016 (CEST)

OneTime Messenger

84.115.70.106 fügte "OneTime Messenger" hinzu. Dabei wurden alle Spalten mit Verschlüsselungsfeatures grün (Ja-Feld) markiert. Aufgrund der Informationen, die ich persönlich im Internet über den Messenger finde ([10] und die FAQ dort), kann ich diese Markierungen nicht nachvollziehen. Deshalb habe ich einige davon zurückgesetzt (auf Nein-Feld). 84.115.70.106 hat daraufhin seine ursprünglichen Markierungen wiederhergestellt. Darauf hin habe ich wieder Belege gefordert (und zurück-editiert). Die Antwort war wieder ein Edit, der die Markierungen wieder auf grün setzt. Und zack fertig: Edit-War. Das ist aber im Interesse von keinem hier. Genauso will ich aber auch keine aus der Luft gegriffenen Informationen irgendwo in der Wikipedia. Ich hätte gern eine Stellungnahme von 84.115.70.106. FeuRenard (Diskussion) 15:18, 25. Nov. 2015 (CET)

Ich habe die Seite auf deinen letzen Bearbeitungsstand mit dem Hinweis auf Belege zurückgesetzt und mit einer vorübergehenden Sperre für unangemeldet Benutzer versehen. Hadhuey (Diskussion) 15:23, 25. Nov. 2015 (CET)

Evtl. sollten die Felder auf auf unbekannt gesetzt werden? Hadhuey (Diskussion) 15:27, 25. Nov. 2015 (CET)

Das FAQ ([11]) sagt zur Frage "Why is messaging with OneTime secure?" folgendes: "Messaging with OneTime is 100% secure and private since the connections to OneTime servers are encrypted and therefore contents of messages are encrypted." Daraus lese ich, dass Client-Server-Verschlüsselung gemacht wird und sie das als ausreichend sicher betrachten. Im restlichen Text wird nur versprochen, dass der Server nichts speichert. Deshalb würde ich die Client-Server-Verschlüsselung mit "Ja" markieren aber nicht mit "TLS". Und beim Rest würde ich von "Nein" ausgehen. FeuRenard (Diskussion) 15:37, 25. Nov. 2015 (CET)

Sprachenunterstützung:

Weiterhin sollte ggf. die Tabelle um die Sprachenunterstützung erweitert werden. Da die meisten Deutschen nur deutschsprachige Anwendungen bevorzugen. Rein Englische Programme fallen bei mir z.B. durch. Es würde also eine Auflistung 'Deutsch' und 'Mehrsprachig' ggf. genügen. (nicht signierter Beitrag von 80.153.75.166 (Diskussion) 14:30, 11. Mär. 2014 (CET))

Bewertungskriterium "Mehrere Server-Anbieter"

Meiner Meinung ist bei der Bewertung von Kommunikationsplattformen auch wichtig, ob es mehrere oder nur einen Server-Anbieter gibt. Alle hier genannten Messenger, außer die beiden XMPP-basierten Messenger ChatSecure und Xabber, basieren jeweils auf einem Server-Anbieter. Man kann es auch als zentrales System bezeichnen. Für mich ist diese Eigenschaft ein entscheidender Nachteil, denn ich möchte selbst entscheiden, auf welchem Server meine Daten gespeichert werden bzw. sogar selbst einen Server betreiben. Als Kommunikationsplattform mit mehreren Anbietern fällt mir neben XMPP nur noch die E-Mail ein. Was ist eure Meinung dazu? --Trustable (Diskussion) 00:36, 16. Mär. 2014 (CET)

eigenentwicklung / ende-zu-ende

die felbfarben bereiten mir immer noch kopfschmerzen. haben wir klare kriterien, was eine eigenentwicklung ist und was nicht? was soll damit ausgesagt werden? geht es um das verfahren oder um die verwendung von bibliotheken? was ist mir geschichten wie SIMSme, wo die benutzer dem schluesselserver vertrauen muessen, der sie problemlos MitM-en koennte? ist das ende-zu-ende? die verschluesselung schon, das ganze protokoll eher nicht. --Mario d 10:29, 15. Sep. 2014 (CEST)

Whistle.im

Es werden keine kontakte gespeichert zum anmelden braucht man bei whistle nur einen namen und ein passwort das wars. Bilder nachrichten gibt es noch nicht. Abstreitbarkeit ja weil jeder benutzer einen eindeutigen finger abdruck bekommt so weiß mann ob man mit dem richtigen spricht wenn dann jemand mit einem Man in the middle angriff kommt dann ändert sich der fingerprint und whistle schlägt dann alarm das es ein anderer finger abdruck ist. Bei der ssl/tls verschlüsselung benuzt whistle PFS. (nicht signierter Beitrag von 176.116.153.21 (Diskussion) 10:44, 19. Jan. 2015 (CET))

Lemmaname

Was ist den die Liste von mobilen Instant-Messengern im Gegensatz zu Liste von Instant-Messengern? Ich bin dafür das "mobilen" rauszustreichen. 87.79.116.50 10:47, 20. Feb. 2014 (CET)

Instant-Messenger sind so Sachen wie ICQ, AIM, YahooMessenger, MSN ... die ganzen Sachen, die wir seit den 90ern auf einem PC nutzen. Die Mobilen Messenger sind allerdings auf eine Nutzung vom Smartphone ausgelegt. Die Übergänge sind stellenweise in der Tat etwas fließend. Eine zusammenlegung mit Instant Messaging fände ich allerdings ungünstig. Die Artikel sind doch sehr unterschiedlich aufgebaut. --Amenthes (Diskussion) 14:03, 23. Feb. 2014 (CET)

Ich würde das gerne nochmal aufgreifen: Wäre es nicht sinnvoll den Artikel in "Liste von Instant-Messengern" umzubenennen, schließlich kann man heute die meisten klassischen mobilen Messenger auch am Computer nutzen und die meisten ursprünglich für Computer entwickelten Messenger haben eine App für's Smartphone. --Jullit31 (Diskussion) 19:34, 5. Dez. 2017 (CET)

Riot

In die Tabelle könnte man auch Riot aufnehmen: https://about.riot.im/

• Freie Software: ja (Lizenz?)
• Ende-zu-Ende: optional
• Bildnachrichten: ja
• Gruppenchat: ja
• Async. Kommunikation: ja
• Federation: ja

--Feinstaub~enwiki (Diskussion) 12:27, 1. Dez. 2017 (CET)

Sicher, gerne. Füge ihn einfach im Artikel hinzu. Tipp: Der Visual Editor macht das sehr leicht. --rugk (Diskussion) 22:36, 3. Dez. 2017 (CET)

Die Lizenz wäre Apache 2.0, siehe https://github.com/vector-im/riot-web/blob/master/LICENSE --rugk (Diskussion) 22:37, 3. Dez. 2017 (CET)

erledigtErledigt --Jullit31 (Diskussion) 01:38, 3. Jan. 2018 (CET)

TLS/SSL

nach RFC 7525 (Best Current Practice) ist SSL in allen versionen veraltet. aktuelle TLS-implementierungen sollten SSLv2 und SSLv3 nicht unterstützen. ich schlage daher vor, die feldfarbe für SSL auf gelb zu ändern. --Mario d 14:03, 19. Okt. 2015 (CEST)

TODO

• Spalten in der Tabelle umsortieren (thematisch besser gruppieren)
• Texte sprachlich und inhaltlich überarbeiten
• Quellennachweise hinzufügen (nicht signierter Beitrag von Tanjeff (Diskussion | Beiträge) 09:21, 20. Dez. 2013 (CET))
• Infospalte ob Benutzername/Passwort frei heraussuchbar oder ob man die Handynummer nehmen muss. --E7 (Diskussion) 17:04, 6. Mai 2018 (CEST)

Whisperpush nicht mehr in CyanogenMod 13.0

Mit Version 13.0 R1 wurde „WhisperPush“ wieder ersatzlos aus CyanogenMod entfernt.[12]--Mideal (Diskussion) 14:52, 17. Mär. 2016 (CET)

erledigtErledigt --Jullit31 (Diskussion) 15:29, 8. Mai 2018 (CEST)

Google Hangouts

Hat es einen Grund, dass Googles Instant Messenger "Hangouts" hier fehlt? Den vermisse ich noch und ich wüsste gerne, wie dessen Eigenschaften sind. --79.252.208.159 15:36, 18. Dez. 2015 (CET)

Falsches Lemma (Übersetzungsfehler)

Die Bezeichnung "mobiler Messenger" ist eine grammatikalisch falsche und sinnentstellende Fehlübersetzung aus dem Englischen - denn beim ursprünglichen "mobile messenger" steht "mobile" nicht als Adjektiv zu Messenger, sondern als Substantiv für "Mobilgerät". Folglich müßte das Lemma hier sowas wie "Liste von Mobilgeräte-Instant-Messenger" oder "Liste von Instant-Messengern für Mobilgeräte" o.ä. lauten. NB: diese Fehlübersetzung kommt anderswo auch vor. Bitte (überall) bereinigen. Danke. --ProloSozz (Diskussion) 16:03, 5. Mai 2019 (CEST)

M.E. ist die Bezeichnung "Mobiler Messenger" eine gängige Bezeichnung und eine allgemeine Änderung wäre deshalb Übertrieben. Ähnlich wie "Handy". Das ist auch eine erfundenes Kunstwort. Richtig müsste es heißen "Mobiltelefon". --Webratte (Diskussion) 16:19, 5. Mai 2019 (CEST)

Sorry, dem widerspreche ich: die Bezeichnung ist zwar gängig, wird aber genauso häufig auch beanstandet. Wirklich etabliert ist sie nicht - insbesondere auch nicht vom Duden. --ProloSozz (Diskussion) 20:31, 6. Mai 2019 (CEST)

Als alternatives Lemma käme auch in Frage: Liste von Messengern für mobile Endgeräte. Das wäre dann die korrekte Definition. Alternativ schlage ich vor: Liste von Messengern. Das würde das Lemma für beide Arten öffnen. Also Desktop- und mobile Apps. --H7 ^{(Mid am Nämbercher redn!)} 17:32, 10. Mai 2019 (CEST)
PS: Das käme auch der Realität näher, denn viele Messenger sind ja auch für den Desktop verfügbar und ob die Trennung hier wirklich sinnvoll ist, glaub ich nicht so recht. Also eine Liste für alles und dafür ein kurzes Lemma? --H7 ^{(Mid am Nämbercher redn!)} 22:04, 25. Mai 2019 (CEST)

Von mir aus gerne - natürlich jeweils mit Angabe der Plattform, die ja dann auch direkt angibt, ob Desktop oder Mobilgerät ... :) --ProloSozz (Diskussion) 12:41, 26. Mai 2019 (CEST)

Telegram

Ich habe alle Quellen überprüft. auch wenn irgendwelche Leute behaupten es gäbe Telegram für Symbian oder andere JAVA ME Geräte stimmt dies definitiv nicht. BlackBerrys könnten sein, weil man da eventuell wirklich die Android APKs umwandeln kann. Der angebotene Download für "Telegram Messenger.jar" führt immer auf den [UC Browser|https://de.wikipedia.org/wiki/UC_Browser]. Der wäre eventuell fähig Telegram Web aufzurufen, aber es gibt für all diese JAVA ME Telefone auch keine inoffizielle App. (nicht signierter Beitrag von 194.191.253.50 (Diskussion) 22:25, 24. Jun. 2017 (CEST))

Informationen über Logging von (Meta-)Daten

In dem vergleichbaren Artikel der englischen Wikipedia (https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#Secure_messengers) werden Informationen zu den geloggten Daten in die Tabelle eingepflegt. Es wird festgehalten, welche Daten wie ((un-)verschlüsselt) gespeichert werden. Das wäre auch für den deutschen Artikel eine Bereicherung.(nicht signierter Beitrag von 77.185.215.212 (Diskussion) 20:01, 4. Jan. 2018 (CET))

Ring

In die Tabelle könnte man auch Ring aufnehmen: https://ring.cx/

• Freie Software: ja
• Ende-zu-Ende: ja
• Bildnachrichten: ja
• Gruppenchat: ja
• Async. Kommunikation: ja
• Federation: ja

(nicht signierter Beitrag von 77.182.50.9 (Diskussion) 14:17, 19. Aug. 2018 (CEST))

ICQ, IM+ und Whatsapp für Symbian

Sicher, dass diese Messenger für dieses Betriebssystem noch erhältlich sind? Auf den Webseiten ist davon nichts zu sehen. (nicht signierter Beitrag von 46.253.186.62 (Diskussion) 15:53, 11. Dez. 2019 (CET))

Briar

In die Tabelle könnte man auch Briar aufnehmen:

• https://briarproject.org/
• Freie Software: ja
• Ende-zu-Ende: ja
• Client-Server: Nein (Mesh)
• Authentifizierung: ja
• Abstreitbarkeit: ja
• PFS: ja
• Bildnachrichten: nein
• Gruppenchat: ja
• Async. Kommunikation: ja
• Übertragung der Kontakte: nein (derzeit nur per Gerät-zu-Gerät-Kontakt)
• Selbstgehosteter Server: nicht nötig, da ein Mesh-Netzwerk
• Federation: nein

--Zukunft (Diskussion) 19:17, 16. Okt. 2018 (CEST)

Du kannst diesen gern in die Tabellen einfügen, eine Artikelseite gibt es ja schon. --Wiki1939 (Diskussion) 14:28, 4. Jul. 2021 (CEST)

Hab Briar mit aufgenommen --Christian Nelke (Diskussion) 21:28, 8. Sep. 2022 (CEST)

@Christian Nelke: Benutzer:Zukunft schreibt oben, "Client-Server: Nein (Mesh)", und dass es keinen Server im Mesh-Netzwerk gibt.

• Aus welcher Quelle hast du, dass Briar dieses Verschlüsselungsprotokoll "MESH" für Client-Server-Verschlüsselung benutzt? Bitte gebe die Quelle als Ref. an.
• Mir ist das Verschlüsselungsprotokoll "MESH" nicht bekannt, kannst du bitte den Link zum Verschlüsselungsprotokoll "MESH" aktualisieren.
• Auch das Ende-zu-End-Verschlüsselungsprotokoll "Ja" ist mir nicht bekannt, ich habe es erst mal in "gelb unbekannt" geändert.
• In der von dir angegebenen Quelle für GPLv3 kann ich Briar nicht finden. Wo hast du das gefunden?

--Wiki1939 (Diskussion) 15:29, 9. Sep. 2022 (CEST)

@Wiki1939 Danke für die Hinweise, das war wirklich keine saubere Arbeit von mir. Schau gerne noch mal drüber. --Christian Nelke (Diskussion) 20:14, 18. Sep. 2022 (CEST)