Hacker News new | ask | show | jobs
by SheinhardtWigCo 2380 days ago
The point of this seems to be hiding the identity of users when they fetch or modify group attributes - but why? The user’s identity is otherwise known to the server: they know that account X was accessed by IP address Y, and that IP address Y fetched metadata for group Z, therefore account X is in group Z. They can also figure out group membership by tracking clusters of messages that are sent simultaneously. What am I missing?
1 comments

They do not know that information unless they’re monitoring on-the-server in the clear. They simply know they’re talking to Signal servers. This new feature protects in the case of Information Requests because they themselves don’t know who is in what groups.
You either have to trust the server operator not to keep logs, or assume they are keeping logs and _do_ know what groups you’re in. In either case, what is this fancy crypto scheme actually buying you?
The fancy crypto is what allows them not to (effectively) keep those logs in the first place. If you build this feature without the fancy crypto, then even if you say you're not logging this stuff, you (effectively) are, because your system depends on durable access to that metadata in order to function. This is, for instance, the major security difference between Signal and Wire.

One strong indication you have that Signal isn't logging this stuff is that they had to wait until they were able to advance the state of the art in anonymous credentials in order to implement group access control at all.

To verify the claim that my group message content is protected, I can examine the Signal client. I don’t have to trust the server operator whatsoever; I can independently confirm there is no way for them to see the content of my messages.

In contrast, I cannot verify this new claim that my group memberships are protected. I have to trust them.

I think you are basically saying: ‘well, they built all this crypto that is only useful if you believe they’re not logging, so I believe they’re not logging.’

No, what I'm saying is that without the cryptographic protections, a messaging provider can't claim not to be logging, because their serverside logic requires the log.

Prior to doing this cryptographic work, Signal simply went without having these features at all.

You're both right. The other poster's claim is that we cannot verify the code running on the server. They could support this new scheme AND just store every thing in plain text. We can only verify the interface is the same (because that's what we're using).

But you're also right it would be a long con to go without these features for so long, develop state of the art cryptography to add them securely and privately, then not use that.

> You either have to trust the server operator not to keep logs

You don't have to trust, you can verify. This has been proven in court: https://signal.org/bigbrother/eastern-virginia-grand-jury/