We got some feedback on twitter I wanted to respond to properly:
Why not enable pre-approval queue by default?
There are are a few biggish reasons we do not
The vast majority of Discourse installs out there do not have this setting enabled, in fact, I can only think of a handful of sites that add this. Even very big install.
Our built in spam measures catch most spam. Friction is high cause you need JavaScript to spam and we measure stuff like typing time and so on which automatically catches spam.
The Akismet plugin catches stuff that missed the automatic measures and is installed by default on our customers
At the moment handling the 2 queues (pre-approval and akismet spam) requires a site moderator. This can lead to quite a few situations where a post can be “in the queue” for hours or days, this drives away new users big time
Why is this so hidden?
The big reason is that, in general, we do not notice people need it. If people experience a spam attack we like to hear about it on meta and get as much details as possible so we can correct any of our automatic detection. Enabling “approve everything by TL0” is kind of giving up, so we try to discourage it.
There are also open UX issues and usability issues around approval queues that need to be polished if this feature is to be more prominent. In particular:
Why can’t high trust users (tl2) approve content in the queues?
Why carry around 2 lists (akismet and approval) of posts?
Why can’t mods approve in the context of a topic?
What happens if something sits in the approval queue for 1 week without being handled? (we send an email to remind to site_contact email, but this is a bit too hidden)
Thanks for the thoughtful and well-explained reply. I didn’t have Akismet installed (or even knew that I needed it), so got nailed hard by the spammers, who somehow got past all the other safeguards like rate limiters. Could Akismet be included as part of the default distro? (apols if it already is and I just screwed up my installation)
We can install it but unfortunately you are going to be stuck buying a key per: Plans and Pricing - Choose the right plan | Akismet. I am open to adding a comment that you can uncomment out of the file for this if you are comfortable with the extra cost.
Regarding the specific spam attack, I take these attacks super seriously, if you can give me admin on your site and open the floodgates for a few hours I would love to debug through to find out how they are bypassing our immune system. I have not heard of any recent severe spam attacks but it is very possible spammers have gotten smarter recently.
The MO here is hundreds of accounts created three days ago, each of which created three posts (long ones about downloading games). All looked like this:
The 6m read time is a very big tell that the spambot is pretty smart, it is actually triggering internal APIs that pretend it has read stuff. I would love to looks at some of the raw data / logs here.
Hmm, that is clever, since it bypasses our first day limits. There are two sets of rate limits:
new user rate limits
first day rate limits
They would still be subject to new user limits, as it takes 10 minutes of read time (plus a few other basic stats) to get out of the trust level 0 sandbox. But waiting more than 1 day gets them past our stricter first day rate limits.
We also rate limit new user signup from the same IP address, but if the new users are coming from different IP addresses they won’t be affected.
Each new user creating 3 posts is indeed them hitting the post rate limit for new users… this is fairly sophisticated.
I am asking again, and I apologize, but I need to be sure: did you change any other Discourse defaults that would affect this, anything around new users, trust levels, rate limits, or anything like that?
I think this also applies to flags, when there’s no higher power to intervene when something goes unhandled for, say… 60 days. I think we need to have a site setting so that very old flags / approvals are auto-dismissed, and don’t endlessly pile up forever.
I added handling for flags and posts, but didn’t do users. In the case when an established site enables “must approve users”, existing users could be deleted if they’ve never posted.
To control how long it takes before something is automatically handled, there’s a new site setting “auto handle queued age” which defaults to 60 days. Setting it to 0 will disable it.
