APNS Authentication
Apple’s push notification service got authentication all wrong (I’m assuming Google’s service is similarly broken but I’m less familiar with it).
Currently, push notifications are tied to an app developer’s certificate. This means the only entity that is allowed to supply an app with a push notification must be controlled by the app developer.
So what?
Apps that could be completely client driven now require a server component. Some simple examples of apps that shouldn’t require such a component are email clients and Twitter clients. This is a negative for app developers as it adds operational and development costs. This is a negative for users as it requires the user to trust an app developer’s server with their possibly sensitive data.
How I think it should work
Push notifications should be authenticated by a user’s iCloud account. A user would be able to authenticate an arbitrary backend to supply notifications for any app on her/his device. The app would supply a documented notification handling API for backends to conform to (I’m assuming best practices/standards would form naturally). Then, for example, an iOS email app wouldn’t require storing user’s email authentication on some arbitrary token just to have push notifs; the email service itself could supply the pushes.
In my dream world, every app that speaks to a service comes with an input field for a server URL. User authed notifications would unlock a lot of possibilities here.
It’s not gonna happen
APNS is 6 years old and I don’t forsee it changing fundamentally like this ever, so of course this is wishful thinking.
I think one issue is that if an app developer somehow abuses the APNS backend, Apple can simply revoke the cert. It would be more difficult dealing with end users who may unwittingly allow a third-party to abuse the service on their behalf.
Also allowing arbitrary backends to send notification payloads to apps could possibly be a vector for security issues, though I think that would just require well thought out client APIs.