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.
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.
You can accumulate encrypted messages at random urls 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.
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.
*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...
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.
Shouldn't Happy eyeballs fall back to IPv4 when IPv6 is 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.
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).
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.
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'.
So yeah, the app has to support it, but the user can choose then.
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.
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...
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?
The reason to use the google services is mostly touted as for battery savings, I believe.
Thus, it makes total sense to have one mechanism for push messages for the entire device. It's great to have degoogled alternatives here.
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).
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.
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.
Wake up one thing,
Check one place,
If (message) wake up correct app
Plus the real time push works differently… like a phonecall comes in and your phone rings thay same second
Wouldn't microG be enough for that?
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.
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!
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?
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.