Apple Change Causes Scramble Among Private Messaging App Makers

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

From PushKit's documentation:

PushKit notifications also have the following advantages over user notifications:

- The device wakes only when it receives a PushKit notification, which can improve battery life.

- Upon receiving a PushKit notification, the system automatically launches your app if it isn't running. By contrast, user notifications aren't guaranteed to launch your app.

- The system gives your app execution time (potentially in the background) to process PushKit notifications.

- PushKit notifications can include more data than user notifications.

Sounds like PushKit notifications are treated like a full app launch, which gives your code access to APIs which regular push notifications don't give you (trivial example being location) https://developer.apple.com/documentation/pushkit?language=o...

This article doesn't quite explain what's going on as much as I would like, so maybe I can add some more detail.

The key problem from an app developer's point of view is that the iOS push notification API doesn't just let a server send an encrypted blob of data to a user's app, and have the app handle it locally, deciding whether it needs to display a notification to the user.

What the iOS push notification API does let you do is send an encrypted notification to a user's app, and then if the user is going to see this notification, have the app locally intercept that, and decide what exactly to display. So for an encrypted messaging service, you can send the encrypted message, and have the app locally decrypt it.

The difference is that the push notification API doesn't let you send push notification data that won't be visible to the end user. So to use this API, your server needs to know that a user just received a message. It can't send out something like an encrypted blob that could be a received-message or could be a different sort of encrypted message like a read receipt, and let the app decide locally. This isn't optimal for a private messaging app - ideally the server wouldn't have to be able to distinguish your received messages from other metadata. This is similar to phone call metadata leaking, where even if someone can't eavesdrop on the content of your phone calls, you still don't want them knowing precisely when you made a phone call.

So one weird thing about iOS is that the VOIP APIs did give you ways to silently send an encrypted blob of data from a server to an app. This functionality would be logical in the push notification API, but the push notification API didn't support it and the VOIP API did, so developers started using the VOIP API for it.

It makes sense that Apple wouldn't want the VOIP API used in this way. But secure messaging apps have a legitimate reason to silently transfer encrypted data from server to application. Making this impossible will weaken the privacy that apps like Signal can offer, not improve it, because Signal will have to know a little bit more about your messaging behavior in order to send you push notifications.

In Apple's API you can send an encrypted message and have the app decrypt it. But you can't send an encrypted blob of data and have the app decide whether that blob of data was a message to be shown to the user, or a different sort of data like a read receipt. So the server needs to be able to differentiate the types of data packets sent from user to user, in order to use Apple's notification API, which is less private.

Find My Friends rarely works reliably for me. It regularly says the person can't be located, while if I use services like WhatsApp this never happens. It's also way slow, I've tried meeting people while we were both on the move and missed them because the update rate was too slow. I don't use Life360, but Find My Friends hasn't worked for me for a long time.