Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com