When a chat app on your phone receives a new message, the server doesn't talk to the app directly. It hands a payload to Apple Push Notification service (APNs) or Google's Firebase Cloud Messaging (FCM), which then routes it to your device. This indirection exists for good engineering reasons — battery life, background-process restrictions, mobile-network NAT traversal — but it has a consequence very few users have thought through: two American companies see the timing and destination of essentially every notification any app delivers to any phone.
For years, this was treated as an implementation detail. In late 2023, a letter from Senator Ron Wyden's office made it impossible to ignore.
The Wyden Letter, Briefly
On December 6, 2023, Senator Wyden sent a public letter to the U.S. Department of Justice asking it to permit Apple and Google to disclose what they were already doing: receiving subpoenas and other legal demands for push notification metadata from governments — both U.S. and foreign. Both companies confirmed shortly after that they had been complying with such requests but were previously prevented from documenting them publicly.
Apple and Google each updated their law-enforcement guidelines to acknowledge push token records as discoverable data. The disclosed picture: requests had been coming for years, the legal process was routine, and the records held by APNs and FCM were sufficient to link a specific app on a specific device to a specific real identity — through Apple ID or Google account billing data.
A push token is a long opaque string an app registers with APNs or FCM. When a server pushes a notification, that token is the routing address. Apple and Google can map tokens to Apple IDs or Google accounts, which map to billing identities. They can log timestamps of deliveries. They cannot read encrypted notification payloads — but they don't need to, to know that this account received a notification from this app at this time.
What Push Metadata Reveals
Even with end-to-end encrypted contents, push notification metadata can reconstruct a great deal of activity:
- Which apps you actually use — every active app registers a push token tied to your account.
- When you're awake and engaged — notification arrival patterns roughly track usage and time zone.
- Who's talking to you — by correlating notification timing across multiple targets and accounts, an analyst can infer conversation graphs without ever reading message content.
- That you're using a specific privacy app — even if the message contents are unreadable, the existence of a push token from a particular bundle ID (e.g. a Signal-like app) is itself information.
This is the same class of problem we covered in our piece on metadata surveillance and sealed sender: encrypting the content of a message doesn't hide the fact that a message was delivered.
Why the Architecture Is Hard to Avoid
Modern mobile operating systems aggressively restrict what backgrounded apps can do. iOS in particular won't let an app maintain a persistent socket to a custom server in the background — the OS terminates such processes within seconds to preserve battery and bandwidth. Android is more permissive but trending in the same direction with Doze and App Standby buckets.
The OS-blessed escape hatch is to register with the platform's push service, which uses a single shared connection per device, multiplexed across all installed apps. This is genuinely good design — for the device. The cost is centralization: every app on the device delivers its background messages through the same Apple or Google pipe.
Apps that refuse to use APNs or FCM can still work — but only by burning battery to keep a foreground connection alive, or by sacrificing real-time delivery and relying on periodic background fetches. The result is a worse user experience that most users will reject in favor of an alternative. Privacy via worse UX is rarely a winning strategy.
What's Actually Sent in a Push Notification
For privacy-aware messengers, the wire payload is usually structured to leak as little as possible:
| What's in the push payload | Visible to Apple/Google? |
|---|---|
| Encrypted ciphertext blob | No |
| Destination push token | Yes |
| Sending app's bundle ID / sender ID | Yes |
| Delivery timestamp | Yes |
| Plaintext title / body (if not deferred) | Yes — unless the app uses a Notification Service Extension to decrypt locally |
Well-designed privacy messengers use APNs's "mutable-content" / "data-only" flags and a Notification Service Extension to receive a push containing only the encrypted ciphertext, then decrypt it on-device before showing a notification to the user. This prevents Apple from seeing the message title or preview. It does not hide the existence of the notification, the destination token, or the time.
Mitigations That Actually Help
There is no clean fix at the user level for the structural problem. There are partial mitigations that reduce specific risks:
- Data-only push payloads — Use messengers that decrypt notifications client-side. Eliminates the title/body leak to Apple or Google.
- Push relays in user-chosen jurisdictions — Signal has experimented with relaying notifications through its own infrastructure for some account flows; the trade-off is latency and battery.
- UnifiedPush on Android — A federated push standard where the user picks which push provider relays their data (including self-hosted options). Some Matrix and FOSS apps support it.
- Reducing identity linkage — Using a separate Apple ID or Google account from your real identity reduces the ability of the platform to tie push tokens back to you. This is a serious operational commitment, not a checkbox.
- Threat-aware app choice — For high-risk users, choosing apps that explicitly minimize push payloads and document their push behavior matters more than features.
Web and Desktop Are Different
The push-notification problem is specifically a mobile-platform problem. On desktop and in the browser, apps can maintain their own long-lived WebSocket or HTTP/2 connections directly to their servers, with no Apple or Google in between. This is one of the underappreciated privacy advantages of running a messenger as a web app or desktop client: the metadata pipe through a third-party push service simply doesn't exist.
Web push (the W3C Push API) does exist, but it's opt-in per site, and many privacy-aware web messengers simply don't use it — they rely on the open WebSocket while the tab is in focus.
What This Means for Threat Modeling
The takeaway isn't "stop using push notifications" — for most users, that's a worse trade than the privacy gained. The takeaway is calibration:
End-to-end encryption protects the contents of your messages from the messenger. Push notification metadata protects nothing from the platform. If your threat model includes governmental access to platform records, your app choice matters less than your understanding of what the platform sees regardless.
For most everyday privacy concerns — advertisers, casual data brokers, accidental exposure — the difference between a messenger that uses data-only push and one that doesn't is real and meaningful. For threats that can legally compel Apple or Google, only architectural choices (jurisdiction of identity, choice of platform, willingness to accept worse UX) change the calculus.
Where Haven Fits
Haven uses data-only push payloads on mobile — the push contains a wake-up signal and an encrypted blob, not the plaintext of the message. On web and desktop, Haven communicates directly over WebSocket without involving Apple or Google at all. We're honest about what we can't fix: as long as you receive notifications on iOS or Android, the platforms can see that a notification was delivered to your account.
Knowing what's exposed is the prerequisite to making an informed choice. We'd rather you understand the trade-off than be reassured by marketing that papers over it.