Hardcode a block for gab's instance by default

[Laurelai]

Just what it says on the tin. Hardcode in a block for gab. In such a way that they cannot see our servers from theirs.

[jhaye]

It's certainly possible to suspend any domains used by Gab by default, and I agree that we should do this. Though that doesn't prevent information from your instance leaking via a third party that doesn't block Gab. This one is tough, and we don't really have a solution for that right now.

What we could do is provide a firewall config that denies any incoming traffic from Gab's domains. For Docker we would simply have to switch the current one out. For non-Docker setups the only thing we could do is encourage people in our setup guide to do it. Though I'm not sure if this measure would achieve anything, or would simply add work without any benefit. I'd like to hear someone else's thoughts on this, especially if they understand exactly how ActivityPub leaks.

[kaniini]

the only way is to firewall them at iptables level. AP itself does not require authorization for object fetches. adding that functionality to AP will take significant amounts of time.

but firewalling their servers will work in the meantime. we do need to learn what IP range they use for object fetches though. with deployment of new gab, their IP ranges will be surely changing.

[falkreon]

I'd strongly recommend peeking at the webfinger output - there are a lot of extra data endpoints in Mastodon. We'll want to make a decision about whether we want to keep supporting ostatus, for instance.

RSS/atom support is universal across all the Mastodon API endpoints (just add '.rss' or '.atom'), which might offer some more elegant ways to federate, but should probably be either authentication-required or disabled for private accounts.

A large swathe of the Mastodon API does not require authentication. There should probably be an option to require authentication everywhere - this already exists in pleroma.

I'll keep my eyes peeled as I continue to prod mainline and update here if I find anything new.

[rtucker]

Identifying requests to pull public posts from a suspended domain is likely to be a serious challenge in the general case.

Take, for instance, vulpine.club... our public-facing IP is 2600:3c03:e000:27b::e621:10, but our sidekiq containers use a slew of various and dynamic IP addresses. This would also fail to properly handle instances behind CloudFlare and other CDN-like entities.

That said: 2600:3c03:e000:27b::/64 would match everything vulpine.club, so assuming I never tried to evade that (intentionally or no), blocking that /64 would work for exactly vulpine.club. So, hand-crafting a block may be possible, although it would be brittle.

[kaniini]

fwiw leaks is too simple of an explanation. as:Public objects should imply zero security, as they are intended to be public.

so even that's complicated, and requiring authorization to fetch as:Public objects is going to be difficult

[Packbat]

I remember seeing a thread a while ago talking about DNS blocking as a less troublesome alternative to IP blocking. tl;dr as best as I understand it: for Mastodon instances, if you edit the /etc/hosts file on your server with, say, "gab.com 127.1.1.1", then any data Mastodon would have sent to gab.com goes to 127.1.1.1 instead and never reaches them.

As implied in the thread, this could probably be implemented into Florence itself, actually, attached to the instance silence/suspend tools.

[falkreon]

One last thing - the fed timeline is built so that posts can leak though third parties. It may be enough to prevent gab from acquiring the user's keys (mainline will drop activities it can't verify) but a bad actor might be able to just passively listen to get indirect, unverifiable knowledge of our fed timelines. Worse yet, make deliberate queries against the third party's unauthenticated fed timeline endpoint, knowing they verified the posts since they didn't drop them. So some leakage may be unavoidable unless you only federate with a network of ubiquitously-authenticated peers.

[falkreon]

Crap, I keep thinking of more things - a surprising amount of data shows up in every Note retrieved from masto API. In particular, a user's bio text and all their Fields.

[pgeorgi]

tl;dr as best as I understand it: for Mastodon instances, if you edit the /etc/hosts file on your server with, say, "gab.com 127.1.1.1", then any data Mastodon would have sent to gab.com goes to 127.1.1.1 instead and never reaches them.

That works for outgoing connections (your server attempts to connect to gab.com), but this doesn't stop gab from connecting to your server to request things. It also doesn't work for subdomains (a.gab.com)

[Laurelai]

I once rewired an image board software to add banned users to iptables drop list, is this possible with the software here?

[Packbat]

That works for outgoing connections (your server attempts to connect to gab.com), but this doesn't stop gab from connecting to your server to request things. It also doesn't work for subdomains (a.gab.com)

Fair 'nuff! The main reason I'm bringing it up is just to suggest domain blocking as a feature in parallel to IP blocking. Hopefully (I'm not a developer) such a feature implemented in Florence instead of roundabout through server setting shenanigans could allow for blocking of subdomains at the same time.

[jhaye]

I once rewired an image board software to add banned users to iptables drop list, is this possible with the software here?

Potentially if the request can be identified somehow. I think Mastodon does something like this, but I'm not sure what or how. The identifier could be removed of course, but it would be an additional road block.

[clarfonthey]

Considering how DNS/IP blocks are possible from a networking standpoint, it makes sense to be able to enforce them in the admin UI itself. IMHO this shouldn't require editing system configuration to make things work properly.

As far as blocking gab goes-- I agree 100% that we should, although thinking ahead, we're going to have to figure out a policy for when we should be adding these instances to a common blocklist. What might be the easiest strategy is just adding these directly to the database under suspensions, although that wouldn't necessarily prevent you from deleting them.

In terms of who we block, I feel like we should only block people who violate our own CoC, as a good metric. Maybe even allowing the ability to import blocklists would be a good idea.

[clarfonthey]

One other thing that is important is that we really shouldn't be making these blocks part of florence-masto itself-- the blocking functionality should be part of the instance software, whereas a separately updateable bit can include the block list. That way, there's no rush to make a new release every time someone gets added to this list, and instead, this can be updated through a separate thing.

[Laurelai]

One other thing that is important is that we really shouldn't be making these blocks part of florence-masto itself-- the blocking functionality should be part of the instance software, whereas a separately updateable bit can include the block list. That way, there's no rush to make a new release every time someone gets added to this list, and instead, this can be updated through a separate thing.

Normally id agree but i believe gab represents a special threat due to their proven connection to violent white supremacists, mass terror and murder.

[kaniini]

One other thing that is important is that we really shouldn't be making these blocks part of florence-masto itself-- the blocking functionality should be part of the instance software, whereas a separately updateable bit can include the block list. That way, there's no rush to make a new release every time someone gets added to this list, and instead, this can be updated through a separate thing.

fwiw, i'm not really enthusiastic about shared instance blocklists (including in the form of downloaded definition files), for reasons i have elaborated many times on fedi. we looked at and prototyped such a system and could not confidently say that it provided adequate protections against gaming the system.

block together, while potentially useful, has also introduced a lot of problems. and this proposed system is worse because the only thing you have to do is compromise the florence team in order to wreak significant havoc against instances that are innocent.

the primary concern i have with instance blocking gab by default at present is, we don't actually know what domains new gab uses. if new gab uses a different domain, like newgab.com or gab.social, or whatever, then the preloaded blocks are ineffective. so i suggest waiting until we have more intelligence concerning their plans.

[Laurelai]

Having the means to do so can be built now and then the specific domains added later.

[Laurelai]

Like not to put too fine of a point on it but we have about a month before the monsters come.

When i first started getting into mastodon i tried to tell people these types would show up eventually and got laughed at and ridiculed for it. Now the barbarians are at the gates and we are not ready and a lot of people just want to let them in. We not only need this new type of domain blocking, we need it quickly. We also need a suite of new moderation tools as well.

If we arent prepared these fascists will overrrun and destroy our communities.

[jhaye]

OK, so from what I can gather dropping network traffic from Gab's servers would be desirable.

So here is our plan for now:

• ready a release for the day Gab joins the Fediverse which adds a suspension for their used domain(s) by default
• add their used IPs to the firewall and drop all incoming traffic for the docker release
• provide documentation for admins of non-docker setups to configure their firewall in the same way

As pointed out by @Laurelai all of this can be done proactively and the only thing we'll need on release day is Gab's used domains and IPs.

[Laurelai]

We may have less time than we thought. https://social.wake.st/@liaizon/102311267814348953

[jhaye]

From their announcement it is clear that they will join July 4th. Which means we have two weeks, that's our timeline.

[mal0ki]

I do agree with that we don't want people using Florence federating with Gab instances (because we know there'll be plurals). But I also agree with that shared block-lists can become a problem. I'm thinking clear vetting process for criteria, specifically against Fascist/Nazi instances.

However, I want to make it clear that I don't see this block-list as a "Must protect everyone from everything", I'd see it as a "when you start your Florence server you shouldn't automatically be federating with nonsense such as fascism), as that could definitely fuck up someone's first experience with the Fediverse. But then you should be able to opt out or in of it as you see fit yourself (on a server-admin level). This could also go on the flip side, start users with an allow list of other Florence instances, and just flip it on it's head.

Someone also mentioned non-binary lists (because it's not allow nor disallow, and I'm not using the regular "colour scheme") as an option along side with allow/disallow. I think you mentioned it @kaniini ?

Thing is, we also know that one of their goals will be to waste our time, either with this work (of trying to actively ban them) or some other venture, so I do want us to look at a more dynamic, swarm like solution, which is faster than the current suspension / block warnings that we send out to the federation.

Someone discovered details they added in their code, which may be able to help us? https://sleeping.town/@zoe/102310618800543068

I'm also aware of the develop-instance (just a moment ago, but been writing and distracted because brains are fun that way).

[kaniini]

i don't know that using the gab software is necessarily indicative of anything, and this is a sore spot for me.

and yes, i have been talking about optionally quarantining new instances for some time. i can see many use cases for it in communities.

as for gab itself, according to conversations i had with them earlier today, i believe they will be using gab.com for their instance domain. so, plan ahead accordingly, I guess.

[Laurelai]

Would you use a fedverse software written by ISIS? Or one made by the DPRK? I sure wouldnt. Same thing here. I wouldnt trust gab not to put malware in it. Or code in malicious features.

[kaniini]

no, i wouldn't personally use a fediverse software written by ISIS or the DPRK. and, that's not my point.

my point is that gab plans to advertise themselves as being easy access to "the federation" (whatever that means), so in a few years if they are still in business (seems unlikely, but i digress), it wouldn't be implausible to assume that there are gab instances out there which are harmless.

my point is that using software as the dividing line doesn't make much sense. we can assume that many gab instances will be absolutely horrible, and there may be justification on those lines to have automatic mitigations in place, but it doesn't solve the core moderation problem, which is that most fediverse software (and especially mastodon) are default open-to-all. i've been warning about these possibilities for years now, and so far, Pleroma is the only mainstream software that allows admins to have some modicum of control over federation behaviour without having to modify the source code.

or, more bluntly, instead of worrying about gab software specifically, we should optimize for the general case.

there are plenty of mastodon and pleroma instances out there run by people we probably don't want in our own communities already, and we have to go out hunting for them or stumble upon them, or worse, find out about them when they come and dogpile on our users.

yes, gab will assuredly add to the sea of bullshit, but there's already an ocean. optimizing for the general case will yield superior tools for communities in this case than spending time working on bandaids.

[Laurelai]

They will use their version of the software as a means to gain funding, like making a patreon for the project. Use of the software even for "harmless" reasons gives them a means to gain financial support. They must not be given any oppertunity to gain traction. Im sorry but there is no harmless case for using nazi software.

[kaniini]

sure, but that doesn't mean that we shouldn't design moderation tools for the general case. i don't believe we should treat moderation tools strictly as mitigations.

probing instances to see if they are gab instances or not is fundamentally bad engineering: the checks are easily bypassed by altering the remote server's behaviour. the checks may also produce false positives for non-gab software. especially checking responses for specific fields is extremely fragile and unreliable for checking.

note that this does not mean that i'm not in favour of having florence blocking gab.com by default -- now that we know they intend to use gab.com, it makes perfect sense to do so given the groups florence is looking to serve.

(and in fact, i am considering revising the MRF documentation in pleroma to use gab.com in the example, but i don't know if giving them that kind of publicity is a good idea.)

[clarfonthey]

I think that the points you're making are reasonable, @Laurelai, but they're not incredibly on topic for this issue. If you think that blocking based upon instance software is a good idea, that should be discussed in another issue. I personally feel that that would be... well, I feel like there are a lot of nuances to consider to avoid messing up, with it, and it's a lot more effort than quarantining new instances like @kaniini suggested.

Again, all of these individual ideas should be separated into their own issues to compartmentalise the discussion and make things easier to follow for people who aren't intently watching this thread.

[meltheadorable]

Trying to block the software based on things like the fields they return or the namespaces they include is likely to end up being a game of cat & mouse that is extremely high friction in terms of updates that require a software upgrade and impossible for admins to keep up with. The fediverse is going to be stuck with the sociotechnical choices that get made here for, potentially, a very very long time, it's more important to get this right than to move quickly, putting out an incomplete solution that gives people a false sense of security or a solution that backfires on the most marginalized groups in the fediverse would be worse than trying to cope with gab using the tools we already have.

It's indefensible that it took this long, and gab joining, for anyone to take this seriously, but half-assed measures that expose people to new risks and different dangers could cause permanent damage and a reactionary panic response is not going to protect anyone. Options and their likely secondary effects & potential unintended side-effects need to be deeply analyzed for abusability and feedback risks in a way I've not really seen anyone doing. Software is not going to save us from this problem, the instances that can't be convinced to block gab using existing techniques won't be convinced to adopt new ones, and none of the options proposed here will add meaningful friction to coordinating harassment and abuse from gab.

The best options right now are to continue putting pressure on admins to block their domain and to encourage people to do less fully public posting, the more admins block them the fewer third parties can leak posts to gab users, the less public posts the fewer posts are vulnerable to circumvention in general. Developing additional privacy modes, alternative posting schemes and improved ergonomics around non-public posts so that less-than-fully-public is a realistic option would all be more productive uses of limited development effort and resources than chasing gab's software, and long-term solutions to mastodon's shitty blocking behavior are going to require deep changes that cut across every aspect of the project and a lot of careful planning and coordination, because ActivityPub just can't support working behavior as currently deployed.

[Laurelai]

https://github.com/florence-social/mastodon-fork/issues/112 New issue here.

[clarfonthey]

Please don't try to provoke people in GitHub issue comments.

[Kootnik]

Cute, but why don't your ilks just go back to twitter, you're actively going to sabotage the decentralized model and feel proud about it? (not to mention it's not going to work, i guess you don't understand that domains are a laughable way of targeting).

One thing is for sure, OSS does not appreciate leftism.

Here's an alternative: grow up and learn to deal with it in other ways than REEEing.