1mo ago

Why do push notifications work the way they do

So I always here about on how Google Android and IOS those companies can see all your notifications. This is because to show a notification it calls an API.

Is there any technical reason that it has to send your notification data to Google and Apple or is it just to get more data on you?

15 comments

At least on Android you have two options: you use Google's notification API which lets your app sleep until the system wakes it back up on receiving a notification. Or you skip all that, then your app has to run in the background or you won't get notifications. You can guess what this does to your battery.
- Centralized vs decentralized. I'm willing to sacrifice privacy for battery in this case, honestly.
- Decided to go the let app run in the background on graphene. With 3 apps in the background running all the time. Battery last 12 hours, with heavy use less. I'm unaware of how to get or self host push notifications outside of Google. It's not death to your battery but it defintely shaves off 20 percent and that's a rough number.
  I've been using a pixel for 2 years with 600 plus cycles and my battery health is still 100 percent excellent, I did a hardware health check today.
  
  Great. Now do 40 apps and try not to get them killed by the OOM mechanism. I'm not saying I like the fact that messages go through Google's servers, but I'm afraid there is no equivalent FOSS solution.
- Ntfy exists. I use it for 3-4 apps.
  
  How do you get it to do discord and other random apps?
Is there any technical reason that it has to send your notification data to Google and Apple or is it just to get more data on you?
the API that for example Google Firebases provides (most used, as it supports ios and android), is basically "send a notification with following content to this device".
Which is very simple to implement. as it's just fire and forget. But you send the actual data to Google in this case.
There are way to do it differently, for example how signal does it: They send a silent (e.g. invisible) notification to the device, which has no data in it.
That notifiation tells the app to check for new messages.
The app will then fetch messages in the encrypted way as it always does, and displays a notification if needed. No need to send actual data through the notification service (other than the metadata, that notifications should be pulled)
device maintains a single connection to Google server
vs
every app maintains their own connection to their server
More technically there's two ways to move data between two separate services. You can either pull or push the data.
Assume for both scenarios that the client is your phone and the server is some machine in the cloud.
With pulls the client calls an API and the server returns a response. Generally the www works this way. You ask a server for a wab page and you effectively pull the source down to your browser.
Pushes work the opposite, in that a server has data for the client and needs to push or otherwise give it to you. Pulls are relatively strait forward because every server has a well known name (the domain name and url). But your phone's IP address changes constantly. So how does a server know how to contact your device? There's generally two ways:
Your device can poll (make repeated pulls to a server checking for new data)
Or you can register some identifier and your IP address with some central server every time it changes. And then the server can essentially call a URL on your device directly. This is essentially what Google and Apple are doing as it doesn't waste CPU resources and your battery.
You could in theory implement either of these yourself but because of the way the OSes work on both Android and iOS there's no guarantee that you can keep a process running in the background forever. As the OS can kill your process if the OS needs more free ram, etc ... The built in notification APIs are exempt from this because they are part of the OS.

15 comments