Through an OS service yes, but not a hosted backend service. Obviously that service has store the notification in plaintext (although everything on an iPhone is encrypted at rest, but notification crypto keys have to stay in active memory for the lock screen to work), otherwise it wouldn’t be able to display the notification text.

Apple support applications sending encrypted notifications, where the OS launches the app the decrypt the notification body locally and pass it back to the OS for display.

I think the idea here is that the notification text was also being put somewhere else that was not really tied to the lifetime of it being shown on screen.

This thread is about Apple servers accessing the contents. Of course the OS has access to the contents of your messages, how else do you expect it to show a preview of the message? Do you want each notification to be a custom-rendered widget from the app?

If the contents are that sensitive you must disable the preview. Even then, the OS has access to the pixels in your app so it really is a moot point.

The caching issue here was evidently a bug.

I don't think there is anything here that I disagree with?

Yes, but that service is running locally.

This is correct, but my understanding of it is that the push notification (which is not the same thing as the actual "Notification" that is shown on the screen) basically contains a "hey $DEVICE, go talk to $APP_NOTO server they got something for you".

APNS just taps on the device's metaphorical shoulder and hands them a courtesy phone "call for you sir"

That’s not how it works. Not on iOS anyway.

For a standard notification the content of that notification is sent through the push notification servers. This includes the title, text, icon, grouping, and sound presets to use. The majority of user-visible notifications are sent this way - the app on the device does not run.

That allows the OS to display your notification without ever running the app, which saves limited resources on the phone. Originally this was the only option, a push notification couldn’t start your app.

These days an app can also register a notification extension which is a standalone program that can modify the incoming notification. It has 30 seconds to do whatever it needs to, though you need to be careful with RAM use or the OS will kill the process and present the notification unaltered. Generally you’d put something generic in the push as a fallback.

There’s also background notifications. These let the app run for 30 seconds and the app can post a local notification during this time, but they’re not guaranteed to be delivered. The OS can decide the system doesn’t have the resources and defer or drop them, or terminate the app before it’s finished if the ram is needed elsewhere.

There are some other special cases depending on what your app does.

More details are documented in the ntfy docs: https://docs.ntfy.sh/config/#ios-instant-notifications

> the app on the device does not run.

That explains an oddity I was experiencing.

Work uses Webex. I had work webex installed on my phone. My password changed on my account in the office, if i try to open Webex on my phone I would be prompted to re-authenticate which I would never do because it required 2FA and the token generator is on my laptop which I generally wouldn't have with me when using my phone.

However, despite not being able to open the app as my account, I was still getting full messages in the push notification for anyone who had messaged me recently while the app was functioning. Anyone new would pop up as 'Message From X'.

Isn't some of this information encrypted, if the app developer chooses?

The notification contents are sent over secure channels but are not end-to-end encrypted.

You can add additional data to the payload and have a helper app decrypt on the device when a notification is received.

> it needs to put it on the screen through an OS service. That service was storing the plaintext on the device.

Technically, so can the OS's text drawing primitive while drawing Signal's UI.

Yes, but it shouldn't ;)

Agreed 100%, but my point is that you have no option but to trust your OS.

Sure, but you can still complain when it does something unreasonable.

They have to. The device storage is itself encrypted, so the FBI already broke into the phone. When the device is unlocked, notifications are visible by design and therefore available in plain text to the user. The edge case is with disappearing messages, a feature Apple did not build for. The message is intended to be plainly visible to the user, but only for a controlled time on the assumption that the users privileges may eventually be compromised.

This makes for a very odd and specific interaction with a 3rd party feature. Security is a hard problem.

Signal (at least on iOS) has a setting called "Notification Content" which defaults (unsafely in the light of this bug) to "Name, content, and Actions", but allows you to select either "Name Only" or "No Name or Content".

I assume that "Name only" option results in the push notification only sending "Signal message from Bob", and the "No Name or Content" one only sending "You have a new Signal message" - instead of the whole "Signal message from Bob: Let's rob the bank tomorrow!"

If I could have it work the way I'd prefer, Signal would let me set those Notification Content on a per contact and per chat basis - so I could set my bank robbing crew and group chats to "No Name or Content" while leaving mom and the family group chat on "Name, content, and Actions".

(But realistically, if I _did_ have a bank robbing crew they'd all be on my burner phone, not the phone I do family group chat with.)

This wasn't a disappearing messages case, this was a case where they had uninstalled Signal entirely, including all their messages. But Apple was storing the received message text from the notification in its local database. I don't think it is edge case, in that if someone uninstalls their Whatsapp or Signal or whatever, or they delete a chat/message within that app, that it should be gone off your phone. The OS storing end to end encrypted message content in notification history for no reason (why store content in a database at all) makes message deletion work differently than most people would expect, so it doesn't feel like an edge case to me.

How did the FBI break into the phone in the first place? Shouldn't they be fixing that bug too?

It could have been by just pointing the phone at the suspect's face.

Side note: FaceID only unlocks if you actually look at the screen. If you’re careful to avoid that, one would have to physically force your eyes to do that without also covering other necessary areas of your face.

A kid and I sometimes engage in a game where they try to get me to look where necessary, so far without success.

  > FaceID only unlocks if you actually look at the screen.

You need "Require Attention for Face ID" turned on for this