Apple Change Causes Scramble Among Private Messaging App Makers(theinformation.com)
theinformation.com
Apple Change Causes Scramble Among Private Messaging App Makers
https://www.theinformation.com/articles/apple-change-causes-scramble-among-private-messaging-app-makers?pu=hackernewsff2o9j&utm_source=hackernews&utm_medium=unlock
109 comments
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.
The article says "Apps that exploited PushKit could drain iPhone batteries, Apple said." and "The basis for doing this is battery savings"
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.
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.
> 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.
Well sure, but on the other hand now all your stuff isn't broken. Give and take, I think.
Had a similar situation once. Apple announced a rule change that impacted our business. We talked to them and realized we had to suck it up. We spent 6 months completely redesigning our app to fit in with the new guidelines. Meanwhile we found out our competitors spend 6 months doing nothing but complaining to Apple. Apple reneged on the change. We lost 6 months dev time trying to comply with the new rules in good faith, our competitors spend those 6 months doing their regular work on new features.
Except if he was using PushKit in a compliant way.
Approval process roulette is exciting enough when you think you're following the guidelines.
Came here to say the same thing. Even this description is _really_ light on details.
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?
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?
iOS 13 has a background task API - why can't that be used?
The iOS 13 background task API limits your background tasks to a few minutes. So, they're useful for short batch tasks you don't want to interrupt when the app closes, like cleaning up a database. They aren't so useful for listening for a notification that could come after hours of inactivity.
Incoming notifications can trigger application code to run - why can't that method be used?
This is probably what apps will do in response to the rule changes. It isn't ideal, though. Incoming notifications can trigger application code to run, but only for notifications that include a visible display to the user. This means that a server has to differentiate between different types of data on their network, like knowing the difference between a new user message and a read receipt. It is not ideal for privacy to expose that information to the server.
So, this isn't the end of the world, but it will hurt the privacy model of non-iMessage private messaging apps.
The iOS 13 background task API limits your background tasks to a few minutes. So, they're useful for short batch tasks you don't want to interrupt when the app closes, like cleaning up a database. They aren't so useful for listening for a notification that could come after hours of inactivity.
Incoming notifications can trigger application code to run - why can't that method be used?
This is probably what apps will do in response to the rule changes. It isn't ideal, though. Incoming notifications can trigger application code to run, but only for notifications that include a visible display to the user. This means that a server has to differentiate between different types of data on their network, like knowing the difference between a new user message and a read receipt. It is not ideal for privacy to expose that information to the server.
So, this isn't the end of the world, but it will hurt the privacy model of non-iMessage private messaging apps.
Honestly, in terms of privacy, I think it's a decent trade-off (from what I gathered from this sparse article).
PushKit
Pros:
- Apps and their servers can be developed in a manner wherein the server doesn't know if it's sending a message or a read receipt (aka, no metadata leak).
Cons:
- "[...] developers could also use PushKit to collect information about the location of users and other sensitive data"
So with the traditional Notifications API, you lose that pro, but now _all_ of your apps with potentially ill-intentions can no longer glean your location and other data.
Edit: Though, another huge con to this is the amount of dev hours to abide by this change. It's already a pretty sizable engineering task to create a fast, secure, and end-to-end encrypted messaging app.
PushKit
Pros:
- Apps and their servers can be developed in a manner wherein the server doesn't know if it's sending a message or a read receipt (aka, no metadata leak).
Cons:
- "[...] developers could also use PushKit to collect information about the location of users and other sensitive data"
So with the traditional Notifications API, you lose that pro, but now _all_ of your apps with potentially ill-intentions can no longer glean your location and other data.
Edit: Though, another huge con to this is the amount of dev hours to abide by this change. It's already a pretty sizable engineering task to create a fast, secure, and end-to-end encrypted messaging app.
> This is probably what apps will do in response to the rule changes. It isn't ideal, though. Incoming notifications can trigger application code to run, but only for notifications that include a visible display to the user. This means that a server has to differentiate between different types of data on their network, like knowing the difference between a new user message and a read receipt. It is not ideal for privacy to expose that information to the server.
I guess I still don't get it.
A notification comes into the iPhone. iOS wakes the app. The user clicks the notification, the app opens, the user reads the message and the app sends a read receipt to it's own servers.
A new message would just be a new message. The user would type it and hit send. The app would send it to it's servers which would then use the push api to send a message to the recipient.
Edit: Ok, I get it. The point is one doesn't want a server knowing the difference between the two types of messages. That's a leak of metadata.
I guess I still don't get it.
A notification comes into the iPhone. iOS wakes the app. The user clicks the notification, the app opens, the user reads the message and the app sends a read receipt to it's own servers.
A new message would just be a new message. The user would type it and hit send. The app would send it to it's servers which would then use the push api to send a message to the recipient.
Edit: Ok, I get it. The point is one doesn't want a server knowing the difference between the two types of messages. That's a leak of metadata.
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.
"allow this application to use PushKit for non VOIP related functions"
The number of users who would understand that phrase and find it useful in making a decision is roughly .000000001%. Maybe.
The number of users who would understand that phrase and find it useful in making a decision is roughly .000000001%. Maybe.
Nitpick: I'd think it's significantly more than that, not because the number of users is large, but because .000000001% is mindbogglingly small. Remove a few zeros!
I don't think they were going for an accurate number. I actually think the hyperbole helps make the point they're making in this case.
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.
This is exactly correct: because average users are dumb, it is our duty as software developers to make decisions for them, and to use whatever practical encryption or legal copyright means available to us to ensure that users do not have the ability--by any means that could plausibly be under the control of the user--to access and modify (or even see!) the behavior of the software running on the hardware they think they "own"... anything less would be devastating for security and is too scary to contemplate.
So, I really wonder if the reason I am getting so many downvotes (I am only at 0 right now, but I have been as high as 3, so this comment has been pretty controversial so far) is because people are somehow failing to get my over-the-top / so-exaggerated-it-hurts sarcasm (which is a bit sad), or if people so truly agree with the premise that upstream developers are smart and users are dumb that they are angry at my strong characterization of it as categorically evil (which is downright terrifying).
Maybe they just think your sarcasm detracts from the conversation.
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.
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.
If there is a need for an API, then I'd rather that API exist, rather than a VOIP API being used for non-VOIP things.
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.
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.
[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.
> 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.
[deleted]
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.
* edit: typo
* edit: typo
What does Life360 provide that Apple's own 'Find My Friends' app does not? That's what my partner and I use to track locations.
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.
Actively notifying you about changes in location, rather than it being a passive thing that the other party has to check.
Find Friends also allows you to request notifications when someone leaves or arrives at a location. It's great for timing when to start dinner.
Android cross compatibility is the only real feature I can think of.
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.
Not a parent, but a recent kid, and I’d hate my parents having that kind of control over me. Though I guess I’d just turn off the phone. Which then makes me even more unreachable than if the tracking had never been instituted in the first place.
A lot of these tools depend a lot on the age of the kid and how they're used.
I have five year old, and they're nearly to the point where they could go the the park by themself if they had some sort of device where (a) we could tell where they were and (b) they could easily contact us plus (c) it was socially acceptable to do this. This would be using tracking to allow our kid more freedom, since the alternatives are (1) go to the park on our schedule and under full supervision and (2) stay home.
As kids get older we would want to pull back that kind of supervision, so that by the time they're 12 or so we can get their location with something active and visible to them, and by the time they're 15 or so we can just call or text them.
The technology can be used in a lot of ways, and whether it makes kids more or less free depends on parenting and culture.
I have five year old, and they're nearly to the point where they could go the the park by themself if they had some sort of device where (a) we could tell where they were and (b) they could easily contact us plus (c) it was socially acceptable to do this. This would be using tracking to allow our kid more freedom, since the alternatives are (1) go to the park on our schedule and under full supervision and (2) stay home.
As kids get older we would want to pull back that kind of supervision, so that by the time they're 12 or so we can get their location with something active and visible to them, and by the time they're 15 or so we can just call or text them.
The technology can be used in a lot of ways, and whether it makes kids more or less free depends on parenting and culture.
Running away from school is pretty serious. When I was a kid, I'd expect some serious repercussions from my father if I did such a thing. The phone just made the consequences arrive sooner, but it's not the root of the issue. And the commenter didn't give us nearly enough information to judge them, so let's not.
It doesn’t sound like anyone is judging here. And I agree, I would hate being tracked on my phone. I don’t share my location permanently with anyone. That just seems odd for adults to do. I was a kid before all of this was possible, but I’ve seen the tracking relatives have on their kids and it abhors me.
If you have a kid who is being monitored for depression and in therapy, it is a totally different story, and the monitoring is completely transparent, my son is not unaware of it, in fact, he specifically has an agreement not to disable location permissions for that app.
Isn’t this possible with Apple’s Find Friends functionality?
EDIT: downvote because why?
EDIT: downvote because why?
I didn't downvote you, but Find Friends doesn't geo-fence. So unless I'm actively tracking him, I won't know.
I only want to be notified if he leaves the school premises during school hours, I don't want to micromanage his location otherwise.
I only want to be notified if he leaves the school premises during school hours, I don't want to micromanage his location otherwise.
Thanks, I understand that the feature is enabled at a more granular level in some of these third-party apps. I don't have smartphone-aged kids, so thankfully I've not dug into these details yet...
Sometimes I forget that this is a community full of engineers, many of whom have poor social skills.
Invest less time in apps and more time in trying to understand your kids.
Invest less time in apps and more time in trying to understand your kids.
Speaking of poor social skills, let's give each other the benefit of the doubt here, please. You have no clue what they're dealing with nor how well they understand their kid.
My son and I have a fantastically close relationship, we talk about everything, including deeply negative feelings. But unless you know how anxiety panic attacks work, don't make comments like this.
Regardless of the relationship and understanding I have with my kids, being triggered at school to ditch it from a panic attack is not a rational understanding.
It is precisely because my son and I have a good relationship, that we can come to an agreement that he needs outside supervision and monitoring.
I attend group therapy seminars with trouble teens. Some of them have been the victim of serious abuse, like revenge porn by peers on campus. This is not something "social skills" solve.
Your own comment to me suggests you lack the very social skills you claim others lack.
Regardless of the relationship and understanding I have with my kids, being triggered at school to ditch it from a panic attack is not a rational understanding.
It is precisely because my son and I have a good relationship, that we can come to an agreement that he needs outside supervision and monitoring.
I attend group therapy seminars with trouble teens. Some of them have been the victim of serious abuse, like revenge porn by peers on campus. This is not something "social skills" solve.
Your own comment to me suggests you lack the very social skills you claim others lack.
[deleted]
I can't see any reason that Life360 would be using a VOIP API for location tracking when Apple's own location tracking APIs work quite well.
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.
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.
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.
They already have: https://developer.apple.com/documentation/usernotifications/...
Previously on this same topic, 29 days ago: https://news.ycombinator.com/item?id=20629567
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.
And that would be a problem if having 'is typing...' and 'was read' notifications had to be pushed realtime to an app that was in the background. What is the point of those notifications arriving in the app when the user isn't using it.
The sender of these notifications doesn't know that the user has closed the app. What this means is that the message send from the sender through the server now has to include whether this is a message or a non-message, which has to be a flag in plaintext.
But why use background notifications for this type of data in the first place?
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...
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...
Correct!
But also some authors uses PushKit to keep their app constantly running in background.
But also some authors uses PushKit to keep their app constantly running in background.
> The article quotes someone as claiming APNS isn't reliable
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...
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...
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.
Apple forum thread on behavior: https://forums.developer.apple.com/thread/118607
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
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
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
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.
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.
[deleted]
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.
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 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.
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.
Regarding your last paragraph, it's actually more severe:
Eventually the silent push notifications (content-available: 1) will not be delivered to the app at all. They are throttled by how much energy the app uses when launching in response.
Send too many or do too much with each one, and you'll find iOS no longer launches the app. The limits are not documented.
The maddening part is everything will work fine while you're developing and have your phone plugged in to power. You'll only notice this on battery power.
Eventually the silent push notifications (content-available: 1) will not be delivered to the app at all. They are throttled by how much energy the app uses when launching in response.
Send too many or do too much with each one, and you'll find iOS no longer launches the app. The limits are not documented.
The maddening part is everything will work fine while you're developing and have your phone plugged in to power. You'll only notice this on battery power.
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
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.
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.
From my perspective, everything you want to see in the app when you next open it, should be transfered to your phone when you have network access; because you might not have access when you open the app. There's lots of things that fit in there -- read receipts, group changes, profile photo changes, contacts that join or leave the network.
Not user visible (mostly), but still important are things like end to end key changes and key cycling related to group changes.
Disclaimer: I used to work for a messaging company.
Not user visible (mostly), but still important are things like end to end key changes and key cycling related to group changes.
Disclaimer: I used to work for a messaging company.
Disagreed.
I don't want apps working in the background. If I want to see what changed in an app, I'll open it and I expect it to request the changes then and only then. If I have no network then I'll see no changes. Easy.
Your perspective is very foreign to me and definitely seems hostile to the battery life of my device.
I don't want apps working in the background. If I want to see what changed in an app, I'll open it and I expect it to request the changes then and only then. If I have no network then I'll see no changes. Easy.
Your perspective is very foreign to me and definitely seems hostile to the battery life of my device.
I want to be able to message with people while I (and they) have intermittent coverage. I live in an area with poor cell coverage, and it's difficult to use messengers that require me to be online while the app is open if I'm on the bus or the ferry. The worst is those that show notifications with partial messages, but then I can't read the whole message, because I'm in a dead zone.
SMS doesn't require me to have the app open while I have a working connection, and an SMS replacement shouldn't either.
But --- I think your perspective is reasonable too; there's a tradeoff here: offline experience, battery (maybe --- if you're going to get and process everything anyway, there is a difference in processing it in small batches vs one big batch, but it might not be that big), server visibility into types of messages, etc. Most phone OSes have a battery saver mode that disables background processing, so you can force this, but I personally disable that for the apps I want to work offline.
SMS doesn't require me to have the app open while I have a working connection, and an SMS replacement shouldn't either.
But --- I think your perspective is reasonable too; there's a tradeoff here: offline experience, battery (maybe --- if you're going to get and process everything anyway, there is a difference in processing it in small batches vs one big batch, but it might not be that big), server visibility into types of messages, etc. Most phone OSes have a battery saver mode that disables background processing, so you can force this, but I personally disable that for the apps I want to work offline.
> Your perspective is very foreign to me and definitely seems hostile to the battery life of my device.
Not if the OS manages the batching of those updates. Then it's barely any more hostile than what the OS needs to do to manage things like receive phone calls.
I think you're also strongly in the minority on this. People who use messaging apps prefer the ability to get notified (at least sometimes) when they get a message, even an unexpected one. That true for phone calls, texts, emails, or Whatsapp/signal/fbm etc.
Not if the OS manages the batching of those updates. Then it's barely any more hostile than what the OS needs to do to manage things like receive phone calls.
I think you're also strongly in the minority on this. People who use messaging apps prefer the ability to get notified (at least sometimes) when they get a message, even an unexpected one. That true for phone calls, texts, emails, or Whatsapp/signal/fbm etc.
Message notification is not impacted here. You don't need to open the full app for that to happen.
If the app uses encrypted messages, you just have to write an extension to handle the decryption on device while the app is not running.
If the user wants to interact further after reading the message notification, they open the full app.
If the app uses encrypted messages, you just have to write an extension to handle the decryption on device while the app is not running.
If the user wants to interact further after reading the message notification, they open the full app.
Indeed. I disabled background app refresh, and I don’t want apps to abuse certain features to do thing I don’t want them to do.
I kicked out zoom and adobe permanently for the same reason
I kicked out zoom and adobe permanently for the same reason
Background app refresh on iOS is one of the few features that Apple automatically allows but you can disable on an app by app basis.
And I did. That's not related to my parent commenter's point, I think.
Apple has had “Background App Refresh” for a while now.
As far as I'm concerned, if reading an incoming message in a notification doesn't motivate me to open your app, then all of those housekeeping tasks can wait until I do open your app.
Respect the battery life of my device.
Respect the battery life of my device.
My exceptions would be financial market apps and news apps. I might also throw podcast apps in this group to selectively download typically viewed shows or topics.
The use case here is to keep it private when exactly you are receiving a message. The push API requires that the server know when data indicates a user-visible message and when it does not, and the maximally private messaging app server wouldn’t need to know that.
There is certainly a trade off between privacy and battery life here. If Apple stated that they were sacrificing a small bit of privacy for improved battery life, I would find their communications honest on this issue. Since their messaging is typically so pro-privacy, they probably have just fallen into the habit of claiming every change enhances privacy even when it isn’t.
There is certainly a trade off between privacy and battery life here. If Apple stated that they were sacrificing a small bit of privacy for improved battery life, I would find their communications honest on this issue. Since their messaging is typically so pro-privacy, they probably have just fallen into the habit of claiming every change enhances privacy even when it isn’t.
From my perspective, receiving an encrypted message, decrypting it, and displaying it for the user is the only thing a messaging app that is not running should be able to do.
I literally can't think of a single other thing that should happen unless and until the user opens the app, at which time the app can open an encrypted connection to the server and exchange any sorts of messages it likes.
I literally can't think of a single other thing that should happen unless and until the user opens the app, at which time the app can open an encrypted connection to the server and exchange any sorts of messages it likes.
> 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.
If privacy will truly be compromised then there's always the option to not support push notifications.
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?
Users need privacy, code doesn't.
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.
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.
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.
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.
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.
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.
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.
We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.
What non-UI-resulting notifications does your app need to deliver that, as a user, will negatively affect the quality of my experience when not delivered through the VOIP method?
Why, as a developer, did you find that non-VOIP Background Data Refresh failed to meet your needs for creating a viable user experience - and what needs did it fail for?
Why, as a developer, did you find that non-VOIP Background Data Refresh failed to meet your needs for creating a viable user experience - and what needs did it fail for?
There is a lot of traffic in xmpp that is not message. Like, delivery / read receipts, carbon copies, etc. It's often fully encrypted and a server doesn't even know the contents and if it should or not be showing anything for this event: it just has to tell an app to wake up, fetch messages, let it decide what to do.
With this change, we're left with 2 notification methods: one that always presents a notification banner (resulting in EXTREMELY BAD user experience - banner on every read receipt, on every your own message sent from every device, etc), or one that is extremely unreliable: it is delivered badly if a user is low on battery, and never delivered if a user swipes an app away.
With this change, we're left with 2 notification methods: one that always presents a notification banner (resulting in EXTREMELY BAD user experience - banner on every read receipt, on every your own message sent from every device, etc), or one that is extremely unreliable: it is delivered badly if a user is low on battery, and never delivered if a user swipes an app away.
So, I’m going to translate this because it will sound different in another phrasing. This will sound judgmental, but I want to present the contrasting view that Apple likely holds here, rather than a sympathetic ear (as many others have provided that service already). No insult or harm is meant, and I have made no effort to look up what your app does, so this isn’t personal at all. Here goes.
You’re willfully circumventing iOS guidelines regarding Background App Refresh in order to provide an experience that breaks two enforced behaviors that Apple imposes on all apps.
First, in low battery mode, iOS reduces the frequency of non-alert notifications in order to conserve power by reducing cellular traffic frequency, often to the point of batching to once a minute or more. By overcoming this behavior with the VOIP framework, you bypass the intentional battery life protections Apple has built into the operating system.
Second, iOS enforces that no invisible background refreshes may occur once apps are force quit%, unless and until they are reopened. You willfully are circumventing this restriction that was put into place to respect user intentions to “quit” an app by using the VOIP framework to perform background activity even after your app is quit.
Both of these actions are taken with the express intent of breaking the constraints that the Background App Refresh system places on all iOS apps, in order to deliver an experience that has no “Fetching latest changes” delay when the app is next opened, either during low power mode or after a force quit.
Apple had the right to terminate your app from the App Store altogether in response to this violation of their background app refresh guidelines, as they make clear that their guidelines are not the sole and exclusive definition of the boundaries of acceptable behavior, and are generally unfriendly towards those who exercise loopholes to the detriment of their designed experience.
For whatever^ reason, Apple instead gave everyone three months warning that this Background App Refresh loophole is being closed. The VOIP system is meant to carry real-time communications that require the user to be immediately notified, visually and/or audibly, and abusing it for non-visible notifications is no longer permissible. Fortunately, the existing notification system that everyone used prior to the VOIP loophole still works just as it always has, and so the apps will have no trouble reverting to compliant methods.
This will not only restore behaviors that users expect from low power mode and force quitting apps, but will also ensure that the critical and significant battery performance gains of low power mode’s reduction in background app refresh update intervals are restored to all iOS devices afflicted by apps using the VOIP hack today.
I hope this helps explain why “delivered badly” may be considered a better outcome than “delivered ignoring low power mode and force quit”. I assume you disagree with Apple’s choice to restrict background app refresh behaviors, and this led you to implement the VOIP mechanism, but unfortunately that time is over. I hope your users and app are able adapt readily and without fuss to the return of the power-saving pre-VOIP paradigm+ for silent background refreshes.
% Nomorobo sends a visible push notification if you haven’t fetched updated rules in a while, offering to reopen the app and start a refresh if you tap the notification. I rarely see it, but I’m grateful for it every time.
^ Facebook.app using this same approach
+ Mail.app demonstrates this paradigm effectively, reducing fetch times to “essentially never” in low power mode if you don’t have notifications configured. It takes a good minute or so sometimes for it to download my Mail after I wake up and check it, but my phone also only uses 5% battery overnight, ensuring that my phone’s alarm clock goes off even when I can’t find a charger. I’m very grateful that Mail.app makes me wait for my mail instead of checking silently in the background and draining my battery, and that in a nutshell is why low power mode is worth a ‘poor’ user experience.
You’re willfully circumventing iOS guidelines regarding Background App Refresh in order to provide an experience that breaks two enforced behaviors that Apple imposes on all apps.
First, in low battery mode, iOS reduces the frequency of non-alert notifications in order to conserve power by reducing cellular traffic frequency, often to the point of batching to once a minute or more. By overcoming this behavior with the VOIP framework, you bypass the intentional battery life protections Apple has built into the operating system.
Second, iOS enforces that no invisible background refreshes may occur once apps are force quit%, unless and until they are reopened. You willfully are circumventing this restriction that was put into place to respect user intentions to “quit” an app by using the VOIP framework to perform background activity even after your app is quit.
Both of these actions are taken with the express intent of breaking the constraints that the Background App Refresh system places on all iOS apps, in order to deliver an experience that has no “Fetching latest changes” delay when the app is next opened, either during low power mode or after a force quit.
Apple had the right to terminate your app from the App Store altogether in response to this violation of their background app refresh guidelines, as they make clear that their guidelines are not the sole and exclusive definition of the boundaries of acceptable behavior, and are generally unfriendly towards those who exercise loopholes to the detriment of their designed experience.
For whatever^ reason, Apple instead gave everyone three months warning that this Background App Refresh loophole is being closed. The VOIP system is meant to carry real-time communications that require the user to be immediately notified, visually and/or audibly, and abusing it for non-visible notifications is no longer permissible. Fortunately, the existing notification system that everyone used prior to the VOIP loophole still works just as it always has, and so the apps will have no trouble reverting to compliant methods.
This will not only restore behaviors that users expect from low power mode and force quitting apps, but will also ensure that the critical and significant battery performance gains of low power mode’s reduction in background app refresh update intervals are restored to all iOS devices afflicted by apps using the VOIP hack today.
I hope this helps explain why “delivered badly” may be considered a better outcome than “delivered ignoring low power mode and force quit”. I assume you disagree with Apple’s choice to restrict background app refresh behaviors, and this led you to implement the VOIP mechanism, but unfortunately that time is over. I hope your users and app are able adapt readily and without fuss to the return of the power-saving pre-VOIP paradigm+ for silent background refreshes.
% Nomorobo sends a visible push notification if you haven’t fetched updated rules in a while, offering to reopen the app and start a refresh if you tap the notification. I rarely see it, but I’m grateful for it every time.
^ Facebook.app using this same approach
+ Mail.app demonstrates this paradigm effectively, reducing fetch times to “essentially never” in low power mode if you don’t have notifications configured. It takes a good minute or so sometimes for it to download my Mail after I wake up and check it, but my phone also only uses 5% battery overnight, ensuring that my phone’s alarm clock goes off even when I can’t find a charger. I’m very grateful that Mail.app makes me wait for my mail instead of checking silently in the background and draining my battery, and that in a nutshell is why low power mode is worth a ‘poor’ user experience.
TLDR: you know nothing.
Longer explanation: You do not know how XMPP works. XMPP is a federated protocol that requires a persistent connection between a client and a server. XMPP consist of multiple independent servers. Client developers and server owners are usually different parties.
To send a push notification to JabberChat app some XMPP server (say, xmpp.org ) must post a notification update to appserver hosted by JabberChat owners (say, jabberchat.org), because only they can send push notifications to an app. If you insist, like Apple, to transmit only 'meaningful' updates, appserver owners will be able to snoop on all passing traffic. That is not desireble bordering not acceptable.
So, XMPP naturally devised a way that only 'content available' notification is transmitted to an appserver, which relays it to a client via APNS/FCM. A client application then wakes up, connects directly to its own server (which is likely INDEPENDENT from app developer!), fetches data and acts accordingly. Now this capability to reliably fetch data without Apple / appserver intermeddling is crippled, which introduces lots of privacy risks.
See XEP-0357 for more details.
You see, instant chat messages are exactly that kind of real-time communications that requires a user to be immediately notified. The only viable way to provide real-time notifications without violating user privacy were these VoIP notifications, and apple just killed these.
All your logic applies only to centralised client-app architecture, and totally not applies to any federated one.
Also, Apple's restrictions are honestly dumb. Smartphone is a computer and one should not restrict how a user wants to use that computer. If a user needs background tasks, just let them do it, only alert them about power usage and let them decide if they need this app or not.
Longer explanation: You do not know how XMPP works. XMPP is a federated protocol that requires a persistent connection between a client and a server. XMPP consist of multiple independent servers. Client developers and server owners are usually different parties.
To send a push notification to JabberChat app some XMPP server (say, xmpp.org ) must post a notification update to appserver hosted by JabberChat owners (say, jabberchat.org), because only they can send push notifications to an app. If you insist, like Apple, to transmit only 'meaningful' updates, appserver owners will be able to snoop on all passing traffic. That is not desireble bordering not acceptable.
So, XMPP naturally devised a way that only 'content available' notification is transmitted to an appserver, which relays it to a client via APNS/FCM. A client application then wakes up, connects directly to its own server (which is likely INDEPENDENT from app developer!), fetches data and acts accordingly. Now this capability to reliably fetch data without Apple / appserver intermeddling is crippled, which introduces lots of privacy risks.
See XEP-0357 for more details.
You see, instant chat messages are exactly that kind of real-time communications that requires a user to be immediately notified. The only viable way to provide real-time notifications without violating user privacy were these VoIP notifications, and apple just killed these.
All your logic applies only to centralised client-app architecture, and totally not applies to any federated one.
Also, Apple's restrictions are honestly dumb. Smartphone is a computer and one should not restrict how a user wants to use that computer. If a user needs background tasks, just let them do it, only alert them about power usage and let them decide if they need this app or not.
I am sad to hear that didReceive(_:withContentHandler:) is not sufficient for you to implement end-to-end encryption of the content of user-visible push notifications using an encryption key exchanged prior to APN delivery. I hope someday Apple extends their support for preprocessing received display notifications to users to ensure that the intermediary only knows the receiver’s destination address at most.
https://developer.apple.com/documentation/usernotifications/...
https://developer.apple.com/documentation/usernotifications/...
By “work like shit”, what exactly do you mean?
Slower delivery? Unreliable delivery?
Slower delivery? Unreliable delivery?
Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.
That’s is what I expect. If I kill your app for whatever reason I expect it to remain killed, not to override my decision.
If your protocol is so bad it can’t handle intermittent connection, well to hell with this protocol.
If your protocol is so bad it can’t handle intermittent connection, well to hell with this protocol.
Oh. You know nothing too. A protocol can handle the intermittent connection. A user can't handle instant message not delivered instantly, and it has nothing to do with a protocol, only with Apple's restriction.
Oh, there ARE ways to deliver a meaningful message, but they require transmitting full unencrypted message text over APNS! (this also results in app developers being capable to snoop on this traffic too - while currently data is exchanged directly between a user server and his client, bypassing client developers).
Next time comment on something you have any clue about.
Oh, there ARE ways to deliver a meaningful message, but they require transmitting full unencrypted message text over APNS! (this also results in app developers being capable to snoop on this traffic too - while currently data is exchanged directly between a user server and his client, bypassing client developers).
Next time comment on something you have any clue about.
Yikes! Attacking another user like this will get you banned on HN. Can you please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here?
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?
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.