They don't like to admit it, that is why the write a whole blog post about it? The app tells you when registering that is is about to send some contact information to the server and that it will not be stored.

Your criticism would be stronger with a list of examples and evidence they are unfixed for at least 6 months.

EDIT:

That metadata problem is essentially unsolved and unsolvable. No system is immune to metadata contact discovery at present.

For instance, https://ricochet.im/, is attempting to solve that problem by relying on the user to make the initial exchange securely. However, in reality, any method of relaying that to their contact point is vulnerable to discovery of that kind of metadata.

Phil Zimmermann gave it a stab:

https://github.com/SilentCircle/contact-discovery

I suggested this to Moxie, he said "it's not meaningfully privacy preserving", but there wasn't any more detail.

> "As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem."

This reminds me of an idea I had which I would love for people to tear apart (I know that the obvious bandwidth problem makes it completely impractical, but I wonder if there are theoretical flaws):

Have a central server which everybody connects to. All clients send a constant stream of data, 24/7 - if they don't have anything useful to send, they send /dev/random. When they do have something to send, they send a GPG public-key-encrypted message. Every client then receives the entire stream of data, handles the data which it can decrypt using its private key, and discards the rest.

- Your contacts list is a GPG keyring - The server knows nothing - Anyone intercepting your internet traffic can't tell where your packets are destined for - You can't even look at two people's traffic patterns and say "these two people were active at the same time, they must be talking to each other"

You don't even need a central server for that. Just set up a p2p network and have all peers broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on. (And, of course, they try to decrypt everything in the meantime to see if any message is meant for them.)

(¶) I think you could do without sending random data unless network consists of only two active peers and your adversary taps every single internet link. (As in, even the cable underneath the street in front of your house.) If he doesn't, broadcasting your message to your (physical) neighbors would likely be enough to obfuscate the message's origin.

Anyway, the idea of broadcasting / flooding to protect metadata is not new. See, for instance, Bitmessage and Ethereum Whisper. If you ask me, though, (and you mentioned that, too) the traffic and performance issues originating from broadcasting and brute-force decryption make this approach rather impractical to pretty much impossible – at least if you want this to work for the masses. (Even if it's just for text messages, not cat pics or anything.)

>broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on.

That sounds like a great way to DDoS everyone using it and every network in between.

Well, there're obviously a lot of things you could improve to lower the chances of a DDoS. (E.g. introducing a TTL / maximum number of hops for a message or forwarding some messages only to some peers, thereby influencing the exact way messages are routed through the network.) But I agree it doesn't look like the most viable idea for a medium for mass communication, not even if it's just for high-latency messages. Yet, people are working on it.

I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon!

[1] https://github.com/Nutomic/ensichat

/dev/random has a nonzero chance of emitting a valid GPG public-key-encrypted message. How does the server tell the two apart? How do you make sure that an external watcher can't tell them apart?

Do you have time to share more details on Signal's metdata problem, especially if you have any ideas about what they could do to solve it?

Is this something that is going to require a Tor-like approach to even have a chance of fixing?

Privacy-preserving contact discovery and obfuscation of a message's metadata (what Tor can be used for) are pretty much orthogonal issues:

The first case is about finding out who of your contacts uses Signal, too. The way it's done in Signal right now is described here: https://whispersystems.org/blog/contact-discovery/.

The second problem is about whether anyone gets to see who is sending messages to whom, e.g. by tapping the wires or running the central server all messages are being routed through (for instance, Signal uses such a server).

In both cases, your social network might get get exposed depending on what data is exposed exactly (IP addresses, pseudonyms, …) and what the attacker can infer from it (your name / home address?).

Let me know if that helps.

NSA only knows then that somebody with that phone number is using Signal ... so what?

They would find out anyway b/c your packets are sniffed on a regular basis and so they know your phone is communicating with the Signal server and maybe the packets itself are characteristic.

So in my humble opinion this criticism is irrelevant.

Isn't the criticism that Signal maps your contact metadata?

An inside man is much easier for NSA than all that expensive world wide data collection. (Of course, in reality surely they do both.)