FYI, the Fedi spam problem is only starting out. It won't take much effort for someone to write a payload running on random compromised webservers to send copious amounts of spam via activitypub, making blocklists ineffective.

We will basically need to implement all the same anti-abuse stuff we're already doing for email in order to cope with it on the fediverse -- greylisting, dnsbl, domain authentication, etc.

Sadly, the only way this won't happen is if ActivityPub stays sufficiently niche to make other targets more popular for spammers.

@monsieuricon

Couldn't that be an opportunity to dust off Hashcash?

@monsieuricon I think it is not good that account creation is automatic and costs nothing.

We ban them, they just create new accounts every 5 minutes.

We need some money-involving mechanism to prevent that. PoW maybe 🤷‍♂️

@Revertron It will just be "proof of someone else's work."

@monsieuricon If they use hacked servers for it, then yes :(

@yassin
@monsieuricon Hashcash didn't work for email, why would it work for ActivityPub which has a reasonably similar interaction between parties?

@monsieuricon 🥲

> It won't take much effort for someone to write a payload running on random compromised webservers

@monsieuricon that's not true because generally servers don't accept incoming payloads if they don't have a valid HTTP Signature.

So a random compromised machine also needs access to a random compromised fediverse actor (in order to have access to its private key) so it can generate a valid signature/digest.

It's not much harder, but still.

@monsieuricon personally I started playing with something called a "silter", an ActivityStreams pluggable filter on top of SpamAssasin.

However that was mostly for a lark, I doubt it would help that much. :)

@monsieuricon it's the "mo' fame mo' problems" bucket, ha!

@monsieuricon

you're the first person outside of ourselves that we've seen say it in these words

https://infosec.exchange/@atax1a/109451665232578836

https://infosec.exchange/@atax1a/109411101242391078

@atax1a it's hardly shocking considering we reinvent static linking about once a decade, each time in more and more convoluted ways that make it even harder to figure out what the heck you're actually shipping and what is the provenance of all components (see "containers").

@monsieuricon we've been running our own email server for a good 22 years now, and that has remained at a constant level of complexity for those 22 years.

wanting to deploy a modern webapp and having it hand us a docker file that pulls in an ubuntu image that it then blows away random parts of with rm -rf is infuriating because our brain parses it as cybernetic strip-mining and thus a form of digital colonialism.

we have Opinions.

@atax1a @monsieuricon it'll end up the same way email is; a couple of huge servers ran by Big Tech that block everyone else :)

@eri @atax1a That's if it succeeds. It can fail in many more different ways, from protocol fragmentation to just abandonment due to bad noise-to-signal ratio and newer, shinier options.

@monsieuricon @eri it is just physically painful to us to watch everyone scramble to reinvent the same solutions that email people have known about for decades

@Revertron @monsieuricon

Adding "money-involving" won't help.

Spammers have much easier access to short-term money than ordinary people - think about stolen credit card numbers, which there's a huge black market for. They won't care when your charges are reversed.

I'll repeat what others are saying, and what I started saying as soon as I joined Mastodon:
Look at what helped solve spam issues for email, and be aware of which solutions were proposed and either failed or had a core flaw.

@CliftonR
> Look at what helped solve spam issues for email

This was money. Most big email providers need a phone number confirmation, so you need to have a SIM-card, so you need to buy that.

@monsieuricon

@mariusor @monsieuricon lots of compromised machines are web hosts running an old version of php and an abandonware cms under a working domain. once you have shell access, you just have to run modified friendica or pixelfed. then use a different server to push outgoing events signed with those friendica keys, so that the web host ip stays clean.

@ww true, I wasn't saying it's impossible, only the complexity doubled over the scenario Konstantin mentioned. Additionally if a single actor from a single instance is used to generate the spam, it's an easy block against that instance.

@monsieuricon

@monsieuricon We have to give up on free as in beer.

@monsieuricon Got followed by my first get-rich-quick scammer yesterday. Zero toots, zero followers, just a scam in the profile. That's an insta-block.

@eri @atax1a @monsieuricon This would be the day I leave and give up any kind of "social network" forever. And give up an illusion we could have nice things :/

@monsieuricon Agree spam will become a problem on a successful future fediverse Disagree that tried and true email techniques will work here. But what about chain of trust? E.g: the only way a server delivers a post is if it can prove cryptographically that the receiving user is currently following the sending user?

@monsieuricon

That reminds me that I still need to see if I can find out why they chose a publish model instead of a subscribe model.

I don’t understand that decision at all.

@monsieuricon Just had to play whack-a-mole with a few of them yesterday. They got accounts on "low-moderation" instances and started spamming their shitty cybercrime Discord everywhere.

I'm just hoping that I got in early enough that whatever anti-abuse solution gets implemented grandfathers me in.

@monsieuricon I'm saddened that gpg web of trust has never been made workable as a reputation system.

@joschi @monsieuricon

Yeah, it was an ill-informed comment. I wasn't aware of the actual reasons why it didn't fly with email, but did some reading now.

@monsieuricon also beware of bots slowly creating 1000s of sleeper accounts on established servers,over months or years of time

@Revertron Do you have evidence that this was the main factor? As far as I know, it's a modest speedbump to using a particular provider, but I think it's pretty far from "what helped solve spam issues for email". @CliftonR @monsieuricon

@IdahoLark @monsieuricon What would be interesting is to use ActivityPub to share the same anti-abuse info in a way that would facilitate ingestion by peers. Collaborative defense.

@williampietri
But what else? I would be glad to know what is better than this 😕

@CliftonR @monsieuricon

@mariusor @monsieuricon Implement a Fedi server on the compromised web server.

@hexbatch yes

@hexbatch @mariusor Yes. At some point servers will have to require explicit admin approval to fully federate with newly discovered servers.

@Revertron @monsieuricon

I'm pretty sure from your comments that you have never worked professionally in spam or abuse prevention.

Anybody who has knows that similar suggestions (which have been going around since at least the mid-1990s, by the way) have done nothing to improve the matter.

@Revertron @williampietri @monsieuricon

A few fairly effective ones:

1) The most long-term effective have been IP matching and reputation services. Spamhaus has joined Mastodon, and everybody should learn from them.

2) Create a shared fuzzy-hash checksum service used by many sites, looking for identical/near-identical content being fed into many sites in the short term. (This was DCC in the email world.)

It has limitations but the original could be improved on.

3) Block TOR outputs. Sorry.

@Revertron @williampietri @monsieuricon

It's been a good 20 years since I was working professionally in that world, though.

I'm sure people who are more current in spam fighting and spam prevention have some newer ideas, but these seem to me to have held up.

The hard part for the first 2 is figuring out how to fund them and pay for the operating costs, both compute/network infrastructure and the humans behind them.

@K. Ryabitsev how do you plan to spam me, when i don't subscribe to your account?

@monsieuricon every truly distributed system needs a cost function. It's hashcash for email (paper from 1998) which is the only fully distributed approach to efficiently fight abuse. See also #fosdem2024 video here (distributed dns in an overlay network) - looking at the challenges of fully distributed systems: https://ftp.fau.de/fosdem/2024/k4201/fosdem-2024-3056-dns-for-i2p-distributed-network-without-central-authority.mp4