[F-Droid] Make Firebase optional or remove it

[jakubgs]

Problem

In the process of researching the build process for F-Droid in #8512 it turned out that we cannot submit Status to their database if it includes Firebase in its dependencies.

From their Inclusion Policy:

We cannot build apps using proprietary tracking/analytic dependencies like Crashlytics and Firebase. Please talk to upstream about an untainted build flavor (either using a FLOSS analytics software like ACRA or by removing non-free dependencies completely).

Implementation

Either:

• Remove use of Firebase entirely
• Create an fdroid build flavour that does not contain Firebase

Acceptance Criteria

Status for Android can be built without any Firebase dependencies included.

Notes

I'm not sure why we even included Firebase in the first place considering it includes analytics and we seem to be using them:
https://github.com/status-im/status-react/blob/3b8d8d0013b4b2dd7cbe3b55ba44ea0f5792e29b/android/app/google-services.json#L4
https://github.com/status-im/status-react/blob/3b8d8d0013b4b2dd7cbe3b55ba44ea0f5792e29b/android/app/google-services.json#L27-L29
I thought that went against our Principles:

IV. Privacy

Privacy is the power to selectively reveal oneself to the world. For us, it's essential to protect privacy in both communications and transactions, as well as being a pseudo-anonymous platform. Additionally, we strive to provide the right of total anonymity.

[pedropombeiro]

Yeah, I think for now we should just turn off Firebase when building for F-Droid. This is what the Push Notifications v1.5 initiative was supposed to address, but we're still a long ways off.

[pedropombeiro]

And yeah, we should disable the analytics for sure.

[jakubgs]

@pombeirp could explain in more detail what we use Firebase for? Why is it even needed?

[pedropombeiro]

Sure. Firebase is only needed right now to interact with GCM (Google Cloud Messaging). AFAIR GCM is implemented in the Google Play Services, so of course not available on stripped-down devices that wouldn't include Google stuff. We use it to receive push notifications (in status-react cljs code) and to send push notifications (in status-go code, for no better reason than the fact that at the time, the API we needed was not exposed in the JS library we used, but was exposed in a Go library we could use. I don't think that's the case any longer, but that's a bit of a tangent).
The idea behind PNs v2 was to allow people to select their PN provider (so if they didn't want to rely on GCM, they could use an alternative open-source implementation, for instance). The advantage of using something like GCM instead of rolling our own is that if you have multiple apps handling PNs in a device, you only need to maintain one open socket, rather than having each app rolling their own, and GCM already has all the smarts implemented in order to handle e.g. power saving considerations.

[jakubgs]

I see, so based on that I guess removing Firebase is not an option, and we can only make a flavour of the App without it?

[pedropombeiro]

Right.

[leafcutterant]

The advantage of using something like GCM instead of rolling our own is that if you have multiple apps handling PNs in a device, you only need to maintain one open socket, rather than having each app rolling their own, and GCM already has all the smarts implemented in order to handle e.g. power saving considerations.

(Bolds mine.)

With all due respect for your work, isn't that just another way of saying "the closed-source, data-collecting alternative from Google is working quite well, so we'll just use that"?

And isn't this...

removing Firebase is not an option, and we can only make a flavour of the App without it...

...basically saying "we'll make a version without the data-collecting component for the few who explicitly seek that, but we'll keep serving the rest of our users with the version that actively relies on exchanging data through Google"?

Of the Status principles, apart from principle IV (Privacy) that jakubgs mentioned in the opening comment, this also seem to go against the following ones:

II Censorship Resistance

We enable free flow of information. No content is under surveillance. We abide by the cryptoeconomic design principle of censorship resistance. Even stronger, Status is an agnostic platform for information.

VII Decentralization

We minimize centralization across both the software and the organization itself. In other words, we maximize the number of physical computers composing the network, and maximize the number of individuals who have control over the system(s) we are building.

[pedropombeiro]

@leafcutterant the assertion that removing FCM is not an option is not a correct one. I think @jakubgs was referring to what can be done in the short term (v1 release) given the constraints we have (in terms of e.g. core contributors). As I mentioned above, there are plans to improve this (Push Notifications v2), where we allow users to select their PN provider, it's just a question of finding the time to implement the spec.

[leafcutterant]

@pombeirp thank you for clarifying. To make it clear, I don't want to make best the enemy of better. I'd be just sad to see FCM remaining included in the code base on the long-term. I appreciate the efforts made towards realizing PN v2.

Speaking of future plans:

there are plans to improve this (Push Notifications v2), where we allow users to select their PN provider

How about, once PN v2 is implemented to the degree that it's working smoothly, removing the FCM option altogether? To make Status completely libre?

[pedropombeiro]

How about, once PN v2 is implemented to the degree that it's working smoothly, removing the FCM option altogether? To make Status completely libre?

Yes, that's the ultimate goal with PN v2.