Push notifications on nogoogle flavor

[Albirew]

I was wondering when I saw that in readme.md but, isn't it possible, at least on the nogoogle flavor, to check presence of other UnifiedPush apps, like ntfy or NextPush, then use them to create and listen in a notification channel the same way as with firebase?

[finiasz]

Hello @Albirew, using these other services would require to integrate additional third party libraries in the app. Adding dependencies is something we try to avoid as much as possible, and this also represents some work on our side which we do not have time for right now. I understand this could be helpful for some of our users, but the permanent websocket option we offer at the moment works well and does not drain that much battery.

When we have time we will probably look into ntfy as several people have pinged us on this, but we currently need to focus on adding some features to the app.

[Albirew]

no worries, I can understand security, bugfixes and new features have higher priority over a specific build's specific use =)

For future's sake, here's UnifiedPush library documentation (usef to communicate with distributors) https://unifiedpush.org/developers/intro/

[finiasz]

I had a look at the docs you are pointing to and there is something I really don't like there!

https://unifiedpush.org/developers/android/#sending-push-messages

The client application of the user gives an endpoint to the server, and whenever this user received a message, our server will send a request to this endpoint.

There does not seem to be any kind of restriction on where this endpoint is located, so implementing this on server side will let any user force our server to send requests to a server of their choice. Pretty easy way of turning our server into a DDoS relay... If we implement this, we will definitely need to whitelist a few providers of unified push!

[Albirew]

There does not seem to be any kind of restriction on where this endpoint is located

Of course, since the user will either install it on his own server or use an existing endpoint.
In order to avoid DDoS, you can limit the number of requests per second per ip (both origin and destination), but either way, you can't push notifications on a server if android app doesn't tell distributor to listen to (locally generated by Olvid, can be randomized at creation) channel

@p1gp1g may be able to give more informations on this matter

[p1gp1g]

A few things :

• There is a discovery request: https://unifiedpush.org/spec/server/#discovery ; your server can send a GET to check if the server is indeed a push provider [Edit: It's more about convenience than security]
• The specification disallow strictly to follow redirections: https://unifiedpush.org/spec/server/#3xx (that's more relative to SSRF)
• You can do a sync-on-push strategy : the android app sync with the server for x seconds when its receive a push. With this solution, you can do a timeout before the server sends another push message.
  • This is the solution Signal has choosed, it syncs for 1 min on a push, and if it receives another push then enqueue a second minute (there is only one minute enqueued)
  • I (and all Molly with UnifiedPush's support users) have tested with a timeout of 1 second with a push only on urgent message, and timeout of 5 seconds with all messages get pushed (signal has a metadata to show if a message is urgent or not - for typing indicator for instance), both works well.
  • This is also useful for FCM and APNS which also have rate limitations.

Edit: And by the way, any application supporting webpush does it as well. If you plan to support UnifiedPush, then you should implement WebPush (the RFC, not the draft like so many apps). UnifiedPush is compatible with it, and it may be useful for other platforms/integration

Edit2: For instance, Telegram supports webpush and also the firefox's deprecated simple push API (which is shown compatible with UnifiedPush by mistake) : https://core.telegram.org/api/push-updates