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

51–60 of 242 posts

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

#51

Post by upofadown »

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…

Just pick an XMPP client that does:

* https://omemo.top/

There is no way that an open IM platform will be able to guarantee E2E by default on all clients simply because someone/somewhere will produce a client that doesn't or doesn't do it properly. It is probably better to start with the E2E encryption system (in my example OMEMO) and then see where you can get it.

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

#52

Post by nothrabannosir »

__david__ wrote: post #48
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…

Someone will correct me if I'm won't but I believe Apple Messages are end to end encrypted by default. I'm not sure if FaceTime audio/video is encrypted.

It is.

https://security.stackexchange.com/questions/123693/how-secu...

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

#53

Post by lucideer »

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

If you want to experience full speed Riot, you can choose a different server. This basically comes down to client UX: if server choice were more discoverable or if it at least didn't always default to the same one, then everyone wouldn't end up on a single overloaded server.

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

#54

Post by electrograv »

lucideer wrote: post #53
electrograv wrote: post #30

Earlier quoted context omitted.

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

If you want to experience full speed Riot, you can choose a different server. This basically comes down to client UX: if server choice were more discoverable or if it at least didn't always default to the same one, then everyone wouldn't end up on a single overloaded server.

I was primarily talking about UI lag, not network speed. Network speed was slow at times, but the worst above all was how laggy every keystroke is, every UI click, etc. and how much CPU it burns (heating up my laptop whenever it's open).

Native IRC clients for example have no such problem, and consume ~0% CPU at all times.

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

#55

Post by cbg0 »

lucideer wrote: post #37

As there's pretty obvious bias showing in the values, some methodology would be good to accompany this sheet. e.g. - Telegram: E2E Private: TRUE - WhatsApp: E2E Private: CLAIMED These are either both "true", or both "claimed". Pick one. In particular, what's the definition of the "Open Spec" column? Signal's GPL spec gets a FALSE here so I'm presuming the definition is something along the lines of "Spec produced by o…

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.

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

#56

Post by lucideer »

electrograv wrote: post #54
lucideer wrote: post #53

Earlier quoted context omitted.

If you want to experience full speed Riot, you can choose a different server. This basically comes down to client UX: if server choice were more discoverable or if it at least didn't always default to the same one, then everyone wouldn't end up on a single overloaded server.

I was primarily talking about UI lag, not network speed. Network speed was slow at times, but the worst above all was how laggy every keystroke is, every UI click, etc. and how much CPU it burns (heating up my laptop whenever it's open). Native IRC clients for example have no such problem, and consume ~0% CPU at all times.

> heating up my laptop

Aha, I was thinking of the mobile client, which is fine perf-wise imo. But yes, the Desktop/web client is very Slack-esque. Not in a good way.

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

#58

Post by lucideer »

cbg0 wrote: post #55
lucideer wrote: post #37

As there's pretty obvious bias showing in the values, some methodology would be good to accompany this sheet. e.g. - Telegram: E2E Private: TRUE - WhatsApp: E2E Private: CLAIMED These are either both "true", or both "claimed". Pick one. In particular, what's the definition of the "Open Spec" column? Signal's GPL spec gets a FALSE here so I'm presuming the definition is something along the lines of "Spec produced by o…

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.

Ah, thanks, I didn't see those comments. That makes some sense for the E2E actually. That's a very reasonable distinction.

Technically one could still argue the same for Telegram unless you're self-building given their source-release delays but that might be nitpick too far.

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

#59

Post by drdaeman »

cbg0 wrote: post #55
lucideer wrote: post #37

As there's pretty obvious bias showing in the values, some methodology would be good to accompany this sheet. e.g. - Telegram: E2E Private: TRUE - WhatsApp: E2E Private: CLAIMED These are either both "true", or both "claimed". Pick one. In particular, what's the definition of the "Open Spec" column? Signal's GPL spec gets a FALSE here so I'm presuming the definition is something along the lines of "Spec produced by o…

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.
Post reply on HN