What if all iOS and Android apps were not complying with GDPR because of push notifications? This heavily used technology is a nightmare in terms of data protection. Users and developers are not aware of how push notifications’ data flows are messy. Let’s dig into it!
Back in 2019 when I built « RIP, le compteur », a collaborative signature counter for an official french petition, I added push notifications. When the user activated this feature, I prompt an information notice saying that their web browser will connect to third-parties servers: Google if they use Chrome, Mozilla if they use Firefox… Because it is how push notifications work.
How push notifications work?
In the following, for writing easing, I will focus on mobile push notifications, but web push notifications work the same way. You just need to replace the constructor’s servers with the browser’s servers.
Push notification is a subscription based system. Your smartphone subscribe to a channel and everything needs to go through the smartphone constructor’s servers. By « constructor’s server », I actually mean Apple if you have an iPhone or Google if you have an Android phone.
When the app wants to send a push notification even when it is closed, it is the app’s server that trigger a notification by sending the information to the smartphone constructor’s servers. So potentially, Apple or Google could read your push notifications or at least know that you are receiving data from an app.
Do not mistake push notifications with regular notifications. An app or your web browser can also send notifications while it is open. These regular notifications do not send any data to some servers. It is only push notifications, that can trigger notifications even while the app is closed, that use external servers.
Services that use this technology often forgot to inform users about it. We can still find some information on it in some privacy policies. For instance, Microsoft added a paragraph about push notifications in their privacy statement:
To let you know of incoming calls, chats, and other messages, Teams uses the notification service on your device. For many devices, these services are provided by another company. To tell you who is calling, for example, or to give you the first few words of the new chat, Teams has to tell the notification service so that they can provide the notification to you. The company providing the notification service on your device will use this information in accordance with their own terms and privacy policy. Microsoft is not responsible for the data collected by the company providing the notification service.
Microsoft privacy statement
We understand here that data could be collected by your device constructor’s servers, but it is unclear which data and why. No security measure like encryption seems to be adopted.
How secured are push notifications?
If data is sent to external servers, the question to come would be how it is secured and if there is end-to-end encryption. Let’s dig into some documentation.
Apple is not very talkative about encryption of push notifications. They still put in place a red warning advising to « not include customer information or any sensitive data […] in a notification’s payload. » They also advice to « encrypt [the data] before adding it to the payload », because yes, push notification data is not encrypted.
Developers simply need to implement encryption themself. Instead of directly displaying the notification, they can modify the notification’s content with some code (and these lines of code can decrypt the data). Here is the data flow:
- On the app’s server, encrypt the data,
- Send it through the Apple/Google servers,
- When the phone receive the data, wake up the application,
- Let the app decrypt the data,
- Display the notification with decrypted data.
It is also important to note that, beside end-to-end encryption of the content of the notification, metadata could not be encrypted. So Google or Apple can know which apps you are using and how many push notifications you are receiving.
What solutions are available?
If you understood correctly the issue of push notifications, you will notice that developers may have no choice but entirely removing push notifications if they want to not send personal data to Apple or Google. From the developer perspective, it is simply impossible to have push notifications without using the smartphone constructor’s servers because the app can only use the push notifications servers provided by the smartphone.
From a legal point of view, if you want to comply with GDPR, you may need to ask express consent with clear information when activating push notification in order to do international transfer of data (article 49(1)a of GDPR). You may need to ask something like this:
Push notifications are using third parties servers provided by your smartphone. We cannot ensure that personal data could not be transferred outside of the European Union and we cannot provide appropriate safeguards. By activating this feature you understood the risks and consent for this international transfer of your personal data according to article 49(1)a of GDPR.
On the user side, you could tell your smartphone to provide an alternative push notification server to the app. But it is very difficult to do. Some prototypes have been developed like the openpush one for instance.
The user can also completely deactivate push notifications or use MicroG on Android opensource alternative OS (like Lineage or /e/OS) in order to mitigate privacy risks. MicroG provides a prompt when an app try to subscribe to push notifications and do not use an unique ID for your smartphone but a different ID for each app so Google may not be able to trace which apps you are using. With MicroG, you also do not need a Google account for receiving push notifications!
This is a not-so-brief summary of the push notifications privacy nightmare. We need to inform users and developers about this privacy risk. Data protection authority should take their part. I have filled complaints to the CNIL (my local DPA) about this and still awaiting a reply.