Can push notifications be used from untrusted servers?

[James Marshall]

Hello,

I'm writing an open source, secure social media system that includes a mobile app and federated servers.  As with many federated systems, the servers may be untrusted.  One of the requirements is to hide not just personal info and content from the servers, but to hide metadata (e.g. friend lists and message recipients) from servers too.  This ends up implying that each device must be able to receive and relay messages while the app is running in the background.

Can push notifications be used from untrusted servers?  I've read that the "firebase-admin" package is intended for use only with trusted servers, while the "firebase" package may be used with untrusted servers.  However, the docs for the latter focus on web apps only.  How can I do this?  Obviously I can't distribute any secrets with the server software.

The alternative is for the app to keep a socket open to one's home server while running in the background, but that seems frowned upon by Google-- it requires a partial wake lock to exist for a long time, which could prompt the OS to close the app, plus learn to close the app in the future.

I see the problem with allowing any server to send a PN to any user, but I believe that is solvable by requiring opt-in permission from a user for a particular server (their home server) to send PNs.

Am I missing something?  I hope there's a solution here.  Otherwise, it seems like Google is disallowing secure systems that use federated servers; the federated approach is getting more popular with the decentralized software movement.

Thanks for any help, or links to relevant docs.

Cheers,

James

[Sent from my phone.]

[Kato Richardson]

Hello James, great questions. I hope others have ideas to share here as well.

> I've read that the "firebase-admin" package is intended for use only with trusted servers

Correct. It's intended for a trusted server environment you control. Never share secrets.

> while the "firebase" package ... focus on web apps only

Not correct. There are a large number of supported platforms and frameworks including iOS, Android, web, Unity, etc.

> I see the problem with allowing any server to send a PN to any user, but I believe that is solvable by requiring opt-in permission from a user for a particular server (their home server) to send PNs.

That seems very likely to lead to abuse; opt in feels insufficient here given all the abuse vectors for a push notification; but maybe you could find a brilliant way to manage this like spam filtering or similar; nothing is built in to provide this automatically, as far as I know.

I would assume you need some mechanism between the two clients that can validate any push notification meets at least some minimal criteria, and importantly, some way to inject abuse mitigation into the pipeline if someone does decide to exploit your app. If not for the sake of your user experience, then simply because abusive patterns will likely lead to Google API endpoints blocking your app.

The common practice is to have the clients ping an HTTP endpoint you control when they want to send a push notification (for example, Cloud Functions) and then have that service manage secrets, perform verification, and then relay them on to Google endpoints.

Also, be sure to check out topics, which can solve some use cases like this.

> The alternative is for the app to keep a socket open to one's home server while running in the background,

Both Android and iOS may chose to close the sockets at any point as part of their battery life management, and they usually do this pretty aggressively. So this isn't really an option when the app is background.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAGEp%3Df0rOQPCJt7Q1T80KgDL7-dV_OcF1RWCWVRR5COn-FMggg%40mail.gmail.com.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[James Marshall]

Hey Kato, thanks for the detailed response!  My thoughts below:

> while the "firebase" package ... focus on web apps only

Not correct. There are a large number of supported platforms and frameworks including iOS, Android, web, Unity, etc.

Great, thanks.  I'm using Cordova myself for the clients, and there seems to be a good Firebase plugin for that.  I'm looking for something that can be run on an untrusted server, which I don't see in that list.  My server happens to be written in NodeJS, but I think the limitation here is more general.

> I see the problem with allowing any server to send a PN to any user, but I believe that is solvable by requiring opt-in permission from a user for a particular server (their home server) to send PNs.

That seems very likely to lead to abuse; opt in feels insufficient here given all the abuse vectors for a push notification; but maybe you could find a brilliant way to manage this like spam filtering or similar; nothing is built in to provide this automatically, as far as I know.

I'm not sure I see the abuse vector if a client can choose to receive PNs from a certain server, permission that can then be revoked if the server misbehaves.  That level of trust seems pretty minimal; the server still can't see any private info.  The client app is controlled by the user, and could automatically look for patterns of abuse.  The PNs I need are data messages, not notification messages, so the client app controls whether or not the user is notified in the status bar.

The *only* message this server ever needs to send is a "data ready" ping to the client, which then connects to the server, gets the new data, and processes it.

I would assume you need some mechanism between the two clients that can validate any push notification meets at least some minimal criteria, and importantly, some way to inject abuse mitigation into the pipeline if someone does decide to exploit your app. If not for the sake of your user experience, then simply because abusive patterns will likely lead to Google API endpoints blocking your app.

I don't need the client apps to send PNs, just one's home server to send a tiny PN to one's client app.  If a remote malicious client causes the server to send many e.g. friend requests to one person, then the receiving client could notify their home server of this, who could then notify their peer server that is forwarding them for the malicious client, so then that peer server could block the malicious client.  If that server doesn't, then the first server can block the non-cooperating server.  In other words, there's still a chain of accountability, even though the servers know no private info.  Currently a message only goes through two servers, but this could be generalized to any delivery path.

The common practice is to have the clients ping an HTTP endpoint you control when they want to send a push notification (for example, Cloud Functions) and then have that service manage secrets, perform verification, and then relay them on to Google endpoints.

Right, but in this case I wouldn't control the servers, i.e. the standard federated architecture.  Like I say, decentralization is a growing trend, and is often done with federation.  By their nature, federated systems must not require trust in other servers, if they are to be secure.  I would hate to see Google not support federated systems that use Android apps.

Also, be sure to check out topics, which can solve some use cases like this.

Thanks, I'll look into topics.  My app has nothing to do with ads, but maybe the mechanism could be used somehow.

> The alternative is for the app to keep a socket open to one's home server while running in the background,

Both Android and iOS may chose to close the sockets at any point as part of their battery life management, and they usually do this pretty aggressively. So this isn't really an option when the app is background.

Indeed, and that's understandable (though I still wish the user had the option to choose, but that's a separate topic).  Push notifications are the natural and efficient way to consolidate all network activity into one listening system process.  I hope I can find a way to use them in this federated system.

Thanks again,

James