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

111–120 of 242 posts

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

#111

Post by seba_dos1 »

CiPHPerCoder wrote: post #105
seba_dos1 wrote: post #103

Earlier quoted context omitted.

OMEMO and its implementation in Conversations has been security audited by an independent entity. Other than that, sure, you have no guarantees, yet it's still desirable for such critical security components to be free, or at least "open source".

> 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 that do right things. 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.

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

#112

Post by lvh »

seba_dos1 wrote: post #108
lvh wrote: post #107

Earlier quoted context omitted.

That's all fine but not responsive to my point. GP post said "but what if whatsapp silently hamstrings e2e overnight" -- my point is: what if my XMPP client/server does? EDIT: I previously said "turns off E2E", which I didn't say in my original referred-to post, and that's more misleading than "hamstrings", which is how the actual attack works.

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 :-)

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

#113

Post by lvh »

lrvick wrote: post #109
gaff33 wrote: post #85

Earlier quoted context omitted.

> Use WhatsApp to talk to normal people. Use Signal for nerds. This has been my go-to advice for a while now too! The key driving point is that amazing crypto is 100% useless if the person you're talking to doesn't use it, or uses it incorrectly. The only sticking point with the above advice is the nerds who think they understand crypto but don't and insist on you using some crazy app :/

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 :)

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

#114

Post by Boulth »

lvh wrote: post #102
Boulth wrote: post #80

Earlier quoted context omitted.

> It supports S/MIME. Do you want S/MIME? (You don't.) Could you provide your source? I've never seen S/MIME used in XMPP. Client certificates for authentication sure but not for E2E security. > It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand how those are different. OTR is being rolled back from clients in favor of OMEMO for good reasons: https://conversations.im/om…

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 players on the market. Look at what happened with HTTP2 and TLS 1.3: browsers basically used their powerful position to upgrade the security for the entire federated ecosystem. There are also other minor factors, such as tooling (SSL Labs) that incentivizes people to maintain their servers. And most certainly users of HTTPS don't need to understand how e.g. Certificate Transparency works, that's handled internally by their clients (browsers).

Of course there will always be a niche of low security clients, but who cares that TLS 1.2 doesn't work on some old Java?

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

#115

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…

Please make comments on individual cells for improvements to be seen/added more easily. This is obviously big research undertaking that got thrown together last weekend :)

> Another example: "open server" and "on-premise" says nothing about whether or not you really want to run one of those instances. It just says that hypothetically one could.

I know a number of people that run matrix.org servers for personal use and companies. The entire French government runs on riot.im/matrix.org.

When security and really privacy matters, you don't want a third party being able to push updates to your clients/servers at any time without warning.

> None of them implement even close to the privacy features Signal has implemented. But on this diagram it is clearly better because there is more green and less red.

What features specifically? Happy to add more columns if signal really has anything unique to offer here.

The things Signal gets red marks on are pretty fair though imo, and things others do better.

> Use WhatsApp to talk to normal people.

I think you will find many options above WhatsApp on the list in terms of security and privacy that have clients that are every bit as simple to use.

Other than their (very) effective marketing advantage, -why- would you encourage people towards these respective walled gardens instead of more open alternatives listed?

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

#116

Post by lrvick »

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

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"

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

#117

Post by saagarjha »

gaff33 wrote: post #89
rdtsc wrote: post #81

It's funny and sad that XMPP hits almost all of the points, has been around since 1999 and yet every year someone reinvents the wheel and makes another messenger system. There are what, about 60+ by now. Granted XMPP is not a messenger it's a protocol and a bunch of standards but still it's hard not to laugh.

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.

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

#118

Post by amandine »

electrograv wrote: post #30
proaralyst wrote: post #2

I would like to use Riot/Matrix but its UI (at least on Android) is terrible. I can't convince non-technical friends & family to switch. Part of the problem is the inability to assign nicknames to contacts, so you have to remember everyone's Matrix ID.

For me, the problem is how incredibly slow Riot is (and every other client I've tried has almost unusable bad UI, sometimes in combination with being slow). IMO: Text chat with a few emojis and images here and there should not ever be among the things that slows your computer to a crawl. EDIT: I'm speaking of the UI, not the network connection; the latter is sometimes slow too, but that's understandable

Just as well that we're working on it and released huge improvements yesterday! Think 70% reduction of memory use and dramatic reduction of launch time :) (https://medium.com/@RiotChat/riot-im-web-0-17-and-ios-0-7-6-... for the details)

We're still aiming for a full redesign of Riot.im to be out before end of the year, there should be things to look at at the end of the month, all crafted for the non-techy friends, so watch de the space!

And yes, the backend is not helping neither, although we've also done good progress on perf improvement there in the last months and still rolling new ones (e.g. Py3 being deployed as we speak and reducing server RAM by 3). Switching away from matrix.org can help, and agreed that a directory of public servers à la Mastodon could be interesting (although we would need to find a non-scary way to do so, lots of non-tech people would run away from it: they just want one click onboarding without having to understand what's happening behind the scenes). We've also soft launched a paid hosted offering, for 50-100 people teams who could do with their own DNS and faster servers at http://modular.im

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

#120

Post by craftyguy »

drdaeman wrote: post #59
cbg0 wrote: post #55

Earlier quoted context omitted.

The comments specify what "claimed" means: > Not possible to verify as application is closed source. Maintainer could compromise security at any time without detection. I think it's useful to have this differentiation, even though technically you could say E2E is TRUE for both of these.

Telegram’s state of source code availability (and whenever prebuilt binaries match that) is a total mess. I think only F-Droid build would qualify, but not the mainstream sources.

That argument goes for every floss app. If you download their binaries from a play store (that is not f-droid), there's no guarantee that what you get is the same as what the source code would produce. f-droid is not a 100% guarantee either (e.g. not all apps support reproducible builds), but it's certainly better than the mainstream play stores.
Post reply on HN