FBI used iPhone notification data to retrieve deleted Signal messages

I'm referring to what sounds like a feature of the app, not the OS... The app... already chooses what to send through the OS notification API so I really don't have any idea what scenario you're worried about.

I generally sympathize, I also don't like when apps block screenshots (or even more stupidly, they can block Android's amazing "select text from anywhere" feature...). But I don't think there are similar concerns for Signal allowing me to hide notification content from the OS.

I disable notifications on every app that is not on the critical path to me earning a living. Notifications are largely unnecessary. Either you are actively engaged with something, in which case you didn't need the notification, or you are doing something else and don't need the distraction, in which case you didn't need the notification. Only my employer gets a right to demand my time during work hours, which is why notifications are enabled during work hours for work apps.

We as a society have gotten way too comfortable expecting every single person to be available at all times to provide us some kind of immediate response. Let people live. If I'm hiking through the woods with my camera doing bird photography, even if you're my best friend you can wait until I get back to my car and manually check my messages, I don't need a notification. If it's an emergency, dial my number and call me, which will make my phone ring. Novel concept, I know.

[flagged]

iOS Data Protection — The Four Classes

Data Protection is implemented by constructing and managing a hierarchy of keys, building on the hardware encryption technologies built into Apple devices. It's controlled on a per-file basis by assigning each file to a class; accessibility is determined by whether the class keys have been unlocked.

The four protection classes, from strongest to weakest:

NSFileProtectionComplete — Files are only accessible when the device is unlocked.

NSFileProtectionCompleteUnlessOpen — A file can only be opened when the device is unlocked, but is not closed when the device is locked — it's encrypted when the last open handle is closed. Suitable for data being uploaded in the background.

NSFileProtectionCompleteUntilFirstUserAuthentication — The resource cannot be accessed until after the device has booted. After the user unlocks the device for the first time, the app can access the resource and continue to do so even if the user subsequently locks the device. Fortify This is commonly called AFU (After First Unlock). This is the default class for all third-party app data not otherwise assigned to a Data Protection class.

NSFileProtectionNone — The resource has no special protections. It can be read or written at any time. The encryption only uses a key derived from the device's UID.

The BFU/AFU Distinction — The Heart of the Signal Issue

Apple's iOS devices operate in two key security states that directly impact data accessibility: Before First Unlock (BFU) and After First Unlock (AFU).

When an iPhone is in the BFU state, it has been powered on or rebooted but not yet unlocked with a passcode. In this state, the Secure Enclave does not release the decryption keys needed to access most user data.

Once you've unlocked once (AFU), files protected with NSFileProtectionCompleteUntilFirstUserAuthentication become accessible, the Keychain is available, and background processes and apps can access encrypted content as needed.

The Signal notification content issue connects here because notification data (including previews) stored in the default CompleteUntilFirstUserAuthentication class remains decryptable by any process — including OS-level forensic tools — as long as the phone has been unlocked at least once since the last reboot.

Android also supports custom encrypted payloads so Signal doesn't have to give them to Google.