While it's definitely surprising that the OS caches this data after the notifications have been swiped away, I always thought that notifications are an obvious hole in the whole E2E encryption setup.
AIUI, Signal push notifications just saying a message was received. Signal then fetches the E2E encrypted message from the server and decrypts it locally. So Apple/Google cannot read the messages, nor can Signal servers.
AIUI, Signal decrypts the E2EE message locally, but then sends the decrypted message to iOS in order to display the notification to the user. iOS then stores this data and it persists after the user dismisses the notification.
This makes sense and there's really no way around it without a change from Apple. If iOS is going to show the user a Signal notification with the decrypted message in the notification body, then iOS must be given the decrypted message. iOS could (and probably should) delete that data off the device as soon as the user dismisses/engages with the notification. But it sounds like they do not.
I agree. My point is that this isn't an "obvious hole in the whole E2E encryption setup", because no network actor (e.g. Google, Apple, Signal servers) can read the data.
This "hole" in E2E is the same as any malware on the device. If the device cannot be trusted, no form of E2E will work. The E2E encryption is functioning properly. The problem here is completely unrelated to E2E encryption. E.g. you could have a personal notes app that makes no network traffic, but generates notifications occasionally regarding your notes, and it could have this same problem, even though no messages are sent over the network, and in fact the phone could have all networking capabilities disabled and still have this problem.
>This makes sense and there's really no way around it without a change from Apple.
There is a bit of a workaround: Signal has a setting to not put message content in the notification. That fixes this AIUI.
