End-to-end encryption protects message content between sender and recipient. It does not protect the infrastructure that tells your phone a message is waiting. That distinction matters enormously, and a recently reported case makes it concrete: the FBI recovered Signal messages a suspect had deleted, not by breaking Signal’s encryption, but by obtaining iPhone notification data from Apple.
The Signal Protocol is not in question here. The weakness is not in the cryptography. It is in the delivery layer that sits between a message arriving and your screen lighting up.
How Apple Push Notification Service Actually Works
Every iOS app that wants to deliver push notifications must route them through Apple’s Push Notification service (APNs). There is no alternative. Apple does not allow apps to maintain persistent background connections or listen on custom ports to receive incoming data. If you want your app to wake up and tell the user something arrived, the message has to flow through Apple’s servers first.
The mechanics work like this. When an app registers for push notifications, Apple issues it a device token, a cryptographic identifier that routes notifications to the specific app on the specific device. The app’s server takes a payload, constructs a JSON object, and sends it to Apple’s APNs endpoint with that device token. Apple delivers it to the device. The device wakes the app.
The critical point is that Apple sits in the middle of every notification. Apple knows:
- Which device token received a notification
- Which app sent it
- The timestamp
- The payload content, unless the payload is entirely absent
Device tokens are stable across reinstalls until the user wipes the device or revokes them. Apple can associate device tokens with Apple IDs. Apple IDs are linked to real identities through payment information, recovery contacts, and account history. The chain from “a Signal notification was delivered” to “a specific named person’s device” is short.
The Payload Problem
The APNs payload is a JSON object with a well-defined structure. A standard notification payload looks like:
{
"aps": {
"alert": {
"title": "Alice",
"body": "Are you coming tonight?"
},
"badge": 1,
"sound": "default"
}
}If an app sends message content in the alert.body field, that content transits Apple’s servers. Apps focused on privacy can avoid this by using silent notifications instead, sending only a ping that tells the app to fetch new content without including any message preview in the payload itself:
{
"aps": {
"content-available": 1
}
}Signal does use this approach. The Signal iOS app is designed to receive a minimal notification that triggers the app to decrypt and fetch the actual message payload directly from Signal’s servers, keeping message content out of the APNs pipeline. This is the right design. The problem is that even a fully content-free notification payload leaves metadata. Apple has a record that your device received a Signal notification at a specific timestamp. That is surveillance-relevant information independent of what the message said.
The 2023 Precedent That Set the Stage
This case did not emerge in a vacuum. In December 2023, Senator Ron Wyden sent a letter to the Department of Justice revealing that the DOJ had been secretly ordering Apple and Google to hand over push notification records. Apple confirmed it had received such demands. Google confirmed the same for Firebase Cloud Messaging on Android.
The method was not new. Law enforcement had apparently been using it for years before Wyden forced it into public view. What the senator’s disclosure did was establish that push notification data was already a well-understood investigative tool, not an exotic technique. The FBI knowing about APNs metadata was not a breakthrough in this recent Signal case; it was a continuation of an established practice applied to a specific evidentiary situation.
The Apple transparency report confirms that Apple responds to legal demands including court orders and search warrants for account information. Push notification records fall within that category.
Why Deleted Messages Are Recoverable
When you delete a Signal message on your iPhone, you are deleting it from local storage. The Signal app removes it from its SQLite database on the device. The end-to-end encrypted payload that Signal’s servers may have briefly held is also gone from Signal’s infrastructure, since Signal is designed to delete messages after delivery.
But none of that touches what Apple already logged at the moment of delivery.
If the notification payload contained any content, that content exists in Apple’s records regardless of what happened afterward on the device or at Signal’s servers. Even with content-free payloads, the delivery record itself, the timestamp, the device association, the frequency of incoming notifications, may be enough to establish that communication occurred and when.
There is also the question of device-level notification logs. iOS maintains notification history for features like Notification Summary and the notification center. Forensic tools used by law enforcement, including products from Cellebrite and Magnet Forensics, can extract notification database artifacts from iOS backups and physical device images. If the device was unlocked or if a passcode was obtained, notification history stored by the OS itself becomes accessible through acquisition tools independently of whether the Signal app has deleted its own records.
The combination of APNs records obtained from Apple through legal process, plus forensic extraction of on-device notification artifacts, creates a reconstruction path for messages the user believed were gone.
What Signal Can and Cannot Do About This
Signal’s architecture already reflects awareness of this problem. The decision to use content-free push payloads is deliberate. Signal’s technical documentation and the work of researchers like Moxie Marlinspike have consistently framed the notification layer as an area of concern.
But Signal cannot opt out of APNs on iOS without giving up push notifications entirely, and an app that requires the user to manually open it to check for messages is not competitive in practice. The constraint is imposed by Apple’s platform policy, not by Signal’s design choices.
What Signal can offer is minimal payload content and a setting to disable message previews in notifications. Users who enable “Show” set to “No Name or Message” in Signal’s notification settings ensure that even if Apple is compelled to produce notification records, those records contain no message text or sender identity in the payload.
Disappearing messages are a related but separate control. Signal’s disappearing message timer deletes content from both devices after a set period. This helps with local forensic exposure but, again, does not affect what Apple already received and logged at delivery time.
The Structural Issue
The deeper problem here is that the security model most users understand, that Signal encrypts messages and therefore the government cannot read them, is correct in a narrow technical sense and misleading in practice. The government does not always need to read the message content. Delivery records, timing analysis, communication graphs, and metadata about who talked to whom and when can be independently valuable, and that data exists in Apple’s infrastructure as a byproduct of normal operation.
This is not a Signal failure. It is a constraint imposed by the architecture of mobile operating systems. On Android, the situation is roughly parallel with Google’s Firebase Cloud Messaging playing the same intermediary role that APNs plays on iOS.
The practical guidance for users with high threat models has not changed: disable notification previews, use disappearing messages, understand that your device token is a durable identifier that can be linked to your Apple ID, and recognize that “deleted” means different things at different layers of the stack. A message deleted from Signal’s database is gone from Signal. It may not be gone from Apple’s records, from iOS notification history, or from a forensic image of your backup.
End-to-end encryption is a strong guarantee about content. It was never a guarantee about the metadata that surrounds delivery, and that gap is exactly where this investigation found its footing.