Hacker News Reader

Comment by jmnicolas | Hacker News Reader

Thanks for the laugh, you should write news title it would be fun!

Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example.

As the ex boss of NSA said "We Kill People Based on Metadata".

View on HN

But I already have a phone number. My friends already know my phone number. If I instead got a "nickname" it would be tialaramex of course, which is even more identifying than my phone number. If I chose a deliberate random pseudonymous "nickname" to avoid "metadata" - then nobody can contact me, what use is that?

The NSA may "kill people based on metadata" but XMPP produces far more metadata for such decisions than Signal.

XMPP encourages people to build clique servers, which fail a key security requirement "Don't Stand Out". The six other users of "Bob's 100% Preparedness Militia and True Patriots Server" may be quite sure Bob is trustworthy and won't rat on them, and maybe one of them only uses it to post funny GIFs of cats, but the loose metadata association between this group and a plot to kidnap a State Senator means all seven of them are targets anyway.

But if you try not to stand out by using a popular server, that server's operators have far more insight into you than Signal's server operators do. Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. I know, because I decrypted the message, but Signal does not. That's a bunch of heavy cryptographic lifting, but from their point of view it was worth it to improve privacy.

> Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that.

This seems wrong. How could the Signal server have relayed the message from Steve to you if it does not know the recipient?

They have a feature called "sealed sender"[1]. Your Signal client authenticates to a Signal service that verifies you, and then signs and issues a certificate that you can use to vouch for your identity.

Then, you can encrypt this certificate as part of your message. Then ask Signal to deliver your message to the recipient. The Signal server won't be able to tell the recipient the account that the message is from, but after the recipient decrypts the message they will see the signed certificate and know it was you.

The problem with this is, Signal is centralized and they see the both the IP address (and other metadata) when you contact them to obtain the certificate and they they also see the IP address you send the message from. Correlation between the two Signal-operated services would reveal your identity. Unfortunately we, as users, have no way to know that this is not happening.

[1]: https://signal.org/blog/sealed-sender/

At the time of reception, the Signal server knew that there was a message from a certain IP to a certain recipient. If the message was put in the queue, the originating IP was forgotten. Once the message is delivered, the recipient is forgotten.

EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal. As neighbor comments have said it still knows at that moment that a message from you is sent.

> EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal.

For a centralized service like Signal, your IP doesn't matter, they own your account, literally. You can randomize it as much as you like, and your peers may too, in the end it will not hide from them who sent a message to whom and when.

Nope. As we already discussed, Signal has no idea who sent messages with Sealed Sender. The recipient finds out who sent them a message, but Signal does not.

> Signal has no idea who sent messages with Sealed Sender.

Sorry to deceive you, but "Sealed Sender" is just an empty promise.

Even if you could assess that this is indeed what is being done server-side (and you won't, because Moxie will neither let you, nor will ever federate his server with yours in case you wanted to run your own Signal instance), this does nothing against the fact that every message still enters and exits Signal's walled garden. No amount of indirection in the middle will change that. You are back to trusting all intermediaries' good faith (which extend beyond Signal, btw, Amazon also controlling every packet that enters/exits its cloud on which Signal runs).

> Sorry to deceive you

Deceive implies bad intent, which you are not doing in this case. What you are actually doing is educating whereas Signal is the one technically doing the deceiving.

It does know the recipient it doesn't know the sender. They call this "Sealed sender" and it is enabled by default for your friends (but you can change who gets this facility).

So instead of a message from Steve to tialaramex, it's just a message to tialaramex. Well, duh, of course tialaramex gets messages, why else have message software?

My Signal client prepared some "stamps" which are good for one message to me. It gave Steve (and all my friends, or maybe only Steve, or maybe everybody except one troll, Signal can't tell and doesn't want to know) some of the stamps when sending them other things, and so Signal just sees the message has a stamp on it, no need to know who sent it.

Your Signal client is at this moment logged into a Signal account on the Signal server. Sealed sender does nothing to protect against this - Signal knows that tialaramex is at that IP address.

The server fully aware where Steve is logged in from, and sees a message come from there to tialaramex. On top of even that: you then reply back, server sees a message going to Steve, going straight back to the IP address where it already knows he's logged in from.

Another thing people don't consider is that Signal's core server infra is hosted at AWS... so Amazon can also peek into both this network traffic and also dump out that it's your Signal account (ie. phone number) tied to that IP from the EC2 instance's memory.

These folks showed that this sealed sender stuff is broken last year: https://www.ndss-symposium.org/ndss-paper/improving-signals-... (and there's an acknowledgment from the Signal team on page 3 of the PDF).

> Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example.

Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"?

And how about looking at more than just an isolated property of a competitor?

> As the ex boss of NSA said "We Kill People Based on Metadata".

XMPP servers are a gold mine when it comes to metadata.

> It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved.

Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. How many of your contacts who use Signal used their real phone number?

> XMPP servers are a gold mine when it comes to metadata.

Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.

> How many of your contacts who use Signal used their real phone number?

Most of them; however, there is no obligation to provide any personal data when registering a SIM card in my country. Even if providing personal data would be mandatory and if we assume that telcom providers track us all the time, then it doesn't mean that this data is accessible to the organization behind an instant messaging service.

> Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.

This ignores that Signal and XMPP don't process the same amount of metadata in the first place, and the de-facto centralization of the XMPP network (also stated in our article -> the majority of XMPP users only uses a small number of public XMPP instances, and these XMPP instances are hosted by a tiny number of companies in mainly three countries on this planet).

> Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place.

I believe the real reason Signal requires a phone number is that it is a pretty good anti-spam filter

You think you're making an argument against Signal, but you're in fact making the argument for it. The reason Signal deals in your phone number is precisely to keep them from managing databases of metadata about who's talking to who; the phone numbers keeps the social graph on the clientside.

Go look at RFC6121 Section 2 for one example of this. The point of Signal's design is that the server can't facilitate this kind of transaction, because it's unsafe for the server to keep that data in plaintext.

Reply on news.ycombinator.com