This is well known in the op-sec communities. iOS and Android notifications route through their servers and can be stored indefinitely (ie especially under a court order)
You need to disable the content previews if you want to be secure. But even the notification metadata can be quite valuable to law enforcement (who is messaging you, what time of day, etc.)
Also standard requirement on govt mobile devices to disable notifications. Mattermost provides this option at the server level to block notifications entirely for ios/android devices.
Ironically, I've got most notifications disabled because I simply find them annoying. I think SMS, phone calls and my CGM are the only things that cause my phone to regularly make noise.
If you run your own XMPP server, like Prosody, this issue is readily apparent. See, e.g., the options push_notification_with_body and push_notification_with_sender for https://modules.prosody.im/mod_cloud_notify
The article is specifically not referring to information that's sent to Apple servers - it's about information on the phone only, accessible through forensics tools with physical device access.
Signal's server-side push notifications only contain a "wakeup" message. The actual message popup is displayed after decrypting the message contents locally on the device. Of the things you mentioned, only the time of notification is visible to Apple/Google.
Fun fact, apps can't wake from APNS if the user killed the app (swipe up) last time instead of switching away normally. Apple publicly said something contrary to this at one point, so it might be surprising that Signal can work this way. The notification itself will still come through outside the app, so I wonder what you see, probably some placeholder text?
You're thread-sliding, friend, and trying to diminish the major blow-up here. ALL notifications from banks, WhatsApp, Telegram you name it are stored indefinitely, and anyone with physical access to the phone and a cable can extract your entire history. This is NOT the same as them being stored at Apple or the NSA. Any shithead with a cable can do it.
So we are talking about that any police with a cable can read ALL my past notifications, WhatsApp, Telegram, all banks? Like indefinitely in the past? And there is no way to flush the database? Wow thanks Apple.
Sort of. Apple's and Google's notifications infrastructure only delivers to signed applications. Even if you run your own IM server, you can't use your own open source client without building and signing it yourself, and then setting up the backend infrastructure, which requires using the developer certificate for the application to generate authentication credentials to Apple's and Google's notification service. IIUC (and I think as you point out) the way it works for XMPP is a client informs the server about its gateway, which will be run by the client publisher; when the XMPP server wants to generate a notification, it contacts that gateway which then pushes the notification through Apple's/Google's service API for delivery to the client. For a nominally self-hosted IM server, notifications are traversing two third parties, either of which might be logging the metadata, which may include the full body of a message, depending on the application's frontend and backend architecture and configuration.
So in a sense it is part of the application, especially if you're a small entity with a single app (as opposed to large entities like Facebook where you have dozens of applications under a complex hierarchy of developer and application certificates).
I can understand why things are done this way. It helps to avoid abuse and spam as there's no way to inject notifications without strict accountability. But it does kind of suck. To fully self-host IM, you need to build, sign, and distribute the client yourself, as well as run a notification gateway with the appropriate credentials. And I'm not aware of any plug-and-play open source solutions for the gateway, at least not for XMPP. (I could be mistaken, though.) Maybe Matrix servers have it builtin, but I wouldn't be surprised if they don't, especially the reference implementation, as this complexity provides a moat for monetization.
possibly. the problem, though, is that 85% of signal's users would A. hate it and B. not know how to shut it off (even if you told them). that's part of the problem with trying to deliver security to the masses (and similar to the backup problem that they used to have).
fwiw, as far as I can remember, the signal foundation's position has always been "once someone has physical access to your device, all bets are off."
The article doesn't actually give a coherent answer on why.
People would generally claim "lazyness", as that is the Apple way. Why fix code when you can just sell new phones?
The actual answer is plausible deniability. Closed source software often leaks metadata in hard to discover ways so governments can deprive citizens of their rights under the law, and then claim "whoops, we didn't clean up correctly, our bad!".
Apple, like every other major tech company, goes along with it when nudged in the right direction.
Why would it keep the notification history after they’ve been dismissed, though? There’s no user-facing way (that I’m aware of) to access a history of dismissed notifications.
Not if you want it to randomly lose its connection to signals servers and then fail to backup so you lose the ability to use Molly randomly when you least expect it and be completely dead in the water when you want to transfer your messages or reinstall it.
I agree, especially in this context. Allows you to avoid the insecure Google push notifications and keeps the proprietary Signal client more honest to prefer a community implementation of the protocol. It also lets you lock down your on-device data with an additional encryption layer.
This is well known in the op-sec communities. iOS and Android notifications route through their servers and can be stored indefinitely (ie especially under a court order) You need to disable the content previews if you want to be secure. But even the notification metadata can be quite valuable to law enforcement (who is messaging you, what time of day, etc.)
Also standard requirement on govt mobile devices to disable notifications. Mattermost provides this option at the server level to block notifications entirely for ios/android devices.
Ironically, I've got most notifications disabled because I simply find them annoying. I think SMS, phone calls and my CGM are the only things that cause my phone to regularly make noise.
If you run your own XMPP server, like Prosody, this issue is readily apparent. See, e.g., the options push_notification_with_body and push_notification_with_sender for https://modules.prosody.im/mod_cloud_notify
The article is specifically not referring to information that's sent to Apple servers - it's about information on the phone only, accessible through forensics tools with physical device access.
Signal's server-side push notifications only contain a "wakeup" message. The actual message popup is displayed after decrypting the message contents locally on the device. Of the things you mentioned, only the time of notification is visible to Apple/Google.
Fun fact, apps can't wake from APNS if the user killed the app (swipe up) last time instead of switching away normally. Apple publicly said something contrary to this at one point, so it might be surprising that Signal can work this way. The notification itself will still come through outside the app, so I wonder what you see, probably some placeholder text?
Yes there's a placeholder in that scenario Something like 'new message available' if I remember correctly (I'm no longer on iPhone, so can't verify)
You're thread-sliding, friend, and trying to diminish the major blow-up here. ALL notifications from banks, WhatsApp, Telegram you name it are stored indefinitely, and anyone with physical access to the phone and a cable can extract your entire history. This is NOT the same as them being stored at Apple or the NSA. Any shithead with a cable can do it.
*Google notifications, not all Android. Unified Push combined with a degoogled ROM works great to have convenience and security.
So we are talking about that any police with a cable can read ALL my past notifications, WhatsApp, Telegram, all banks? Like indefinitely in the past? And there is no way to flush the database? Wow thanks Apple.
Not that this makes it ok, but they still have to break into the phone's encryption, right? Idk, article is paywalled
> Signal had been removed, but incoming notifications were preserved in internal memory
Why are app notifications not part of app data that gets deleted on uninstall???
Notifications is a different app?
Notifications are not part of an app, it is a service provided by Apple/Google
Most notifications are sent by backend servers straight to Apple/Google
Sort of. Apple's and Google's notifications infrastructure only delivers to signed applications. Even if you run your own IM server, you can't use your own open source client without building and signing it yourself, and then setting up the backend infrastructure, which requires using the developer certificate for the application to generate authentication credentials to Apple's and Google's notification service. IIUC (and I think as you point out) the way it works for XMPP is a client informs the server about its gateway, which will be run by the client publisher; when the XMPP server wants to generate a notification, it contacts that gateway which then pushes the notification through Apple's/Google's service API for delivery to the client. For a nominally self-hosted IM server, notifications are traversing two third parties, either of which might be logging the metadata, which may include the full body of a message, depending on the application's frontend and backend architecture and configuration.
So in a sense it is part of the application, especially if you're a small entity with a single app (as opposed to large entities like Facebook where you have dozens of applications under a complex hierarchy of developer and application certificates).
I can understand why things are done this way. It helps to avoid abuse and spam as there's no way to inject notifications without strict accountability. But it does kind of suck. To fully self-host IM, you need to build, sign, and distribute the client yourself, as well as run a notification gateway with the appropriate credentials. And I'm not aware of any plug-and-play open source solutions for the gateway, at least not for XMPP. (I could be mistaken, though.) Maybe Matrix servers have it builtin, but I wouldn't be surprised if they don't, especially the reference implementation, as this complexity provides a moat for monetization.
Perhaps Signal should force the notification settings to "don't show the content" when disappearing messages are enabled in a particular chat?
possibly. the problem, though, is that 85% of signal's users would A. hate it and B. not know how to shut it off (even if you told them). that's part of the problem with trying to deliver security to the masses (and similar to the backup problem that they used to have).
fwiw, as far as I can remember, the signal foundation's position has always been "once someone has physical access to your device, all bets are off."
On IOS 26.3.1 - settings > notifications > signal
Show previews is set to Never (Default).
Sounds like Apple needs to start flushing that database regularly, at least by option. Perhaps as part of Lockdown Mode?
Can someone explain why notification databases are stored for a long period of time? The article is behind a paywall.
The article doesn't actually give a coherent answer on why.
People would generally claim "lazyness", as that is the Apple way. Why fix code when you can just sell new phones?
The actual answer is plausible deniability. Closed source software often leaks metadata in hard to discover ways so governments can deprive citizens of their rights under the law, and then claim "whoops, we didn't clean up correctly, our bad!".
Apple, like every other major tech company, goes along with it when nudged in the right direction.
I presume it's from here:
> Notification Center shows your notifications history, allowing you to scroll back and see what you've missed.
https://support.apple.com/en-ca/108781
Note that although Android has a similar "notification history" feature, it's disabled by default and requires opt-in.
Why would it keep the notification history after they’ve been dismissed, though? There’s no user-facing way (that I’m aware of) to access a history of dismissed notifications.
Does it, or did the defendant just not dismiss them? Maybe if you delete the app, the notifications aren't dismissed.
https://archive.ph/bSQhD
I think that https://molly.im/ is better than Signal Android.
Not if you want it to randomly lose its connection to signals servers and then fail to backup so you lose the ability to use Molly randomly when you least expect it and be completely dead in the water when you want to transfer your messages or reinstall it.
I agree, especially in this context. Allows you to avoid the insecure Google push notifications and keeps the proprietary Signal client more honest to prefer a community implementation of the protocol. It also lets you lock down your on-device data with an additional encryption layer.