Extremely important side channel attack bug

[helloiamaperson3371]

Guidelines

• I have searched searched open and closed issues for duplicates
• I am submitting a bug report for existing functionality that does not work as intended
• This isn't a feature request or a discussion topic

Bug description

This is for all platforms.
https://arxiv.org/pdf/2411.11194

Screenshots

No response

Device

No response

Android version

No response

Signal version

No response

Link to debug log

No response

[skdza]

+1

[sailbird]

Perhaps people are afraid to open your link, OP, which goes to a PDF, but of course there are safer ways to do that.

For those who don't know, you're referring to an attack wherein the attacker sends lots of stealthy messages at high-frequency (on essentially any chat app) in order to get a read-receipt ping (meaning device-received as opposed to user-read, in this case). Then you have a sort of crude sonar device which can map out how many devices one has (I guess due to latency) and what times of day one tends to be on them. I tend to think this is pretty hard to hide anyway, but yeah it's still a leak and a debate deserves to be had about that.

Meanwhile, users can toggle:

Settings -> Privacy -> Read receipts
Settings -> Privacy -> Typing indicators

The compromise is that if nobody is allowed to see your read receipts then you won't be allowed to see anyone else's. I guess fair is fair. But now that you bring this up, I wonder what "Read receipts" actually means. Maybe there should be 2 toggles: device-received receipts and that plus user-read receipts.

While we're on the topic, I always thought that the checkmark scheme was too subtle for noobs to pick up on. I think it should be 3 distinct checkmarks, all in high contrast to the message bubble color. And even then, it's not immediately obvious that the first one means the Signal server got the message, the second one means that the user's phone and/or desktop got the message, and the whitening color change means that the user interacted with the message, such as tapping on it, and has therefore presumably read it. I just deduced this myself, hopefully correctly.

One way to have your cake and eat it too would be to keep a dedicated Signal Desktop peer online 24/7 with low connection latency, so the attacker would always get a device-received return ping with effectively no information in it. The fact that your phone then picks up the same message when it gets back online later shouldn't result in a redundant notification to the attacker (which would indeed be a gaping side channel); it should die at the Signal server which realizes that the second checkmark has already been sent. Of course there might be weird race conditions between the phone and the desktop, so in a perfect world, the desktop would be close to a Signal server and literally do nothing all day other than say that everything has been received as rapidly as possible.

Empirically, but unknown to me, Signal servers introduce random delays (from what probability distribution, I don't know) so that message-in-message-out correlations are hard to do, so that would at least somewhat thwart the attack, but statistics would probably reveal the same basic information eventually.

I'm usually not here but if you have more to add then I'm sure others will chime in. Good contribution!

[greyson-signal]

Please refer to the reply we made here: #14463 (comment)