Comment by lvh | Hacker News Reader

Comment by lvh | Hacker News Reader

Parent Full thread

> "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 delayed delivery but certainly does not imply they have a store of (src_phone, dst_phone, hires_timestamp) triples. When subpoenaed for user data[0], they claimed to have no responsive records of IP data, let alone src, dst _and_ hi-res timestamps altogether. Are you saying that has changed, they're lying in their response to the subpoena, they were lying in their privacy policy, or something else?

The issue of long-term identifiers for offline delivery is well-understood (e.g. Rottermanner05) but also not actually a Signal problem. In that light: what do you propose we do instead? (You can probably see the response coming already: let's just say metadata protection is, ahem, complicated.)

[0]: https://signal.org/bigbrother/eastern-virginia-grand-jury/

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

Well, shit: you're right.

I do realize that Signal is open source, yes (and I'm guessing from your phrasing you know I know that), but I don't feel a moral imperative to source dive every time someone says something weird. Putting that burden on the claimant seems pretty reasonable. This set of threads alone was exhausting enough without having links to GitHub with every message :-)

In particular: I interpreted your "stored (at least temporarily)" claim as in like, a logfile that's rotated daily or something. I think we can both agree that would be much worse than a 60 second leaky bucket and hence I interpreted that as more outlandish than what you intended.

But regardless, you're right: that's not how it works today, I read that code an extremely long time ago (when it was really just sender ID limited), and having both sender and receiver in plaintext is clearly worse than having just one, and having a leaky bucket with a timer is clearly a much higher resolution timestamp than the day previously claimed. I'm guessing the distinction is between what's stored and what's not? But I'm definitely uncomfortable and will make a note to follow up. In particular, now I would like to know under what circumstances that Redis cluster will attempt to persist. I think the answer is "never--it only has caches and the directory", but you've definitely shaken my confidence in that answer :)

Reply on news.ycombinator.com