I wonder why Apple doesn't 'just' delete the notification data associated with the app from the internal database when the user deletes the app? It seems like asking for problems to just keep old notification content around forever.

It's one of those problems where as soon as someone notices, it's crazy that no one noticed. I can't imagine this not being overhauled going forward. It's just a bad way to operate and now it's news.

> I can't imagine this not being overhauled going forward.

On which end, Apple or Signal? Because neither Apple nor Google will overhaul this behavior, the FBI asked for it directly: https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...

This is different than push data, which already does not contain any content or metadata in Signal. This is about local OS caches, whereas for push notifications Signal only sends a push saying “message received” which wakes the device up and triggers the device to pull the message from the server over the regular e2e encrypted path.

I think that's how the Android notification history works. If I uninstall an app, the entries in the history aren't shown anymore. You also have to opt in to notification history and toggling it off and back on clears the old entries. There's also a time window that it keeps entries for: https://source.android.com/docs/core/display/notification-hi...

If it never hits flash that might work, but if it's in flash storage then the block may not be erased by the time its dumped.

I'm not sure precisely how the NAND controller responds to requests for raw data from blocks with "deleted" data. And if this would require decapping the flash.

Some flash will happily let you see the data and delay erasing it.

Generally flash is non deterministic about when blocks even those with entirely stale data are erased . It might be years before the block is reused due to wear leveling algorithms and it might retain data that entire time.

Here's hoping the controller for phones which hold sensitive data are more active

If the "database" works like most other databases (eg. postgres or sqlite), deleting a row doesn't immediately cause the data to be wiped from disk, for performance reasons. Then as others mentioned you have filesystem/SSD logic that does something similar on top of that.

But you can do other things to mitigate this. For instance, give each app a set of rolling daily encryption keys, and encrypt new messages at rest. Remove the app, remove all keys. Nightly, remove the oldest key. Perhaps have the entire key database either stored in Secure Enclave, or if there isn't room, have the key database itself encrypted by a rotating single key in Secure Enclave. Now there's nothing that an attacker can do.