Do not rely on Firebase for auth

[michaelcpuckett]

After sharing widely via Feditips, some people have voiced concern about relying on Firebase.

[Andre601]

What are the main concerns actually?

[broukema]

The whole idea of the Fediverse is community run conversations without providing users - or moderators - as raw materials ("ordinary people are the product, not the client") to feed into GAFAM [1] for selling to advertisers [2]. Firebase appears to be run on Google/Alphabet servers. Using it for Fediverse groups defeats the point of the Fediverse.

Nuances:

• A lot of Fediverse conversation is technically public, but it's equally public to everyone with internet access rather than just to one corporation, and there are a variety of opinions about the degree to which Fediverse conversations or meta-data should be propagated further.
• Github itself is now controlled by GAFAM with attempts to get people to download repositorities using 'gh' instead of 'git' under the EEE (Embrace, Extend, Extinguish) policy of M; people remaining on Github are generally aware of this and waiting for further developments of Forgefed [3].

[1] https://en.wikipedia.org/wiki/GAFAM [2] https://en.wikipedia.org/wiki/surveillance_capitalism [3] https://forgefed.org

[michaelcpuckett]

Yes I think the concern is google. The site is hosted on DigitalOcean but authentication is handled by Firebase.

[michaelcpuckett]

I would like to implement an alternate authentication method, probably: Passport.js + existing mongo database

[goodevilgenius]

One suggestion I have is to eliminate authentication entirely, by allowing groups to be administered through an existing Fediverse account.

Administration could be done through DMs to an admin account, or to the group account itself, rather than through a web interface.

So, I imagine creating a new group might start with someone sending a DM to @admin@chirp.social with a message like:

create group CoolThing

Description: This is for everyone to talk about Cool Thing™

This would create @CoolThing@chirp.social, which would auto-follow the user who created it.

Then, that user could send DMs straight to @CoolThing@chirp.social for various admin tasks, like changing the description, or meta fields, adding a profile picture (by sending the file itself), banning users, or unboosting posts.

They could also add additional admins who could do the same things.

You could eventually add a moderator level as well, who could unboost posts and ban users, but not change metadata about the group itself.

[Andre601]

Yeah.... security doesn't seem that safe with this setup...

[goodevilgenius]

And by the way, the concern with Firebase isn't necessarily just that it's Google, but also that it's a proprietary, closed-source service.

If auth was handled directly, then I can see the code and know what it's doing with my password (presumably, hashing it and adding the hash to the database). But, with Firebase, I have no way of knowing exactly what is happening to my email and password.

Handing auth off to Firebase makes this service not fully open-source, because of that dependancy.

[goodevilgenius]

@Andre601 what seems unsafe about that setup? Are you worried that someone could spoof a Fediverse account?

ActivityPub handles that with encryption keys and signatures: https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/#http-signatures

[Andre601]

@Andre601 what seems unsafe about that setup? Are you worried that someone could spoof a Fediverse account?

ActivityPub handles that with encryption keys and signatures: https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/#http-signatures

Well, for once is Mastodon, which a lot of people use, not end-to-end encrypted in DMs, so there's no guarantee that someone couldn't find info and alike.