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

201–210 of 242 posts

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

#201

Post by lvh »

codedokode wrote: post #198
lvh wrote: post #183

Earlier quoted context omitted.

That equivalence does not follow. The counterpoint is simple: can people figure out how to get burner numbers? Yes, they can: there are a myriad of services for doing so. And, importantly: journalists already know how.

First, that leaves a trace: location where you used that number to connect to GSM network (ok, there are also services receiving messages for you). Second, this is inconvenient: if you change your IP address or log out, the server will require you to provide a SMS code.

What? No, SMS is not a reauth factor in Signal, and the number doesn’t have to be physically proximate to you: you just have to receive a text message on it once.

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

#202

Post by lvh »

tialaramex wrote: post #196
codedokode wrote: post #181

Earlier quoted context omitted.

> No messenger system protects you against that. If the system doesn't have central server then it would become more difficult. You cannot subpoena a Tox network. Any messenger that requires and stores a phone number (read your real-world identity and physical location) is neither anonymous nor private. Also, a centralized messenger with a single server means that all traffic between all the users around the world go…

So that whole "it's all flowing though a single DC" thing for Signal - that has a name in this sphere. It's called "Don't Stand Out". When five people call the known mob boss you follow all of them. Maybe one is just a friend from high school. Another is the mob accountant, another an enforcer, you're getting leads. But what if it's five thousand people - now you can't follow them all, it's overwhelming. Knowing five…

You know what makes you not stand out? WhatsApp.

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

#203

Post by tialaramex »

lvh wrote: post #202
tialaramex wrote: post #196

Earlier quoted context omitted.

So that whole "it's all flowing though a single DC" thing for Signal - that has a name in this sphere. It's called "Don't Stand Out". When five people call the known mob boss you follow all of them. Maybe one is just a friend from high school. Another is the mob accountant, another an enforcer, you're getting leads. But what if it's five thousand people - now you can't follow them all, it's overwhelming. Knowing five…

You know what makes you not stand out? WhatsApp.

Indeed, and since it uses the Signal protocol I'd suggest it's the best option for a wide variety of practical circumstances.

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

#204

Post by saurik »

lvh wrote: post #144
saurik wrote: post #125

Earlier quoted context omitted.

Signal's stubborn insistence upon using Google Cloud Messaging (which is mostly notable due to their attempts to shut down third-party clients that remove this requirement) combined with its reliance upon phone numbers for identity is itself a serious problem, but when you combine this with the fact that their servers know "this phone number sent a message to this phone number at this time" (information that is even…

> "this phone number sent a message to this phone number at this time" (information that is even stored, at least temporarily, on their servers in order to implement rate limiting) This claim appears to be unsupported by both Signal's privacy policy and public evidence. Unless I misunderstand, they've claimed to use IP addresses for rate limiting. Messages only necessarily contain the recipient's identifier for delay…

You do realize that their code is open source, right? Here's the line of code that does exactly what I "claim": their message rate limiter implementation uses string keys that are constructed using the source and destination phone numbers.

https://github.com/signalapp/Signal-Server/blob/e26e383bd7a6...

Frankly, the fact that people like you believe so strongly that Signal doesn't do this should be damning for Signal, as it goes to show just how deceptive they are being about this issue: the reality is that Signal is quite careless with metadata :/.

(As for what you do instead, there are tons of trivial ways of making a secure messaging system that are better about metadata than Signal, and even ways that allow you to implement various forms of rate limiting. Signal is just being lazy here.)

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

#205

Post by jplayer01 »

saurik wrote: post #125
lvh wrote: post #113

Earlier quoted context omitted.

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

Signal's stubborn insistence upon using Google Cloud Messaging (which is mostly notable due to their attempts to shut down third-party clients that remove this requirement) combined with its reliance upon phone numbers for identity is itself a serious problem, but when you combine this with the fact that their servers know "this phone number sent a message to this phone number at this time" (information that is even…

It's always been possible to get a non-GCM version of Signal if you really wanted. And there are plenty of reasons to shut down third party clients that have nothing to do with the Signal team wanting to keep backdoors open.

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

#207

Post by lucideer »

dijit wrote: post #158
lucideer wrote: post #58

Earlier quoted context omitted.

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.

This isn't true. A trivial example of a significant difference in which they would still interoperate would be a binary distributed version which phones home the shared key.

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

#208

Post by lawnchair_larry »

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…

Signal using phone numbers is almost as anti-anonymous as you can possibly get. A phone number leaks nearly everything about you to anyone who has access to the right data sources. Most people would be more anonymous providing a SSN than a phone number in practice.

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

#209

Post by tptacek »

lrvick wrote: post #192
tptacek wrote: post #176

Earlier quoted context omitted.

You professionally audit secure messaging applications? For what kinds of vulnerabilities? I have turned down invitations to audit some of these applications because I didn't feel qualified to render an assessment (I've been doing professional software security assessment, of closed/open source applications, since 1996). Did you take money for those assessments? Which ones did you do? I'd like to take a closer look a…

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've produced; it gloms together assessments of wildly differing depth and quality and condenses them all to a single pass/fail.

2. Secure messaging security is hard, much harder than secure transports (which you alluded to in the other subthread when you mentioned TLS). There are in fact not that many people in the world who can do a proper cryptographic assessment of a messenger at this point (not because it's prohibitively difficult; it should be well within the reach of everyone with a graduate degree in cryptography who enjoys coding --- rather, just because it's a specialized skill set that not many people have an opportunity to get good at). Like I said: I wouldn't say I'm qualified to perform such an assessment (LVH, different story). And all that "just" gets you the cryptography! If your messenger gets popular, the framework it's built on becomes one of the most important targets on the Internet!

So I get itchy when people say things that amount to "I've audited things, I have an authoritative opinion about this stuff". Probably not? Maybe, but, like, if we were going to place a bet...?

You can turn that logic around on me. But I'm not the one making an extraordinary claim. You are. So: what really bugs me is the idea that this is a problem domain you can reduce to a Wikipedia-style comparison chart. That kind of chart will get people hurt.

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

#210

Post by tptacek »

lawnchair_larry wrote: post #208
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…

Signal using phone numbers is almost as anti-anonymous as you can possibly get. A phone number leaks nearly everything about you to anyone who has access to the right data sources. Most people would be more anonymous providing a SSN than a phone number in practice.

You just said the same thing LVH did, just with more emphasis.

It's tough to reason about on a message board. Signal does some important privacy things better than anyone else does; for instance, Signal cares more about metadata that I think any mainstream messenger does.

On the other hand, Signal made a conscious, deliberate choice to ensure that it works for ordinary users. It is not a goal of Signal's to mollify the tiny fraction of people in the world who have strong opinions about Tor; it is much more important to them that, say, any immigration lawyer in the country could readily pick it up and start using it.

The phone number ID thing creates an instantly bootstrapped social network. It solves a problem Signal actually cares about, while making a problem nerds care about a little more annoying. That is a reasonable reason not to use Signal (if you're one of those nerds), but, like DeVault's inane F-Droid conspiracy theory, not a reasonable reason to warn people off of Signal.

Signal, WhatsApp, Wire: any one of those is going to be radically better than the alternatives nonspecialists are likely to use (Fb Messenger, email). But my confidence drops rapidly when you go to anything else on this list.

Post reply on HN