Hacker News

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

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.

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.

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?

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.

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

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.

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

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.

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.

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.

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.

And yet iOS is probably the most secure mobile platform for secure messaging. Especially in lock down mode.

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.

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

> 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

What did Anthropic have to do with any of this?

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

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.