Pre-approval queue is too hidden

UX
1

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

  1. 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.

  2. 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.

  3. The Akismet plugin catches stuff that missed the automatic measures and is installed by default on our customers

  4. 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)

6 Likes
2

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)

3

We can install it but unfortunately you are going to be stuck buying a key per: Pricing – 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.

6 Likes
4

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:

4 Likes
5

Out of curiosity, what is the setting of min first post typing time on your install? As usually those type of posts are copied and pasted in.

6

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.

4 Likes
7

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?

8

These are never spambots, they are always humans… captcha is useless on them. Bamwar et al.

9

Happy to give you guys admin access so you can dig through the logs. Email me at chris@3dr.com

3 Likes
10

It’s 3000, which I think is the default

3 Likes
11

@sam will follow up with you to take a look and discuss some options.

2 Likes
12

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.

@neil can we make a note to try this in 1.9?

2 Likes
13

@xrav3nz since you are looking at approval queue, be sure to read this topic as well. There is some very important context in the OP

4 Likes
14

So for flags older than 60 days, automatically perform the “Defer” action:

20 PM
20 PM1036Ă—114 8.22 KB

If the post was automatically hidden because of the “flags required to hide post” setting, it remains hidden.

Posts pending approval will be rejected.

Users pending approval will stay as they are, or should we auto-reject them too?

3 Likes
16

  • automatically defer flags after (x) days, yes

  • posts pending approval must be rejected

  • users pending approval must be rejected

I can’t think of any safe alternative in the latter two cases, so it has to be reject.

4 Likes
17

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.

4 Likes
18

Just following up on this,has everything been ok since we last discussed this?