Apple Change Causes Scramble Among Private Messaging App Makers
theinformation.com
theinformation.com
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I kicked out zoom and adobe permanently for the same reason
Respect the battery life of my device.
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.
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.
If privacy will truly be compromised then there's always the option to not support push notifications.
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.
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.
> 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.
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?
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.
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.
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.
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...
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...
But also some authors uses PushKit to keep their app constantly running in background.
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.
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
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.
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.
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.
We even added honest working VoIP calls to an app to have legal access to working background notifications, and now they pull it away.
Slower delivery? Unreliable delivery?
If your protocol is so bad it can’t handle intermittent connection, well to hell with this protocol.
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.
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?
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.
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.
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.
https://developer.apple.com/documentation/usernotifications/...
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.
* edit: typo
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.
Invest less time in apps and more time in trying to understand your kids.
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.
EDIT: downvote because why?
I only want to be notified if he leaves the school premises during school hours, I don't want to micromanage his location otherwise.
> 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.
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.
The number of users who would understand that phrase and find it useful in making a decision is roughly .000000001%. Maybe.
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.