Mobile Push Notifications Privacy (Lack Of)
I’m looking into adding push notifications to an app I’m writing. Being a bit of a privacy nerd, I noticed that push notifications on all the well-known mobile platforms (iOS, Android, and Windows) have two privacy limitations.
- Apple or Google or Microsoft (or more likely, somebody who can coerce them :)) have the ability to read the actual content of all notifications from any app on their platform. In other words, notifications lack “message secrecy” because they cannot be encrypted by the app developer.
- Platform owners have the ability to send fake notifications to any app on a user’s device. In other words, notifications lack “message integrity” because messages cannot be cryptographically signed by the app developer.
Why is this important? In messaging apps, the first message of conversations almost always ends up being presented as a notification to the recipient. Due to the way notifications are implemented, platform owners can access this first message, unless the app developer uses the workaround described below. Based on a small, informal survey, users expected their conversations to be available only to the app sending the notification, not to the platform owner also.
Basics of Push Notification Architecture
The basic architecture of push notifications across platforms is as follows: App developers don’t directly send their notifications to end users’ device, they use the platform provider (e.g., Apple) as an intermediary.
For example, say app CoolBling is installed on user Alice’s phone. The developers of CoolBling want to send push notifications to Alice. They first set up an Internet server, which generates the message to be sent. This server forwards the message to the platform owner’s notification server requesting that it be delivered to user Alice’s phone. The platform server relays the message to the device.
Here are links to Apple’s architecture, Google’s architecture, and Microsoft’s architecture. Link to Apple documentation where the alert shown to the user is required to be present in plain text (others have similar architectures, AFAICT).
What End Users Can Do Now
AFAICT, you can’t do anything other than to turn off notifications for the app whose info you consider sensitive.
What App Developers Can Do Now
You can hack together a solution that solves the secrecy problem, but not the fake notifications problem by cleverly using two mobile APIs called “silent notifications” and “local notifications”.
Silent notifications are a special type of remote notification sent by an app’s servers to the device. The operating system (OS) wakes up the app on the device and lets it process the notification, but doesn’t produce any alert or sound for the user. Local notifications are alerts generated by an app on the device itself (e.g., a calendar event). They produce alerts for the user.
The basic idea is to send a silent notification with an encrypted payload, decrypt the message, and generate a local notification with the decrypted message.
I couldn’t confirm which of the popular messaging services use this workaround. Hopefully they all already do this.
This scheme doesn’t address the limitation that platform owners (or more likely, those who can coerce them) can generate of fake notifications. And we glossed over what encryption key will be used, which is an involved problem too.
Improving Privacy and Integrity
Here are a couple of simple proposals to close these two loopholes to make it easier for all apps to improve privacy.
Preventing Fake Notifications
Even people without crypto expertise can easily imagine how receiving fake notifications claiming to be from trusted contacts can cause problems. Fortunately, preventing fake notifications aka “message integrity”, is relatively easy.
Fake notifications can be prevented with a straightforward application of public key cryptographic signatures.
Apps could have an extra asset file containing a public key. When sending a notification, the app developer signs the message with the private counterpart of the public key. On the device, messages are rejected if the signature is faulty.
Preventing Platform from Reading Notifications
Encrypting messages is a more complex problem with a large number of solutions, varying in complexity, latency, and power consumption depending upon the protections desired. There are variety of more nuanced protections in addition in just secrecy of individual messages:
- Foiling replaying and reordering of messages. Schemes that do this even if an adversary causes some messages to be dropped.
- Detect deletion of some preceding messages.
- Minimize message metadata leakage (e.g., length).
However, I’d start with a design that only ensures individual message secrecy with per-recipient keys. That could work as follows.
When an app is first installed, an operating system (OS) library on the device negotiates an encryption key with the app developer’s servers by doing the well-understood and relatively simple Diffie-Hellman key exchange. Both sides save the negotiated encryption key for future use. The app developer sends messages encrypted with this key. The OS library on the device decrypts messages.
Conclusion
Push notification systems that exist today allow mobile platform owners (and entities that can coerce them) to read all push notifications and create fake ones. App developers can provide message secrecy with a hack. Solving the problem of message integrity will probably need platform support. Platforms should probably make it easier for apps to provide message secrecy and integrity. In the meanwhile, they should publicize the silent+local workaround more.
