10 ms·

Apple Change Causes Scramble Among Private Messaging App Makers

133 points by ballmers_peak 7y ago

portmanteaufu 7y ago
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.
- msie 7y ago
  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.
  - Icathian 7y ago
    Well sure, but on the other hand now all your stuff isn't broken. Give and take, I think.
    - AmericanChopper 7y ago
      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.
      - hosteur 7y ago
        What was the change?
      - pfranz 7y ago
        Working the refs works way more often than people think.
    - kabes 7y ago
      Except if he was using PushKit in a compliant way.
  - fooey 7y ago
    Approval process roulette is exciting enough when you think you're following the guidelines.
- turdnagel 7y ago
  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?
  - lacker 7y ago
    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.
    - JustSomeNobody 7y ago
      > 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.
Blinks- 7y ago
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.
- reaperducer 7y ago
  "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.
  - Wowfunhappy 7y ago
    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!
    - dave5104 7y ago
      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.
- olliej 7y ago
  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.
- pwinnski 7y ago
  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.
- 7y ago
t0mbstone 7y ago
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.
- pcora 7y ago
  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
- cromwellian 7y ago
  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.
  - jakear 7y ago
    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.
    - hombre_fatal 7y ago
      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.
kevin_b_er 7y ago
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.
- csande17 7y ago
  They already have: https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension https://developer.apple.com/documentation/usernotifications/...
floatingatoll 7y ago
Previously on this same topic, 29 days ago: https://news.ycombinator.com/item?id=20629567 https://news.ycombinator.com/item?id=20629567
eridius 7y ago
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.
- joecool1029 7y ago
  > 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-whatsapp-sending-end-to-end-encrypted-messages-in-push-notifications https://security.stackexchange.com/questions/119624/how-is-w...
- madrox 7y ago
  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=objc https://developer.apple.com/documentation/pushkit?language=o...
  - mobilio 7y ago
    Correct! But also some authors uses PushKit to keep their app constantly running in background.
- lacker 7y ago
  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.
joecool1029 7y ago
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 https://forums.developer.apple.com/thread/118607
comex 7y ago
Note that the intended replacement API has been available for three years: https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension 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://twitter.com/moxie/status/1159127482143875072
- deleted 7y ago
  [deleted]
- oneplane 7y ago
  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.
  - saagarjha 7y ago
    The complaint is that that the server now needs to know the difference between the types of messages passing through it.
lacker 7y ago
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.
- _bxg1 7y ago
  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.
skybrian 7y ago
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.
- RandallBrown 7y ago
  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.
malicioususer11 7y ago
What? People dont want a million invisible notifications sent without their awareness?? Madness.
jjtheblunt 7y ago
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.
ajconway 7y ago
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.
Andrew_nenakhov 7y ago
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.
- vonseel 7y ago
  By “work like shit”, what exactly do you mean? Slower delivery? Unreliable delivery?
  - Andrew_nenakhov 7y ago
    Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.
    - p2t2p 7y ago
      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.
      - Andrew_nenakhov 7y ago
        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.
        dang 7y ago
vonseel 7y ago
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?
- lacker 7y ago
  For the vast majority of cases it’s better to just use the Apple push notification API and not try to keep a background process running constantly.
  - vonseel 7y ago
    What if you need to decrypt the payload?
mickael 7y ago
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.
- Andrew_nenakhov 7y ago
  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.
laythea 7y ago
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.
- colejohnson66 7y ago
  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.
  - laythea 7y ago
    The article says "Apps that exploited PushKit could drain iPhone batteries, Apple said." and "The basis for doing this is battery savings"

133 points by ballmers_peak 7y ago

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.

msie 7y ago
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.
- Icathian 7y ago
  Well sure, but on the other hand now all your stuff isn't broken. Give and take, I think.
  - AmericanChopper 7y ago
    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.
    - hosteur 7y ago
      What was the change?
    - pfranz 7y ago
      Working the refs works way more often than people think.
  - kabes 7y ago
    Except if he was using PushKit in a compliant way.
- fooey 7y ago
  Approval process roulette is exciting enough when you think you're following the guidelines.
turdnagel 7y ago
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?
- lacker 7y ago
  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.
  - JustSomeNobody 7y ago
    > 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.

Blinks- 7y ago

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.

reaperducer 7y ago
"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.
- Wowfunhappy 7y ago
  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!
  - dave5104 7y ago
    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.
olliej 7y ago
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.
pwinnski 7y ago
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.
7y ago

t0mbstone 7y ago

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.

pcora 7y ago
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
cromwellian 7y ago
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.
- jakear 7y ago
  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.
  - hombre_fatal 7y ago
    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.

kevin_b_er 7y ago

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.

csande17 7y ago
They already have: https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension https://developer.apple.com/documentation/usernotifications/...

floatingatoll 7y ago

Previously on this same topic, 29 days ago: https://news.ycombinator.com/item?id=20629567 https://news.ycombinator.com/item?id=20629567

eridius 7y ago

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.

joecool1029 7y ago
> 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-whatsapp-sending-end-to-end-encrypted-messages-in-push-notifications https://security.stackexchange.com/questions/119624/how-is-w...
madrox 7y ago
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=objc https://developer.apple.com/documentation/pushkit?language=o...
- mobilio 7y ago
  Correct! But also some authors uses PushKit to keep their app constantly running in background.
lacker 7y ago
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.

joecool1029 7y ago

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 https://forums.developer.apple.com/thread/118607

comex 7y ago

Note that the intended replacement API has been available for three years: https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension 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://twitter.com/moxie/status/1159127482143875072

deleted 7y ago
[deleted]
oneplane 7y ago
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.
- saagarjha 7y ago
  The complaint is that that the server now needs to know the difference between the types of messages passing through it.

lacker 7y ago

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.

_bxg1 7y ago
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.

skybrian 7y ago

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.

RandallBrown 7y ago
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.

malicioususer11 7y ago

What? People dont want a million invisible notifications sent without their awareness?? Madness.

jjtheblunt 7y ago

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.

ajconway 7y ago

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.

Andrew_nenakhov 7y ago

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.

vonseel 7y ago
By “work like shit”, what exactly do you mean? Slower delivery? Unreliable delivery?
- Andrew_nenakhov 7y ago
  Yes, slow delivery when user is low on battery. No delivery at all if a user swipes an app away.
  - p2t2p 7y ago
    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.
    - Andrew_nenakhov 7y ago
      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.
      - dang 7y ago

vonseel 7y ago

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?

lacker 7y ago
For the vast majority of cases it’s better to just use the Apple push notification API and not try to keep a background process running constantly.
- vonseel 7y ago
  What if you need to decrypt the payload?

mickael 7y ago

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.

Andrew_nenakhov 7y ago
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.

laythea 7y ago

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.

colejohnson66 7y ago
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.
- laythea 7y ago
  The article says "Apps that exploited PushKit could drain iPhone batteries, Apple said." and "The basis for doing this is battery savings"