Add another way to receive notifications

[ghost]

Hi,

It seems weird that Signal still relies on GCM/FCM for notifications.

Even with Signal APK downloaded from the website, and having whitelisted Signal in DNSfilter (personalDNSfilter | F-Droid - Free and Open Source Android App Repository 3), I can’t receive Signal notifications if I do not open the app, because I blocked GCM/FCM adresses (mtalk.google.com 5, alt1-mtalk.google.com,…) with DNSfilter.

While we trust Signal for keeping the minimum metadata, how can we know what Google keeps if Signal needs to transmit data to their servers for each notification/message ?

Furthermore, curcumventing GCM/FCM has been solved by other android app team, like Tutanota (the blog post also cites Mastodon):

Link to post in blog

Is there a plan to drop GCM/FCM (which as Tutanota highlights “includes Google’s tracking code for analytics purposes”) for SSE (Server Sent Events API) or another alternative ?

[Alaknar]

Here's a Reuters article on why is that important:

Governments spying on Apple, Google users through push notifications - US senator

[Privat33r-dev]

@cody-signal @dev-aniketj maybe it can be escalated?

The situation raises security concerns. If data sent with FCM is unencrypted, then message data may be compromised. By the very least metadata is leaking.

[codethief]

@ghost At least the standalone Signal APK uses FCM opportunistically and falls back to using a WebSocket if Google Play Services are not available, see also https://github.com/signalapp/Signal-Android/issues/1000 and https://github.com/signalapp/Signal-Android/commit/1669731329bcc32c84e33035a67a2fc22444c24b.

Now, the question is whether "available" means "installed on the phone" or "network connection can be established". If it's the former, your DNSFilter wouldn't cause Signal to fall back to a WebSocket since Play Services are still available on your device. Looking at the code (see the aforementioned commit) and at the function isGooglePlayServicesAvailable it uses, it looks like it's indeed the former.

Is there a plan to drop GCM/FCM (which as Tutanota highlights “includes Google’s tracking code for analytics purposes”)

As for analytics please see https://github.com/signalapp/Signal-Android/issues/6848#issuecomment-464409912 .

[codethief]

@0xB001

The situation raises security concerns. If data sent with FCM is unencrypted

But it's not. (I have trouble finding an official source right now but here is at least one source and here is another.)

Also note that even Google itself recommends E2E-encrypting push notifications, so on these grounds alone I doubt the Signal developers didn't do their homework.

[Alaknar]

@0xB001

The situation raises security concerns. If data sent with FCM is unencrypted

But it's not.

It's not about encryption. From the Reuters article:

Wyden's letter cited a "tip" as the source of the information about the surveillance. His staff did not elaborate on the tip, but a source familiar with the matter confirmed that both foreign and U.S. government agencies have been asking Apple and Google for metadata related to push notifications to, for example, help tie anonymous users of messaging apps to specific Apple or Google accounts.

[codethief]

@Alaknar

It's not about encryption.

I was addressing @0xB001's comment which was talking about encryption.

Regarding your comment and the Reuters article you posted:

U.S. government agencies have been asking Apple and Google for metadata related to push notifications to, for example, help tie anonymous users of messaging apps to specific Apple or Google accounts.

What is the "metadata" here? That you're using Signal at all? They already know this if you installed Signal through Google Play Store. If you see a real issue here I'd suggest you open a separate ticket.

Also, last time I checked I could use Google Play Services/FCM on my phone without logging in with my Google account. And, once again, you can use Signal entirely without FCM (at the cost of battery life).

In any case, I think we should continue the discussion here -> https://community.signalusers.org/t/use-gcm-fcm-alternatives-for-notifications/10264/43

[Privat33r-dev]

@codethief thank you so much for clarifications and detailed response.

[BentiGorlich]

I would love it if signal would support UnifiedPush via Ntfy

[ghost]

Any updates?

[schklom]

@BentiGorlich Molly-UP (https://github.com/mollyim/mollyim-android-unifiedpush/) does, it is a fork of Signal with UP and no Google stuff :) Although, it requires a small server.

[NilsRenaud]

Any updates on this issue ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[schklom]

@NilsRenaud If you can convince a signal dev to take a look at this :P

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BluePixel4k]

Bump

[codethief]

I'd vote to close this issue, for the following reasons:

Reason 1: The original concerns brought up by the OP,

While we trust Signal for keeping the minimum metadata, how can we know what Google keeps if Signal needs to transmit data to their servers for each notification/message ?

have been addressed. Signal transmits no information through FCM beyond simple wake-up messages. See also Meredith Whittaker's clarification here.

Reason 2: It is unclear what a privacy-preserving integration of UnifiedPush would look like. Any UnifiedPush integration in Signal will require the user to specify a separate server for Signal to send notifications to. This is by design. As @schklom says, a user would probably set up "a small server", e.g. a VPS at some hosting or cloud provider, or a machine at home.

This would arguably be much worse for privacy, since the Signal servers would now need to permanently store that server's IP address, i.e. a direct link either to the user's payment information at that hoster / cloud provider, or to their home address. Either way, a three-letter agency would have no trouble linking your Signal account to them.

Meanwhile, FCM does not require user registration. You can use it without signing up for a Google account. Heck, you could probably generate a new device ID whenever you fire up FCM.

The only way I could imagine avoiding the privacy issues of a UnifiedPush-like approach would be through some sort of onion-routing of notifications, e.g. via

• via Tor (though we all know it has issues, plus you would still need a server or a device that's connected 24/7), or
• via some p2p network (with onion routing of course) that would store wake-up notifications in a DHT (in a "distributed mailbox"), so that users can pick them up whenever they want. Here I wish the GNUnet people had an actual "product" that people could install & use today…

Anyway, for now, integrating UnifiedPush into Signal seems like a snake oil solution to me. While I think the effort & work of the UnifiedPush developers in general is commendable, since some apps continue to use push notifications to deliver privacy-sensitive data, I think the Signal situation is different since it already avoids sending anything relevant or valuable through push notifications. As always, the valuable information is in the metadata ("We kill people based on metadata") and the metadata exposed through UnifiedPush seems quite a bit worse to me (or at least not better) than when using FCM with an ephemeral device ID, or when using WebSockets (in both cases together with a phone's usual ephemeral IP address).

[BluePixel4k]

It's useful for people with an ungoogled phone. Currently, they have to use the WebSockets integration, but it's much more battery intensive, if you have many of them for different apps. With UnifiedPush you have only one notification service.

[schklom]

@codethief The separate server I pointed to is necessary because Signal does not support UnifiedPush natively. That server receives message notifications (is registered as a Signal linked device) and sends a wake-up notification via UnifiedPush to Molly (the forked Signal app).

If Signal could send these wake-up messages to e.g. https://ntfy.sh natively instead of Google servers, this small server wouldn't be necessary.

If Signal allows it, we could choose to either use Google servers (as the app currently does), or an alternative like ntfy.sh, or even a self-hosted solution.

Meanwhile, FCM does not require user registration

Neither does ntfy

the metadata exposed through UnifiedPush seems quite a bit worse to me (or at least not better)

It is the same as the one sent to Google. But we could choose to avoid using Google.

[codethief]

@BluePixel4k

It's useful for people with an ungoogled phone. Currently, they have to use the WebSockets integration, but it's much more battery intensive, if you have many of them for different apps. With UnifiedPush you have only one notification service.

Makes sense!

@schklom:

If Signal could send these wake-up messages to e.g. https://ntfy.sh/ natively instead of Google servers, this small server wouldn't be necessary.

I see. My understanding so far had been that UnifiedPush users typically deploy their own notification server. (Could it be that last time I looked, ntfy.sh wasn't selling their open-source notifications server as a service yet?) If the goal is to replace one centralized solution (Google/FCM) with another (ntfy.sh), then of course the security considerations are the same, as you say.

Anyway, I would still suggest to close this ticket – in favor of a new, more specific ticket/proposal to add UnifiedPush support, outlining why UnifiedPush support would be a good thing. The pain points mentioned by you and @BluePixel4k (using Signal on a de-googled phone while trying to save as much battery as possible) definitely seem valid. However, this ticket started off as a discussion about how Signal supposedly leaks personal data through FCM notifications, and that's simply not true, so I think it'd be best to start fresh.

[schklom]

There is https://github.com/signalapp/Signal-Android/issues/12490 but a maintainer closed it after misunderstanding it :/

[codethief]

@schklom I'm not sure there was a misunderstanding. OP wrote "[X] I am submitting a bug report for existing functionality that does not work as intended", to which @greyson-signal responded with

We reserve github for bug reports not feature requests, which is why it was closed before.

and

Signal does work without play services.

(= "There is no bug and this ticket is a feature request" – which it was.)

That being said, if I understood OP correctly, they created the ticket hoping for a official response to the long-standing feature request in the community forums. Of course I do get where they're coming from and understand how frustrating the radio silence of the Signal developers can be. I wish I knew a solution here. :\

[schklom]

Fair point, it seems I'm the one who misunderstood ^^