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

151–160 of 242 posts

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

#151

Post by vader1 »

lvh wrote: post #107
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".

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.

The difference of course being that WhatsApp is closed source, and they can push any kind of change without anyone noticing.

If the client is open source, you can verify exactly what it does. Compile the app yourself or download it from F-Droid and you can be sure that the binary you get matches those sources.

Sure you can argue this all the way down to "Trusting Trust", but that doesn't really make sense when comparing two apps/ecosystems that operate in the same real world's constraints.

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

#152

Post by lvh »

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.

Since the author added a link to the Wire audit after I pointed out it existed, I think it means "third party has audited it and verified claims". On the other hand, they also still claim Telegram has been audited in this sense, which I have also pointed out and they have not resolved.

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

#153

Post by lvh »

craftyguy wrote: post #120
drdaeman wrote: post #59

Earlier quoted context omitted.

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.

As I've mentioned elsewhere: this is why you audit the apk, not the claimed source.

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

#154

Post by lvh »

vader1 wrote: post #151
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.

The difference of course being that WhatsApp is closed source, and they can push any kind of change without anyone noticing. If the client is open source, you can verify exactly what it does. Compile the app yourself or download it from F-Droid and you can be sure that the binary you get matches those sources. Sure you can argue this all the way down to "Trusting Trust", but that doesn't really make sense when compar…

As I've mentioned elsewhere: you do not need the source code to verify what something does, that's not generally how you'd audit this. Audits may be source-assisted, but you'd still bang at it from the actual binary. If you're more comfortable reading source and compiling from scratch then fine, do that: but we should not pretend that Conversations on the Play Store is generally more trustworthy than anything else because the source code is publicly available.

The random update bit is real! But also real for Conversations or whatever, and more real for small developers less likely to have their opsec in check. For the vast vast majority of people in this fashion WhatsApp is identical to Conversations and Signal.

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

#155

Post by lrvick »

lvh wrote: post #147
lrvick wrote: post #115

Earlier quoted context omitted.

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 an…

The care Signal puts in that actually makes it a better, more secure messenger is primarily about metadata management. Consider how long it took for them to implement profiles, how much time they took to explain how their contact discovery works, et cetera. These are not trivial matters: they got subpoenaed and had nothing to respond with, because they're tried extraordinarily hard not to.

These are problems other tools have solved, without having to resort to a walled garden network or having a SPOF.

Sure, maybe Signal has done some useful technicality -legal- protections for now for US citizens, but what happens when a state actor threatens to kill the family of a Signal employee if they don't ship a very subtle compromise in how their binaries source random numbers, or if they don't sell the metadata of who is talking to who.

Signal is not anonymous so that metadata alone could have real value. It is at the end of the day using phone numbers as identifiers. Sure they do SGX remote attestation but that has been demonstrated broken multiple times and won't stand up to a motivated physical attacker. Even if it -is- solid now, I would not underestimate how far a state actor will go. (As demonstrated by NSA wiretaps on google datacenters). Can they compel the right Intel employee to CA certify a manipulated enclave? Can they just get handed the key?

Also why would people outside the US trust the legal protections afforded to a US company to protect US citizens?

Their refusal to federate their network just creates a Lavabit sized target... and I have yet to hear any technical reasons for doing so particularly when, again, other projects have demonstrated end to end encryption and decentralization are not ast mutually exclusive as Moxie claims.

The idea that only Signal can do this right, and only if they keep it centralized on their servers, with them being the only people that can sign the binaries... is pure hubris imo.

There are a lot of alternatives we all should be carefully considering for the next -standard- for ubiquitious secure messaging.

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

#158

Post by dijit »

lucideer wrote: post #58
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.

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.

However; compiled versions and binary distributed versions would not suppport E2E chats together if there were any significant difference.

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

#159

Post by lvh »

lrvick wrote: post #155
lvh wrote: post #147

Earlier quoted context omitted.

The care Signal puts in that actually makes it a better, more secure messenger is primarily about metadata management. Consider how long it took for them to implement profiles, how much time they took to explain how their contact discovery works, et cetera. These are not trivial matters: they got subpoenaed and had nothing to respond with, because they're tried extraordinarily hard not to.

These are problems other tools have solved, without having to resort to a walled garden network or having a SPOF. Sure, maybe Signal has done some useful technicality -legal- protections for now for US citizens, but what happens when a state actor threatens to kill the family of a Signal employee if they don't ship a very subtle compromise in how their binaries source random numbers, or if they don't sell the metadat…

You asked "what valuable thing has Signal done" and offered to track them, and I responded with two examples. "What if someone threatens a Signal employee" is a moved goalpost. Who else has solved private contact discovery? Conversely: who else has solved Mossad as a threat model? I have repeatedly pointed out the Signal subpoena elsewhere, which is responsive to a number of your comments.

If your threat model includes Mossad, you're going to get Mossaded upon. You say "thinking only Signal can do this is hubris", but in the same breath suggest we're just carefully consideration of a standard away from being safe against Mossad threatening someone's kids. That's hubris.

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

#160

Post by pvg »

lrvick wrote: post #155
lvh wrote: post #147

Earlier quoted context omitted.

The care Signal puts in that actually makes it a better, more secure messenger is primarily about metadata management. Consider how long it took for them to implement profiles, how much time they took to explain how their contact discovery works, et cetera. These are not trivial matters: they got subpoenaed and had nothing to respond with, because they're tried extraordinarily hard not to.

These are problems other tools have solved, without having to resort to a walled garden network or having a SPOF. Sure, maybe Signal has done some useful technicality -legal- protections for now for US citizens, but what happens when a state actor threatens to kill the family of a Signal employee if they don't ship a very subtle compromise in how their binaries source random numbers, or if they don't sell the metadat…

but what happens when a state actor threatens to kill the family [...]

No messenger system protects you against that. You seem to be going through the full sequence of well-known poor ways to evaluate the security of something like an instant messenger, starting with the feature matrix, going through 'it can't be secure if it's not open source/self-hosted/federated' and reaching the Mossad. Which is a worthwhile and educational exercise but it's still not a good way to evaluate the security of something like an instant messenger.

Post reply on HN