Merle: Why Even Signal Calls Apple & Google

Summary

The talk examines why mobile push notifications commonly depend on Google’s Firebase Cloud Messaging (FCM) or Apple’s Push Notification service (APNs), and what that means for privacy, reliability, and self-hosting.

How push notifications work

Keeping a separate connection open for every app drains battery. The speaker’s first Zulip notification prototype used long polling, but that approach would not scale to dozens of apps.

FCM and APNs address this by maintaining a single system-level connection to a phone. A service sends a push notification to Google or Apple, which wakes the app so it can fetch the actual message.

The speaker describes this infrastructure as highly optimized and reliable, but also as a significant dependency. On iOS, the talk says, apps have no practical alternative to APNs. Android allows alternatives, though background-app restrictions make them harder to use.

Privacy and metadata

Even when push messages contain no sensitive content, the push provider can observe metadata such as which app is contacted, when and how often it is contacted, and which device receives the notification. The speaker argues that patterns over time can reveal personal habits and relationships.

The talk cites a 2023 disclosure prompted by US Senator Ron Wyden: government agencies had sought push-notification records from Apple and Google. It also discusses research that found some messaging apps sent metadata—and, in some cases, message content—to Firebase.

Signal is presented as an example of “push-to-sync”: it sends an empty wake-up notification through FCM, then retrieves and decrypts the message on the device. This limits content exposure but does not remove the metadata dependency.

Alternatives on Android

UnifiedPush is an open standard that lets apps receive notifications through a distributor rather than relying on Google’s push service. The distributor maintains the connection; apps register with it and are notified when messages arrive.

ntfy is presented as a simple UnifiedPush option. Sending a notification can be as easy as making an HTTP request, such as with curl. It can be self-hosted or used through a public instance. Users should consider who can access a public topic and whether to use authentication or encryption.

Other options mentioned include the XMPP Conversations app as a distributor and Sunup, which an audience member described using with GrapheneOS. The speaker says Sunup appears to route through Mozilla’s push service.

A key limitation is Android vendors’ aggressive background-app management, which can kill alternative distributors. A persistent foreground service may be needed. UnifiedPush support exists in apps including Element, Tusky, Fedilab, FluffyChat, Nextcloud, and Molly.

iOS web push does not eliminate Apple’s role: the talk says it still uses APNs.

Apps and practical project

Zulip’s mobile app did not initially meet the speaker’s notification needs for a self-hosted setup, so they began building Zulip Mobile Notifs.

The project has three approaches:

1. An Android foreground service that polls Zulip directly and creates local notifications, avoiding a push gateway.
2. A Cloudflare Worker that polls Zulip and sends web push, including support for iOS as a progressive web app.
3. A planned self-hostable approach using web push and a UnifiedPush distributor.

The speaker also describes features in the app, including real-time notifications for direct messages and mentions, multiple Zulip accounts, muted channels, quiet hours, and several authentication methods. When the Cloudflare Worker is not used, credentials remain on the device.

Molly, a Signal-compatible fork available through F-Droid, is highlighted for users who want Signal-style messaging with UnifiedPush. The speaker notes that Molly has a smaller team and fewer formal audits than Signal.

Monitoring, alerting, and sovereignty

The same dependency affects operational alerts: systems such as CloudWatch, Prometheus, Grafana, PagerDuty, and CI/CD tools may ultimately deliver phone notifications through FCM.

The speaker argues that this can create privacy and reliability concerns. They cite a reported global FCM outage and note that alerts routed through a failing service may not reach responders.

Self-hosting a notification path can provide more control and logs, and can be inexpensive to run. A Prometheus Alertmanager webhook can send alerts to a self-hosted ntfy server, which then reaches a phone through a distributor.

The speaker stresses that ntfy is not a full PagerDuty replacement: it does not provide features such as escalation or on-call rotation. The point is to control the notification “last mile.”

The talk also uses Huawei’s loss of access to Google services after US restrictions as an example of how reliance on a single provider can become a strategic risk. It connects this to digital sovereignty and regulated or isolated networks.

Practical takeaways

• Try sending a notification with curl, and check whether preferred apps support UnifiedPush.
• Consider Molly for a Signal-compatible option that avoids Google’s push service.
• For self-hosting, weigh the privacy benefits against the reliability and maintenance challenges of keeping a distributor alive in the background.
• For iOS users, the talk says there is currently no equivalent escape from APNs. Sending less message detail can protect content, but not eliminate metadata exposure.

Main speakers and sources

• Main speaker: Merle (the speaker introduces herself in the talk as “Mada”).
• Cited sources and systems: Ron Wyden’s 2023 letter concerning push-notification records; the research paper The Medium Is the Message; statements attributed to Stewart Baker and Michael Hayden; FCM, APNs, UnifiedPush, ntfy, Zulip, Signal, Molly, Matrix/Sygnal, and Prometheus Alertmanager.
• Q&A contributors: Audience members asked about topic security, iOS options, alternative distributors such as Sunup, app wake-ups, and hiding persistent notifications.