Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

docs.google.com

Post reply on HN
Print view View original

121–130 of 242 posts

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

#121

Post by amandine »

lucideer wrote: post #41
John_KZ wrote: post #25

There still isn't a popular messaging and voice call platform that supports private end-to-end encryption by default. How terrible is this? I mean it would be so trivial to establish a secure and private communications standard. Europe and North America has a population of almost a billion people combined. If 500 millions of those live in first-world conditions and only 1% cares about privacy, with $1/year worth of g…

WhatsApp does but the author of this sheet has chosen to list it as "claimed", despite other also-unverified clients like Telegram getting a "true" for their (non-default) e2e support. FWIW I believe Riot/Matrix are planning e2e by default as soon as their implementation stabilises. Theirs is more complex/powerful than WhatsApp's though since they have multidevice support (which WhatsApp lacks). They've avoided makin…

Yup planning to get it on in the coming months. As a data point e2e by default is on for the French government deployment and we haven't seen huge drama, so we're mostly waiting to get the UX out. We'll be sharing our work for insights this week.

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

#122

Post by lvh »

saagarjha wrote: post #117
gaff33 wrote: post #89

Earlier quoted context omitted.

XMPP has a terrible user experience, which is why it's never caught on.

XMPP is a protocol; it doesn't have a user experience. Sure, it may have been difficult to adapt for mobile, but that doesn't mean it inherently has a poor experience.

This is silly hair-splitting. If it's "hard to adapt" to mobile then it's the protocol implying poor UX.

Fortunately, in XMPP country, we're always just a XEP away!

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

#123

Post by lrvick »

lvh wrote: 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…

> Wire has a real audit that isn't listed

Fixed

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

#124

Post by lvh »

lrvick wrote: post #116
lvh wrote: post #106

Earlier quoted context omitted.

Typo correction, but I can no longer edit: WhatsApp uses the Signal protocol, just with fewer of the privacy tweaks in the implementation. The criteria don't seem to consider those. They're important, but the two should be equivalent.

Whatsapp is closed source so we can't really verify any claims about it. It thus gets "claimed"

You can't validate anything about an open source project either unless you have repeatable builds. Real audits can be source-assisted, but do not rely on anyone pinky-swearing that this is actually the checkout that eventually produced the apk.

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

#125

Post by saurik »

lvh wrote: post #113
lrvick wrote: post #109

Earlier quoted context omitted.

Consider that security you can't possibly verify is just marketing. Maybe try listening to those nerds and try out some open alternatives with security that is possible to verify. You might be surprised to find both tools are pretty low on the list in respect to security and privacy compared to tools with smaller marketing budgets.

Could you elaborate how WhatsApp and Signal are not doing well from a security/privacy perspective? Can you name an alternative that does better under those criteria? I was under the impression that Signal precipitated most modern messaging protocol design and verification. But what do I know: I'm just a relapsed cryptographer :)

Signal's stubborn insistence upon using Google Cloud Messaging (which is mostly notable due to their attempts to shut down third-party clients that remove this requirement) combined with its reliance upon phone numbers for identity is itself a serious problem, but when you combine this with the fact that their servers know "this phone number sent a message to this phone number at this time" (information that is even stored, at least temporarily, on their servers in order to implement rate limiting) we really should not give Signal as much default credit as it gets :/.

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

#126

Post by CiPHPerCoder »

seba_dos1 wrote: post #111
CiPHPerCoder wrote: post #105

Earlier quoted context omitted.

> it's still desirable for such critical security components to be free, or at least "open source". Why the scare quotes? What about software's source code being available makes it more desirable for your non-technical users who will never modify their software?

Even though I'm not a "non-technical" user, I don't review crypto of my XMPP client. And that's fine, I know a few people that did and I trust them enough. This way I don't have to trust an entity that may benefit from being able to access my messages. Also, this is a fallacy. Just because "typical user" won't care or won't be able to do something doesn't mean we shouldn't strive to build and popularize platforms tha…

> Also, this is a fallacy.

What is a fallacy? I asked a question.

Non-technical users will never modify their software. The act of doing so would recategorize them as "technical". I don't see any fallacy here?

The most likely interpretation of your comment is, you're assuming an argument that I am not making.

> Just because "typical user" won't care or won't be able to do something doesn't mean we shouldn't strive to build and popularize platforms that do right things.

That's a disagreement with an argument I did not make.

> Of course it also has to be good at what users actually do care for to have any chance of taking off, but that's not the point.

What is the point, even?

I just asked how something being "open source" (to borrow the scare quotes) is more desirable to users who do not read/write software code? What is their incentive supposed to be to prioritize open source over proprietary software?

That's not an argument. It's certainly not a fallacious one.

> Even though I'm not a "non-technical" user, I don't review crypto of my XMPP client.

Little bit of background: I'm the sort of person who would review the crypto of an XMPP client.

> And that's fine, I know a few people that did and I trust them enough. This way I don't have to trust an entity that may benefit from being able to access my messages.

Cool, let's ask an trustworthy expert then. I can think of no finer expert to chime in on this discussion than JP Aumasson, one of the co-authors of SipHash and BLAKE2, who wrote the book Serious Cryptography and conducted many cryptography audits in his career.

https://research.kudelskisecurity.com/2018/10/02/open-source...

Oh.

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

#127

Post by lrvick »

lvh wrote: post #124
lrvick wrote: post #116

Earlier quoted context omitted.

Whatsapp is closed source so we can't really verify any claims about it. It thus gets "claimed"

You can't validate anything about an open source project either unless you have repeatable builds. Real audits can be source-assisted, but do not rely on anyone pinky-swearing that this is actually the checkout that eventually produced the apk.

I do agree reproducible builds are the only solution to have practical evidence a given binary came from given source code. F-droid does this, which is why I personally don't consider any clients that are not willing to undergo that rigor.

"AOSP" support in this context implies f-droid and implies reproducible builds, but maybe I should break that out more clearly.

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

#128

Post by lrvick »

LinuxBender wrote: post #76

There is no mention of Mumble (client) or Murmur (server). [1] From a privacy perspective, I find it superior to everything else. End-to-end voice encryption with PFS. As much or little server logging as you wish. Super easy to set up and scales to large numbers of people. I have a few of them running on VM's with 1GB ram. Only downside for me: It is not as happy-clicky (frictionless) as discord, yet. Authentication…

Added!

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

#129

Post by Boulth »

lvh wrote: post #112
seba_dos1 wrote: post #108

Earlier quoted context omitted.

If your server does, your client will notice. If your client does, the other party's client will notice.

Neither server nor peer will notice if you perform the serious attack: exfiltrate the plaintexts or key material and keep the OMEMO/Signal dance around as kabuki theater :-)

For paranoid users there is also an option of running their own servers and clients (both Prosody and Conversations are open source). XMPP at least provides that option and if you choose it you can still communicate with the rest of the ecosystem.

No such luck for Whatsapp and Signal. And although they may be fair now I think putting all eggs in one company's basket is a bad idea in general (see e.g.: Google).

Post reply on HN