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.
3 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 
3 Likes
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?
For anyone curious about Signalâs further thoughts on this, hereâs a Github exchange between one of the authors of the paper and a Signal dev, detailing some of the complexities involved with implementing mitigations:
Link starts from the authorâs initial message; the discussion continues after the issue is closed.
As far as I can tell, this was the threadâs most actionable advice from Signal for concerned users:
For people who want to restrict delivery receipts, Signal already supports disabling phone number discoverability (Settings > Privacy > Phone Number > Who Can Find Me By Number). With this setting enabled, you can choose a random alphanumeric username and no one will be able to send you any messages (delivery receipts or otherwise) unless you share that username with them.
I donât understand the technical details of delivery receipts well but I believe improving client-side validation could be implemented in Signal clients without much difficulty and would go some way towards mitigating abuse of delivery receipts. Can anyone who knows the details of delivery receipts chime in?
Improve Client-side Validation. When messages are not E2EE, they can be validated by the server and only forwarded to the receiver when passing the validation. However, this server-side validation is not possible with E2EE, requiring more rigorous validation by the receiving client. For example, many of the presented attacks are not possible when clients properly validate the referenced message IDs and thus discard invalid messages (instead of acknowledging them via a delivery receipt). While our primary focus is on privacy-related issues, the shift from server-validated input to E2EE content is particularly important from a security standpoint. Parsing unvalidated data can quickly introduce severe security vulnerabilities.
For people who want to restrict delivery receipts, Signal already supports disabling phone number discoverability (Settings > Privacy > Phone Number > Who Can Find Me By Number). With this setting enabled, you can choose a random alphanumeric username and no one will be able to send you any messages (delivery receipts or otherwise) unless you share that username with them.
The suggested setting is intended to enable/disable contact discovery in the case someone already knows a Signal userâs phone number. Does disabling this really stop a stranger who already knows the targetâs phone number (or username) from extracting delivery receipts from their target using a custom client?