Who Gets a Copy of Your Messages? The Push Notification Trail Nobody Told You About

Every notification you've ever received on your phone made a stop you never chose. The sender's name, the message preview, the "your package is out for delivery" — before any of it appeared on your screen, the app's own servers handed it to one of two companies: Google or Apple.

That's not a bug or a leak. It's the architecture. It's publicly documented. And the part that should make you stop and think — government agencies demanding access to that data stream — was confirmed by the companies themselves after a U.S. Senator spent years dragging the answer into the open.

I started pulling on this thread with what I thought was a simple technical question about blocking push-notification ports on a router. The answer rearranged how I think about every messaging app on my phone. Here's the full trail: how the plumbing works, who gets a copy of what, what the documented record says about who can read those copies, and — because my first instinct was the wrong one — why you can't block your way out of this at the firewall.

The plumbing: how a notification actually reaches you

Push notifications are not delivered app-to-app. They ride a dedicated delivery system operated by the phone's platform vendor:

• Android: Firebase Cloud Messaging (FCM) — Google's service
• iPhone: Apple Push Notification service (APNs)

The flow works like this:

1. Registration. When you install an app, it registers with FCM or APNs and receives a device token — an opaque ID that uniquely identifies your phone for that app.
2. Handoff. The app sends that token to its own backend. WhatsApp's servers, for example, now know "Stan's phone = token XYZ."
3. The message arrives. Someone sends you a message. It lands on the app's servers.
4. Submission. The app's server makes an authenticated API call to Google or Apple: "deliver this payload to token XYZ." The payload is whatever the developer chose to include — a title, the sender's name, message preview text, or nothing at all.
5. Delivery. Google or Apple looks up which phone holds that token and pushes the payload down an always-open encrypted connection every phone maintains for exactly this purpose (Android holds it to Google on TCP 5228; iPhone holds it to Apple on TCP 5223, with HTTPS/443 as a fallback).
6. Display. Your OS renders the notification — or wakes the app in the background to fetch and decrypt the real content before showing anything.

Notice steps 2 through 5. The app's developer — not you — decides what gets handed to Google or Apple. Google and Apple don't compose anything; they relay. But they receive a copy of whatever the developer handed them, and it sits on their servers as part of the delivery process.

Three kinds of apps, three kinds of copies

How much a notification leaks depends entirely on the app's design. There's a spectrum, and it's worth naming where the popular apps sit:

• Signal — the clean case. Signal's push payload is a contentless wake-up tap: "wake up and check in." No sender, no preview, nothing. The actual message travels as end-to-end ciphertext between you and Signal's servers, and after the tap wakes the phone, the app fetches and decrypts locally. Google and Apple learn only that this phone uses Signal and roughly when messages arrive. (On Android without Google Play Services — GrapheneOS and friends — Signal skips FCM entirely and runs its own background connection, proving the tap doesn't need Google.)
• WhatsApp — the encrypted-payload case. For end-to-end-encrypted chats, WhatsApp puts ciphertext in the notification payload itself. The phone decrypts it on arrival. Google and Apple hold an unreadable blob — the design is safe, just a different trick than Signal's.
• Instagram — the messy case. Instagram DMs (Meta-owned) are not end-to-end encrypted — and since May 8, 2026, they can't be: Meta discontinued the optional encrypted-chats mode entirely. Since Meta's servers already hold the plaintext, the push payload they hand to Google and Apple includes the actual notification content: sender name + message preview text. Google and Apple aren't relaying an opaque tap — they're receiving "John: hey are you coming over?" That's a third copy of your DM, held by a company neither you nor your correspondent chose.

That last point got worse this year. Meta spent years rolling out optional end-to-end encryption to Instagram DMs, and then reversed course: effective May 8, 2026, Instagram no longer supports end-to-end encryption for direct messages at all (Proton's write-up has the details). The stated reason was low usage — for a feature that was never the default and had to be hunted for in settings. As of now, every Instagram DM is plaintext on Meta's servers, and its sender and preview ride in the push payload to Google and Apple.

And here's the uncomfortable math: for any Instagram DM, Google and Apple only hold a preview-length sliver. The app vendor holds the full plaintext of everything, indefinitely. Hardening the notification path doesn't touch that copy at all.

The paper trail: what's actually documented

None of what follows is speculation. It's the public record:

• December 6, 2023: Senator Ron Wyden disclosed that U.S. federal agencies — and unnamed foreign governments — were demanding push-notification data from Apple and Google, and that both companies were legally gagged from even admitting it. (Wyden's press release, Reuters, The Washington Post)
• Both companies have since publicly confirmed that government agencies can obtain push-notification data from their servers.
• Current policy, per the EFF (April 2026): Apple and Google now both require a judge's order before handing over push-notification details — and even with that requirement in place, Apple has shared data on hundreds of users. The safeguard is a court, not a technical impossibility. (EFF, "How Push Notifications Can Betray Your Privacy")
• The intelligence-law machinery stays warmed up. Section 702 of FISA — the authority most associated with tapping exactly these kinds of data stores — was reauthorized in April 2024 with a two-year sunset, then kicked down the road with a series of short extensions through 2026. A House reauthorization vote failed 218–198 on June 11, 2026, and the statute itself lapsed the next day. The surveillance did not stop: the Foreign Intelligence Surveillance Court had certified one-year extensions in March 2026, and those certifications keep the program running through March 2027 — even with the authorizing statute expired. Reauthorization remains contested as of this writing. (Congressional Research Service, Brennan Center's 702 resource page, EFF, "Victory! 702 has Expired!")

Read those together and the shape is clear: the notification stream is valuable enough that multiple governments have demanded access to it, the companies have complied under legal process, and — as of this year — the program collecting it doesn't even have an authorizing statute behind it, just court certifications. The barrier standing in front of any future demand is a piece of paper.

The forgotten copy: your phone's own database

There's a fourth copy that almost nobody thinks about: your phone keeps its own notification history in a local database. Recent notifications, sender names, preview text — stored on the device.

Per reporting from 404 Media (referenced in the EFF piece above), the same forensic extraction tools law enforcement uses to pull data from seized phones can extract that notification database. Your notification history is one Cellebrite-class tool away from being read off a phone that gets confiscated, subpoenaed, or borrowed.

Apple quietly improved this in April 2026 — iOS 26.4.2 and 18.7.8 now stop retaining notifications marked for deletion in the local database (EFF's update note). That's a real fix for the retention half. The extraction capability itself remains — the database has always been readable by anyone with the tooling and the device.

So the full accounting looks like this:

1. The app vendor — often the full plaintext
2. Google or Apple — whatever the developer put in the payload (sometimes nothing, sometimes ciphertext, sometimes your actual message preview)
3. Your phone's notification database — whatever was displayed
4. Whoever extracts copy #3 — with a court order, a warrant, a stolen phone, or a forensic tool

"This has been going on a lot longer than they admitted"

Some people in the security community have believed for years — long before 2023 — that this data path was being exploited. You don't have to take anyone's word for it, classified or otherwise. Two facts do the work:

First, the mechanism is fifteen-plus years old. Apple's push service launched in 2009. Google's launched in 2010 as C2DM, the predecessor of today's FCM. The entire architecture — developer servers handing user-specific payloads to Google/Apple for relay — has existed since then. Every ingredient needed for government access to this data stream was in place and humming along for over a decade before anyone was allowed to say it was happening.

Second, confirmation lag is the norm in this space, not the exception. Look at the pattern:

• Stellar Wind began in October 2001. The New York Times revealed the warrantless surveillance program in December 2005 — four years later.
• Room 641A — the AT&T facility in San Francisco splitting traffic for the NSA — was allegedly operating for years before whistleblower Mark Klein's 2006 disclosure.
• PRISM began in 2007, according to the leaked slides themselves. The public learned of it in June 2013 — six years later.

Every major disclosure in this domain describes practice that substantially predates the disclosure. A 2023 letter revealing "agencies were demanding this data and the companies were gagged" fits that pattern exactly. The reasonable read is not that the demands started in 2023 — it's that 2023 is when we were told.

Why you can't firewall your way out

My first instinct — as a network guy — was to block the push ports at the edge and be done with it: deny TCP 5228 and 5223, problem solved. Two reasons that doesn't work:

1. Both services fall back to HTTPS/443. If 5228 or 5223 is unreachable, the notification comes down the same port as every other encrypted web session. Port-based blocking catches almost nothing; to actually suppress push you'd have to block the platform endpoints by hostname, and you'd be playing a permanent whack-a-mole against the two companies whose entire ecosystem rides those endpoints.
2. More fundamentally: the copy is created before your network is ever involved. The developer's server submits the payload to Google/Apple the moment the message arrives — that leg of the journey happens on the internet's side of your router, where you have no reach. Blocking ports on your own network controls delivery to the phone. It does nothing about what Google and Apple's servers already received. The copy you're worried about exists whether or not the notification ever reaches the handset.

This is worth internalizing, because it's the difference between two very different problems. Delivery control is a network problem, and network people can solve it. Copy control is an application-design problem, and it's decided by choices made in server rooms you'll never see.

What actually works

• Choose your messengers by design, not by settings. End-to-end encryption is a property of the app's architecture, not a toggle. Signal (contentless tap) and WhatsApp (ciphertext payload) are built so the notification path leaks nothing readable. That protection exists only if you're using an app that engineered it — and it can be taken away: Meta spent years adding E2EE to Instagram DMs, then removed the feature entirely in May 2026.
• For non-E2EE apps, turn notifications off inside the app. This is the switch that actually prevents the copies. When you disable notifications in the app's own settings, the app tells its own server to stop sending — and the server never submits a payload to Google or Apple at all. Contrast that with the phone's OS notification toggle, which only suppresses the display: the payload was already submitted and transited Google's or Apple's servers before your phone declined to show it. Likewise, the "Show Previews: Never" setting is cosmetic — the OS just won't render text that already made the trip.
• Assume your notification history is extractable. If a device might ever be seized or forensically examined, its notification database is part of your surface. Clear it like you'd clear a browser history, and know that on current iOS versions deleted notifications actually leave the database — on older versions they lingered.
• Threat-model honestly. For apps that aren't end-to-end encrypted, notification hygiene treats a symptom. The vendor still holds the full plaintext, and no router setting, preview toggle, or notification switch changes that. The durable fix for message content is an architectural one: apps where the content was never readable by anyone except the endpoints.

The point

I'm not telling anyone to throw their phone in a lake. Notifications are useful, and the plumbing that delivers them is, mostly, just plumbing.

But the model most people carry in their heads — the message goes from my friend to me — is wrong, and it's wrong in a specific direction. It's missing a step where a third and sometimes fourth copy gets made, at companies chosen by the app developer, governed by legal processes that were secret for a decade, and extractable from a phone that leaves your possession.

You can't opt out of the architecture. You can only choose apps whose architecture has nothing worth copying — and turn off the feeds of the ones that do. Now you know which is which.