TLDR: you can use delivery receipts to track active time (like is the device opened, is app opened or just in the background, what user the device is on)
Quite interesting, also linked bellow is the paper mentioned https://arxiv.org/pdf/2411.11194
2 Likes
The title seems clickbaity and lacks detail which is why i assume this isn’t getting the attention it deserves on this forum. I’d maybe change the title to something more descriptive or reflect the title of the paper: Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers
To summarize his video, Signal and WhatsApp (potentially others?) are apparently vulnerable to a side-channel attack which allow anyone to determine:
- What devices you use
- How long you use them for (and by extension, your daily habits)
- Who you communicate with
- When you physically move
- When you’re on WiFi vs cellular data
- Times and durations of your phone calls
It’s important to note that:
- This can be done without indicating any suspicious activity to the user.
- This was reported to Signal and WhatsApp in September 2024. Signal has ignored it and WhatsApp released a questionable mitigation without comment.
- There are known solutions/mitigations to this issue Signal and WhatsApp could’ve implemented.
2 Likes
To begin with, I’ve always felt uncomfortable with Signal’s intended use of delivery receipts. They show senders when their contacts are online and when they are not, even when read receipts are disabled. Unfortunately these delivery receipts are not just for telling senders that their messages have been successfully delivered (to the server and then the intended recipient) but also appear to be functionally depended upon by the Signal Protocol.
The paper suggests some mitigations to abuse of delivery receipts, listed below. The descriptions are my words based on my understanding. See the paper for full and accurate description.
- Restricting delivery receipts: Dropping messages from unknown Signal users and not sending delivery receipts to them.
- Coarser receipt timings: Adding a small randomized delay before delivery receipts are sent by a client.
- Improving client-side validation: Since messages are E2EE and thus cannot be validated by the Signal server, clients should perform validation and drop invalid messages (for instance deletions for messages that are already deleted).
- Rate limiting: The Signal server could tighten rate limiting. A client that receives a flood of messages could warn the user about it and perhaps temporarily block the contact.
- Synchronized multi-clients: Having all linked devices synchronize their state between each other and then send just one delivery receipt, instead of multiple delivery receipts (one from each device).
- Harmonizing client behavior: Unifying the client codebases across operating systems to help mitigate fingerprinting.
However, all the above are all client or server mitigations, none of which Signal users can implement by themselves 
1 Like
In Signal, you do not appear to get delivery receipts for “spooky strangers”. Only when a msg request is accepted by the stranger will you then get delivery receipts moving forward.
What am I missing?
I’m not sure I understand your post. Did you mean receiving delivery receipts from strangers (non-approved contacts)?
The issue discussed in the paper is that strangers are capable of sending hidden or invalid messages to their targets in order to receive delivery receipts from those targets.
Correct, “spooky strangers” in the paper are contacts not in your address book. Regardless if valid, invalid, or hidden msg type - Signal does not appear to send delivery receipts to these strangers. Perhaps this behavior was changed by Signal since publication?
I hope so, but what evidence do you have that supports your belief that Signal does not send delivery receipts to strangers? Unfortunately it appears Signal’s release notes are almost meaningless.
The whitepaper and YouTube video is making the claim that Signal user’s can be tracked by defined “Spooky Strangers”. As an end-user layman I am unable to reproduce the findings within the whitepaper for the issue that most concerned me (Spooky Strangers). I’m not necessarily presenting evidence - I’m encouraging other users to attempt to reproduce the whitepaper’s claims because I am not able to.
Here is another thread on the topic. In this thread it was helpful to learn:
- Appears there has been a behavior change?
- Delivery reports are sometimes sent by the server, not the recipients device.
- Sealed Sender changes the behavior. This makes sense - If using sealed sender and the delivery receipt is handled by the device then the server cannot send a delivery report on the recipients behalf, right? The server does not know who sent the message to craft a delivery report to.
That’s good to point out if it has changed since, but if Daniel Boctor’s summary is otherwise accurate, this is still a very serious issue to ignore. It can’t be too hard to become someone’s Signal contact, especially when nearly all users are unaware of the privacy implications of accepting a contact.
Also there are many people (including journalists) who share their Signal as a preferred means of communication to the open internet and thus it’s impossible for those users to protect themselves by rejecting unknown contacts.
2 Likes
Thank you for the link to the Signal community forum thread. However, unfortunately the discussion doesn’t show Signal has patched the vulnerability, in fact it appears that so far they are in denial about the issue 
On one hand, the researchers who wrote the paper and presented at DEF CON demonstrated that “spooky strangers” can extract delivery receipts from any target user as long as they have their phone number (or perhaps username).
On the other hand, the person in the Signal community forum claims
You can only receive delivery receipts from a user if they’ve shared a profile key with you, by accepting a message request or being part of the same group chat.
These two appear to be in contradiction with each other. Of course other people should independently verify the research findings, but to me it looks like a demonstrated exploit versus words from the Signal community. What am I missing?