alt Hacker NewsThis 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.
Replies
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.
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
> 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.
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
> 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.
> 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.
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.
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.
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.
> 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.