Your phone buzzes on the table. You glance at it — or, more honestly, the person sitting across from you glances at it — and the screen reads the first words of a message that was never meant for them. For most messengers, that’s not a bug. The notification text is a product feature: the more of the message it shows, the more useful the app feels. Somewhere between “your chat is encrypted” and “your screen is face-up”, the words quietly end up in plain sight.
This is the quietest privacy leak in modern messaging, because almost nobody calls it one. The conversation is end-to-end encrypted, so we stop thinking about it. But the notification is a copy of the message that travels outside the encrypted channel — written in plaintext by the platform’s servers and printed on the most public screen you own. If you care about who holds your conversations, the lockscreen is where that question stops being abstract.
The leak nobody counts as a leak
When someone sends you a message in a mainstream messenger, two things happen. The encrypted copy goes to your phone. And the platform’s servers — which for many apps can read your messages — compose a push notification and ship it through Apple or Google’s push networks, in plaintext, to be displayed on your lock screen.
That push has two homes, and both are outside your control:
- On the platform’s servers. The notification text is a plaintext copy of your message, generated and stored by the company that runs the service. Whatever that company does with message content, the notification is content too.
- On your lock screen. The notification is shown to anyone within reading distance — a colleague leaning over, a stranger on the train, a partner glancing at the table. You didn’t choose to publish it; the vendor’s default did.
Encryption is supposed to protect the words. But the notification re-prints the words in the one place encryption doesn’t reach. It’s a metadata leak with the actual content attached — a billboard mounted on the front door of your private conversation.
What a server that can’t read should mean for a push
Here’s the interesting part. In a sovereign messenger, the server cannot read your messages at all — it stores and routes only ciphertext. So it physically cannot put your words into a push notification. The server has nothing to leak, because it never had the plaintext in the first place.
That single fact changes the shape of the whole system. When the server pushes an encrypted message, the push itself carries ciphertext — the same encrypted form that’s stored in the archive. The notification isn’t a plaintext copy of your message. It’s a handle that lets your own device, and only your own device, decrypt and display the message — on the client’s terms, not the vendor’s.
That’s the difference between “the platform shows your message on your screen” and “your client decides when you can read it”. The first is a broadcast. The second is a private decision made on hardware you hold.
Strict outside, cozy inside
The latest Infium release — v0.9.77 — is where this gets concrete. When an encrypted message arrives on iOS and your device is locked, the notification shows “New message” and nothing else. No sender, no preview, no first sentence of a fight or a confession. The lock screen is treated as public space: strict on the outside.
The real text appears as soon as you unlock the device — Touch ID or Face ID. The notification that said “New message” becomes the actual message, in place, without you opening the app. The unlock is the moment you’ve confirmed you’re alone with your phone, and only then does the text exist for anyone’s eyes. Cozy on the inside.
You stay in control of the trade-off in both directions:
- A system-level switch. Settings → Notifications → Infium → Show Previews on iOS controls the same behaviour from the OS side.
- An in-app toggle. Infium’s own setting, Show message text in notifications, is on by default — the message text appears while the device is unlocked. Turn it off and the text is never shown, and your encryption keys never leave the app at all: the notification extension isn’t even given the means to decrypt.
None of this is a workaround. It’s the honest consequence of the architecture: because the server holds only ciphertext, the client is the only component that can produce readable text, and it only does so when you’re actually there to read it.
The lockscreen as a sovereignty test
People usually judge a messenger by its big promises — encryption, no ads, no data selling. But the small surfaces are where those promises actually get tested, and the lockscreen is the smallest, most frequent one. The small fixes are exactly where sovereignty is decided, and notification privacy is a sharper test than most, because it’s the one place where even a privacy-focused app can default to broadcasting your words.
Notice what the design doesn’t do. It doesn’t stop showing notifications — you still know a message arrived. It doesn’t hide who’s writing to you. It treats the notification as what it should be: a signal that something is waiting, not a transcript of what it says. The message itself stays behind the same wall as your history in the archive — encrypted at rest, encrypted in transit, and now encrypted in the one place people actually see it.
So the honest test to carry around: if your phone buzzes face-up on a table, what can a stranger read? In a mainstream messenger, often the message. In a sovereign one, “New message” — until you decide, by unlocking, that it’s safe to read.
That’s the same deal as everything else in owning your messenger: the words are yours, and so is the moment they become readable. No billboard, no broadcast, no plaintext copy parked on someone else’s server — just a message that waits for you to be alone with it.
Want to see what a lockscreen that respects you feels like? Request an invite and try the live demo — the difference shows up the first time a notification arrives.