Hacker News Reader

Comment by satvikpendem | Hacker News Reader

If your app needs to send a notification while it's not currently a running process, it must go through Firebase on Google's side and APNS on Apple's side. There is no way for a non running app to send a notification entirely locally, this is by design of both companies.

View on HN

Signal developer here. Not entirely sure what you're saying. I'm only an Android guy, but FCM messages are certainly one trigger that can allow an app process to run, but it's not the only trigger. You can schedule system alarms, jobs, etc. And the notification does not need to be provided by the FCM message. In our case, the server just sends empty FCM messages to wake up the app, we fetch the messages ourselves from the server, decrypt them, and build the notification ourselves. No data, encrypted or otherwise, is ever put into the FCM payloads.

Sure but it needs to go through Firebase regardless of the content of the notification message, I do not believe there is a way to use a third party notification service which does not depend on Firebase.

Any application can send notifications without going through a server.

How? I'm not talking about an application backend server but a notification server which Google and Apple have for all apps. I'm not sure besides polling or having a persistent connection to send notifications to an app while that app is not running.

When running Signal without google play services, Signal reliably received push notifications and with minimal battery drain.

Do you have microG? That provides a compatibility layer for FCM.

No, my intention was to not touch google services.

It doesn't. The API for displaying a notification is purely local.

Receiving a ping from Firebase Cloud Messaging triggers the app to whatever it does in order to display its notification. In the case of Signal, that probably means something like fetching the user's latest messages from the server, then deciding what to show in the notification based on the user's settings, metadata, and message content.

Here's example code for using FCM to show a notification. In this case, the notification content also passes through FCM, but Signal does not do that. https://www.geeksforgeeks.org/android/how-to-push-notificati...

Sorry I should clarify, by "it" I meant any sort of ping must go through Firebase Cloud Messaging, not that the message content itself goes through Firebase.

Looks like there is a way to bypass Firebase by using something like UnifiedPush which runs a perpetual background process that acts similar to Google Play Services to pick up notifications from the server and calls the local notification API.

It's theoretically possible to just keep an app running in the background all the time and periodically poll a server.

That's unreliable though since some OEM Android builds will kill it for that even if the user disables battery optimizations. Those OEMs sort of have a point; if lots of apps did that it would drain the battery fast.

Then that's basically what I said right? That there is in practice no way to opt out of using Firebase if you want consistent notifications.

Not clear what your point is. The Signal server wakes up the app via an empty message. At most the info this conveys is that a Signal app got a message to pull.

My point is there is no reasonable way to remove oneself from Google and Apple even with a fully custom application, they control the notification servers for their devices.

Yea sorry I didn't follow the thread properly.

> […] this is by design of both companies.

This is more of a fundamental technical limitation of operating systems and networks; I don't think it is possible to design distributed communication between arbitrary service provider infrastructure and end-user devices without an always-online intermediary reachable from anywhere (a bouncer, in IRC terms) that accepts messages for non-present consumers.

Yes, however the fact that it is not customizable is what is annoying, you are forced to rely only on the OS makers' implementations, which I guess should be expected in the day and age.

It sounds like you’re hinting at being unhappy with the lock-in forced by the ecosystem.

The flip side of the coin: any possibly avenue to exfiltrate data and do (advertising) tracking by app developers will be used. The restrictions also protect my privacy.

And my phone battery.

Clearly they don't protect your privacy as evidenced by the post we're commenting on.

> this is by design of both companies.

I’ll note that whatever other reasons it’s also the only way to make this battery efficient. Having a bunch of different TCP connections signaling events at random times is not what you want.

Ideally the app also is responsible for rendering rather than having to disclose the message but that can be challenging to accomplish for all sorts of reasons).

But there is a way to do this encrypted, so that when the notification is received on your iPhone, the process itself needs to decrypt it.

Except you need an entitlement for that, because it requires that your app has the ability to receive a notification without actually showing it (Apple checks this).

Your app gets woken up, decrypts the message, and then shows a local notification.

Reply on news.ycombinator.com