This really seems like a potentially great solution to allowing mobile push notifications for self-hosted RC servers with zero cost for RocketChat the company beyond some relatively nominal initial development cost (I’d guess 2-4 days for one dev).
Implementing this would be congruent with an open source project and a company actually committed to open source ideals. Not implementing it would be congruent with a for-profit company looking to generate revenue.
I don’t think there is anything wrong with for profit companies and generating revenue. I sell code and Internet services for a living, and I have no problem at all in paying for same.
There is something wrong, I think, with positioning your code and its associated basic functionality as open source, allowing multiple organizations to implement and build infrastructure and various dependencies around it over years, and then afterwards force those organizations to start funding your company in order to continue having access to basic functionality (mobile push notifications are not optional in my opinion for an organizational chat service).
It would be totally different and 100% fine (great even) if you brought RocketChat to market with a disclosed business model of charging for some aspect of using it. Then users would be making an informed decision to choose it or not.
I also think it would be 100% fine to ask self-hosting users to pay some nominal fee for push notifications to cover unavoidable infrastructure costs that RocketChat would otherwise have to bear.
But it’s not ok to have launched an open source project for which adopters had good reason to believe that there would be no cost to them (other than their server costs), and then later impose a revenue generating fee on those users, and it’s double-not-ok to do that when a workable alternative exists that would allow the same basic functionality without incurring an ongoing cost for RocketChat.
One user’s opinion (a user who has built infrastructure around RC and is now reluctantly looking at matrix and zulip).
Although it’s possible to configure dynamic Sender IDs for Android devices via FCM allowing the application to request that information from the server and make the communication directly, it’s not possible to do the same for iOS where the FCM acts as a bridge only, receiving the Push Notifications from the server using the same service but requiring to configure the iOS certificates to forward them to the iOS application meaning that it’s still relays on APNs certificates that are only configurable at the build time.
@rodrigo.nascimento
All that is required to register an iOS application for FCM push notification is the APN authentication key (exported by the RC team as .p8 text file), the key ID and team ID for the project.
Self-hosted RC servers would enter this data along with the iOS bundle id and App store id in their own FCM account. That’s it!
Obviously the RC team would still need to build the mobile applications and upload them to their respective app stores.
@pjv If enough of the hundreds of RC community members using push notification were keen to chip in $10-$20 for a bounty, I’m sure it could be implemented.
Zulip looks quite nice but it actually suffers from the exact same problem as RC with respect to push notifications. The developers didn’t realise that the message system can be used with federated servers, if you read past all the simple examples in the documentation.
Don’t bother with Matrix unless you’re happy to pay for the enterprise solution, as there are features (such as the ability for any user to delete channels) that effectively cripple the offering in the community edition.
We really don’t want to make our private certificates open for everyone, it would be a security issue allowing attackers who got access to data (database dump, a man in the middle, etc) and get the notifications tokens can impersonate any RC server easily. We can, definitively, talk more about that, but it’s not something we are willing to do without a proper evaluation of all risks involved for all of our customers/users. There is a reason for the existence of those certificates and why it’s not possible to send notifications only based on the app’s name or bundle id.
@rodrigo.nascimento
The APN Auth key is for the iOS client to listen for push notification messages, so where is the security risk for the server? Each self-hosted RC server would set up their own FCM account and they would keep their own private FCM authorisation key secure. I never EVER suggested publishing that information.
I think you’re muddying the water. Firstly you claim it cannot be done and then, when I point out how it can be done, you change tack by citing erroneous security concerns. Please explain how a man-in-the-middle or database attack on the server is possible using the apple push notification key for the iOS client.
The only thing that a third party can do with the APN Auth key is send messages to an iOS client application, but to do that they also need a device token. The device token is dynamically generated when the mobile application starts and cannot be brute force acquired from a running instance. Therefore each running instance would be responsible for handshaking with a RC server upon login to provide a temporary FCM registration token via an encrypted websocket. There’s no security risk here to either the client or the server.
LOL, I’ve already actually “bothered” a fair bit with matrix/synapse in the past while checking out running a personal homeserver. I agree it’s not a perfect fit for a corporate chat server. But they seem to be pretty revved up development-wise lately.
I can see that Zulip is using the same methodology for pushing notifications to their mobile apps that RC is, but I don’t see them asking users to pay for it (so far). I don’t understand your reference to federation. What does that mean for mobile push?
What I mean is that the mobile applications must be able to exchange notification tokens at runtime with one or more servers hosted by any number of independent parties. The approach I have outlined solves that problem.
In terms of a user logged into a server but invited to join conversations in another federated server, the handshaking may need to be nuanced. I haven’t looked into whether each server only pushes notifications to it’s logged in users or is also responsible for invited users.
Gabriel, the way you communicate with people is offensive and comes across extremely condescending. People are irritated that they adopted an open-source platform that fits a lot of their needs that is slowly eroding its way into pay to play by reducing or limiting feature sets that are vital to the practical use of the platform. Many people in the community have contributed to the success of the platform.
There needs to be a practical way for end users to configure their own push gateways if they are so inclined (and I don’t mean recompiling the apps) so there is not a ‘free consumption of services that someone else is paying for’, which is entirely unfair to the Rocket Chat team or company.
I am sorry if you find the way I communicate with people offensive, this was absolutely not my intention. I simply tried to state the facts as clearly as possible, if it comes across extremely condescending, please accept my apologies. We fully acknowledge that A LOT of people in the community have contributed to the success of the platform and everything they’ve contributed is open and free for everybody else to use.
I understand your request, but do you have any suggestions on how to achieve it? We will not publish our private keys, as this is against Google’s and Apple’s policies and could cause disruptions for the community as a whole.
According to this article, “If you think your certificate or private key has been compromised, you can revoke your certificate from your developer account.”. If we publish our Private Keys, they become compromised by default. We cannot even invalidate them without disruption of the whole ecosystem, not to mention the update process that we have to go do every year and manage to get all admins to do it too.
@toddy we are not muddying the water. What @rodrigo.nascimento explained is that it cannot be done without publishing out Private APN keys. If we publish our key, we won’t be able to invalidate them when they are miss used. Our mobile app is a multi-server app, all servers share the same token. A server admin with bad intentions could use the token it received from the app to send push notifications as pretending to be from another server. We’d have no way to stop that. With our own gateway and registered servers, we have a token from the server to validate the source.
But maybe I am missing something about your suggestion. Do you know of any project that has implemented what you are suggesting that you can point us to so we can take a look?
Actually that is what I proposed. What hasn’t been answered is how that poses a specific security threat.
This is not the same thing as publishing the RC team code signing development & distribution certificates which would be dangerous.
That’s a vague statement. How exactly?
A connection between the mobile application and a RC server is initiated by the client. This can only happen when/if the client logs in. That authentication step provides the necessary security for limiting interaction to particular servers.
The APN auth key is used to sign, not encrypt, the web token so that the client can ensure the plain text content has not been doctored. JWTs can also be used in other situations like OpenID connect and OAuth where signing the token is important to prevent tampering. However for push notification the JWT is generated dynamically and the transport protocol is encrypted so the token can’t be abused in transit. Finally a third party cannot push notifications to a running instance without its device token either. I’ve already discussed this.
@toddy I’m still waiting for a list of other companies opening their keys. If you can point some we will contact them to understand the security and legal implications.
I have had a sales person email me 3 days after the deadline to register and I wanted to get confirmation that this is a legit sales person with your organization? Everything seems off about this encounter, between the fact that he is trying to get us to upgrade to Enterprise immediately after the deadline occurred to suggesting we actually use 470K push notifications in a month. If we were a large organization, then I can see where that would be possible and why a sales person would already be reaching out to us. However, I would not consider us to be large, at least not in concern with RC. Since push notifications totals is the only number I cannot pull out of the statistics of RC, I decided to pull all that I can daily since this first email with this sales person. According to the statistics, there is no way to support my company using any where near 470K push notifications in one month.
We have done a total of 1700 messages in a little less than a week, and all of those are direct messages (1 to 1). Even if all of my users were logging on and off of RC to make sure they are “offline” or “away” as much as possible to guarantee a push notification per message that was sent within the last week or so, that would still only be a max of 1700 push notifications in about a week. The math just doesn’t add up.
Sorry if this is the wrong place to reach out on this, but this sales person didn’t seem like they were going to share my statistics with anyone.
@the_dude thanks for the question. It’s for sure a legit contact. We did a whitelist of every server that still not finished the registration to work with them to finish or alert before we cut the notifications for them. All the new servers are already enforced to register in order to have notifications working.
We may have a problem with our metrics for the whitelist, can you let me know your server address so I could check the usage?
The dashboard for push usage verification is almost done and will be available in this or in the next week, but since it’s a cloud dashboard you still need to register your server to check the usage. We didn’t enforce the usage limits yet.
Hello, @the_dude!
I was the salesperson which contacted you.
I apologize for the confusion, it was defintely an human error on my side.
I will reach out to you by email and give you more details, ok?
Thank you,
Any news about the usage statistics for push gateway? Is there a way to have more insights (not only total number but also the statistics who is sending most push notifications (channel, user)).
I have got information that i am sending over 40k push but i am trying to find where it comes from. Looking at the server logs even in debug mode doesn’t help to identify push notifications source.
Any help would be appreciated.