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.
Sounds like they're really running up against a genuine conflict of trust. Apple doesn't really trust iOS apps to be "real programs" that just run on your device and do whatever they want, even sandboxed away from the rest of the system. Processing and data transfer is forced through Apple's special-made API hooks for purposes of battery life/performance management and privacy. Apple doesn't trust app developers, and developers of these apps don't trust the client OS.
I don't think there really is a single solution that works for everybody, although I wouldn't mind Apple providing an opt-in app permission for "make arbitrary network connections in the background". The privacy argument against that seems pretty academic, though the battery argument is stronger.
I am a developer of a messaging app downloaded so far by 5 million users around the world. I was very concerned about this news and looked into it.
Apple is simply doing away with silent push notifications through the VoIP API. Apps can still register an extension that will process arbitrary push notifications that result in a visible notification to the user.
If the application needs to silently send something to the app, it can do so with background modes, such as sending a push notification via PushKit with content-available: 1. The OS then schedules when the download may happen. If the download doesn’t happen before the app is started, the app can simply send a request at that time and download it, just like any other content-available thing.
There is no legitimate use I can think of for silently sending data using VoIP push except when you’re on a call and you want to send WebRTC type data (eg say someone joined the call).
But here is the kicker: PushKit notifications are reputed to be delivered on a lower priority basis than VoIP notifications. And that’s the big thing. Apple can simply slow them down to make FB messages arrive slower than iMessage for example.
When the user is not running the app, what is the use case for the app waking up and processing data that is not an incoming message to be delivered to the user?
Facebook was using the VOIP framework to burn so much power after the user had quit the app that you would see articles pointing out that deleting the Facebook app could double the battery life of the device.
>Deleting This 1 App Can Literally Double Your Phone's Battery Life
> 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.
If privacy will truly be compromised then there's always the option to not support push notifications.
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.
But why is it a problem that the app must be running to decrypt the silent notification? The user doesn't know about it and won't know about it until the app is opened, but then the app is already open and can process the notifications.
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.
This article is terrible. The change mentioned in the headline isn't explained until the fifth paragraph and beyond.
> Apple’s change involves an API called PushKit, which was originally designed to be used in apps that let people make online phone calls using voice over internet protocol. .... Over time, many apps began using the tool for purposes other than Internet phone calls, including encrypted messaging apps that found it was the best method for decrypting messages in the background on iPhones. .... But app developers could also use PushKit to collect information about the location of users and other sensitive data, which concerned Apple. .... With iOS 13....the company is finally cutting off developers from using PushKit for any purposes other than internet phone calls.
Wow, and to think of all the times I've held myself back colouring within the app guidelines. Meanwhile other app developers are abusing the apis to no end.
It's pretty weird how the article doesn't even bother to mention that Apple has an official API for doing encrypted notifications, and I really have no idea why these apps are abusing the VOIP stuff instead of using the actual encrypted notification feature. The article quotes someone as claiming APNS isn't reliable, but with zero evidence, and it seems pretty darn reliable for all of the non-encrypted apps using it.
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.
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.
The title is (inadvertantly?) misleading, since the aforementioned private messaging app makers are only inconvenienced because they were knowingly misusing an API for which an incomplete API existed.
So, as Apple updates APIs, they're having to repay their own knowingly-incurred technical debt to stop using what was the only thing working, a workaround, before.
Hm. I think I'm already seeing SMS/VOIP apps show bugs that are trying to comply with the changes. Google Voice app keeps showing last missed call notification every time I open the app. (I have the app set to do calls over circuit switched instead of data). I also noticed there was a recent move on T-Mobile digits to move to data calling in their app on iOS.
It's definitely causing problems now on 12.4.1 because it's a behavior shift that app developers have to get done before 13 drops.
Innovation is often about using things in ways that were never intended. This often conflicts with the ability to police other people's behavior.
Maybe the resolution in this case would be requiring notification decryption to be open source with a verified compile, so Apple (and users) can see what the code does?
People were using APIs in a way that wasn't intended, so Apple built APIs for the new use case. Seems like a pretty good way to handle the problem, without requiring a bunch of people to verify code.
I'm not an expert here, but if the problem is battery life (?), then surely the apps that abuse this will be outed by the users who will, by definition, see the battery getting drained faster.
Apple, how about a battery-energy per app usage display so the users can detect apps that call home/abuse battery usage, and then they can remove them? Is this something that already exists? I would suspect not, as then apple's own apps may get outed! The user could set an energy usage threshold and be told/warned that an app is misbehaving.
I don’t understand the cynicism; That feature already exists. It’s under Settings > Battery. And users really don’t care. Facebook uses a ton of battery and people keep using their app.
Apple removed the ability of app developers to use the (somewhat) reliable way to deliver events to apps without alerting the user.
There’s API that lets an app to decrypt visible notifications, but it’s incredibly limited (it will crash if the process uses more than 5 MB if RAM, if I remember correctly). This presents unique challenges as the app’s code also takes up RAM.
There’s also an old API that enables developers to silently wake up the app in background, but it’s highly unreliable (it won’t work more than 3-5 times per hour or so). This one can still be used for tracking.
The notification are for signaling. The message notification can be distinct and encrypted using standard push notifications. If the problem is with metadata around the conversation (like typing indication, etc), they still can be encrypted on the server but with a cleartext flag associated with them to tell if the content should be pushed or not.
You do not want any kind of cleartext alerts on read receipts or typing notifications. Most people also don't want apple to know what type of data is transmitted to your app.
In short: apple is breaking the only reliable way to deliver notifications. We're making an xmpp app and this breaks everything: regular silent notifications provided by apple work like shit.
We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.
If you were building an app that needs to do something like this in the background today, what is the recommended approach if you're on a platform like React-Native? Can JS even be reliably executed in the background?
Or Apple could make a better messaging and notification system that's similar to pushkit but without the supposed "sensitive data", or just fork pushkit to have a "low permission" version of it.
My wife and I use Life360 every day for giving us notifications whenever we leave work, arrive at home, arrive at our kid's school, etc.
We use these tracking notifications for all sorts of things. For example, my wife won't start prepping dinner until she gets the notification that I've left work.
I will be very annoyed if Apple's changes break tools like Life360. I opted into the tracking for a reason. I don't need Apple making privacy decisions for me. I'm more than capable of making the decision myself.
FYI, Life360 sells your location information, driving habits, and registration details to third-parties including advertisers and insurance companies. From their privacy policy (https://www.life360.com/privacy_policy/):
> One of the 3rd parties who we share data with is Arity. [...] Arity may use this data to [...] provide and service insurance products, including using personal data to perform profiling activities and to provide you with relevant and personalized advertising.
> We share your personal information, driving event data and other information to Arity 875, LLC (“Arity”), which provides driving analytics behavior services to enable us to provide certain functionalities of the Service, such as driving event
history. Arity may also use this information to calculate discounts, rewards or
pricing offers by third parties such as insurance companies, and to perform
various profiling activities in order to produce a score which may predict the
level of driver riskiness, and to develop its risk predictive models for its
own analytics purposes. You hereby acknowledge and consent to the collection
and use of your data and information by Arity as set out in this policy and in
Arity’s privacy policy, which is located at https://www.arity.com/privacy.
So, in other words, they sell your driving information along with your name, phone number, email address, etc. to insurance companies so that they can adjust the prices you're charged based on how you drive.
I don't think that they are trying to make privacy decisions for you, but they are making sure that an API created for a specific reason stops being abused by many other use cases then the original one.
I also used Life360 to geofence my kids and get notifications when they leave school and return home. It actually caught my son running away from school one time, and when the guidance counselor couldn't find him, I was able to locate him outside the school wandering around the streets.
You may be more than capable of making the decision yourself, but most people are not (cf Facebook's user count), so it's perfectly reasonable for Apple to set rules to minimize risk rather than enabling the most capable users.
Lewis Hamilton could probably safely drive at 150 miles an hour on Highway 101, that doesn't mean that the speed limit should be 150.
It seems like a user side configurable app permission such as "allow this application to use PushKit for non VOIP related functions" would take care of this without breaking functionality. However if the author of this article is correct it seems like this is more a jab at Facebook messenger than anything.
That doesn't work with average users. Basically Android did that - apps started to ask for admin permissions, accessibility features and other dangerous stuff and users just click Allow on anything.
The problem is that users can’t meaningfully make that decision. It’s especially bad when the app says “you need this for message notifications”, but then uses it for tracking.
I feel like an API that let you provide an XPC service to handle incoming messages, but restricted that service’s access to any device info, would be the best solution.
I have no idea how feasible it would be to make such an API.
[+] [-] lacker|6 years ago|reply
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.
[+] [-] _bxg1|6 years ago|reply
I don't think there really is a single solution that works for everybody, although I wouldn't mind Apple providing an opt-in app permission for "make arbitrary network connections in the background". The privacy argument against that seems pretty academic, though the battery argument is stronger.
[+] [-] EGreg|6 years ago|reply
Apple is simply doing away with silent push notifications through the VoIP API. Apps can still register an extension that will process arbitrary push notifications that result in a visible notification to the user.
If the application needs to silently send something to the app, it can do so with background modes, such as sending a push notification via PushKit with content-available: 1. The OS then schedules when the download may happen. If the download doesn’t happen before the app is started, the app can simply send a request at that time and download it, just like any other content-available thing.
There is no legitimate use I can think of for silently sending data using VoIP push except when you’re on a call and you want to send WebRTC type data (eg say someone joined the call).
But here is the kicker: PushKit notifications are reputed to be delivered on a lower priority basis than VoIP notifications. And that’s the big thing. Apple can simply slow them down to make FB messages arrive slower than iMessage for example.
[+] [-] GeekyBear|6 years ago|reply
Facebook was using the VOIP framework to burn so much power after the user had quit the app that you would see articles pointing out that deleting the Facebook app could double the battery life of the device.
>Deleting This 1 App Can Literally Double Your Phone's Battery Life
https://www.inc.com/john-koetsier/deleting-this-one-app-can-...
If I am not running a messaging app, the only power draw I want to see from that app is decrypting an incoming message intended for delivery.
Anything else can wait until I next open the app.
[+] [-] whycombagator|6 years ago|reply
If privacy will truly be compromised then there's always the option to not support push notifications.
[+] [-] comex|6 years ago|reply
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
[+] [-] oneplane|6 years ago|reply
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.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] portmanteaufu|6 years ago|reply
> Apple’s change involves an API called PushKit, which was originally designed to be used in apps that let people make online phone calls using voice over internet protocol. .... Over time, many apps began using the tool for purposes other than Internet phone calls, including encrypted messaging apps that found it was the best method for decrypting messages in the background on iPhones. .... But app developers could also use PushKit to collect information about the location of users and other sensitive data, which concerned Apple. .... With iOS 13....the company is finally cutting off developers from using PushKit for any purposes other than internet phone calls.
[+] [-] msie|6 years ago|reply
[+] [-] turdnagel|6 years ago|reply
I'd love to see a technical breakdown of this problem. iOS 13 has a background task API - why can't that be used?
Incoming notifications can trigger application code to run - why can't that method be used?
[+] [-] eridius|6 years ago|reply
[+] [-] lacker|6 years ago|reply
[+] [-] madrox|6 years ago|reply
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...
[+] [-] joecool1029|6 years ago|reply
I looked into that, the second answer here gives better but slightly dated insight on the matter, it makes sense: https://security.stackexchange.com/questions/119624/how-is-w...
[+] [-] jjtheblunt|6 years ago|reply
So, as Apple updates APIs, they're having to repay their own knowingly-incurred technical debt to stop using what was the only thing working, a workaround, before.
[+] [-] joecool1029|6 years ago|reply
It's definitely causing problems now on 12.4.1 because it's a behavior shift that app developers have to get done before 13 drops.
Apple forum thread on behavior: https://forums.developer.apple.com/thread/118607
[+] [-] floatingatoll|6 years ago|reply
[+] [-] skybrian|6 years ago|reply
Maybe the resolution in this case would be requiring notification decryption to be open source with a verified compile, so Apple (and users) can see what the code does?
Users need privacy, code doesn't.
[+] [-] RandallBrown|6 years ago|reply
[+] [-] laythea|6 years ago|reply
Apple, how about a battery-energy per app usage display so the users can detect apps that call home/abuse battery usage, and then they can remove them? Is this something that already exists? I would suspect not, as then apple's own apps may get outed! The user could set an energy usage threshold and be told/warned that an app is misbehaving.
[+] [-] colejohnson66|6 years ago|reply
[+] [-] ajconway|6 years ago|reply
There’s API that lets an app to decrypt visible notifications, but it’s incredibly limited (it will crash if the process uses more than 5 MB if RAM, if I remember correctly). This presents unique challenges as the app’s code also takes up RAM.
There’s also an old API that enables developers to silently wake up the app in background, but it’s highly unreliable (it won’t work more than 3-5 times per hour or so). This one can still be used for tracking.
[+] [-] mickael|6 years ago|reply
[+] [-] Andrew_nenakhov|6 years ago|reply
[+] [-] Andrew_nenakhov|6 years ago|reply
We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.
[+] [-] vonseel|6 years ago|reply
[+] [-] lacker|6 years ago|reply
[+] [-] malicioususer11|6 years ago|reply
[deleted]
[+] [-] kevin_b_er|6 years ago|reply
[+] [-] csande17|6 years ago|reply
[+] [-] t0mbstone|6 years ago|reply
We use these tracking notifications for all sorts of things. For example, my wife won't start prepping dinner until she gets the notification that I've left work.
I will be very annoyed if Apple's changes break tools like Life360. I opted into the tracking for a reason. I don't need Apple making privacy decisions for me. I'm more than capable of making the decision myself.
[+] [-] NobodyNada|6 years ago|reply
> One of the 3rd parties who we share data with is Arity. [...] Arity may use this data to [...] provide and service insurance products, including using personal data to perform profiling activities and to provide you with relevant and personalized advertising.
[EDIT] The "more detailed" privacy policy is more explicit (https://life360.helpshift.com/a/life360-family-locator/?s=pr...):
> We share your personal information, driving event data and other information to Arity 875, LLC (“Arity”), which provides driving analytics behavior services to enable us to provide certain functionalities of the Service, such as driving event history. Arity may also use this information to calculate discounts, rewards or pricing offers by third parties such as insurance companies, and to perform various profiling activities in order to produce a score which may predict the level of driver riskiness, and to develop its risk predictive models for its own analytics purposes. You hereby acknowledge and consent to the collection and use of your data and information by Arity as set out in this policy and in Arity’s privacy policy, which is located at https://www.arity.com/privacy.
So, in other words, they sell your driving information along with your name, phone number, email address, etc. to insurance companies so that they can adjust the prices you're charged based on how you drive.
[+] [-] pcora|6 years ago|reply
* edit: typo
[+] [-] pwinnski|6 years ago|reply
[+] [-] cromwellian|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] RandallBrown|6 years ago|reply
[+] [-] paggle|6 years ago|reply
Lewis Hamilton could probably safely drive at 150 miles an hour on Highway 101, that doesn't mean that the speed limit should be 150.
[+] [-] Blinks-|6 years ago|reply
[+] [-] reaperducer|6 years ago|reply
The number of users who would understand that phrase and find it useful in making a decision is roughly .000000001%. Maybe.
[+] [-] Daniel_sk|6 years ago|reply
[+] [-] olliej|6 years ago|reply
I feel like an API that let you provide an XPC service to handle incoming messages, but restricted that service’s access to any device info, would be the best solution.
I have no idea how feasible it would be to make such an API.
[+] [-] pwinnski|6 years ago|reply