|
|
|
|
|
|
by comex
2475 days ago
|
|
|
Note that the intended replacement API has been available for three years: https://developer.apple.com/documentation/usernotifications/... According to Moxie, it does have a downside. Notifications must be marked as either displaying an alert or as silent. Silent notifications are invisible to the user, but can be read by the app; Signal uses them for things like typing indicators and read receipts. With the new API, if a notification is marked as displaying an alert, the notification extension gets a chance to modify (i.e. decrypt) the content, but the end result must be an alert of some sort. If it’s marked as silent, the notification extension doesn’t run at all: after all, the data isn’t used for anything until the app asks for it, which can only happen if the app is actively running, so the app can just handle decryption itself. And if notification extensions were allowed to trigger on silent notifications, app developers could send meaningless notifications to keep their apps running in the background without the user’s awareness – the same issue Apple is trying to address by cracking down on PushKit. The problem is that the flag for whether a notification is silent or not is visible to Apple’s server, whereas Signal wants to keep even that one bit of information hidden behind its end-to-end encryption. https://twitter.com/moxie/status/1159127482143875072 |
|
|
As a user I really would not care if the 'read receipt' or 'is typing' notification is unavailable to an app while I'm not using it anyway. And when I'm using it, I don't see a problem with the app having to process some notifications in a different thread and update the UI accordingly.