Live data from Hacker News

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

docs.google.com

211–220 of 242 posts

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

#211
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.

When Jan and I evaluated XMPP in 2009, we found that it was not very mobile friendly. To provide a couple of examples -- (1) The login path required an inordinate number of round trips (I think it was 4+). This slowed down login quite considerably. (2) XMPP is byte verbose and expensive on mobile networks. We came to the conclusion that XMPP was built for desktop computers connected to strong internet via LAN connect…

> We went on to invent our own protocol which was byte efficient and minimized roundtrips.

Completely understandable. And well, looking back it was the right decision. You definitely have solid proof.

Yeah as much as XMPP looks good on paper I don't think it will ever take over the messaging world. Even if the devices and the network capacity could handle the larger messages I feel developers don't really want to deal with XML standards. There were a lot of cool things in the 90's but XML wasn't one of them.

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

#213
post #116
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"

There are third-party-clients, reimplementing the crypto. But you are right, you don't know what the binary will do additionally.

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

#214
post #150

Interesting comparison Irvick. Enjoying the resuling conversation too. More detail on meanings and methodology would be helpful as some other HN folks suggest. Stealthy.im isn't mentioned (I develop that presently). Stealthy makes use of decentralized identity in the blockchain and a decentralized storage system called GAIA. Regular chat is E2E encrypted using ECIES. Currently released for Android and iOS.

[deleted]

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

#215
post #60

A missing column among the Features is if a system allows automation (chatbots or other). Notable examples: Telegram and FB Messenger do, WhatsApp doesn't (there are workarounds but they're mostly against the Terms of Service.)

Great suggestion. Will add this.

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

#217
post #100
post #73

Earlier quoted context omitted.

Fair enough, but this is kind of inherent for anything based on open standards. Was your email encrypted? It depends on whether the sending and receiving mailserver support TLS. Is your website visit perfect-forward-secret? Depends on whether your browser and the webserver support modern cipher suites. Is your DNS request encrypted? Only if your OS and your DNS server support DNSSEC or DoH. These are valid challenges…

How do I know my XMPP client is actually doing what it says? Are you saying the provenance for my XMPP client is fundamentally better than that of the WhatsApp app?

Well, there are different ways. If you want to know what your client is sending and you use your own server, then your server might be able to show you what it receives. ejabberd for example, lets admins inspect the stored offline messages. That way it is very easy to see if a message is encrypted or not. But you could also run a MitM proxy.

Another option is trusting audits or the developers. Last but not least you can inspect the source code of open source apps. So I don't know how deep you want to go with this, but for XMPP there are plenty of options to make sure the client does what it advertises.

Btw. I do not think that OMEMO is fundamentally better than WhatsApp does, as they are implementing the same protocol (Double Ratchet). The main differences are that one is an experimental public standard while the other is a proprietary protocol extension.

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

#218
post #64

Well, that is a protocol comparison. A client comparison would be much closer to the real world user experience. Don't get me wrong, I am a huge fan (and daily user) of XMPP, but the best protocol will not be of any use if the clients are too complicated or buggy to use. So yes, XMPP supports audio and video calls but finding two different clients which work on the first try together can be a challenge. Sometimes I w…

We have the XMPP Compliance Suites 2018[0] providing an overview of protocol-level specifications that a modern client or server should implement, and there was recently a nice article[1] for some example use cases. What is still missing is everything above the wire protocol level. The XSF, being the XMPP Standards Foundation, is guarding the protocols, and things like UX and client interoperability are considered as…

That looks pretty cool. Maybe I should ask SamWhited why they didn't include OMEMO, Audio and Video Calls as features as he is writing in this thread too :D

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

#219
post #192

Earlier quoted context omitted.

I audit tools myself, my employers, or partners consider and if I find obvious flaws then I file bugs for those products and generally we either don't use them or limit their use. I feel qualified only to certify that a tool is obviously insecure, but I don't think -anyone- will ever be qualified to solo certify something as totally secure. (but sadly that is how clean audits are generally read). I have in the past h…

I think you probably understand where I am coming from at this point. When I think about "audits" for secure messengers, I think about professional, specialized, contracted assessments with dedicated teams of experts (I'm a little biased, since that used to be my line of work). And my two objections to this discussion are: 1. I think LVH is right to point out that "audit" doesn't have much meaning in the document you…

I don't know that I made any extrodinary claims.

You did ask me if I audited things before and I answered honestly. I frequently report vulnerabilities in a range of open and closed systems and read a lot about those others find. I also don't consider myself an expert and generally distrust people that claim they are in this space because it is, as you say, really hard.

I initially started a spreadsheet to document the very high level objective traits of messengers I find useful and others found it interesting/useful and helped extend it.

It is far too much cognitive overhead to do deep dive evaluation of 75+ messengers, but what this list allows one to do is quickly eliminate services from consideration that lack features vital to address their use cases, platform targets, or threat profile: for instance the ability to self host, or end to end encryption.

From there once you have your short list, you can then make more effective use of time reading code, doing audits, reviewing audits of others.

If a list like this simply makes someone aware of new up and coming projects in the space, or old ones that have been quietly evolving in capability... then I feel justified in having shared it instead of having kept it as a private document of my personal notes.

I for one learned about a number of new projects when putting this sheet together, and interesting new approaches on solving these problems.

The thing that is pretty subjective about the list is how I sorted items based on my own research and threat profile.

I won't sit here and say Matrix or briar or any other items near the top are perfect, or lacks any security flaws. I personally place my bets on Matrix at this point based on my deep dive evaluation of it and similarly featured alternatives, but that is subject to change! Others are free to share your view that a well funded but closed source messenger like whatsapp is the general best bet.

To sober up on this topic a bit: Matrix has had glaring security flaws in the past, but also so have the options you personally recommend like Signal and Whatsapp.

At the end of the day all one can do is collect data, look over all the options, deep dive into the relative merits and claims of each to the extent one can, look at the research provided by others, and make a judgement call.

This list should be considered a starting point for research and a way to discover lesser known projects as it was for me.

It should -not- be seen as an end all "use this it is most secure" recommendation by any means. Anyone that looks at any one high level list of binary data points and makes an exclusive choice on that alone is doomed to shoot themselves in the foot with or without my help.

Hopefully that addresses your concerns about my intent here.

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

#220
post #177
post #114

Earlier quoted context omitted.

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?

HTTP/2 is federated in a sense that the network is composed out of heterogeneous nodes operated by different parties and these nodes communicate with each other (applications running on servers frequently act as clients accessing other HTTP servers).

If calling HTTP/2 federated bothers you I can rephrase my argument:

> Federated protocols can be made secure, if there are popular, secure by default players on the market. Look at what happened with the other IETF-standard protocol: HTTP2: browsers basically used their powerful position to upgrade the security for the entire 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).

Post reply on HN