Oh, I was originally confused about this because I had thought the push notifications were end-to-end encrypted, so they couldn't be cached in readable form by the push notification service, and only decrypted by the app on device upon receiving the notification. But it seems like after the notification was decrypted by the app and shown to the user using OS APIs, the notification text was was then stored by the OS in some kind of notification history DB locally on the device?
In privacy circles, this was always known, as Google/Apple often sends notification content to their servers (which means that it bypass the App realm).
This was a bug that left it cached on the device. Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring.
If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
Incorrect. At least according to the Matrix (chat) app FAQs I have read recently.
With Matrix apps, certain metadata is pushed from the chat server, to a push server, through Google and then to my device. But the message is not part of that data - it's E2EE. What happens is the app wakes up from the metadata notification, and then fetches the message and displays it in the notification field.
Your last point is correct, at least until/unless this is remedied in Android, too.
Right, it would be too hard to just have a server send a notification and to jumble that notification locally with the read of the unlocked message without it going through Apple/Google servers.
For many apps, they choose to do it this way. For most e2ee apps, they do not. The notification displayed on screen does not need to be the notification pushed through APNS.
From the discussion under this comment it seems its a lot more complicated than that, and lots of people think they know how it works and then lots of other people disagree with them. So all very murky
Honestly, there are so many good reasons to turn off notifications entirely. Sure, maybe leave them on for phone calls from people you know. But past that, I think getting interrupted by your phone is more trouble than it's worth.
> If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
We have no idea if this actually works or even what it does, because we can't see the source code. We just have to take Apple and Google's word for it. Which is not exactly a smart thing to do.
> If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
Why would an encrypted app broadcast your messages to notifications? That sounds like a failure of the messenger service vendor to secure their app. My banking app requires me to log in to read messages and my account statement EVERY TIME. I get a notification that is just that, notifies me of some pending information, not the information itself.
This is the notification layer, but the same structural problem exists one level deeper: the OS vendor is the custodian of the user's entire digital identity, not just message contents, but context, behavioral history, and application relationships. The notification routing is a symptom. The custody assumption underneath it is the root.
As long as your identity lives inside a vendor-controlled OS, encryption at the app layer is a patch on a structural problem
The "bug" discussed in the article is only part of the problem.
The main problem, which is notifications text is stored on a DB in the phone outside of signal, is not addressed. To avoid that you have to change your settings.
In this case, the defendant had deleted the signal app completely, and that likely internally marks those app's notifications for deletion from the DB, so the bug fixed here is that they were not removing notifications from the local database when the app that generated them was removed, now they do.
Impact: Notifications marked for deletion could be unexpectedly retained on the device
Description: A logging issue was addressed with improved data redaction.
CVE-2026-28950
They classify this as "loggging issue" so it sounds like notifications were not actually in the database itself but ended up in some log.
This makes me wonder: Cellebrite makes tools for law enforcement to break into iPhones, likely exploiting weaknesses/vulnerabilities. Does Apple buy Cellebrite’s tools and reverse engineer them? Or would they not have a way of acquiring them legally?
I can’t imagine a scenario where Apple couldn’t legally buy them on the grey market. I can imagine it being illegal to sell them, like contractual restrictions blocking purchasers from reselling them. But short of the tools being a munition or controlled substance, you can buy whatever you want.
It's not new that push notifications should be presumed to be insecure, with their content passing through - and probably persisted - outside the app sandbox and anything in control of in-app encryption.
Apple should have fixed this long ago (not that you can trust a closed system), but Signal should also have strong guardrails & warnings around allowing message content in push notifications.
> This was because notifications that displayed the messages’ content were also cached on the device for up to a month.
Why can't we have notification history just like on Android then. It's very useful when you dismiss a notification you didn't want to, or you look for some old stuff.
every time something like this surfaces I'm reminded how many privacy guarantees end at the app boundary. you can do all the e2e crypto you want, the OS layer is going to do whatever it does with your strings once they hit a render path. probably an unsolvable category of bug as long as notifications need to show readable text somewhere.
Looking at the detritus in the filesystem on Jailbroken iOS devices you will observe that iOS decides to vacuum, purge, and let linger all sorts of databases and logs until something triggers a cleanup which is usually time or an iCloud sign-out induced erase and subsequent sync. People have been complaining for years about excessive phantom “system storage” and “other data.” Interestingly the photos thumbs database can grow seemingly indefinitely in size for some weeks or more if you’re regularly deleting all of your photos and saving to photos from apps or taking photos. I suspect that there a lot of behavioral data records that is left on most devices until a convenient period of inactivity passes and the possible user behavior analysis and reporting functions of iOS allow whatever cleanup happens after processing on device. It would be useful to capture iCloud backup restores from physical devices to corellium virtual devices with some creative matching of your existing idevices identifiers. Could see what triggers a cleanup during backups, local or otherwise, get a good look at what is being restored from iCloud. I also think it’s possible that iCloud can sync a database, say safari bookmarks, pushing it to the device inducing a state where the device bookmarks are moved to inaccessible tables and left there, unavailable to the end user, but not out of sync with the current active session state. Of course this is just my musing based on observations of weekly ffs extractions of a few devices over the last 5 years.
My observations from when I daily drove iOS (no more) mirror yours: the incredible amount of cruft that would accumulate was astonishing. At one point I had a device that was majority full of system storage and other data. The same was true across family devices, too.
Some years ago I stopped depending on Apple's purchased downloaded movies for long flights, after an instance of having the files downloaded to the device beforehand, but Apple deciding I didn't have the DRM keys to play said files during a long transoceanic flight. I then moved to storing DRM-free movies in VLC, but iOS prioritized keeping system storage and other data cruft around, and wiped VLC's stored files. Talk about paying for an expensive device and media you don't really own.
I'd imagine the metadata picture that could be synthesized from that data could be extensive in some cases. This stuff is hard and I'm sure there are good reasons for caching things, especially on a device positioned to primarily act as a readily available front end for online stores, but I have a hard time believing that Apple's executing it well.
This all seems like a reasonable critique but the idea that the reason for not cleaning up data is so the system can run background behavioral analysis on it seems paranoid. Surely the main reason for not running cleanup until storage is needed is just optimizing for in the moment performance.
Anthropic Mythos at work! iOS is so good and well built that only 1 bug was found and those patch. "It's either all a joke ... or none of it is." -Bruce Banner
60 comments
[ 3.0 ms ] story [ 65.0 ms ] threadMuch of the metadata is plaintext, in both Apple and Google's Push Notification architecture.
Some people talking about it (different but in the same scope of issue): https://blog.davidlibeau.fr/push-notifications-are-a-privacy...
If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
With Matrix apps, certain metadata is pushed from the chat server, to a push server, through Google and then to my device. But the message is not part of that data - it's E2EE. What happens is the app wakes up from the metadata notification, and then fetches the message and displays it in the notification field.
Your last point is correct, at least until/unless this is remedied in Android, too.
I'm pretty sure that's the default in GrapheneOS. Or at least that's how mine behaves.
For many apps, they choose to do it this way. For most e2ee apps, they do not. The notification displayed on screen does not need to be the notification pushed through APNS.
We have no idea if this actually works or even what it does, because we can't see the source code. We just have to take Apple and Google's word for it. Which is not exactly a smart thing to do.
Why would an encrypted app broadcast your messages to notifications? That sounds like a failure of the messenger service vendor to secure their app. My banking app requires me to log in to read messages and my account statement EVERY TIME. I get a notification that is just that, notifies me of some pending information, not the information itself.
As long as your identity lives inside a vendor-controlled OS, encryption at the app layer is a patch on a structural problem
The main problem, which is notifications text is stored on a DB in the phone outside of signal, is not addressed. To avoid that you have to change your settings.
In this case, the defendant had deleted the signal app completely, and that likely internally marks those app's notifications for deletion from the DB, so the bug fixed here is that they were not removing notifications from the local database when the app that generated them was removed, now they do.
They classify this as "loggging issue" so it sounds like notifications were not actually in the database itself but ended up in some log.Biome — /private/var/mobile/Library/Biome/streams/.../Notification/segments/ — the raw title/body logs
2. BulletinBoard + UserNotificationsCore — /var/mobile/Library/{BulletinBoard,UserNotificationsCore}/.{json,plist} — delivered + dismissed state
3. CoreDuet — /var/mobile/Library/CoreDuet/coreduetdClassD.db — SQLite that re-ingests Biome events
https://x.com/zeroxjf/status/2047081983449178128?s=46
UPDATING IOS WILL ENABLE AUTOMATIC UPDATES TO IOS 26.
(Bad!) This is a new shady tactic they're using trying to get iOS 18 users to install iOS 26.
Apple should have fixed this long ago (not that you can trust a closed system), but Signal should also have strong guardrails & warnings around allowing message content in push notifications.
It has to do with the fact that any notification displayed on your device goes via a separate system service which was caching them.
It is amusing to see how often people confuse device notifications with Apple notification service.
Why can't we have notification history just like on Android then. It's very useful when you dismiss a notification you didn't want to, or you look for some old stuff.
Let screens always show garbled pixel vomit, decoded on device only by your private AR glasses
Some years ago I stopped depending on Apple's purchased downloaded movies for long flights, after an instance of having the files downloaded to the device beforehand, but Apple deciding I didn't have the DRM keys to play said files during a long transoceanic flight. I then moved to storing DRM-free movies in VLC, but iOS prioritized keeping system storage and other data cruft around, and wiped VLC's stored files. Talk about paying for an expensive device and media you don't really own.
I'd imagine the metadata picture that could be synthesized from that data could be extensive in some cases. This stuff is hard and I'm sure there are good reasons for caching things, especially on a device positioned to primarily act as a readily available front end for online stores, but I have a hard time believing that Apple's executing it well.
I disabled notifications and instead Signal reminded me to re-enable them…