Where's the "don't allocate 8 gigabytes and crash the system" feature? (Yeah Slack, I'm looking at you.)
Indeed, and for "compatibility" it doesn't really say anything about the quality of the software for that system. Signal, for example, doesn't have a native iOS app and it shows.
Messenger systems compared by security, privacy, compatibility, and features
171–180 of 242 posts
Re: Messenger systems compared by security, privacy, compatibility, and features
#172Earlier quoted context omitted.
but what happens when a state actor threatens to kill the family [...] No messenger system protects you against that. You seem to be going through the full sequence of well-known poor ways to evaluate the security of something like an instant messenger, starting with the feature matrix, going through 'it can't be secure if it's not open source/self-hosted/federated' and reaching the Mossad. Which is a worthwhile and…
I actually think it is. Journalists covering sensitive topics in sensitive areas -must- care about these questions. If you are using something anonymous, fully end to end encrypted with open source reproducible verified builds on decentralized servers, you can greatly limit the risk of having a central third party that can be compelled to act against your interests. Maybe in the US we don't think we need those sorts…
In fact: a huge portion of commercial vulnerability research and assessment work is done on binaries of closed-source products, and it has never been easier to do that kind of work (we're coming up on a decade into the era of IR lifters). Meanwhile, the types of vulnerabilities we're discussing here --- cryptographic exfiltration --- are difficult to identify in source, and source inspection has a terrible track record of finding them.
There's no expertise evident in the strident arguments you've made all over this thread (network security work is not the same as shrink-wrap software security work, which is in turn not the same as cryptographic security work --- these are all well-defined specialties) and it concerns me that people might be taking these arguments seriously. No. This isn't how things actually work; it's just how advocates on message boards want them to.
Re: Messenger systems compared by security, privacy, compatibility, and features
#173This is neat but it has plenty of flaws. I wish the definitions were spelled out. It says Signal isn't "anonymous", which I assume means "uses a phone number to find peers". And it has the usual feature matrix problem: sure XMPP "does E2E". But what does that mean? It supports S/MIME. Do you want S/MIME? (You don't.) It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand ho…
I'm not sure what the solution is, besides much more interactive and thorough presentation of features in a way that allows classification of how advanced they are or likely you are to need them, but that's a lot of work. Until then, a comparison like this will always suffer from rarely matching exactly what the reader is looking for. They do work well as quick references though.
Re: Messenger systems compared by security, privacy, compatibility, and features
#174This is neat but it has plenty of flaws. I wish the definitions were spelled out. It says Signal isn't "anonymous", which I assume means "uses a phone number to find peers". And it has the usual feature matrix problem: sure XMPP "does E2E". But what does that mean? It supports S/MIME. Do you want S/MIME? (You don't.) It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand ho…
That's always a problem with comparison charts when used to survey they field. The flip side is if they compare a bunch of features you don't care about at all, there's a bunch of red on some which makes no difference to you in real life, but now you either need to know what each esoteric feature means so you can ignore it, or just accept that the one with more red is probably worse and avoid it, even if overall it's…
Re: Messenger systems compared by security, privacy, compatibility, and features
#175Earlier quoted context omitted.
but what happens when a state actor threatens to kill the family [...] No messenger system protects you against that. You seem to be going through the full sequence of well-known poor ways to evaluate the security of something like an instant messenger, starting with the feature matrix, going through 'it can't be secure if it's not open source/self-hosted/federated' and reaching the Mossad. Which is a worthwhile and…
I actually think it is. Journalists covering sensitive topics in sensitive areas -must- care about these questions. If you are using something anonymous, fully end to end encrypted with open source reproducible verified builds on decentralized servers, you can greatly limit the risk of having a central third party that can be compelled to act against your interests. Maybe in the US we don't think we need those sorts…
Re: Messenger systems compared by security, privacy, compatibility, and features
#176Earlier quoted context omitted.
> Allo, whatsapp and other closed systems that give you no resaon to trust them other than faith in the people shilling them. Their claims can't be verified so they can only be marked as just that, claims. I have repeatedly refuted that point and you have repeatedly ignored it. > Sure, plenty of obvious flaws can be spotted without source code access, but many are hard to find even if you -do- have source code to the…
I changed the word "shill" in an edit right after I posted as that was unfair/unhelpful and realized you might think it was directed at you. It was not. I welcome this type of debate personally. > Do you professionally audit software? I do as a matter of fact. I'll be honest it is normally much easier in closed products as I know what to look for. It is generally much harder to find flaws in popular open source syste…
Re: Messenger systems compared by security, privacy, compatibility, and features
#177Earlier quoted context omitted.
S/MIME for XMPP E2E: https://xmpp.org/rfcs/rfc3923.html I am aware that OTR is being rolled back. My point is that extensibility is at odds with practical security and privacy for the vast majority of users. The people who need it the most do not understand the difference between OMEMO and OTR, but I can tell them to go install WhatsApp or Signal, give them a rough idea of why you want one or the other, and everythin…
Thanks for the link, it appears to be from 2004. > The people who need it the most do not understand the difference between OMEMO and OTR, For most of them there won't be any difference. Modern clients do not implement OTR so people will not even encounter the term and OMEMO is enabled by default so users don't need to bother with it. Federated protocols can be made secure, if there are popular, secure by default pla…
Re: Messenger systems compared by security, privacy, compatibility, and features
#178Regarding Wire, is not contact list stored on Wire's server? Then it is even less private than Jabber.
Re: Messenger systems compared by security, privacy, compatibility, and features
#179Are there any good XMPP clients that provide a "modern" messenger experience? For example seamlessly switching between online/offline mode, built in audio and video calls, sharing photos/videos.
Re: Messenger systems compared by security, privacy, compatibility, and features
#180This is neat but it has plenty of flaws. I wish the definitions were spelled out. It says Signal isn't "anonymous", which I assume means "uses a phone number to find peers". And it has the usual feature matrix problem: sure XMPP "does E2E". But what does that mean? It supports S/MIME. Do you want S/MIME? (You don't.) It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand ho…
Imagine, one of your contacts is captured; attackers get his contact list that includes you; then they get your phone number from Signal; then they get your location and put you to all kinds of black lists, extremists lists, no fly lists, watch lists and so on.
Signal is nothing better than Telegram. They should be on the same position.