> 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.

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.

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.

> 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.

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 fact that you received messages at specific times can be enough to identify you, if you have the data from the sending side.

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.

> 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.

> 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.

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.

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.

[dead]

Telegram secure chat messages do this by default.

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.

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

You're speculating. "Marked for deletion" could mean after you dismiss it, not just after you delete the whole app.

SQLite WAL?

Why do you think they aren't the same thing?

> 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.

Something of that sort.

So does every app, go to iOS settings > notifications shows previews > never.

And if you turn off notifications, Signal is more than happy to nag at you for having notifications turned off.

That's the first thing that came to mind. Glad that they already thought about it!

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.

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

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.

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.

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.

> 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

If you want security through obscurity you can revert to IPoAC (RFC 1149).

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.

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.

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.

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.

The thing is, this whole debate is happening above the baseband. Linux phones (Librem 5, PinePhone) tried to solve this and went nowhere, you can open-source everything above the modem, but the GSM/LTE protocol stack is still a proprietary blob with DMA access to your main memory. It's basically a second computer in your phone that's directly addressable by carrier infrastructure, and nobody gets to audit it. Doesn't matter if you're running iOS, Android, or postmarketOS. Qualcomm/MediaTek own that layer and it's not changing anytime soon.

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.

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.

"Never attribute to malice that which is adequately explained by stupidity."

What did Anthropic have to do with any of this?

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.

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.