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.
> 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.
This incorrect on two counts:
1. As per what you wrote immediately before the quoted text, the issue was that the OS keeps track of notifications locally. Google/Apple's notification servers have nothing to do with this
2. It's entirely possible to still have end-to-end messaging even if you're forced to send notifications through Google/Apple's servers, by encrypting data in the notification, or not including message data at all. Indeed that's what signal does. Apple or Google's never sees your message in cleartext.
If Signal wants to show you a notification with message text, it needs to put it on the screen through an OS service. That service was storing the plaintext on the device.
Through an OS service yes, but not a hosted backend service. Obviously that service has store the notification in plaintext (although everything on an iPhone is encrypted at rest, but notification crypto keys have to stay in active memory for the lock screen to work), otherwise it wouldn’t be able to display the notification text.
Apple support applications sending encrypted notifications, where the OS launches the app the decrypt the notification body locally and pass it back to the OS for display.
I think the idea here is that the notification text was also being put somewhere else that was not really tied to the lifetime of it being shown on screen.
They have to. The device storage is itself encrypted, so the FBI already broke into the phone. When the device is unlocked, notifications are visible by design and therefore available in plain text to the user. The edge case is with disappearing messages, a feature Apple did not build for. The message is intended to be plainly visible to the user, but only for a controlled time on the assumption that the users privileges may eventually be compromised.
This makes for a very odd and specific interaction with a 3rd party feature. Security is a hard problem.
Signal (at least on iOS) has a setting called "Notification Content" which defaults (unsafely in the light of this bug) to "Name, content, and Actions", but allows you to select either "Name Only" or "No Name or Content".
I assume that "Name only" option results in the push notification only sending "Signal message from Bob", and the "No Name or Content" one only sending "You have a new Signal message" - instead of the whole "Signal message from Bob: Let's rob the bank tomorrow!"
If I could have it work the way I'd prefer, Signal would let me set those Notification Content on a per contact and per chat basis - so I could set my bank robbing crew and group chats to "No Name or Content" while leaving mom and the family group chat on "Name, content, and Actions".
(But realistically, if I _did_ have a bank robbing crew they'd all be on my burner phone, not the phone I do family group chat with.)
This is correct, but my understanding of it is that the push notification (which is not the same thing as the actual "Notification" that is shown on the screen) basically contains a "hey $DEVICE, go talk to $APP_NOTO server they got something for you".
APNS just taps on the device's metaphorical shoulder and hands them a courtesy phone "call for you sir"
For a standard notification the content of that notification is sent through the push notification servers. This includes the title, text, icon, grouping, and sound presets to use. The majority of user-visible notifications are sent this way - the app on the device does not run.
That allows the OS to display your notification without ever running the app, which saves limited resources on the phone. Originally this was the only option, a push notification couldn’t start your app.
These days an app can also register a notification extension which is a standalone program that can modify the incoming notification. It has 30 seconds to do whatever it needs to, though you need to be careful with RAM use or the OS will kill the process and present the notification unaltered. Generally you’d put something generic in the push as a fallback.
There’s also background notifications. These let the app run for 30 seconds and the app can post a local notification during this time, but they’re not guaranteed to be delivered. The OS can decide the system doesn’t have the resources and defer or drop them, or terminate the app before it’s finished if the ram is needed elsewhere.
There are some other special cases depending on what your app does.
Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption.
Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext.
A Signal developer 12 days ago said Our FCM and APN notifications are empty and just tell the app to wake up, fetch encrypted messages, decrypt them, and then generate the notification ourselves locally.[1]
You don’t need a rooted phone. An open source OS with reproducible builds is enough. That way you can validate what the code does without giving up verified boot, or opening up another attack vector, etc.
talking totally out of my ass, but apple seems to have robust infrastructure for e2ee communication between your devices, for example it is known that location information in find my is not visible to apple. I’d be surprised if the channel to send iphone notifications to your mac wasn’t also e2ee
Unless something has changed since I last did this, the app's server initiating the apns doesn't encrypt using some public key for the destination. So no e2ee at that layer. But you could encrypt the payload and have the app decrypt it if you're managing the keys yourself.
The real question is why iOS caches notification payloads to a persistent SQLite DB in the first place. The notification content only needs to live long enough to render the banner and be shown in the lock screen shade. Persisting it to disk for a month past dismissal isn't a "bug", it's a design choice that someone signed off on. Signal can set UNNotificationContent to show empty/placeholder text, but the default path for any app that hasn't opted out hits this cache. Worth reading the 404 Media piece for the forensic tooling details, this isn't a 0day, it's Cellebrite reading a plist.
Both Apple and Google offer the ability for your app to intercept and modify messages before being displayed. Use that to send encrypted messages and decrypt them there, using your own code on the user’s device.
That framing Makes it sound like the app developer has to do something active to keep message cleartext out of notifications. That's not how it is on Android.
A Firebase Cloud Messaging push notification contains what the app developer's server puts in it. That could include the message body or it could just be an instruction to the app to poll the server for new messages. It has nothing to do with the notification that's displayd on an Android device. Those are entirely local.
An app that cares about privacy wouldn't send anything more than a poll instruction over FCM.
But if you have strong end-to-end encryption for messages, then you don’t have to care about the transport anymore, you assume they’re all compromised. At that point you might as well use the push notification system as your transport, given both OSs allow applications to intercept the push notification locally and decrypt it before it’s displayed to the user.
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.
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
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.
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.
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.
But in the real world, for maximal battery savings and therefore UX, routing any notification data via APNS is recommended.
Fortunately you can choose the payload by yourself and just send a notification "ping" without any data about the messages. But if we're serious about security, you just don't ping the client about new messages because even the time and existence of a notification can be compromising. _The user will know that they got a message, when they open the app and see that they got a new message._
Oh please, Telegram being mentioned positively during a discussion of security, privacy or state surveillance? Telegram is a security nightmare, it’s not e2ee no mater what BS their very very untrustworthy founder keeps spouting, it’s not default and what they do offer is probably not secure. Servers owned by Russian oligarchs loyal to Putin. Durovs rebel persona, where he’s persona non grata in Russia is also BS. He was shown to be freely traveling in and out of Russia and having negotiations with the Russian government around censorship of Telegram all while Durov was telling us he couldn’t return. And the Russian FSB won’t use it because it’s known in their circles as being compromised.
> "That largely depends on what an officer does outside of work. If someone is involved in corrupt dealings, and in fact, I know very few who aren't, then they reason like this. Can this messenger be monitored by internal security officers? Previously, many used WhatsApp. Almost no one used telegram because there's a wellfounded belief that this messenger is to some extent controlled by the Russian authorities. People used signal. Some use three months, but all that has now been shut down again. Why is it monitored? I think they're worried about a possible coup and trying to limit the ability to coordinate mass actions via communication channels from abroad. Hence the Max messenger. So now most security officers have switched to Chatty. That's a Dubai based messenger, but it's definitely not a universal remedy. Some have moved to Zangi, which is [clears throat] an Armenian app that markets itself as American. When it comes to targeting the opposition, the state will always find the resources. It's one of the main priorities, more important than any financial or commercial issue, even more than counterterrorism."
As mingus88 said, this story is literally in response to Apple leaking messages sent through Signal. Doesn't matter if the message is securely transmitted if the operating system then keeps it lying around in plain text in a cache.
From the linked article:
> The independent news outlet reported that the FBI had been able to extract deleted Signal messages from someone’s iPhone using forensic tools, due to the fact that the content of the messages had been displayed in a notification and then stored inside a phone’s database — even after the messages were deleted inside Signal.
The original comment mentions this but gives the wrong reasoning. The APNs are encrypted either way, but this setting prevents Signal from decrypting them client-side and letting the notification cache store it. Yeah this is more secure because it means not trusting Apple to do their job right with local storage, but it's also kind of a reasonable thing to trust.
Except even when you turn off message previews, it has to be specifically from within Signal settings. Not the iOS settings for notifications for the Signal app. To the user it looks the same, so it’s easy to make the mistake of turning off the previews in iOS settings instead of from within Signal settings. I didn’t even know there was a difference between the two until the recent posts about it.
This is also an oversimplification. If I understand the issue correctly, the notification with the message contents was what was cashed locally and then accessed. This same vulnerability would exist with Signal if you had the notifications configured to display the full message contents. In this case, it has nothing to do with either Apple or Signal.
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.
i'll speculate further: it could've been on the dismiss notification code, and when you delete the app the OS dismisses the removed app's notifications, triggering the same code path.
in this case as per reporting, defendant removed the app. unclear if they first dismissed them.
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?
My understanding is that in Signal's implementation of push notifications the message text is end-to-end encrypted by Signal and decrypted on device by the Signal app. The decryption is not handled by the OS's push notification system.
If I am reading this right, your understanding is incorrect. Signal's "new messages" push message payload is empty. Upon receiving a message of this type, the Signal app wakes up, fetches the actual messages, and (optionally) displays local notifications for them.
At no point does the push message payload contain message text or metadata, encrypted or not.
The message text is still sent to the push notification server from the app's infrastructure - this setting simply stops the phone from displaying the message.
The app itself must choose not to send the message text in the push notification.
Nice. Will Apple now also fix the "bug" where you delete a message on your phone, and 3 months later it downloads on your iPad or Watch, and you can never be sure your messages are really gone?
Before anyone asks: No , I didnt turn on any setting to save all my messages to some external server and download them whenever, even if I delete them locally
Is it a bug or a feature though? What's more common: wanting to delete a message and have it stay gone, or accidentally deleting the message you wanted to preserve? For most people the latter is more likely than the former.
This is a problem with all kinds of apps. There is no discipline in the handling of user data. Take the notes app. When you delete text it not gone you can still see it in the sqlite database they use for storage. I'm sure this is so they can support sync be recording your changes as CRDTs or something.
And if the app isn't leaky, the OS will probsbly screw you like in this case. The concept of being able to clean up your laptop is just not supported, you have to wipe the whole device which is ridiculous.
Signal deletes the message. Apple keeps the notification that shows the message. For a month. On-device. This is exactly the kind of bug that isn't a bug it's what happens when privacy is owned by the app but the OS isn't aligned.
It seems so weird that it caches for so long. Notifications are rare enough that you could clean it out of the cache as soon as it's dismissed. It's not like it's something that's happening every few ms
So for third party apps this seems like if you do e2e then along with this bug fix your texts are safe. E2E apps could be independently verified by a third party let’s say.
But what about iMessage. The source code will never be available for neither the servers nor the app.
The issue is only an issue if your phone is physically taken, then unlocked and the message notifications extracted from a iOS cache database. Todays update by Apple fixes issue for every app, not just Signal.
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).
I expect that Signal encrypts the notification data prior to sending it to Apple, then decrypts it on-device using a Notification Service Extension – this is a common pattern to avoid trusting Apple with any sensitive data.
That would mean Apple stored the cleartext on-device after decryption.
Signal doesn’t provide anything in the message other than… “there are pending messages.” Signal wakes up, fetches them, then generates notifications on the phone itself.
Not only that, but iOS 18.7.8 actually seems to be available to devices capable of running iOS 26 without any workarounds, unlike 18.7.3 through .6. It makes me wonder if those intermediate releases really were supposed to be available but weren't due to some issue on the distribution side that no one bothered to fix.
Very serious vulns were being exploited in the wild, I think that's what forced their hand. I don't think Apple ever had a discrepancy like the one with iOS 18.7.3 through .6 being held back.
For those on iOS 18, beware that the update to iOS 18.7.8 will toggle Automatic Updates back on. Make sure to switch it back off so you don't wake up to a nasty surprise when iOS 26 is non-consensually forced onto your iPhone.
I think that was another attempt by Apple to push users to iOS 26, but after seeing how many people with compatible devices refuse to upgrade, they finally caved in and provided an update.
They caved, but they're still pulling out new tactics to trick users into installing iOS 26.
The new iOS 18 update will _also_ toggle Automatic Updates back on. I had it happen just now on my 13 Mini against my will. I had to go back into settings and very carefully navigate to disable automatic updates.
Interesting. Judging by the time of your post I assume that you're American. I'm in Europe and automatic updates stay disabled for me. I just upgraded 3 devices without any problems.
There seems to have been a change of mind, maybe also due to the severity of the exploits. The non-availability of security updates for models that are upgradable to a newer major version has been Apple's practice for many years now.
The way major upgrades are presented in the Settings UI makes it clear that users installing these security updates while not upgrading to a newer major version do so very intentionally. So Apple is now supporting these users deliberately.
Apple has repeatedly shown - as in this case - that when police are able to find a way to use their subpoena and coercive powers over Apple to subvert a user’s privacy expectations and extract data from an iPhone, that they see that as a failing of iOS and are willing to fix that bug.
In this case they are patching out a data extraction path that was exploited to access data a user thought had been deleted.
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.
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.
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.
Agree. Peoples are trusting App with unknown source code & delivery path, infrastructure controlled by 3rd party. Application cannot protect against OS and OS cannot protect against HW. Too many known unknowns. Seek the arguments how and why OTF got re-funded last time.
Except, you cant really verify all of that. so IMHO that's just speculation based on the surfacing of news which can easily be distorted. Or maybe you can. Is there any sources on people that have evaluated the security of these features.
You can’t verify that even on an open OS as there will still be closed hardware blobs. At least with popular systems there’s a lot of state level hacking activity so zero days get patched routinely. Also Apple has a program for researchers where they get more access to the system (That program was criticized heavily though for the way it was implemented).
It’s not a perfect system so right now you still have to trust someone at some point in the chain.
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?
Cellebrite sells their lower-level devices to Apple directly for things like data transfer at Apple Stores. The ones above that are unlikely to be sold to Apple.
> Cellebrite sells their lower-level devices to Apple directly for things like data transfer at Apple Stores.
Please substantiate that claim. Why would Apple need mystical third party devices to transfer data? They've designed both the user devices and the software, and they're both capable of exchanging data, and I'm sure Apple can do even more once they put the devices in diagnostic mode. What am I missing? What is Cellebrite providing here?
Because it’s a pain in the arse to design, manufacture and build a specialist device just for use in your stores.
I’m sure Apple could do everything that box does and more. But why bother designing, building and manufacturing your own specialist device when someone else already sells a perfectly good tool that does the job.
Don’t forget this is for use in a retail store by people who will have been given 5mins training on how to use the device. You want something that just requires a person to plug two phones in and hit a big “go” button. And it needs to work 99% of the time with zero messing around.
They built specialized tools to update iOS through the cardboard box without opening it before it goes on sale. I’m sure they can build something with a big “go” button if it’s important.
Nobody is arguing whether or not Apple could build the box. Apple could do almost anything that another company does. "Why doesn't Apple build their own planes to ship iPhones". Well, obviously because it's way cheaper, faster, and rational to use the perfectly good existing planes/boxes/you-name-it.
That’s true, but it seems unlikely to me that they would partner with the company that helped the FBI unlock iPhones and is in general an adversary to Apple.
> Nobody is arguing whether or not Apple could build the box.
People aren’t debating whether or not Apple could theoretically find a way to transfer data between the devices they make and sell. The question here is if there is any evidence for the assertion that Apple buys Cellebrite devices in lieu of making their own solution for transferring data between the devices that they make and sell.
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.
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.
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.
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
To be fair, the day after Glasswing was announced [1] iOS 26.4.1 was released [2]. Three weeks later, we have 26.4.2. When I saw the update prompt, my first thought was security fixes from Mythos. (In reality, the data do not show that Apple is releasing iOS 26 versions more frequently after Project Glasswing was announced than it was before. If we see another release in two weeks, I think we can conclude at least a statistically-meaningful signal.)
I think people are too focused on the device part of it.
Whatever Apple did to block access to the cache does not negate the fact that these notification messages are still being sent in plaintext through Apple and Google’s servers.
It’s hard to imagine that Apple/Google couldn’t just be compelled to hand this information over if ordered by a court and wouldn’t need your phone at all.
And this loophole possibly only hinges on the fact that most law enforcement maybe never realized this was something they could ask for.
Or perhaps this is happening and the public just doesn’t know it yet.
> 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.
This was already the case for 18.7.7. However, after turning automatic updates off in 18.7.7, after updating to 18.7.8 it remained off (reproducibly on several devices I updated). Maybe there is a one-time flag that is set so that after turning off automatic updates after having been turned on automatically, they aren't automatically turned on again on subsequent updates.
Avoid iOS 26 at all costs. I was forced to update to it because I needed to factory reset my phone, and it's super buggy. I'm not even one of those people harping on the Liquid Glass design decisions, those are w/e, the problem is just that the phone routinely freaks out doing basic tasks like trying to open the camera app or close the keyboard. They should roll it back.
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.
> 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.
This incorrect on two counts:
1. As per what you wrote immediately before the quoted text, the issue was that the OS keeps track of notifications locally. Google/Apple's notification servers have nothing to do with this
2. It's entirely possible to still have end-to-end messaging even if you're forced to send notifications through Google/Apple's servers, by encrypting data in the notification, or not including message data at all. Indeed that's what signal does. Apple or Google's never sees your message in cleartext.
If Signal wants to show you a notification with message text, it needs to put it on the screen through an OS service. That service was storing the plaintext on the device.
Through an OS service yes, but not a hosted backend service. Obviously that service has store the notification in plaintext (although everything on an iPhone is encrypted at rest, but notification crypto keys have to stay in active memory for the lock screen to work), otherwise it wouldn’t be able to display the notification text.
Apple support applications sending encrypted notifications, where the OS launches the app the decrypt the notification body locally and pass it back to the OS for display.
I think the idea here is that the notification text was also being put somewhere else that was not really tied to the lifetime of it being shown on screen.
They have to. The device storage is itself encrypted, so the FBI already broke into the phone. When the device is unlocked, notifications are visible by design and therefore available in plain text to the user. The edge case is with disappearing messages, a feature Apple did not build for. The message is intended to be plainly visible to the user, but only for a controlled time on the assumption that the users privileges may eventually be compromised.
This makes for a very odd and specific interaction with a 3rd party feature. Security is a hard problem.
Signal (at least on iOS) has a setting called "Notification Content" which defaults (unsafely in the light of this bug) to "Name, content, and Actions", but allows you to select either "Name Only" or "No Name or Content".
I assume that "Name only" option results in the push notification only sending "Signal message from Bob", and the "No Name or Content" one only sending "You have a new Signal message" - instead of the whole "Signal message from Bob: Let's rob the bank tomorrow!"
If I could have it work the way I'd prefer, Signal would let me set those Notification Content on a per contact and per chat basis - so I could set my bank robbing crew and group chats to "No Name or Content" while leaving mom and the family group chat on "Name, content, and Actions".
(But realistically, if I _did_ have a bank robbing crew they'd all be on my burner phone, not the phone I do family group chat with.)
This is correct, but my understanding of it is that the push notification (which is not the same thing as the actual "Notification" that is shown on the screen) basically contains a "hey $DEVICE, go talk to $APP_NOTO server they got something for you".
APNS just taps on the device's metaphorical shoulder and hands them a courtesy phone "call for you sir"
That’s not how it works. Not on iOS anyway.
For a standard notification the content of that notification is sent through the push notification servers. This includes the title, text, icon, grouping, and sound presets to use. The majority of user-visible notifications are sent this way - the app on the device does not run.
That allows the OS to display your notification without ever running the app, which saves limited resources on the phone. Originally this was the only option, a push notification couldn’t start your app.
These days an app can also register a notification extension which is a standalone program that can modify the incoming notification. It has 30 seconds to do whatever it needs to, though you need to be careful with RAM use or the OS will kill the process and present the notification unaltered. Generally you’d put something generic in the push as a fallback.
There’s also background notifications. These let the app run for 30 seconds and the app can post a local notification during this time, but they’re not guaranteed to be delivered. The OS can decide the system doesn’t have the resources and defer or drop them, or terminate the app before it’s finished if the ram is needed elsewhere.
There are some other special cases depending on what your app does.
More details are documented in the ntfy docs: https://docs.ntfy.sh/config/#ios-instant-notifications
Yes, but that service is running locally.
> it needs to put it on the screen through an OS service. That service was storing the plaintext on the device.
Technically, so can the OS's text drawing primitive while drawing Signal's UI.
Yes, but it shouldn't ;)
You are correct, but you omitted one complication: Clients trust Google's and Apple's servers to faithfully exchange the participants' public keys.
Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption.
Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext.
This is how it used to work; notifications can be encrypted now and Signal uses an extension to decrypt them.
A Signal developer 12 days ago said Our FCM and APN notifications are empty and just tell the app to wake up, fetch encrypted messages, decrypt them, and then generate the notification ourselves locally.[1]
[1] https://news.ycombinator.com/item?id=47723445
Ah, yes, they would be right. I feel like I had read that someone had migrated at some point, maybe it was WhatsApp or something.
Sending public keys through the notification system is an unnecessary complication.
Which clients?
Isn’t that what Contact Key Verification solves? Or do I misunderstand how that works?
... and hold participants' private keys truly private, which you cannot verify without a rooted phone.
You don’t need a rooted phone. An open source OS with reproducible builds is enough. That way you can validate what the code does without giving up verified boot, or opening up another attack vector, etc.
What about when my notifications are showing up on my MacBook next to the phone via mirroring?
talking totally out of my ass, but apple seems to have robust infrastructure for e2ee communication between your devices, for example it is known that location information in find my is not visible to apple. I’d be surprised if the channel to send iphone notifications to your mac wasn’t also e2ee
Unless something has changed since I last did this, the app's server initiating the apns doesn't encrypt using some public key for the destination. So no e2ee at that layer. But you could encrypt the payload and have the app decrypt it if you're managing the keys yourself.
The real question is why iOS caches notification payloads to a persistent SQLite DB in the first place. The notification content only needs to live long enough to render the banner and be shown in the lock screen shade. Persisting it to disk for a month past dismissal isn't a "bug", it's a design choice that someone signed off on. Signal can set UNNotificationContent to show empty/placeholder text, but the default path for any app that hasn't opted out hits this cache. Worth reading the 404 Media piece for the forensic tooling details, this isn't a 0day, it's Cellebrite reading a plist.
Both Apple and Google offer the ability for your app to intercept and modify messages before being displayed. Use that to send encrypted messages and decrypt them there, using your own code on the user’s device.
That framing Makes it sound like the app developer has to do something active to keep message cleartext out of notifications. That's not how it is on Android.
A Firebase Cloud Messaging push notification contains what the app developer's server puts in it. That could include the message body or it could just be an instruction to the app to poll the server for new messages. It has nothing to do with the notification that's displayd on an Android device. Those are entirely local.
An app that cares about privacy wouldn't send anything more than a poll instruction over FCM.
You can implement either approach on iOS as well.
But if you have strong end-to-end encryption for messages, then you don’t have to care about the transport anymore, you assume they’re all compromised. At that point you might as well use the push notification system as your transport, given both OSs allow applications to intercept the push notification locally and decrypt it before it’s displayed to the user.
Plus, decrypting using a key stored locally cuts out a network roundtrip, which has battery and data usage impacts.
This has performance/reliability tradeoffs.
In fact this is what both iMessage and Signal (and maybe Whatsapp too but I can’t tell from a quick google) do.
The fact that you received messages at specific times can be enough to identify you, if you have the data from the sending side.
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.
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
> set your notifications to only show that you have a message, not what it contains or who its from.
I'm pretty sure that's the default in GrapheneOS. Or at least that's how mine behaves.
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.
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.
This is misinformation, and is false.
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.
But in the real world, for maximal battery savings and therefore UX, routing any notification data via APNS is recommended.
Fortunately you can choose the payload by yourself and just send a notification "ping" without any data about the messages. But if we're serious about security, you just don't ping the client about new messages because even the time and existence of a notification can be compromising. _The user will know that they got a message, when they open the app and see that they got a new message._
Telegram secure chat messages do this by default.
Oh please, Telegram being mentioned positively during a discussion of security, privacy or state surveillance? Telegram is a security nightmare, it’s not e2ee no mater what BS their very very untrustworthy founder keeps spouting, it’s not default and what they do offer is probably not secure. Servers owned by Russian oligarchs loyal to Putin. Durovs rebel persona, where he’s persona non grata in Russia is also BS. He was shown to be freely traveling in and out of Russia and having negotiations with the Russian government around censorship of Telegram all while Durov was telling us he couldn’t return. And the Russian FSB won’t use it because it’s known in their circles as being compromised.
https://www.youtube.com/watch?v=a2eBDU5ea0A&t=392s
> "That largely depends on what an officer does outside of work. If someone is involved in corrupt dealings, and in fact, I know very few who aren't, then they reason like this. Can this messenger be monitored by internal security officers? Previously, many used WhatsApp. Almost no one used telegram because there's a wellfounded belief that this messenger is to some extent controlled by the Russian authorities. People used signal. Some use three months, but all that has now been shut down again. Why is it monitored? I think they're worried about a possible coup and trying to limit the ability to coordinate mass actions via communication channels from abroad. Hence the Max messenger. So now most security officers have switched to Chatty. That's a Dubai based messenger, but it's definitely not a universal remedy. Some have moved to Zangi, which is [clears throat] an Armenian app that markets itself as American. When it comes to targeting the opposition, the state will always find the resources. It's one of the main priorities, more important than any financial or commercial issue, even more than counterterrorism."
You are right in that it is Google’s and Apple’s OS notification api, and we do give them the plaintext messages.
Seems like you should use an app like Signal for anything sensitive at all so you don't have to worry about megacorp ecosystems as much.
As mingus88 said, this story is literally in response to Apple leaking messages sent through Signal. Doesn't matter if the message is securely transmitted if the operating system then keeps it lying around in plain text in a cache.
From the linked article:
> The independent news outlet reported that the FBI had been able to extract deleted Signal messages from someone’s iPhone using forensic tools, due to the fact that the content of the messages had been displayed in a notification and then stored inside a phone’s database — even after the messages were deleted inside Signal.
This article is about Apple fixing what they considered a bug, that signal messages were cached locally.
You can easily configure Signal not to show the message contents if you want, though.
The original comment mentions this but gives the wrong reasoning. The APNs are encrypted either way, but this setting prevents Signal from decrypting them client-side and letting the notification cache store it. Yeah this is more secure because it means not trusting Apple to do their job right with local storage, but it's also kind of a reasonable thing to trust.
Except even when you turn off message previews, it has to be specifically from within Signal settings. Not the iOS settings for notifications for the Signal app. To the user it looks the same, so it’s easy to make the mistake of turning off the previews in iOS settings instead of from within Signal settings. I didn’t even know there was a difference between the two until the recent posts about it.
That's what Signal does on my iPhone, I thought it was the default?
Nope, Signal messages were stored in the phones notification DB even after the app was deleted
https://www.404media.co/fbi-extracts-suspects-deleted-signal...
totally agree
This is also an oversimplification. If I understand the issue correctly, the notification with the message contents was what was cashed locally and then accessed. This same vulnerability would exist with Signal if you had the notifications configured to display the full message contents. In this case, it has nothing to do with either Apple or Signal.
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.
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 tweet seems to imply it’s logs, json, plist and SQLite DB.
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
I don’t think they are correct
You're speculating. "Marked for deletion" could mean after you dismiss it, not just after you delete the whole app.
i'll speculate further: it could've been on the dismiss notification code, and when you delete the app the OS dismisses the removed app's notifications, triggering the same code path.
in this case as per reporting, defendant removed the app. unclear if they first dismissed them.
SQLite WAL?
Why do you think they aren't the same thing?
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?
Something of that sort.
> I had thought the push notifications were end-to-end encrypted
Much of the metadata is plaintext, in both Apple and Google's Push Notification architecture.
My understanding is that in Signal's implementation of push notifications the message text is end-to-end encrypted by Signal and decrypted on device by the Signal app. The decryption is not handled by the OS's push notification system.
If I am reading this right, your understanding is incorrect. Signal's "new messages" push message payload is empty. Upon receiving a message of this type, the Signal app wakes up, fetches the actual messages, and (optionally) displays local notifications for them.
At no point does the push message payload contain message text or metadata, encrypted or not.
This is correct, but the timing of a notification that there is a new message is itself metadata.
So that means iOS is caching the local notifications, not the push event... I wonder why it was needed to begin with, especially for a month
Note that Signal offers the option to use generic “You’ve received messages” notifications - it’s good practice in general.
So does every app, go to iOS settings > notifications shows previews > never.
Most likely changes the preview on the client-side, but the message is still full on the server-side
Signal does not have the plaintext of the messages and therefore could not send it as part of the notification.
Correct, parent comment is spreading misinformation/false sense of security.
Is setting it from Signal directly more trustworthy?
Or maybe it’s impossible for iOS to store the preview content if it never showed in the first place, but not sure if it’s even documented.
I wish it can be disabled for particular apps and not an all or nothing situation.
Can be!
Settings > Apps > choose an app > Lock Screen Appearance: Show Previews - Never
The message text is still sent to the push notification server from the app's infrastructure - this setting simply stops the phone from displaying the message.
The app itself must choose not to send the message text in the push notification.
That setting is available for each individual app.
That's the first thing that came to mind. Glad that they already thought about it!
And if you turn off notifications, Signal is more than happy to nag at you for having notifications turned off.
Nice. Will Apple now also fix the "bug" where you delete a message on your phone, and 3 months later it downloads on your iPad or Watch, and you can never be sure your messages are really gone?
Before anyone asks: No , I didnt turn on any setting to save all my messages to some external server and download them whenever, even if I delete them locally
Is it a bug or a feature though? What's more common: wanting to delete a message and have it stay gone, or accidentally deleting the message you wanted to preserve? For most people the latter is more likely than the former.
This is a problem with all kinds of apps. There is no discipline in the handling of user data. Take the notes app. When you delete text it not gone you can still see it in the sqlite database they use for storage. I'm sure this is so they can support sync be recording your changes as CRDTs or something.
And if the app isn't leaky, the OS will probsbly screw you like in this case. The concept of being able to clean up your laptop is just not supported, you have to wipe the whole device which is ridiculous.
Signal deletes the message. Apple keeps the notification that shows the message. For a month. On-device. This is exactly the kind of bug that isn't a bug it's what happens when privacy is owned by the app but the OS isn't aligned.
It seems so weird that it caches for so long. Notifications are rare enough that you could clean it out of the cache as soon as it's dismissed. It's not like it's something that's happening every few ms
So for third party apps this seems like if you do e2e then along with this bug fix your texts are safe. E2E apps could be independently verified by a third party let’s say.
But what about iMessage. The source code will never be available for neither the servers nor the app.
I’m frustrated that Signal isn’t notifying users about this.
I disabled notifications and instead Signal reminded me to re-enable them…
The issue is only an issue if your phone is physically taken, then unlocked and the message notifications extracted from a iOS cache database. Todays update by Apple fixes issue for every app, not just Signal.
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).
Some people talking about it (different but in the same scope of issue): https://blog.davidlibeau.fr/push-notifications-are-a-privacy...
I expect that Signal encrypts the notification data prior to sending it to Apple, then decrypts it on-device using a Notification Service Extension – this is a common pattern to avoid trusting Apple with any sensitive data.
That would mean Apple stored the cleartext on-device after decryption.
Signal doesn’t provide anything in the message other than… “there are pending messages.” Signal wakes up, fetches them, then generates notifications on the phone itself.
in the case reported the content did not leave the device. feds retreived them directly from the phone.
+ Messengers like Snapchat and WhatsApp;
despite "end-to-end" encryption (for WhatsApp) they are sending copy of some messages based on keywords to authorities, PRISM-like.
Officially to protect kids, but who knows what is in this keywords list.
Thankfully Apple backported the fix the iOS 18 as well.
Not only that, but iOS 18.7.8 actually seems to be available to devices capable of running iOS 26 without any workarounds, unlike 18.7.3 through .6. It makes me wonder if those intermediate releases really were supposed to be available but weren't due to some issue on the distribution side that no one bothered to fix.
Very serious vulns were being exploited in the wild, I think that's what forced their hand. I don't think Apple ever had a discrepancy like the one with iOS 18.7.3 through .6 being held back.
For those on iOS 18, beware that the update to iOS 18.7.8 will toggle Automatic Updates back on. Make sure to switch it back off so you don't wake up to a nasty surprise when iOS 26 is non-consensually forced onto your iPhone.
I just updated to iOS 18.7.8 and automatic updates are still off. Updates used to enable Bluetooth but event that's not the case anymore.
I think that was another attempt by Apple to push users to iOS 26, but after seeing how many people with compatible devices refuse to upgrade, they finally caved in and provided an update.
They caved, but they're still pulling out new tactics to trick users into installing iOS 26.
The new iOS 18 update will _also_ toggle Automatic Updates back on. I had it happen just now on my 13 Mini against my will. I had to go back into settings and very carefully navigate to disable automatic updates.
Interesting. Judging by the time of your post I assume that you're American. I'm in Europe and automatic updates stay disabled for me. I just upgraded 3 devices without any problems.
There seems to have been a change of mind, maybe also due to the severity of the exploits. The non-availability of security updates for models that are upgradable to a newer major version has been Apple's practice for many years now.
The way major upgrades are presented in the Settings UI makes it clear that users installing these security updates while not upgrading to a newer major version do so very intentionally. So Apple is now supporting these users deliberately.
Who cares, Apple as any other US company must cooperate with "cops" or 3-letter agencies.
Not publicly, of course.
Ask yourself, do you really own your device? Can you access kernel? Can you flash your own firmware on your device? No?
Then you DON'T own it.
Apple has repeatedly shown - as in this case - that when police are able to find a way to use their subpoena and coercive powers over Apple to subvert a user’s privacy expectations and extract data from an iPhone, that they see that as a failing of iOS and are willing to fix that bug.
In this case they are patching out a data extraction path that was exploited to access data a user thought had been deleted.
That was definitely necessary, becuase the major reason people buy iphones is privacy and security
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.
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.
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.
I would never rely on a closed system for secure messaging to many unknowns.
Agree. Peoples are trusting App with unknown source code & delivery path, infrastructure controlled by 3rd party. Application cannot protect against OS and OS cannot protect against HW. Too many known unknowns. Seek the arguments how and why OTF got re-funded last time.
And yet iOS is probably the most secure mobile platform for secure messaging. Especially in lock down mode.
Except, you cant really verify all of that. so IMHO that's just speculation based on the surfacing of news which can easily be distorted. Or maybe you can. Is there any sources on people that have evaluated the security of these features.
You can’t verify that even on an open OS as there will still be closed hardware blobs. At least with popular systems there’s a lot of state level hacking activity so zero days get patched routinely. Also Apple has a program for researchers where they get more access to the system (That program was criticized heavily though for the way it was implemented).
It’s not a perfect system so right now you still have to trust someone at some point in the chain.
> At least with popular systems there’s a lot of state level hacking activity so zero days get patched routinely
Not sure how you're implying one leads to the other.
have you ever thought maybe Apple is creating a backdoor like this to make secret deals with gov orgs.
trusting a valley company is the last thing you could do since there is a ton of money to be made from selling secrets
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?
Cellebrite sells their lower-level devices to Apple directly for things like data transfer at Apple Stores. The ones above that are unlikely to be sold to Apple.
> Cellebrite sells their lower-level devices to Apple directly for things like data transfer at Apple Stores.
Please substantiate that claim. Why would Apple need mystical third party devices to transfer data? They've designed both the user devices and the software, and they're both capable of exchanging data, and I'm sure Apple can do even more once they put the devices in diagnostic mode. What am I missing? What is Cellebrite providing here?
Because it’s a pain in the arse to design, manufacture and build a specialist device just for use in your stores.
I’m sure Apple could do everything that box does and more. But why bother designing, building and manufacturing your own specialist device when someone else already sells a perfectly good tool that does the job.
Don’t forget this is for use in a retail store by people who will have been given 5mins training on how to use the device. You want something that just requires a person to plug two phones in and hit a big “go” button. And it needs to work 99% of the time with zero messing around.
They built specialized tools to update iOS through the cardboard box without opening it before it goes on sale. I’m sure they can build something with a big “go” button if it’s important.
Nobody is arguing whether or not Apple could build the box. Apple could do almost anything that another company does. "Why doesn't Apple build their own planes to ship iPhones". Well, obviously because it's way cheaper, faster, and rational to use the perfectly good existing planes/boxes/you-name-it.
That’s true, but it seems unlikely to me that they would partner with the company that helped the FBI unlock iPhones and is in general an adversary to Apple.
> Nobody is arguing whether or not Apple could build the box.
People aren’t debating whether or not Apple could theoretically find a way to transfer data between the devices they make and sell. The question here is if there is any evidence for the assertion that Apple buys Cellebrite devices in lieu of making their own solution for transferring data between the devices that they make and sell.
They did?
Yes!
https://www.macworld.com/article/2107557/iphone-ios-update-i...
https://talk.macpowerusers.com/t/apples-in-box-device-update...
Apple was not always a 4 trillion dollar company.
Do you have a link that talks about this in more detail?
Sure: https://www.zdnet.com/article/more-evidence-that-apples-morp.... Also you can just ask people who've worked in the stores: https://old.reddit.com/r/gadgets/comments/sodt49/most_us_cab...
That is an article from 2010, the same year that “The US military buys PS3s for compute” was a true statement.
https://phys.org/news/2010-12-air-playstation-3s-supercomput...
It’s like saying “Single Ladies” by Beyoncé is topping the charts.
Do you have a link that talks about Apple buying cellebrite devices presently?
No, I don't think they are using Cellebrite devices currently.
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.
I bet Apple has access to Mythos now.
Not saying they should use it to reverse engineer hacking tools.
Just saying they have access to Mythos now.
You bet that the company that was prominently mentioned as a parter in the announcement for a thing, has access to that thing?
Wow, such a risky bet, I'm not sure it'll pay off.
Makes you think what’s the biggest concerns wrt Mythos — is it finding or fixing the vulnerabilities that’s scarier :))
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.
If you want security through obscurity you can revert to IPoAC (RFC 1149).
Speech capable avians can spontaneously leak secrets
> probably an unsolvable category of bug as long as notifications need to show readable text somewhere.
Let screens always show garbled pixel vomit, decoded on device only by your private AR glasses
threat model just shifts to whoever has a camera pointed at your face, but probably still an improvement.
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.
Cat and Mouse, good. This is the adversarial setup that results in a better outcome for all.
I wonder if the same flaw exists on Android/GrapheneOS.
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
What did Anthropic have to do with any of this?
> What did Anthropic have to do with any of this?
To be fair, the day after Glasswing was announced [1] iOS 26.4.1 was released [2]. Three weeks later, we have 26.4.2. When I saw the update prompt, my first thought was security fixes from Mythos. (In reality, the data do not show that Apple is releasing iOS 26 versions more frequently after Project Glasswing was announced than it was before. If we see another release in two weeks, I think we can conclude at least a statistically-meaningful signal.)
[1] https://www.anthropic.com/project/glasswing
[2] https://en.wikipedia.org/wiki/IOS_26#Version_history
It was an attempt at humor and banter, should've flag that or something.
Finally!
It is completely unclear from this article whether this means Apple does no longer cache dismissed notifications somewhere.
I like apple, but would never trust them with privacy. NYPD uses ISMI catchers and other tech. This is a nothing burger or nothing donut.
I think people are too focused on the device part of it.
Whatever Apple did to block access to the cache does not negate the fact that these notification messages are still being sent in plaintext through Apple and Google’s servers.
It’s hard to imagine that Apple/Google couldn’t just be compelled to hand this information over if ordered by a court and wouldn’t need your phone at all.
And this loophole possibly only hinges on the fact that most law enforcement maybe never realized this was something they could ask for.
Or perhaps this is happening and the public just doesn’t know it yet.
bug or backdoor?
"Never attribute to malice that which is adequately explained by stupidity."
Good. Now, are they fixing any of their other gazillion bugs?
This has nothing to do with Apple/Firebase notification service.
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.
> 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.
Heads up. They have released an iOS 18 update (good!) but, and please bear the caps:
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.
This was already the case for 18.7.7. However, after turning automatic updates off in 18.7.7, after updating to 18.7.8 it remained off (reproducibly on several devices I updated). Maybe there is a one-time flag that is set so that after turning off automatic updates after having been turned on automatically, they aren't automatically turned on again on subsequent updates.
Huh, my experience was the opposite. I don't think Apple undid my setting with iOS 18.7.7, but they did with iOS 18.7.8.
Thanks for the warning!
Avoid iOS 26 at all costs. I was forced to update to it because I needed to factory reset my phone, and it's super buggy. I'm not even one of those people harping on the Liquid Glass design decisions, those are w/e, the problem is just that the phone routinely freaks out doing basic tasks like trying to open the camera app or close the keyboard. They should roll it back.