Hacker News Reader

Comment by MayeulC | Hacker News Reader

Wow, that was submitted here quicker than we could do it!

UnifiedPush has been a thing for a while, see the official website: https://unifiedpush.org/

With this blog post, we† tried to clarify a few names. Feel free to point out things that are still unclear, the documentation is pretty much a WIP.

UnifiedPush aims at replacing the push notifications mechanism provided by Google services with something independent, that anyone can self-host or any OS can provide without compatibility issues. It does require small adjustments server-side and client-side for applications assuming Google services.

There is also a Matrix room at #unifiedpush:matrix.org and a Mastodon account at https://fosstodon.org/@unifiedpush

Note: we'll be monitoring this topic for a while, you don't have to reply to this thread.

† karmanyaahm and S1m are main authors

View on HN

Sorry if I’m not understanding something but…

Doesn’t Apple and Google on the OS level only allow push notifications to come from its own services? Like, they look for the signature to be compatible with https certificate etc. Otherwise the phone could have a ton of push notifications incoming from anywhere on the Internet. The APN service for instance would only route notifications to a phone if it came from a registered website. How do you get around this?

As far as I know, even for VOIP permissions, iOS only wakes your code up if ITS APNS SERVICE sends the notification. How are you able to install a long-lived application in the background on iOS?

Similarly, the phone radio is listening for calls from the nearby cell towers in the network, not from absolutely any tower. I guess a Stingray can impersonate one, but they would probably need to fake the attestation, right?

I believe the notifications used to be delivered by a very long-lived TCP connection, and there probably is no limit to those on Android.

The reason to use the google services is mostly touted as for battery savings, I believe.

Afaik Google and Apple just discount their own poller. It still has to wake up and check periodically.

They have special deals with the telcos that TCP connections to their servers can have longer TTLs. Plus of course, even if you do polling, if you have 5 different apps that connect every 10 minutes to their own respective services with different offsets, you have the device waking up every 2 minutes, with a potential latency of up to 10 minutes for each individual service. If it uses a central push service, you can set it to 5 minutes, the device would therefore wake up less than half of the time, and maximum latency would be 5 minutes, not 10.

Thus, it makes total sense to have one mechanism for push messages for the entire device. It's great to have degoogled alternatives here.

> Plus of course, even if you do polling, if you have 5 different apps that connect every 10 minutes to their own respective services with different offsets, you have the device waking up every 2 minutes,

This is now impossible with background execution restraints set in Oreo. The OS clusters requests for background execution and does them with the same wake. Apps can only wake the device every 15 minutes at most (and requests to wake are not guaranteed).

> This is now impossible with background execution restraints

Signature spoofing is similarly "impossible" there's no rule saying this stuff can't be changed by distributions that care about it. You already have to install a custom OS to get rid of gapps to begin with so aside from the maintenance burden for changes that will never get upstreamed this is really a nonissue.

>and there probably is no limit to those on Android.

Not true since Android Oreo. Long running background Service execution (without a foreground notification) has been dead for a while. Most of the useful system-wide config change updates (implicit Broadcasts) got killed as well. Basically, only Google (or GCM/Firebase Messaging) gets to do timely push notifications. You can try to roll your own MQTT server, but there’s a good chance the OS will kill your Service, in which case you would have to poll every 15 minutes with JobScheduler/WorkManager, with no guarantee that background task would even get run every 15 min.

Afaik Push is really

Wake up one thing,

Check one place,

If (message) wake up correct app

The wake up one thing is the issue

Plus the real time push works differently… like a phonecall comes in and your phone rings thay same second

Thanks for your great work creating this protocol. Hope more app developers add support for it, especially for privacy focused apps like Signal which by relying on Google servers are leaking metadata.

Regarding Signal, I don't think they have been approached yet... https://github.com/UnifiedPush/wishlist/issues/8

I think the consensus was that we wanted to wait for UnifiedPush to be more mature before approaching them, but it's probably about time. S1m made an interesting implementation for the (compatible) Signal fork Molly: https://github.com/mollyim/mollyim-android/pull/152

The implementation is quite interesting: it adds a linked device that does not receive encryption keys, but sends push notifications to the client.

The team has been working to get UP support added to Molly, a fork of Signal for Android.

https://molly.im/

https://github.com/mollyim/mollyim-android/pull/152

If you deliver notifications, you are always leaking metadata around timing.

A police unit parked outside a guy’s house and confirmed it was him in the real time chatroom, by cutting his internet and seeing him drop off.

If you want real anonymity on the Internet, never use push notifications. Always “pick up your mail” periodically from random endpoints on the Web.

In theory, if you were worried about this, I think you could get around that problem by just constantly send fixed sized encrypted messages large enough to hold any potential notifications. When a notification needs to get sent, you add it to the next outgoing encrypted message. Of course, now the delay for notifications is now coupled to the rate of these messages being sent.

The messages can still be traced to the client picking them up. Cut their networking and the client doesn’t receive the messages anymore… this shows up as a bounced message.

You can accumulate encrypted messages at random urls instead

I guess I initially misunderstood what you meant by timing, but that makes sense.

If nobody in the chat room can know that you lost connectivity, that means you can't do real time chat and might as well use email instead.

Note that a similar thing happens with any two-way conversation; if an immediate reply is expected and there's no reply, it's not a conversation anymore. (For more possible reasons, though.)

Disappearances can't have good error messages if you want plausible deniability. This will make any UI much less user-friendly.

This would be an interesting protocol. Almost like spread spectrum or frequency hopping in the radio space.

Have many servers who just accumulate encrypted packets and then only the host knows how to reassemble them in order and decrypt.

Could probably be somewhat realtime if executed correctly.

Simply use free Usenet Servers via Tor and post your anonymous* PGP messages to the Usenet group alt.anonymous.messages.

*You send PGP encrypted messages via Mixmaster Remailers (via Tor) and preferably use a hashed subject (hsub) so that the intended receiver(s) can filter out their messages.

https://lists.gnupg.org/pipermail/gnupg-users/2019-March/061...

> A police unit parked outside a guy’s house and confirmed it was him in the real time chatroom, by cutting his internet and seeing him drop off.

I guess I'm going off of too few details probably, but this doesn't seem like a very sound strategy to me. It's certainly not impossible that the real criminal lost internet around the same time as some suspect's was cut by the police. I know I've shown up as online to other people for up to several minutes after losing internet in real-time situations (e.g. games). I suppose police just need "reasonably likely" to take action though, not definite reasons.

More than that, the criminal could have been a neighbour piggybacking on his WiFi.

Congrats! It's always surprised me that Amazon or one of the other Android vendors didn't do this themselves to make porting to FireOS or other services-included Android distributions easier, but I hope you get funding from them for doing their job for them.

Everyone wants to be Google, and I bet most managers see lock-in to their platform as a good thing, and ease of porting to competitors a bad thing.

At least, if they feel big enough to gain initial traction...

Huawei is pushing their own thing, alternative to Firebase[1]; Amazon as well[2].

There's a dozen services that provide cloud-based services to send push notifications to various services. I think the incentive to gain subscription revenue was greater than the opportunity to make these partially redundant.

I'm not sure why it took so long for something like UnifiedPush to appear. It took a fair bit of debugging, but ultimately, it was mostly up to one dedicated individual (S1m) with Android experience.

Before UnifiedPush, there was OpenPush[3], but it never materialized.

[1]: https://developer.huawei.com/consumer/en/hms/huawei-pushkit

[2]: https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-applica...

[3]: https://bubu1.eu/openpush/

I would imagine Huawei is doing that moreso due to sanctions, no?

Thank you very much for your hard and important work!

And a special thanks for not forcing us to use a slack channel!

Hopefully other OS projects will follow.

Good health and all the best for 2023!

Does the user require to install a separate app to receive UnifiedPush messages?

Yes, they need to have a UnifiedPush distributor on their device, that acts like Google services.

OS makers could install a default UnifiedPush distributor though.

Lastly, the Embedded FCM UnifiedPush library (to be embeded into a client app) handles UnifiedPush over FCM (Google-provided push notifications), so that a server only has to handle the UnifiedPush API (with a rewrite proxy for UP->FCM).

https://unifiedpush.org/developers/embedded_fcm/

We can't get users to understand that the ceo isn't sending them mail from giftcards563@gmail.com to go and buy giftcards, and not to ask any questions.

What's the actual likely hood that the average end user is going to install a random service?

> What's the actual likely hood that the average end user is going to install a random service?

For now, UnifiedPush is targeted towards De-Googlers, self-hosters and FOSS enthusiasts, not average users.

Except, in the threads here, this is called out repeatedly as a replacement for push notifications on phones, replacing webpush, apple push notifications, and whatever google is calling it.

Which implies the use case people are seeing is phone apps. Unless people are building one off apps for themselves, you've got end users in the mix.

I don't see how this can be positions as much outside of phone apps, as txt messages or emails would be easier and more universal. Being that they're probably going to be supported here.

To note, i haven't see anyone talking about this being replacement for the part of webpush that handles registration for notifications or whatnot, but as a whole separate channel/technology. Not 'install this to avoid using google/apple for webpush' but 'use this in your app, and have your users install the service'.

Some apps just offer both, and even auto-detect. So if your phone is de-googled, the app will use UP, if it has the Google Services it will use that. For some apps it is available in the settings.

So yeah, the app has to support it, but the user can choose then.

People are seeing it as a way to get efficient push notifications in an open, decentralized system.

That's pretty much it. Because there isn't really any possible alternative except something that looks like this.

GCM/APNS/ETC do not fit those requirements, so it needs to be something new.

Is there any plan to have a method available for patching proprietary apps to work with this? Notifications is the only reason I still have Goolag services on my phone's work profile, and having an alternative to that would be great for privacy.

The sender needs to know which push service to send the message to, so no.

> Notifications is the only reason I still have Goolag services on my phone's work profile

Wouldn't microG be enough for that?

As a sibling commenter said, those proprietary apps have a server part that sends notifications to Google's server.

If UnifiedPush were to gain enough traction (say it would be adopted on FireOS, HuaweiOS and whatever platform don't use Google services), those apps would likely start to support it directly.

Another possible avenue is to add UnifiedPush support to push libraries used by these apps both server and client-side. Multiple libraries (Google FCM included, I linked at least two others from Amazon and Huawei in another comment here) abstract push notifications away so the developer gets a single server to talk to, and a unified API across iOS, Android, Web, etc. If these libraries started supporting UnifiedPush, adoption could increase a lot, without involving any developer effort for these proprietary apps.

The home page you've given is a little confusing to me and I'm not sure if it's confusing or just not aimed at me.

Is this just for mobile (android only?) developers, or is it for any push notifications e.g. browser.

Could I use this with PHP or JavaScript for example?

Uh, the site doesn't load...

Looks like IPv6 is broken :/

The AAAA record was temporarily removed to try to mitigate.

Interested to know what happened here.

Shouldn't Happy eyeballs fall back to IPv4 when IPv6 is broken?

They should, which is why nobody noticed it was broken.

Someone told us IPv6 was broken after we submitted here, as they use an IPv6-only network, apparently. I just posted that up there in case that was the actual issue encountered by the commenter. We're not sure why it broke yet, but we'll fix it when there's less traffic.

Reply on news.ycombinator.com