Closed Bug 1802846 Opened 3 years ago Closed 8 months ago

UnifiedPush support

Categories

(Firefox for Android :: Push, enhancement, P5)

Product:
Firefox for Android
Component:
Push
Platform:
All
Android
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kbrosnan, Assigned: git+bugzilla)

References

Details

Attachments

(7 obsolete files)

From github: https://github.com/mozilla-mobile/fenix/issues/27983.

What is the user problem or growth opportunity you want to see solved?

Firefox is currently reliant on FCM for push notifications for websites. UnifiedPush is an alternative that allows applications to use Gotify/ntfy/Nextcloud to send push notifications to devices.

How do you know that this problem exists today? Why is this important?

UP is a major privacy win for people with Android devices that ship with Google dependencies, which is essentially 100% of the worlds Android devices.

Who will benefit from it?

Anyone desiring privacy.

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

This PR from Element-Android is a good starting point.

Severity: -- → S4
Type: defect → enhancement
Priority: -- → P5

Enhancements should have severity N/A.

Severity: S4 → N/A
Assignee: nobody → c+bugzilla
Status: NEW → ASSIGNED

Run UnifiedPush receiver within process scope

The uploaded patch is very Android implementation specific, which probably is the only option right now. We should consider having a common backend within Gecko if we want to proceed, but given the Android implementation is very different, that would take some time.

(In reply to Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-03-29) from comment #7)

The uploaded patch is very Android implementation specific, which probably is the only option right now. We should consider having a common backend within Gecko if we want to proceed, but given the Android implementation is very different, that would take some time.

I am not sure to understand, can you rephrase ? This bug is to add UnifiedPush on Android so it can be used instead of FCM. Otherwise, AutoPush is the WebPush backend common to other platforms.

We have two very different implementations, one in Firefox and one in Fenix. Both connect to autopush eventually but with different code modules, and we should probably not keep it separate with different feature sets.

I think you are talking about the implementation of the autopush feature aren't you ? In this case, this is not related to this patch. The path adds UnifiedPush feature but doesn't touch autopush related code.

UnifiedPush is a decentralized push notification system, so users can benefit from mobile push notifications without relying on Google Services. Users choose the application (and server) they wish to use to manage webpush for other applications. If enabled, the browser (e.g. Firefox for Android) will receive webpush messages via the chosen app.

No, I'm talking about the general push subscription implementation, regardless of the specific server backend. We need an implementation (or in this case, infra for the implementation as there will be platform-specific code anyway) that can be used by both Android and desktop, like handling the subscription database and etc.

I'm not saying this should be blocked right now, I'm saying there's something to consider for the future.

Quick note regarding privacy.

Mozilla's Autopush service does use FCM and APNs as bridge protocols. The messages we send over those protocols are still very much encrypted while in transit and the User Agent is the only thing that can decrypt and read the message content. You can verify this by looking at the Server code. The bridges just know that you received a message from Mozilla, not the actual origin of the message. Somewhat annoyingly, due to complications when using bridges, message payload sizes are truncated due to encoding issues because we keep the payloads encrypted. (This is why we can return a PAYLOAD_TOO_LARGE / errno:104 error

Autopush, likewise, cannot (and frankly, does not want to) read the content of the message. It's purely opaque.
In addition, Subscription Providers technically do not know the type of device they're communicating with using purely push. They just get an endpoint that they can publish to. Granted, this is trivial to circumvent, and I don't see how this actually improves that, but I'll admit it's a tricky problem to solve.

-- your friendly, neighborhood autopush developer

I agree, UnifiedPush support won't improve privacy regarding push notifications in itself. And the majority of the users will continue to use Autopush + FCM.

However, UnifiedPush support brings push notifications to some users: at this moment push notifs rely on FCM, which requires to have the Google Services installed, and to be able to access FCM servers (which is not possible in air gaped networks, or in some geographical regions).

Google Services are designed to be installed with privileges. And they don't come with push notification support only, but also with "features" some users may not want. This is why some (usually-advanced) users prefer to not install them. In that sense, being allowed to use a non-privileged service dedicated to a single usage (push notifs) can be considered as a privacy win.

Actually, some users already use Autopush for UnifiedPush, to get their notifications for other apps. So they will be able to use Autopush, without FCM, to get push notifications for Firefox.

Yeah, I can definitely see folk not wanting to run services that go through Google Play.

There is another concern, and it's why we route or messages over APNs & FCM to begin with. It's also one I don't really see being addressed by UnifiedPush.

Mobile devices do A LOT to ensure that device battery life is maximized. The two things that are the highest source of battery drain are the Radio and the CPU. FCM, APNs and other proprietary messaging systems effectively "short cut" this by using agreements with various Telcos to use SMS based data messaging in order to send data to secondary systems that do not require the full radio or CPU. It's my understanding that this means devices using UnifiedPush either:

  1. wake up regularly to fire up the radio and CPU in order to poll the remote servers for messages, then deliver them or
  2. fetch messages when the device activates, meaning that any pending message is by virtue low priority since the device will never know it's pending until it connects on activity.

(FWIW, I'm somewhat of the opinion that if an application wanted very quick throughput for push messages, it could connect directly to the Autopush websocket servers, which would also bypass the need for Google Play. Granted, it might also drain your battery in a couple of hours unless you adopted some sort of polling system, but then you may not get your meeting reminder for a few hours after the meeting started.)

If this is basically a polling service that delivers messages only when the device is active, then it could probably be done as an add-on. In any case, I'd want to make sure that the polling is not aggressive, since that may get the app flagged and forced closed by the OS (or worse, flagged for removal for "excessive battery consumption").

UnifiedPush allows you to get push messages ("real time") in doze mode, and doesn't drain your battery. For example I use NextPush, it uses ~1% a day for 13 registrations, 7 apps (and my battery usually lasts more than 3 days).

Under the hood, Google Service is just an usual app that keep a TCP connection to their server, and send some pings to keep that connection awake. They don't need any privilege to do that. About the privileges they use: they are allowed to be in the foreground without the foreground notification, and they use a privileged API (a broadcast option) to allow the targeted application to start foreground services on push. On GrapheneOS, they have implemented a compatibility layer to be able to use Google Services with user app privileges: they attach Google Services to a foreground notification, and replace the BroadcastOptions#setTemporaryAppAllowlist() privileged option by binding with foreground importance a service on the targeted application app. This two mechanisms are used for UnifiedPush too

Nevertheless, using a push notification system makes a lot of sense:

  • Keeping active a dedicated application is lighter on memory than keeping active all applications that need instant notifications
  • It avoids having multiple ping and wake cycles, that could prevent a doze mode
  • Usually, when an application adds a constant background connection, they have either to develop a 2nd kind of connection, optimized for background use, or to use the same they use when the user uses the app. The former requires development, the later may not be optimized at all for this. For example, Signal have done the later, which had battery drain issues (The next version should be improved)
  • Most users have multiple applications installed they very rarely use. And for these applications, draining 1% a day is already too much

So, in mobile environment, it definitely make sense to allow users to use a push service, Google Services or UnifiedPush. In my opinion, it is even better to allow them to chose what push service they want to use

Ah! Thank you. Clearly it's been too long since I did mobile development. I didn't know about doze mode. This does indeed appear to be something close to polling mode, where the OS sets the idle period for the device. I suppose this does mean that "timely" has a bit longer of a window for UnifiedPush.

(Side note: I have an internal proposal for Autopush that is somewhat similar. In essence, the "main" push would wake the device, which would then establish a WebSocket connection to the server to exchange the data. This removes a number of other issues with Mobile Push, and potentially allows for things like mobile devices to be able to use Megaphone/Broadcast functions as well. I have no idea if this work might get us closer to that, but I'd be very happy if it did.)

This does indeed appear to be something close to polling mode, where the OS sets the idle period for the device. I suppose this does mean that "timely" has a bit longer of a window for UnifiedPush.

So yes, the UnifiedPush distributor (push service) is polling for other applications, exactly like Google Services is polling the FCM server. So both solutions work in (~) the same time window. The delays are more likely to be impacted by other reasons: FCM (and some UP servers) may apply some rate limitation for some applications, servers may be congested, many apps must use a gateway to translate protocols (eg. webpush to FCM, I'm talking about them here: https://unifiedpush.org/news/20250131_push_for_decentralized/) that can be congested too, and the device configuration (for example, it is known that Samsung doesn't follow Android standard, and they apply arbitrary restrictions unless one go through many settings, cf. https://dontkillmyapp.com/samsung)

In essence, the "main" push would wake the device, which would then establish a WebSocket connection to the server to exchange the data.

It makes a lot of sense, especially in the case of autopush. We often call that "sync on push": the application server (autopush here) sends a ping to wake the mobile app that synchronize with the server.
If the app starts a connection that lasts x seconds after a ping, it is a good idea to add a timeout between 2 pings, it avoid spamming the mobile push server (FCM/UnifiedPush), and being rate limited. For example, on Molly (Signal fork), the connection lasts ~20 seconds (IIRC) and we use a timeout of 1 second, which is enough to drop 50% to 60% of the push notifications.

Attachment #9487707 - Attachment is obsolete: true

As discussed on the attached patch, it doesn't sound like unified push is a direction we want to go in at the moment.
So i'm going to close the bug, but do appreciate the interesting exploration and discussion it has generated.
Thank you to everyone who contributed thoughts, time and code to this issue!

Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → WONTFIX

That's OK. At least it hasn't been a waste of time as Fennec just merged it and IronFox plan to do it as well. Perhaps experience with forks will let you reconsider this feature in the future.

(In reply to s1m from comment #22)

That's OK. At least it hasn't been a waste of time as Fennec just merged it and IronFox plan to do it as well. Perhaps experience with forks will let you reconsider this feature in the future.

The data that would impact any future decision is usage: as far as I can tell, there simply aren't many UnifiedPush users in the world. Data to the contrary, especially data showing that there are lots of browser fork users using UnifiedPush, would be appreciated.

Attachment #9475389 - Attachment is obsolete: true
Attachment #9475390 - Attachment is obsolete: true
Attachment #9475391 - Attachment is obsolete: true
Attachment #9475392 - Attachment is obsolete: true
Attachment #9484964 - Attachment is obsolete: true
Attachment #9487708 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: