[lacker]

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]

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.

[EGreg]

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.

[mapmap]

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.

[crummy]

Could Apple have slowed down VoIP notifications before, to negatively affect FB messages vs iMessage?

[azinman2]

While I don’t work on this at Apple, I’ve never once heard of anything being designed to punish a competitor like that.

[GeekyBear]

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.

[toast0]

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.

[GeekyBear]

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.

[pmart123]

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.

[pdimitar]

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.

[toast0]

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.

[joshuamorton]

> 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.

[GeekyBear]

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.

[jbverschoor]

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

[scarface74]

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.

[pdimitar]

And I did. That's not related to my parent commenter's point, I think.

[scarface74]

Apple has had “Background App Refresh” for a while now.

[lacker]

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.

[GeekyBear]

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.

[whycombagator]

> 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.