I just started my de-googling journey recently, and so the mechanics of notifications were still unclear to me, and I found this video super helpful.
It explains how most mobile messaging apps (including privacy-focused ones like Signal) rely on Google and Apple’s centralized servers to deliver push notifications, which exposes vast amounts of user metadata.
Here’s the YT link, for people who prefer it: https://youtu.be/c3ennD3wKn0
This is the reason why I went out of my way to use Molly (a fork of Signal), since it supports delivering the push notifications through a self-hosted server instead. Unfortunately the process is complex: it requires both a method to deliver the notifications to your phone via UnifiedPush (an alternative to Google’s push system that generally suffices on its own) and a compatibility service called MollySocket (that bridges Signal’s notifications with the UnifiedPush provider). Both typically need a self-hosted server and specific configuration to talk to each other though. And I don’t even have any contacts that use Signal anymore, so, well…!
From what I recall, Google would be able to see our device received a notification and when but not the actual message nor sender/recipient identity.
I think that’s fine for my threat model.
Molly seems like a potential alternative though since its a signal fork and supports UnifiedPush so you can choose a different notification supplier like ntfy or sunup
They see cintents if the contents is displayed in the notification
you can choose websocket on signal instead of Google unified push
Removed by mod