When the victim receives a malformed message it shouldnt call back to the server. This is a bug.

Remember, everyone has something to hide, something they don't want to be public.
If you disagree, please respond with your full name, date of birth, social security number, government ID number, credit card number, expiration date, and the number on the back.

plot twist - this is a feature. it will never get fixed.

Suggestions : add disabling phone number lookup, unifying timing, and block random accounts from messaging you unless you accept their message request like discord, it makes sure you don't respond to their messages, give read receipts, and don't respond with delivered

Thank you for your service in making this report!

The more I look into these privacy focused tools, the more I feel like the majority of them are honeypots designed specifically to attract persons of interest

there's an option in the android developer settings that allows you to completely turn off ALL background processes, but that's basically the nuclear option as far as android goes

I've been telling this for years. Only a few understands.

i think issues like this are due to arise when using centralized technology. the Laissez-faire response to the findings is a bit strange however.

I've always considered the phone number and Apple's push notification service to be major leaks as they are PII in every sense. The same is true of IP addresses.

This is CWE-208, CWE-213, arguably CWE-807, and arguably CWE-754... why the hell has it got no CVEs assigned yet?

A little addendum: This kind of side channel attack (which is actually data traffic analysis) can be done for any communicating device, as long as you have any way of observing the device's traffic behavior.
You see I did not use "phone" or "app" in the last sentence. That's intentional.
As long as the network between communicating devices is not fully controlled by the parties that want to communicate in a secure manner, which is never (!) the case for internet or mobile communication, people who can observe that traffic (be it live or via logs later) can always create the behavior profile described in the video.
I hope it does not need to be explicitly stated, who has those capabilities.
What could you do as a communication app developer, if you would like to fill in the little hole you can fill in, while you can't do anything about the big hole I described above:
If you do not want to remove your general purpose (sending messages between people) or reduce your receipt functionality (because those receipts actually make sense), you could permanently send random traffic to random targets. That would mask the actual communication to a good extent and make data traffic profiling impossible, because you're obviously always on and always communicating. Obvious big problem with this approach: You create a lot of traffic, which reduces the available bandwidth on the network paths taken and will cost your users money for as long as it takes before every provider would forbid that kind of use.
The same would work (with the same advantages and disadvantages) on the OS and hardware levels.
This is not a real option (as long as bandwidth and cost are an issue). Would modifying the timing help: Just a tiny bit, probably not really worth it.
What would help is: Checking for communication attempts from unknown sources and never responding to them in any way (including receipts), just presenting the fact that X (listing all identifying properties) tried to communicate to the receiver. As long as our Bob (the receiver) did not state: "Hey, that's Alice." to the App. the sender will not get anything back. Easy to implement. Helps for the specific apps communication pattern (just not against the overall possibilities of data traffic analysis of communicating devices).

They are definitely refusing to fix it because the spooks are leaning on them to keep it

This is less of an attack like a breaking and entering
and more of looking out the window to see when your neighbor is upstairs.
Even for people aiming towards 'air tight', there is such a thing as 'good-enough'

This might just be a weakness in the phone number system itself

By the way, some people like to promote Telegram as a safe alternative to WhatsApp, but Telegram isn’t end-to-end encrypted by default. You have to manually enable this option (which is somewhat hidden and unintuitively placed) for each individual chat. And even then, it only works in the mobile app. The Windows app doesn’t support end-to-end encryption at all.

Thanks to this video, I finally understand why chats in Telegram don't have delivery receipts, and why secret chats in Telegram don't offer multi-device support.

All this can be done and have been done already, without any of these app installed.

With a true backdoor into every device, that can just take your encryption keys.

I thought you said you’d show solutions