Deleted on Signal or just hidden—Pavel Durov shares his concerns. The debate isn’t really about whether end-to-end encryption works; it’s about what your phone and its notification system may keep even after you hit delete.
What Pavel Durov is warning about: deletion vs. disappearance
When people hear a message was “deleted,” they usually imagine it vanished everywhere: from the app, the device, backups, and anything a third party could read. Pavel Durov’s concern cuts into that assumption. In practice, deletion inside a messaging app often means the app is no longer showing the content in the chat thread—not that every copy created by the operating system or other services has been wiped.
This matters because modern smartphones are designed to be helpful, fast, and searchable. Notifications, previews, widgets, and “recent items” features can momentarily store snippets of message content outside the encrypted conversation itself. If those snippets are recorded in logs or cached in memory, they can linger longer than users expect.
My personal take: privacy education is lagging behind UX convenience. Phones are optimized to surface information instantly, while secure messaging is optimized to protect content in transit. Those goals can collide in the messy middle—your device.
Push notifications: the overlooked privacy leak
Push notifications are often treated as harmless pop-ups, but they are a separate delivery channel with its own storage and behavior rules. Even if a secure messenger encrypts messages end-to-end, the notification your phone displays may contain text fragments that are handled by the operating system and notification services. That extra handling creates potential persistence beyond the app’s “delete” command.
A key nuance is that notification privacy is not fully under your control alone. You can disable previews on your phone, but the person you’re messaging might keep default settings that display full message content on their lock screen. The moment a message hits their notification system, it can be captured by screenshots, synced to wearable devices, or stored in logs depending on platform settings and enterprise policies.
The practical implication is uncomfortable: a message can be cryptographically protected in transit and still become exposed at the endpoint via previews. That doesn’t “break encryption,” but it can undermine the privacy outcome users think they’re getting.
Metadata, device logs, and what “deleted” can still leave behind
Even in the best-designed secure messengers, there’s more to a conversation than the text itself. Timestamps, contact identifiers, notification events, and system-level traces can reveal patterns. When investigators, forensic tools, or device management systems analyze a phone, these peripheral records may provide clues about what was said or at least when and with whom communication happened.
The big lesson is that privacy is an end-to-end experience, not only end-to-end encryption. If the phone’s OS stores notification history, if backups capture app state, or if lock-screen previews reveal message text, then the “surface area” expands far beyond the chat database. Deleting inside the app can reduce risk, but it may not cover every copy created elsewhere.
If you’re choosing a messenger for sensitive conversations, it helps to ask a more specific question than “Is it encrypted?” Ask: What’s stored on-device, what’s stored in notifications, what can be backed up, and what can be exported by the OS?
Practical steps to reduce exposure (without becoming paranoid)
Most people don’t need spy-level operational security, but a few settings changes can significantly reduce accidental leaks. The goal is not perfection; it’s lowering the chance that message content appears outside the encrypted thread.
Safer notification habits you can apply today
- Disable lock-screen previews for messaging apps (show “Notification” only)
- Turn off notification history/logging if your OS offers it
- Reduce wearable mirroring (smartwatch notifications can duplicate content)
- Use “disappearing messages” plus manual discipline: avoid sending highly sensitive text that could appear in previews
- Consider separate profiles/devices for high-sensitivity chats (work profile, secondary phone)
Also consider your counterpart’s device. If you’re discussing something sensitive, it may be worth a quick check-in: Are their notification previews off? Do they share devices? Are they using a managed phone controlled by an employer? It’s not romantic, but it’s realistic.
Finally, remember that screenshots exist. Even if notifications were perfect, humans can still copy content. The most secure message is the one you never send—so reserve high-sensitivity details for safer channels or in-person conversations when possible.
Decentralized apps gain users during bans—and why that trend connects to Durov’s point
In periods of unrest, internet restrictions, or platform bans, people often scramble for tools that keep communication alive. That’s where the rival keyword trend shows up clearly: decentralized apps gain users during bans because users want resilience—options that don’t rely on a single provider or a single point of failure.
This trend intersects with Durov’s concern in an important way: resilience and privacy are related but not identical. A decentralized or offline-capable messenger may help people communicate when networks are blocked, but it doesn’t automatically solve endpoint leakage. Even a clever mesh-based app can still display notifications, store local caches, and create logs. In other words, decentralization can reduce centralized data exposure, yet the phone remains a privacy battleground.
From my perspective, the “best” tool depends on the threat model. If your main risk is censorship and outages, decentralized or peer-to-peer designs may help. If your main risk is device seizure, then endpoint hardening and notification hygiene are just as important as the network architecture.
Choosing a secure messenger: what to evaluate beyond marketing claims
When comparing secure messaging apps, it’s tempting to look for a single winner. But the more honest approach is a checklist: encryption, on-device storage, notification behavior, backups, and how deletion works. Some apps excel at cryptography yet leave users exposed through default UX settings. Others prioritize minimal data retention but may be less user-friendly, causing people to misconfigure them.
A useful evaluation framework:
– Encryption model: end-to-end encryption by default, key verification options, forward secrecy
– Data retention: what’s stored locally, what’s stored on servers, how long metadata persists
– Deletion semantics: does “delete for everyone” truly remove content from devices or only hide it in-app
– OS interaction: notification previews, clipboard behavior, share sheets, backups, and crash logs
– Usability under stress: can non-technical contacts use it safely without special training
The uncomfortable reality is that privacy is often lost in defaults. If an app requires expert configuration to be safe, most real-world users won’t achieve the intended protection. The best security feature is the one that works even when people forget to toggle settings.
Conclusion: deleted on Signal or just hidden?
Pavel Durov’s concerns highlight a modern privacy truth: deletion inside a messenger can be real yet incomplete, because phones may store message fragments in notifications, logs, backups, or synced devices. That doesn’t mean secure messengers are pointless—it means the endpoint matters as much as the encryption.
If you want practical safety, start with notification previews, notification history, and backup settings, then think about your contacts’ devices and habits. “Deleted” should be treated as a risk reduction step, not a guarantee of disappearance—especially in a world where convenience features can quietly keep copies you never meant to save.
