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

131–140 of 242 posts

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

#131

Post by paulryanrogers »

pmlnr wrote: post #72
fyfy18 wrote: 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.

Cross platform, closed source, including Jingle (audio/video): http://astrachat.com/ Android (no audio/video): https://conversations.im/ Web: https://conversejs.org/ Web with extras: https://movim.eu/ Desktop (Mac): https://adium.im/ Desktop (Win): https://gajim.org/ (not sure about this) Desktop (Linux): http://pidgin.im/ (needs extras: https://petermolnar.net/instant-messenger-hell/#extra-plugin... )

Is Adium still maintained? Their version history link is broken.

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

#132

Post by jhammons »

jstanley wrote: post #130

What does "E2E Audit" mean? Or, why does Ricochet have a "false"? The Ricochet codebase has been audited, if that's what it's supposed to mean.

I think it means two parties can verify their public encryption keys with one another.

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

#133

Post by SamWhited »

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…

This isn't actually a thing anyone uses; I'm not aware of any non-commercial XMPP clients implementing it. It's just an attempt the IETF had a while back at standardizing E2E. It didn't really work, OMEMO has come much further.

And you don't have to explain the difference between OTR and OMEMO to anyone, just tell them to "Go use Conversations, it's on the Google Play store" and they'll be using OMEMO to speak with you.

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

#134

Post by SamWhited »

lvh wrote: post #122
saagarjha wrote: post #117

Earlier quoted context omitted.

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!

It's actually pretty easy to adapt to mobile, it may have been hard in 1998 when it was released, but these days with stream management (session resumption and TLS like packet counting) and message archive management (history and catchup) it's pretty great on mobile. The round trips to log in have also been significantly reduced (you'll incur a few more if you use SCRAM based auth, but there's always a trade off for security), though there are still a few of them for the most basic login. If you ignore TLS (which can come first so you don't have to do STARTTLS anymore) and do PLAIN auth (over TLS so it's fine) I think you have 3 round trips to login. That can be improved in the future with pipelining which has some experimental specs out.

See also: https://xmpp.org/extensions/xep-0286.html

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

#135

Post by lvh »

lrvick wrote: post #127
lvh wrote: post #124

Earlier quoted context omitted.

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.

This is not responsive to the core of my argument that nobody who actually audits and analyzes this stuff will tell you that source availability is necessary or even useful for figuring out if a particular application does what it says it does, unless you’re building the entire thing yourself off a trusted buildchain.

Even if you have repeatable builds you still audit what the thing actually does.

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

#138

Post by SamWhited »

XMPP is a protocol meant for building chat services; some of these others are chat services themselves so eg. it doesn't make sense to say that XMPP is not e2e by default (of course it's not, it's a protocol which may or may not be used to build an e2e encrypted chat service). Maybe that should be changed to "Jabber" which is what a lot of people call the public, federated network of servers built on XMPP these days? (The term has all sorts of other historical baggage and some people use XMPP/Jabber as synonyms, but mostly I think people use Jabber to refer to the public network these days and XMPP to the protocol, rather like email and SMTP).

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

#139

Post by jstanley »

jhammons wrote: post #132
jstanley wrote: post #130

What does "E2E Audit" mean? Or, why does Ricochet have a "false"? The Ricochet codebase has been audited, if that's what it's supposed to mean.

I think it means two parties can verify their public encryption keys with one another.

E.g. by comparing them in person? Ricochet can do that. The "Ricochet ID" is just a hash of the public key, so if you meet up in person and verify that you have added the correct ID for your counterparty, that sounds like you've verified the public keys, no?
Post reply on HN