The Medium is the Message: How Secure Messaging Apps Leak Sensitive Data to Push Notification Services

TL;DR

This paper investigates privacy risks arising from the use of Google’s Firebase Cloud Messaging (FCM) by secure messaging apps on Android. Using a combination of static and dynamic analysis across 21 popular apps, the authors quantify how often personal data and even message content are leaked to the FCM delivery path, and they assess mitigation strategies such as end-to-end encryption and push-to-sync. They reveal substantial gaps between observed data sharing and what apps disclose in privacy policies, highlighting a systemic misalignment and the need for security-by-default in SDKs and platforms. The findings stress the importance of improved incentives and governance across developers, platform providers, and regulators to reduce sensitive data exposure in the software supply chain and protect user privacy in real-world messaging scenarios.

Abstract

Like most modern software, secure messaging apps rely on third-party components to implement important app functionality. Although this practice reduces engineering costs, it also introduces the risk of inadvertent privacy breaches due to misconfiguration errors or incomplete documentation. Our research investigated secure messaging apps' usage of Google's Firebase Cloud Messaging (FCM) service to send push notifications to Android devices. We analyzed 21 popular secure messaging apps from the Google Play Store to determine what personal information these apps leak in the payload of push notifications sent via FCM. Of these apps, 11 leaked metadata, including user identifiers (10 apps), sender or recipient names (7 apps), and phone numbers (2 apps), while 4 apps leaked the actual message content. Furthermore, none of the data we observed being leaked to FCM was specifically disclosed in those apps' privacy disclosures. We also found several apps employing strategies to mitigate this privacy leakage to FCM, with varying levels of success. Of the strategies we identified, none appeared to be common, shared, or well-supported. We argue that this is fundamentally an economics problem: incentives need to be correctly aligned to motivate platforms and SDK providers to make their systems secure and private by default.

Figures (5)

• Figure 1: An illustration of an Android push notification.
• Figure 2: Flow chart of FCM's push notification infrastructure for messaging apps, highlighting the actors involved and the interactions between them: an event occurs that triggers a push notification, e.g., a message from a sender (1) prompts the app server to create and send the message to FCM (2), which then forwards it to the recipient's Android device (3). If needed, the receiving app running on that device may also query additional information from the app server (4).
• Figure 3: Google's guidance to send as much data as possible via FCM payloads, noting that end-to-end encryption can optionally be used via additional libraries androidDevBlog. It is unclear whether the data flows labeled "encrypted" refer to this option or the fact that the transmissions use TLS.
• Figure 4: Example payload from within the RemoteMessage object received by the Signal app. Note the empty notification field, indicating the correct usage of the push-to-sync notification strategy.
• Figure 5: Payload contained inside the RemoteMessage object received by JusTalk. Note the MtcImTextKey and MtcImDisplayNameKey, which contain the unencrypted message contents and username, respectively.