“App developers can encrypt these messages when they’re stored (in transit they’re protected by TLS) but the associated metadata – the app receiving the notification, the time stamp, and network details – is not encrypted.”
“App developers can encrypt these messages when they’re stored (in transit they’re protected by TLS) but the associated metadata – the app receiving the notification, the time stamp, and network details – is not encrypted.”
But that’s why UnifiedPush exists, an open standard where you can choose what server to use or selfhost it
As I said earlier, this idea is good too. Open push standards are generally the best for efficiency but they can become proprietary or die (usually after getting bought by a big tech company) and even if a fork emerges it may be difficult to switch to it since it’s an important component and 100% compatibility with the previous standard is not always possible. That’s the main problem with unification and monopolization. The open standards can run into severe issues and then everything may collapse. When apps control the notifications, such risk is almost completely mitigated. Even though the described scenario is generally unlike to happen, push notifications have always been very “interesting” for big tech which rises the concerns about the stability of open push standards. Fortunately it’s possible to make an app that can work in both push and standalone modes (e.g. Telegram) which is good I guess
The UnifiedPush standard is actually so simple, I don’t think a company could even make that proprietary if they wanted to. You need to keep in mind that it’s not sending the notification contents but just that there is a notification for a specific app.
I definitely agree that it’s best when apps support all methods, so UnifiedPush, running in the background and Firebase (that one just for the Google Play build). That way you can use whatever is best for you.