Live data from Hacker News

Messenger systems compared by security, privacy, compatibility, and features

docs.google.com

171–180 of 242 posts

Re: Messenger systems compared by security, privacy, compatibility, and features

#171
post #18

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.

Maybe you meant that it doesn’t have a native macOS app? It is indeed an Electron app on macOS.

Re: Messenger systems compared by security, privacy, compatibility, and features

#172
post #168
post #160

Earlier 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…

None of this makes any sense. This reads like an argument from a parallel universe where the only sane option for end-users is Linux on the Desktop.

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

#173
post #45

This 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 a better fit for your needs. The extreme ends of this are simple charts where someone just tells you "good" or "bad" on one end, or pointlessly complex ones where someone adds bullshit fields like "experienced developers" or something like it.

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

#174
post #45

This 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…

I'm concerned that they don't work well at all: a number of highly important properties are missing and a number of the criteria have been challenged; see rest of thread.

Re: Messenger systems compared by security, privacy, compatibility, and features

#175
post #168
post #160

Earlier 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…

My point is not that this isn't of interest or important (especially to people who routinely handle sensitive information) but that your methodology is poor and it's poor in ways that have been reasonably comprehensively examined. As I said, it's still a worthwhile exercise and there's no law of physics that says you have to agree with existing consensus-y thought but your effort would be more serious if you're familiar with the arguments. You, on the other hand, just reinvented a threat model that has its very own funny paper.

Re: Messenger systems compared by security, privacy, compatibility, and features

#176
post #165
post #162

Earlier 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…

You professionally audit secure messaging applications? For what kinds of vulnerabilities? I have turned down invitations to audit some of these applications because I didn't feel qualified to render an assessment (I've been doing professional software security assessment, of closed/open source applications, since 1996). Did you take money for those assessments? Which ones did you do? I'd like to take a closer look at some of them sometime.

Re: Messenger systems compared by security, privacy, compatibility, and features

#177
post #114
post #102

Earlier 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…

In what sense is HTTP/2 or TLS 1.3 federated?

Re: Messenger systems compared by security, privacy, compatibility, and features

#178
I think Tox should be higher than Jabber. With Tox, there are no servers and contact list is stored on your device. With Jabber, it is stored on the server (and will be happily provided to NSA when needed). So unless you deploy your own Jabber server, it provides less privacy.

Regarding 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

#179
post #10

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

Conversations for Android and Monal https://monal.im/ for iOS.

Re: Messenger systems compared by security, privacy, compatibility, and features

#180
post #45

This 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…

Requiring a phone number means you have to disclose your identity (in many countries, for example in Russia) and your physical location (everywhere). This is the opposite to privacy and anonimity.

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.

Post reply on HN