UnifiedPush/Ntfy - Integration in the OS

Eirikr70

Hello GrapheneOS devs and another big Thank you for your impressive contribution to privacy,
I was thinking that maybe you should include UnifiedPush/Ntfy in the perimeter of your OS. As a matter of fact, it is an essential brick of your strategy of giving the user the choice to protect one's privacy. And UnifiedPush is not very accessible to non-tech users. Integrating the solution to GrapheneOS would make it much easier for non-tech users to avoid GSF, without increasing significantly either the load of maintenance or the attack surface.
I am aware that there are other distributors than ntfy, but they are quite restricted in the field of the users they can serve, whereas Ntfy is generic.
What do you think about that ?

homejacob

Eirikr70 Most apps don't support UP, so I doubt most users would benefit from it. UP even is some kind of security issue, as the notifications can kinda easily be interfered. NTFY should warn you about that when setting it up.
I don't see how this could be of any importance to the GOS developers currently.

de0u

Eirikr70 I was thinking that maybe you should include UnifiedPush/Ntfy in the perimeter of your OS.

Fundamentally this is up to the author of each app, since it's the app's servers that are sending the notifications to their app on phones. GrapheneOS can't force Google to rewrite Gmail to stop using FCM and start using UnifiedPush.

Eirikr70

homejacob Well, on the opposite, it seems of importance to me since it allows to benefit from notification with certains apps, without depending on the Google Services Framework.
I'd be interested in a development about the security issue.

missing-root

Yes some push service is very nice as it reduces battery drain. Its a chicken and egg problem, only with established implementation in OSses Apps will start to support it.

Many FOSS messengers already do.

Possible requirements I imagine

work as an unprivileged user app
be safe from interferences as described above
possible to use with many providers including Nextcloud
a maintainer that is involved somewhat in the project.

Eirikr70

de0u I wasn't talking with the viewpoint of the app developper, but with that of the user. A fair number of apps use that protocol. The challenge is now to put it at the disposal of the non-tech user who just wants to regain control over their privacy. As long as it won't be integrated in an OS, it won't be at reach of non-tech users, which in return might lead to its death.
As for now, it suffers malfunctions in Element and its forks, but that doesn't seem to disturb the Element team (https://github.com/element-hq/element-android/issues/7069). That will lead to people switching to other solutions. That is a bad signal for the durability of the solution.

de0u

Eirikr70 The challenge is now to put it at the disposal of the non-tech user who just wants to regain control over their privacy.

Is the non-tech user willing to pay (hypothetically) $2/month?

The missing piece isn't OS integration, because where UnifiedPush must be integrated is in each app's servers and in each app itself. The missing piece is server infrastructure. Presumably Google pays for their server infrastructure via general advertising revenue, and presumably Apple pays for their server infrastructure via hardware sales and subscriptions.

It's probably a fair amount of work not just to set up UnifiedPush servers, but also to manage people's accounts (e.g., password-reset requests) and to deal with law enforcement subpoenas. Perhaps this might be done by Proton, Tuta, etc. -- though Proton seems pretty resistant to UnifiedPush so far.

Eirikr70

de0u I think you're mistaking : there is nothing to pay to benefit from UnifiedPush. The server is now provided by ntfy. Anyone (tech users) can build their own servers and GrapheneOS might set up their own when integrating the service, together with all the other pieces of infrastructure they provide, with, I think, limited extra-cost. And there is no load for its management : I have set up my own server, and when it's built, it runs with no maintenance apart from the obvious security and upgrades, which is anyway included in the basic costs of any infrastructure.

de0u

julianfoad Thanks for the update!

That said, it appears that a key question (perhaps the key question), namely "Who will pay for the server infrastructure?" (de0u de0u), is still unclear.

If each user is running a server, or there are small "notification server clubs", the overhead of setting that up seems likely to dwarf the overhead of installing a push client on a device and configuring it. If some entities get involved in running large notification servers, that will cost money for servers and money for user support -- and those servers may become targets for law enforcement data requests, which will also cost money.

de0u

Eirikr70 I think you're mistaking : there is nothing to pay to benefit from UnifiedPush. The server is now provided by ntfy.

And here is the ntfy.sh pricing info. Server infrastructure costs somebody money!

Eirikr70 And there is no load for its management : I have set up my own server, and when it's built, it runs with no maintenance apart from the obvious security and upgrades, which is anyway included in the basic costs of any infrastructure.

The administrative load for a server used by one well-behaved person (or by a group of well-behaved friends) will inherently be much lower than the administrative load for a server fleet used by a billion people. Serving a billion people involves different kinds of problems, requiring different kinds of solutions.

Perhaps some user of this forum is willing to operate an ntfy server for the 100,000(?) GrapheneOS users.

jackFang

This will go under self-hosted. Should GrapheneOS implement own features making it easier to setup self hosted applications/project without relying on third party apps. I am all up for it.

I however, see this as non critical, so unsure how much priority there would be.

Eirikr70

jackFang It is not at all a self hosted matter. It is just about having the ability of using some pieces of software, especially chat apps, without relying on Google servers and requiring Google Services Framework. Nothing there requires any self-hosting.
For self-hosters, they can build their solution on their own the way I did.