Probe and block instances running gab software

[Laurelai]

Since gab likes to have gab branding. You can count on them to want to advertise the fact its gab. It should be fairly easy to detect that an instance is using gabs fork of mastodon.

Blocking this and only this software i believe would be imperative to denying fascists a means to spread their ideology and deny them a means of funding to propel their project.

If using their software means they can only talk to gab then theres no real point in them using it, funding its developments etc. It will also prevent so called "innocent" people from using the software because the reprecussions will be mass suspension and lack of federation, they will likely move to use non gab branded software just to have people who arent nazis to talk to.

This probe and block should be automatic and on by default.

[clarfonthey]

Linking comment from other thread:

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]

Again, gab will not likely hide their gab branding as they are overt with this sort of thing. The particular adversary in this case is not likely to be clever enough to play many cat and mouse games. By all objective measures they got a large bag of cash to build their own social media site and failed at this task.

To put it simply, i dont think they are that smart.

[meltheadorable]

Unfortunately, the primary motivation for gab's move to the fediverse was to use 3rd party clients that are unlikely/less likely to be removed from the app stores on mobile, they are perfectly happy only talking to each other and other so-called "free speech" extremists, and their users will gladly hand over their money to fund continued development.

Their secondary motivation is to cause as much hurt as possible by federating with as much of the fediverse as they can get away with -- if the software's advertising itself overtly prevents them from doing it, they will work around it. It'd be nice to think they're not that smart, but this time their code will be open source, and they'll get pull requests from motivated assholes in tech, of which there is no shortage whatsoever.

While there's a small chance that a hardcoded block based on detecting certain namespaces or user agents would work temporarily, they are keeping very aware of conversations like this, the cat & mouse games are inevitable and the sheer magnitude of effort for instance admins to keep up with them would effectively be a denial-of-service attack on the part of the fediverse with a conscience. I'm not horribly opposed to trying, but fascists are no stranger to coded language & infiltration, many of them will be capable of PRing trivial patches to branding strings, over and over again if that's what it takes, this will not be effective if they are half the threat we're expecting them to be.

[Laurelai]

I mean you could just write a bot that scans their repo for changes and then reports them to you all when they would change anything that would interfere with the detection and adjust accordingly. That might help. But as of yet they are violating the AGPL and havent published their repo. If they make changes to their site to evade detection and dont push it to github, they violate the AGPL. Either way you have something to get them with.

[meltheadorable]

Right, and depending on how often they do that, admins would then need to update their versions over and over again to keep up -- 30 seconds of work for gab merging a PR leads to potentially hundreds of collective hours of work for developers here and instance admins across the fediverse, it's just not workable, the effort asymmetry plays out in their favor every time.

[Laurelai]

They are lazy as well.

Remember they abandoned twitter due to twitter banning some of them, instead of making new accounts or using tor (ive been banned from twitter like 7 times, im the nightmare scenario you are talking about of motivated, knowledgable adverseries who will adapt to whatever you do. Twitter just in the end gave up.) they just went to gab because it was easier, and they have stuck with this obvious scam artist because its too much effort to do anything else.

These people do not posess the level of motivation i have. I can almost promise that.

How about this. Just try the detection method and see what happens? If it becomes too burdensome it can be easly abandoned. But i dont think it would hurt to try.

[clarfonthey]

I feel like labelling a large fascist movement as "lazy" is a very dangerous statement. Also, I don't think it's entirely reasonable to use your own motivation as justification for a feature implementation-- unless you are capable of fully managing a project by yourself, I don't think that's going to help. It's pretty clear that the entirety of gab has far more spoons than we collectively do.

Like, I feel like this is going far too fine-grained into a cost/benefit analysis to actually be helpful. Right now, a lot of this is hypotheticals and can't really help. Maybe it'd be more effective to talk about why this solution is also needed in addition to others, like quarantining new instances before they federate, or requiring authentication for public posts.

[Laurelai]

Oh im not saying we should do this instead of whitelisting. Im saying we should do it with whitelisting.

[Laurelai]

The detection would be a first stage defense, and whatever slips through from adaptations would be caught by the whitelisting system. This would just reduce the noise that comes through to be checked if you want to allow them to federate or not.

[clarfonthey]

So… essentially, maintaining a list of gab instances and blocking those by default? That wasn't clear at all.

[Laurelai]

Im sorry. I sometimes have difficulty transmitting what i mean. I should have thought a little longer before typing.

[clarfonthey]

The main thing that I was thinking about discussing in a separate issue was whether we should be attempting to block an instance based upon the software at all, and not whether we should consider gab-based instances in addition to gab to be worth adding to a default block list.

There may be some merit to blocking based upon instance software, and having some level of instance software detection built in. This could be to detect gab instances, but also to potentially defederate with software that's old and has security problems.

I feel that this issue should probably be kept to the software-based blocking and the discussion of which instances to block should go in the original issue.

Apologies for jumping in and asking to split up the discussion-- gab is a problem in and of itself that needs to be addressed directly. I'm mostly just trying to think of these problems more generally in ways that can help for situations beyond gab, because we only have the ability to work on so much and I feel that going for solutions which solve multiple problems at once is better than targeted things that require a lot of work.

[Laurelai]

I get that and having systems and solutions that handle many cases is generally best. My mindset with this is to throw literally everything we can at them that will make their stay on the fedverse as hard as possible.

Ive been trying to tell people that the monsters were coming for a very long time and i am very concerned that the fedverse is not ready. its why ive been trying to make issues to ask for solutions that can buy us some more time, now that people see the threat is real.

[meltheadorable]

The problem with that strategy is that sometimes solutions that are ill-considered can cause more harm, especially if they become long-term and not just short-term strategies, which things are bound to do because once they're there, inertia will carry them. We don't know what collateral damage we might cause or who we might cause it for, it was irresponsible for the fediverse to wait this long to care (I've been working on these problems since before mastodon came out, and have not released software yet because it would have been irresponsible to do so without having this shit nailed the fuck down), but unfortunately we can't retroactively start taking this seriously so here we are.

Rushing to throw things at the wall hoping to give them a bad time now when like, we already know that no matter what happens they will be freely federating with at a minimum purism's servers and many many others who have taken a minimalist or hands-off approach to moderation, is just going to put people at risk of exposure from the hasty decisions that get made in panic here. The sad truth is that the monsters have been here all along, the only unique element of gab's threat is that they're larger and comparatively well-funded -- that's a serious problem but it's not one that we can fix by hacking together a collection of patches we don't understand the longer-term risks & implications of.

[Laurelai]

I mean no disrespect when i say this but, perfect is the enemy of good.

The time to carefully plot out all of the possible ramifications for this stuff was two years ago. That didnt happen. It could take years longer to properly create the best possible tools, in the meantime people will be harmed because as of yet, theres not much to help them.

Thats why im saying do some faster stuff that helps people in the now, while also planning for better replacements for the long term. This gives your project some breathing room to actually plan these new tools and have the time to do it right.

[meltheadorable]

I'm saying that people are already being harmed by not having planned out the ramifactions of ActivityPub and mastodon's existing feature set and that the kinds of changes that will actually introduce meaningful friction to Gab and threats like Gab are going to have to be deep, fundamental ones.

None of the stuff that's been proposed so far makes life considerably harder for Gab (not even the IP blocks, they are not going to work the way people want them to), but has the potential for dramatic negative social effects that will primarily harm already-marginalized people -- things like automating blocklists are going to predictably backfire and magnify the fediverse's existing racism & other bigotry problems, as one of the most obvious for-instances -- we don't understand the extent yet to which these other strategies will cause similar problems -- how okay are you with harming people in the pursuit of taking out Gab? What new harassment & abuse tools are we gonna hand to bad actors in the fediverse because we didn't think about what we were doing?

I'm not arguing for perfection, but not thinking before YOLOing a brand new social platform into existence as if there's no possible way it could do any harm is how we got in this mess, not thinking while trying to get out of it is just gonna dig the hole deeper.

[Laurelai]

Oh im against blocklists in general. Ive had a lot of bad experiences with them. I think however it would be doable to have a limited scope "just gab stuff because they are absolutely evil" type of mass block system. For anything other than that having blocklists is a very bad, very abusable idea.

I agree that activitypub needs fundemental changes at the core level. Ive been trying to light a fire under peoples behinds for a while about this kind of thing.

[meltheadorable]

Just so this isn't all teardown, at the risk of straying off the topic, the strategies that will have mileage in the short term are all social, not technical:

1) Pressure on instance admins to block gab 2) Pressure on client app developers to block gab 3) Pressure on app stores to block clients that won't block gab 4) Educating people about their harassment risk and the ways that public posts create an information asymmetry that harassers can exploit

Tech isn't gonna fix this, if we're going to make life hard for gab we need to hit them where it hurts, which is primarily in the general zone of mobile app support for their server, the entire reason they're doing this is to circumvent their bans from the app stores.

[Laurelai]

As for the pressure the client app devs to block gab, this has been tried. Fedilab has refused to and thus gab has the opening they need. Google didnt even reply to them when they asked if they had to block gab. Thats why i even made these issues.

To get google to move on this would require a lot of negative press in the media, something im incapable of causing, otherwise i would have done so. If you all have media contacts or know people who do perhaps that can be organized.

[meltheadorable]

The big issues with trying to fix this at the server software/instance layer is that

1) Gab will already have the openings they need -- nothing is going to be done upstream and many admins are not going to upgrade or switch to something that does, any adoption will be a "preaching to the converted" situation, changes have very limited reach. 2) Gab would be perfectly content not to federate at all -- since they are doing this to circumvent their mobile bans, they'd be happy as clams just continuing to rot in their personal playground so there's relatively little to leverage from this end 3) None of these proposed patches fix the few holes that could be fixed on the server end, with significant enough changes, the vector that harassers exploit through the UI is not going to be meaningfully mitigated with the IP ban strategy.

On topic: I do think it may be worth trying to do some form of software detection to expose in the moderation UI, and a feature that added new instances to some kind of queue (either tentatively federating or tentatively suspended by default) which showed what software they were running would be potentially helpful in making decisions about whether to allow or suspend them. The detection code is gonna be ugly because mastodon & gab don't expose nodeinfo, but that might be surmountable.

[mkljczk]

Pressure on app stores to block clients that won't block gab

please, don’t use corporate app stores reports mechanism for your ideological reasons.

Gab would be perfectly content not to federate at all -- since they are doing this to circumvent their mobile bans, they'd be happy as clams just continuing to rot in their personal playground so there's relatively little to leverage from this end

nope, they want to federate. https://develop.gab.com/robcolbert/posts/102311458912483486

We are federated on-purpose. We 100% intend to be a member of the federation. Full-stop. We will 100% adhere to the communications protocol standards and do nothing to stop people from blocking us. Gab.com made some compromises for federation. We eliminated downvoting/dislike. We reduced our character count per post. Overall, though, it's a great fit. We want to federate. There is more value in federation than downvoting.’ I’m all for more sophisticated moderation tools on Florence, but having hardcoded blocks is kinda the opposite…

Also, I guess Gab would love to expose nodeinfo, they would probably accept a PR, they really don’t seem to want to force everyone to federate with them… They even understand app developers decision to block Gab…

[mal0ki]

I'm just going to respond to this for now:

The sad truth is that the monsters have been here all along, the only unique element of gab's threat is that they're larger and comparatively well-funded -- that's a serious problem but it's not one that we can fix by hacking together a collection of patches we don't understand the longer-term risks & implications of.

I don't want us to hack something together, this is really good points (in all your threads), the goal here for Florence is going to be the bigger picture and long term, and yes it's going to suck that we can't get it out fast, and it's going to suck if we try to get it out fast but still do it wrong.

Would (everyone in this thread) want to start mapping out long-term concerns, short-term gains, long-term gains, etc. So we can get a bigger overview? I feel like containing this in GitHub issues wont work anymore.

[kaniini]

i think the way to fix trust and safety concerns with activitypub is to fix the trust and safety concerns. people are already working on this. we've been working on it for a long while now. it's just not very exciting work, so it never becomes the discourse topic of the day.

the path forward is to leverage OCAP instead of signature-based authentication as authorization method. then florence just requires authorization to fetch anything. i intend to push for leaving the authorization behaviour of serving as:Public posts undefined explicitly to enable that use case.

[Laurelai]

i think the way to fix trust and safety concerns with activitypub is to fix the trust and safety concerns. people are already working on this. we've been working on it for a long while now. it's just not very exciting work, so it never becomes the discourse topic of the day.

the path forward is to leverage OCAP instead of signature-based authentication as authorization method. then florence just requires authorization to fetch anything. i intend to push for leaving the authorization behaviour of serving as:Public posts undefined explicitly to enable that use case.

How do we accelerate what you are proposing

[meltheadorable]

Where is this work happening? The SocialCG hasn't had a meeting in months and I've not seen any other serious discussions about OCAP & related possible changes to ActivityPub except to the extent it's related to the work being done on Spritely.

[kaniini]

@meltheadorable

Litepub community have been working on an OCAP adaptation for AP as well (LiCE). Chris has been working on a proposal that brings his work on Spritely together with the Litepub proposal.

We are pretty close to something, I don't know where it will happen quite yet, maybe we reboot SocialCG and do it there, maybe we press forward in Litepub. But, nonetheless we are close.

[ghost]

i don't like gab, but i hate censorship even more. censorship is a slippery slope :)

[mal0ki]

We will not have any slippery slope arguments in this repo or any other repo under this org.

[ghost]

This convo is a bunch of fascists deciding how to be fascists most effectively and efficiently, fyi.