
Fuck Cloud Messaging - anthropodie
https://telegra.ph/F-Cloud-Messaging-09-13
======
ogre_codes
> Instead, they have this warped reasoning where they don't allow any program
> to run in background, except theirs, "to save the battery".

Looking at the landscape of shit software out there, I find this justification
entirely plausible. If iOS & Android didn't lock this down, phones would be
running 4-5 different poorly implemented push platforms (or more). Battery
performance on mobile would be utter crap.

There is a big balancing act going on here. People want phones that do the
thing they are supposed to do. They also want battery life to be _excellent_
and the device to be secure by default. It's impossible to give 3rd party devs
100% access and meet those 2 demands.

~~~
potamic
It's easy to implement a software solution that punishes poorly behaving apps
and allowing the rest.

~~~
cortesoft
No matter how good the push implementation is, it is still best to only have
one connection that the phone has maintain. 5 great push services still takes
5 times the battery that 1 great push service would take.

~~~
jlokier
> 5 great push services still takes 5 times the battery that 1 great push
> service would take.

This is true with current implementations, but it doesn't have to be true.

Coordinated CPU wakeups and radio packet timings would mean the power
consumption from waking the radio would be not much larger with 5 apps than 1.

It needs coordination, but the coordination doesn't have to be done inside a
service daemon as it is now, and it doesn't have to go through one shared
cloud service provider as it is now.

~~~
ogre_codes
> It needs coordination, but the coordination doesn't have to be done inside a
> service daemon as it is now, and

It more-or-less does need to go through a single daemon, or it would be nearly
impossible to coordinate the requests.

> it doesn't have to go through one shared cloud service provider as it is
> now.

This is more true, for example you could have an open protocol and an app
could register with the push daemon. It would be impossible to consolidate
push notifications or throttle them for bad actors though.

~~~
jlokier
> It more-or-less does need to go through a single daemon, or it would be
> nearly impossible to coordinate the requests.

A single daemon, or a single kernel, it doesn't really matter which.

I'm thinking a few socket() options. The kernel already coordinates coarse-
grained timer wakeups between processes; it's not that outrageous to think it
could nudge multiple pinging sockets towards each other then coalesce timings.

The underlying mobile network registration for notifications is already quite
low level.

> It would be impossible to consolidate push notifications or throttle them
> for bad actors though

At least at the moment, I don't think there's a need to consolidate push
notifications into the same packet for different apps. The rate of
notifications isn't high enough to matter.

For keepalive pings (if the underlying radio network can't provide events to
piggyback on), and consolidating pushes (if that is needed), voluntary
cooperation on timings among good actors would allow incoming packets to
arrive around the same time, and the mobile base station could, if a protocol
was agreed, queue and coordinate the transmission time of those packets as a
group, or coalesce them into a specially-addressed packet representing the
group.

For throttling bad actor pushers, the device itself (kernel or daemon) could
block sockets and source IPs that are sending too fast.

Presumably there's already some mechanism in place for things like SYN
attacks. If there isn't, bad actors already have a way to drain your battery.

------
fcm_throwaway
One of the more insidious things Google has done here is that they force you
to use the Firebase SDK to implement Cloud Messaging / Push Notifications.

This SDK has "Google Analytics for Firebase" enabled by default, and they use
dark patterns to make it seem like having Analytics enabled is required:
[https://imgur.com/a/Nk2KhFo](https://imgur.com/a/Nk2KhFo)

Of course, if you do enable analytics, then Google sucks up your customer data
(including in-app purchase behavior!) for their own data collection and
advertising purposes. Also, you're required to tell your users this is
happening, but of course developers don't know this. (More dark patterns in
how Google reveals that they steal your analytics data for themselves:
[https://imgur.com/a/R0K71Zn](https://imgur.com/a/R0K71Zn))

~~~
risyachka
As far as I know to add Analytics to your mobile project you need to
explicitly do that in Android studio or Xcode.

Enabling it in your project like you show on the screen does basically nothing
as long as you don't have analytics SDK in your app.

~~~
fcm_throwaway
When you go to add the SDK, Analytics gets added by default. The setup flow
makes it seem to be required. But also the previous screens (when creating a
Firebase account) appear to imply that Cloud Messaging won't work correctly
without analytics.

[https://imgur.com/a/Fl919Wm](https://imgur.com/a/Fl919Wm)

~~~
risyachka
> For an optimal experience with Firebase Cloud Messaging, we recommend
> enabling Google Analytics in your project

This is stated right before the steps you show. Only the one who doesn't read
will blindly add analytics.

------
jitl
On the other hand, when I used Android (2010s), I remembered using tools that
required root – or even custom OS builds – just so I could prevent apps (like
Facebook) from running in the background and draining my battery doing who-
knows-what network activity. In this case, I much prefer today's heavy-handed
platform restrictions on background processes to yesteryear's permissive but
perpetual battery-drained Android ecosystem.

Edit: the article references this HN thread, which I'm sure we'll end up
rehashing:
[https://news.ycombinator.com/item?id=22310319](https://news.ycombinator.com/item?id=22310319)

~~~
umvi
Surely they could have put in a switch in a sub sub sub menu that allows the
user to still have the freedom to have apps with background processes though?

The thing I hate is megacorps slowly infringing and removing device/OS
freedoms in the name of some stated "good cause" (security, malware
prevention, battery life, etc.).

~~~
jitl
There is such a setting:
[https://support.google.com/pixelphone/thread/6068458?hl=en](https://support.google.com/pixelphone/thread/6068458?hl=en)
Although perhaps it is not respected correctly by the OS?

~~~
anthropodie
I have had this enabled for KDEConnect in past but it still used to fail.

------
valuearb
I don’t see the authors point, battery life is important. A phone is not a
Unix server or a desktop PC. This is the same reason iOS doesn’t allow apps to
have arbitrary background execution time.

And phones know your location virtually 100% of the time because of cell tower
triangulation. That’s part of being a phone, not a google hypocrisy.

~~~
swiley
You can leave a socket open in the background (although you do need a periodic
keep alive but the period can be pretty long.) to receive push messages
without draining the battery (as long as the server doesn’t spam it.).

The real problem is pushing everyone towards unconfigurable closed software
that would otherwise abuse full access to the device. Because people can’t
trust what they run on their phones the apps can’t be given any more
privileges than a random web page.

~~~
ogre_codes
> You can leave a socket open in the background (although you do need a
> periodic keep alive but the period can be pretty long.) to receive push
> messages without draining the battery (as long as the server doesn’t spam
> it.).

This only works on a platform where apps can run in the background
indefinitely. Small memory, limited CPU, and battery life means apps have
short life-spans on phones.

This is why there is a push notification service for mobile platforms.

~~~
swiley
Modern phones have as much memory as most people’s laptops.

The reason apps have to have short lifetimes on people’s phones is because
they’re encouraged to install untrusted software as native apps.

------
marcan_42
My biggest problem with FCM is how hostile it is to open source and self-
hosted services. If you want to push a message to a phone, you don't just need
to be registered with Google; you need to _be_ the app developer. App
developers cannot allow third parties to push to their app, because they'd
have to give them their FCM credentials, which is a no-no.

So the only way to get push notifications on, say, apps that provide a client
for generic protocols or self-hosted services, is for either the app developer
to run a proxy gateway (which inevitably runs into scalability issues forcing
them to start charging for it or require registration with free quotas), or
for you to create your own build of the app. I ended up having to do that with
Linphone, rebuild it under my own app ID with my own FCM creds, just so I
could get push notification integration with my own SIP server instead of
having to keep a background SIP connection open to receive calls.

This is completely silly, with the only free endgame being everyone has to
compile their own apps and have one app installed for every potential
provider, even if they share a protocol.

~~~
techslave
> they'd have to give them their FCM credentials, which is a no-no.

trivially addressed via a proxy, which you’d want anyway to properly monetize
it

~~~
jlokier
GP: "open source and self-hosted services"

There's probably no wish to monetize, just to distribute working apps for
free.

You're right that the issue is easily addressed with a proxy.

But now you need to maintain and pay for a proxy in perpetuity, for other
people to use who aren't paying anything.

Even if it's cheap, maybe you don't have the time. It will break occasionally.
Knowing there are people who may depend on it 24x7x365 is burdensome too.
You'd like to have vacations.

It's not very open source friendly if other people can't just take your
software and run it themselves without depending on you.

Those other people can avoid depending on you by registering themselves with
FCM, but having to do that is not open source or self-hosted friendly either,
which was the GP's point.

------
maple3142
GCM doesn't work in China, so the Android ecosystem there is very different
from the world.

Before manufacturers come up with there GCM alternative, each apps actually
have there own service to handle push messaging. It is fine when the number of
apps is small, but drains a lot of battery when it gets larger. So
manufacturers started to introduce some aggressive strategy to kill background
processes to save batteries, but it also makes small developers' app less
usefull. It is because apps from big corporations usually get a pass, while
others will be killed. Now, as far as I know, manufacturers have their own GCM
alternative now as an alliance.

So I think even if you don't have it, you eventually need one, because it is
too inefficient to let each apps handle this by themselves.

~~~
anthropodie
Why not start using OpenPush which is decentralized
[https://news.ycombinator.com/item?id=22306174](https://news.ycombinator.com/item?id=22306174)

------
swiley
Apple is even worse. There is a singular service, there’s, and using it costs
$100/year. Rate doesn’t matter ... and Mozilla can run theirs for free.

I’m just glad my pinephone shipped and everything on my phone _actually makes
sense_ now (even if I have to compile things and write a few config files.)

~~~
ogre_codes
> Apple is even worse. There is a singular service, there’s, and using it
> costs $100/year.

You say this like it's some egregious burden. Compared to the cost of building
an app and shipping it $100/ year is a fraction of a drop in the bucket. It's
less than 1 developer hour.

If you are capable of building an app with push service, the cost is trivial.
If you aren't capable, it's irrelevant.

~~~
banachtarski
$100 is actually a really big deal in developing countries and lower-income
areas. How many of us started working on software to experiment with for
_free_ growing up? Arbitrary cost barriers like this are honestly an
impediment to learning, and in my opinion, even harmful to Apple in this case.
Why wouldn't they want more people to learn iOS programming and Swift
programming.

~~~
ogre_codes
The cost to learn to program on Apple's platforms is the cost of an iPad or
Mac. The $99/ year is only required if you want to deploy an app to the App
Store or use Apple's cloud services.

~~~
creativeCak3
I will get downvoted for saying this, but I don't care: STOP defending Apple.
The amount of egregious things Apple has done over the years is amazing. Not
only do they charge developers for publishing apps EVERY year, but they also
make up arbitrary rules in the name of "Privacy" or "Better user experience".
Oh Please. You want to give people Privacy? Use open protocols for your shitty
iCloud so that people KNOW just how much data you are are giving your Siri-
shit voice assistant. Want better user Experience? Let me transfer music and
ebooks to MY iPhone without having to use your joke of software called iTunes.
And trust me, I used to be a big fan of theirs. But after they started glueing
everything to their "computers", I had a wake-up call. The macbook used to be
a great product, and then they started glueing everything to it and shoving
the iCloud into it. Slowly, they killed their own product.

So please, stop defending them. They are doing really shitty things that will
just become stains in computing history.

~~~
ogre_codes
I'm not "defending Apple" here, I'm pointing out simple economics. A typical
app costs upwards of $50,000 in developer time to build. Even if you are
building your own app, we're talking about a person with valuable skills
investing months of their personal time. This idea that for a typical
developer $99 is a huge burden is just not an issue.

This is true if you love Apple or hate them deep in your soul for a million
burning reasons.

~~~
sofixa
And not everyone lives in the US. How much do you think it costs in USD for an
app developer in a developing country to create an app, and how much is that
$99/year as a percent of yearly income?

------
amar-laksh
Ever tried to send a push notification to your phone? How hard can it be? - At
least locally, KDE
Connect([https://kdeconnect.kde.org/](https://kdeconnect.kde.org/)) got you
covered.

~~~
anthropodie
It doesn't allow you to send custom notification though. I am using GSConnect
on desktop btw.

------
67868018
Apple has this solved for iOS 14

[https://developer.apple.com/videos/play/wwdc2020/10113/](https://developer.apple.com/videos/play/wwdc2020/10113/)

------
ocdtrekkie
This is one of those subtle ways the Play Store protects its monopoly. Sure,
you _technically can_ install an app without using Google Play Services, but
notifications won't work.

~~~
onli
But to not be misleading, that does not mean you will not get notifications in
apps that need them. The F-Droid version of Telegram will still notify you
when someone writes you, and mail programs will still show a notification
about incoming mail. There are alternative solutions.

And there is microG, to hook into the Google way of doing things.

------
asdfasgasdgasdg
I still see apps that poll from time to time. Most of them require keeping a
notification active to prevent their service from getting shut down. Surely
under such a regime you could send a "push" notification to the phone. Not
sure how easy it is to listen on android though.

~~~
zaptrem
Doesn't Android have a local notification function like iOS does?

~~~
throwaway8941
It does. You have to keep one running (with it being impossible to dismiss) if
you want to prevent your application from being shut down. That's what GP is
talking about.

~~~
asdfasgasdgasdg
To be fair I believe you can now "mute" these permanent notifications and you
still get the same user experience, although with an extra step.

------
cocktailpeanuts
It's funny how he's even imagined implementing his own push server. Only
because Android. On iOS people have already taken for granted that you must go
through APNS.

Also, this is not just about push. The problem is that Apple and Google de
facto own the edge user interface: phones.

~~~
swiley
It doesn’t have to be this way. You can buy pine phones now and they actually
work.

~~~
oneplane
But does it work at scale and with the UX of the other platforms? If so: why
hasn't it taken off yet?

The technical part is not the hardest part; it's the "everything else".

~~~
swiley
Personally I don’t like the UX of other platforms at all so I don’t see why
that’s a requirement.

It hasn’t taken off yet because it’s only barely started shipping.

~~~
packetlost
One of my friends has one of these and says it's horribly unstable and the LTE
usually doesn't work. I imagine there's still a lot of work to be done to make
it usable for technical people, much less non-technical people.

------
jayd16
This article is just lame. OP couldn't seem to figure it out but you can
implement a background service.

>why not shutdown location and frequent play service updates as they aren't
helping my phone battery either

They do. The recommendation is to use the location library that batches GPS
use instead of manually calling it per app. The playstore uses heuristics to
know when to query for updates and when to download. Its better that the OS
batches these sorts of things.

There may be some valid critique but this article is devoid of anything
useful.

------
whatsmyusername
Any end-user tech that requires a listening port on the internet will:

A: Never work, because NAT isn't going away (even with increased IPV6
adoption). Even locally it will work less and less because "block all incoming
connections" host firewall configs will eventually become the norm.

B: Be a security risk waiting to happen (EX: Chromecasts using UPNP to expose
themselves to the internet, which were immediately blasted with broadcasts
from one of PewDiePie's wretched fans).

------
maxbaines
Via a PWA seems like the Notification API works with no 3rd party
[https://developer.mozilla.org/en-
US/docs/Web/API/Notificatio...](https://developer.mozilla.org/en-
US/docs/Web/API/Notifications_API/Using_the_Notifications_API)

~~~
swiley
This is for locally generated notifications only. Push messages are different,
last time I checked Mozilla operates a free service to relay push
notifications.

~~~
maxbaines
I suppose the OP should comment, but I read that although local push was tried
there was a wider view about using walled services. the Push API does solve
that.

------
3np
This is the most significant hurdle to do proper decentralized smartphone
applications today. Me and some friends were sketching on something that could
be used for grassroots movements and peer-to-peer marketplaces - push
notifications is the one thing making it practically untenable.

~~~
valuearb
Open source a push server, boom, problem solved.

~~~
3np
Unless there's something I'm completely unaware off, there's still no way to
make that work without root (Android) or jailbreak (iOS).

~~~
valuearb
You can connect your third party push server to APNS no problem, it’s fine all
the time.

------
guerby
I've never looked deeply into this notification thing but people seem to
conflate saving the battery and having only one notification server.

If energy used by firing up the CPU frequency plus the 4G radio to send some
packet is the main battery drainer, why not just synchronize the poll of
multiple notification servers?

The CPU will be waked up, a few data packets will go to a few notification
servers, then in the common case of no notification everything goes back to
sleep.

If it's the network that wakes up the phone when some packets are there (as
WiFi energy saving does), if synchronized in time (NTP goog enough) it should
also work and be energy efficient.

Probably naive, curious about real world measurements in this area :)

~~~
room500
Just one issue - there are timers on connections regulating how long a
connection can be kept alive before a packet is required. Larger timeouts are
better for phones, but require more resources on the servers/networks.

Google/Apple work directly with carriers to extend the timeouts for their push
services so the phones aren't required to send keepalive packets every 30
seconds to keep the connection alive. Carriers won't be willing to do that for
every random server out there.

This is just one of many ways these push services are carefully
designed/operated to save as much battery life as possible. If you had more
than one notification service, battery life would degrade to the worst
performing one (the radio would be forced to wake up to keep _every_
notification service alive... Even if the Google one could go minutes between
the keepalive packets)

(Another is the way Google batches low priority notifications... Sending a
push message won't immediately wake up a phone - it delays to try to batch as
many messages as possible. This scheme breaks down if messages aren't all
routed through a single server)

------
BlueTemplar
Can't we move to IPv6 where there is no NAT ?

~~~
WarOnPrivacy
Not if you have an ISP, that won't ever support IPv6. There are a lot of us
(in the US) in that boat. It's hard to play with unavailable tech.

edit: removed stuff about Push via SIP, that might be too incorrect to be
helpful. Also removed some pondering about trying msg.exe over IPv6. I was
probably fishing for trouble there.

~~~
BlueTemplar
They're going to have to move to IPv6 : with Europe running out of IPv4
addresses, and a lot of third-world countries never having had enough of the
in the first place, soon enough an IPv4-only connection won't be considered a
real Internet connection any more...

~~~
WarOnPrivacy
They're not. Over 10 years, our ISPs went from "imminent deployment" to
"looking into it" to "what is IPv6?".

In 2030 we won't have native IPv6 and it won't be on the drawing board.

------
return1
We just need an SMTP extension that says ‘this email is a notification. Delete
after x days’. The rest of the mechanism is there. Apple and google will
follow. Emails may not be instant but most notifs are not urgent. I know there
are 1000 other protocols out there, but email is the only one that s widely
used and hasn’t been bastardized or wallgardened

------
snthd
Related (Android):

[https://dontkillmyapp.com](https://dontkillmyapp.com)

------
SergeAx
If I have 50 apps on my device and 30 of them are keeping connection to their
mothership-server — they will indeed drain my battery in hours. I can't
imagine a plausible solution for that problem except centralized notification
service.

------
crizzlenizzle
Things like this explain some devs I encounter solve networking things which
could be done on a LAN level using multicast for instance instead through the
cloud.

------
gravypod
For anyone who's worked on an IoT platform built in Android this is a huge
pain that's nearly constant.

------
codegladiator
I really dislike the "to save the battery" reason. Lets also disallow games to
save the battery ?

~~~
valuearb
We are talking about background execution time.

That’s something that is hidden from users, they put their phone in their
pocket and two hours later their battery charge is substantially diminished.
They don’t understand why or how to stop it.

They know playing a game for hours straight reduces battery charge.

~~~
codegladiator
Okay, I get it, author provides another analogy as well thogh, probably more
apt. Their own location services.

~~~
valuearb
No they didn’t. Location services are a necessary part of being a phone.

It’s called cell tower triangulation and your phone needs to do it constantly,
or you can’t receive or send calls.

~~~
mindslight
You're posting shallow dismissals while seemingly having no idea what you're
talking about.

The complaint about location in the article is about Google's tendency to bug
you to turn on GPS and leave it on, happily draining the battery but for
Google's own surveillance purposes. Having a GPS fix is not a requirement of
the cell network.

Cell tower triangulation is something the network can do as a result of your
phone connecting to cell towers. While connecting to a cell tower is mandatory
for cell communication, an open baseband could make it a point to only connect
to one tower at a time (although a single tower will still have some location
information due to sector antennas).

~~~
valuearb
> Hey Google, why not shutdown location and frequent play service updates as
> they aren't helping my phone battery either

Doesn’t mention GPS. That may be what the author meant, but certainly could be
written far clearer.

Still, Google isn’t using GPS all the time, their power management strategy
can’t allow that. It’s likely only using it when its deemed necessary. Android
is tuned to balance offer users the most functionality possible with longest
battery life. If it did not iOS would destroy it in battery life tests.

Triangulation is necessary to determine which tower to connect to and when to
switch to a new tower. It’s why they are called “cellular” phones.

~~~
mindslight
> _It’s likely only using [GPS] when its deemed necessary_

The entire point is that Google encourages you to leave the setting on,
meaning you'll be doing GPS fixes more than what the user actually considers
necessary.

> _Triangulation is necessary to determine which tower to connect to and when
> to switch to a new tower._

No, it's really not. It's hard to even figure out what you're trying to
describe here.

Yes, the baseband sees the signal strength from each nearby tower to know when
to switch between them. But the baseband doesn't itself have a map of cell
towers. If the list of visible towers is used for client positioning, it
happens on the application processor. The work of deriving a location from the
towers is not necessary for cell network communication.

~~~
valuearb
Your points on the actual details of what how cellphones work is exactly
right, but it’s trivial to calculate location from those values. My point was
that your phone is not powering up any additional hardware, or doing anything
extra in software to burn battery life to estimate your location, the
information is already there. The phones application processor is already
monitoring them if only to keep your radio strength meter display accurate.

And Google should encourage you to keep GPS on if they do a good job managing
its power usage. Users aren’t always going to know when the app they are using
is going to work better with more precise location data. This is a user
friendly feature.

Circling back around, the author is still wrong that allowing installed apps
to run unrestricted background network processes is anything like the OS
carefully managing location accesses to minimize power usage.

------
YarickR2
Another pointlessly aggressive rant. Like it or not, FCM provides unified push
mechanism, aggregating communications for every app using it and ensuring
least resource usage . Open Push, or whatever it would be, will need to make
sure all apps used same server(s) and, preferably, single connection kept
alive, otherwise some apps will get notifications , others wont, and it will
be seemingly random.

~~~
WilTimSon
It's currently on the main page of Hacker News with 61 points and lots of
attention turned to it. Sadly, as long as people find this needlessly
aggressive tone appropriate, we'll keep seeing this kind of stuff everywhere.
It's like clickbait, fewer people would click on this if this was titled 'I
have some issues with cloud messaging', I know I wouldn't.

