Hacker News Reader

Comment by ysleepy | Hacker News Reader

This is an open-source implementation of the google cloud integration in Android that is necessary for push notifications in virtually all apps, the account mgmt that the Play Store uses and so on.

This makes it possible to use LinageOS without installing Google Blobs with root access, while having almost 90% of apps work as normal.

View on HN

> This is an open-source implementation of the google cloud integration in Android that is necessary for push notifications in virtually all apps, the account mgmt that the Play Store uses and so on.

No, sorry, this is not true at all - MicroG push notification module will talk to Google servers and use their infrastructure to deliver the notifications.

It can't really work any other way - the app backends will request notification delivery from Google servers and you can't really MITM that.

What exactly are you disagreeing with here? You're just saying the same thing a different way. It's open source, it implements google cloud integration, google cloud integration is necessary for push notifications...

Question: who is running the push notification service? Why are they doing it for free?

Considering app servers have to hardcode the https://fcm.googleapis.com/fcm/send API endpoint and auth details, I don't really see how push could work properly without each app developer modifying their server side code.

Most apps work kinda without push - you just have to open the app to get notifications.

I wonder if fastmail could be persuaded to put in a different endpoint for their app. They already have the infrastructure in place to run servers, and take a privacy stance. Not having to go through google would probably make them happy. Obviously it would have to be optional, but little cracks in the door.

Tutanota did that: https://tutanota.com/blog/posts/open-source-email-fdroid/

This seems like it would be great to release as a library. That might increase adoption.

There is a massive technical benefit for all apps to use the same push server.

If many different apps use their own push server, a connection has to be kept open to each and every server, and each open TCP connection costs quite a lot of battery (since the system has to wake up to receive keep alives)

Agreed, but I trust my email provider to provide push. I would be willing to block all the rest.

I'd imagine an accompanying Android fork could intercept requests to that address and send them elsewhere, no?

It might need to do naughty things to get around https issues, but that shouldn't be much of a barrier since the project would control both the client OS and the server endpoint.

Android fork cannot intercept request between (for example) Slack backend servers and Google backend servers.

To fork this service, you need your own push notification infrastructure and then persuade app developers to implement it as another option (next to Apple, Google, Firefox, Huawei and other existing ones).

There are push arbitrator services which make this easier, so perhaps having those on board might be a good path forward.

...oh, I just re-read the great-grandparent. I didn't realize the application's servers were talking to Google's servers, I thought the application was talking to Google's servers directly. That seems terribly convoluted, although I assume there's actually a sound reason for it.

The push servers (Google, Apple, etc.) effectively work as a message queue server - they aggregate and batch payloads and send them to the devices. The devices keep a single persistent HTTP connection for reception of all possible messages.

It's built like that due to efficiency - the devices need to minimize number of radio and CPU wakeups to keep running on battery. In early days of Android each app handled this by itself. This resulted in apps polling their servers on fixed interval (e.g. every 5 minutes, etc.) which caused a disastrous tragedy of the commons and horrible standby battery life.

This is why the approach was changed to mandatory push services - the long-lived TCP connection, push aggregation and radio management have significantly prolonged battery life.

Google runs the notification delivery on Android. It is part of of Firebase, which is present in almost every app on your phone

Firebase has analytics built in, on by default. Therefore Google gets to know how users use all other apps, so they can release their own version or just to improve their AI.

I think it is free, but only till a certain number of notifications. (Not sure, I am not an android dev)

https://firebase.google.com/docs/cloud-messaging/

It's still using Google's push notification server. There is also no way to get around this, as apps backend server talk directly to Google to send notifications.

I also just found this: https://news.ycombinator.com/item?id=25253091

which IS LineageOS without Google Blobs :)

When i used lineageOS+microG on my old phone i could not get Telegram + Signal to work. WhatsApp worked, but push messages arrived hours later or if i opened WA. No idea if this is fixed now.

I'm using MicroG for a year now and didn't have problems with push yet. Signal and WA are working fine, other Apps with push as well. No idea about Telegram, I'm not using that.

Telegram works for me if you use the Google Store version.

I think it's worth noting that Telegram and Signal both have fallbacks in the absence of FCM or microG. I use both daily and luckily am able to daily Android without any of Google's services or microG.

Reply on news.ycombinator.com