Hacker News Reader

Comment by dep_b | Hacker News Reader

Not being able to lurk in the background does not have anything to do with security. I don’t think Signal uses it and they’re generally considered secure. You can check out their source.

View on HN

The current Apple VoIP APIs don't actually let apps run in the background all the time anyway. What they provide is a way to instantly remotely wake up an app, let it connect to your server in the background, do some local processing, and then create and display a notification. This is exactly what end-to-end encrypted messaging needs, but Apple is killing off the ability to use the VoIP APIs in this way in iOS 13.

Signal uses the exact same PushKit VoIP API that Facebook does, by the way - check PushRegistrationManager.swift in their source. I'm not sure if they use it for text chat as well as voice, but I assume so since there's no references to the newer API they could use in their code and they still support iOS 9 which doesn't have it (as do Facebook Messenger and WhatsApp). Edit: I think it's safe to say that Signal does this, given that Moxie Marlinspike isn't aware of any other way to do it: https://twitter.com/moxie/status/1158852855291269120

(Well, they don't intentionally let apps run all the time in the background. They're quite lax about how long apps can run for in the the background after being woken up in order to support voice calls, but that's not the feature messaging apps need from them.)

This is what is confusing about this article anyway. You used to be able to run your VoIP application in the background all of the time. This has been closed for longer. But WhatsApp and Facebook are really old apps, supporting pretty ancient versions of iOS (last time I checked). They might have inherited the capabilities back from the time it was the only way to have VoIP?

The intended way VoIP application should work is using PushKit and CallKit to show a native call screen after receiving a special VoIP push notification message. Only when the user accepts the actual application will open.

"Background App Refresh" is used for silent push notifications, which should be used to download content when the application is not running. It could be used to download images in messages ahead of time, though could be abused just as well. "Background App Refresh" is not a reliable way to deliver notifications to an application since they're dropped pretty easily.

VoIP apps built against the iOS 9 SDK and earlier can still run in the background all the time, but we know WhatsApp and Facebook Messenger have used iOS SDK 10 or higher since 2016 because they introduced support for CallKik back then which requires that version. Also, the current version of their apps only support iOS 9 and newer and PushKit has been available since 8. As far as I can tell, the media coverage is just misleading in a way that pushes their existing narratives about Facebook and Apple.

Signal docs say it needs Background permission :

"Without this, there may be a delay in sending and receiving messages."

https://support.signal.org/hc/en-us/articles/360007062172-Si...

That doesn’t mean encryption won’t work, just that you may not get instant notification of messages.

Yes, but I did not mention security. I commented on "I don’t think Signal uses it". I should've quoted it.

I wouldn't be so sure about that: https://twitter.com/moxie/status/1158852855291269120

Would be interesting to hear his opinion on this. It's awesome anyway that all of the source is just in the open. I often use it as a sanity check for my own code when I'm dealing with messaging and VoIP.

You can test it yourself, by turning off background permissions. You will still receive messages.

Background processing simply allows it to have the message ready for you by the time you open the app.

I read a reply on Twitter explaining why it was used on Signal (and I can't update my own statement anymore). So basically these push notifications are used because they always work and they work for everything.

If you would use the custom notification handler you are required to show a notification, which is fine for a new message but doesn't make sense for read confirmations, "is writing" updates or all other types of information that should not pop up to the user immediately.

Of course you can work around it by using a WebSocket while the app is open and only use push notifications for new messages but obviously that's going to be less tight than the current situation.

Reply on news.ycombinator.com