Spam Prevention

WriteFreely
1

I’d like to get everyone’s input on potential future spam prevention built into WriteFreely.

Today we deal with a sizable amount of SEO / backlink spam on Write.as, thanks to our anonymous / no sign-up publishing feature. But I know spammers have quickly made it into various open WriteFreely instances as well – some are filled with it. So I’d like to figure out how we might help, especially to make it easier on open-instance admins.

Here are a few ideas to get the conversation started.

Required email confirmation

WriteFreely currently doesn’t require an email address to sign up. This is by design, to make signup painless and give people privacy, should they choose it. Unfortunately, it also makes it easy for spammers to quickly create accounts.

Possible solution: We could add a configuration option for admins that would require users to sign up with an email address and confirm that email address before accessing the instance.

Possible downsides: This only adds friction; additional controls will be needed for spammers that get in.

User approval queue

Along with our existing registration options (open, closed, invites), we might add a new option: approval required. Like Mastodon and other platforms, this would notify the admin when a user asks to sign up, so they could approve or deny the request.

New user states

Today, admins can simply “silence” a user, which prevents them from publishing new posts. There are more controls we could add to help admins more surgically moderate their communities. We might also pair this with simple automation to reduce admin workload (think Discourse’s “user trust levels”). For example:

  • Optionally require approval before publishing to the public Reader. Here we might only notify the admin when a user:
    • Switches to Public blog visibility, and
    • Publishes their first Public blog post
  • Add moderation option to disable Public visibility setting, either for an entire user or for individual blogs
  • Mark users as either “trusted”, “untrusted”, or “unknown” (default), and tie different abilities to those states
    • Optionally, add different ways to get to a “trusted” state, e.g. manual admin action, verifying email address, being a long-time user, making several posts without any reported problems, submitting payment, etc.

Automated post blocking

We might add light, automated filtering for spam users that make it onto an instance. To reduce circumvention, I could imagine a simple hosted service that would accept a chunk of plain text and return whether or not it looks like spam. If it’s classified as spam, WriteFreely could perform certain actions automatically:

  • Completely block publishing that post
  • Publish with a limited audience (author-only)
  • Hold the post and notify the admin, so they can make the determination
  • Publish normally and notify the admin, so they can easily take further action if needed

This is something we could easily launch on Write.as, since we’ve gotten pretty good at blocking spam. But of course, I’m wary of a few aspects of this solution:

  • Diminished privacy from sending all content to a spam filtering service.
  • Centralized decision making – with a centralized service comes a single group classifying content.

So if we did go this route, we’d standardize the API and add instructional resources so anyone could launch their own service, and make sure admins could choose the service that fits them best.

What does everyone think of these ideas? What ideas do you have?

3 Likes
2

One consideration regarding e-mail confirmations: over the years of running multiple community sites (phpBB, Invision Board, vBulletin, now XenForo) came across with several kinds of spamming waves and there is one problem right in the beginning: big amount of bots register with fake e-mails from free e-mail providers (Outlook, Gmail, Yahoo) - they use a number of random addresses and your mail server keeps sending those initial e-mails asking to confirm registration. Now filters behind those free mail providers start tagging your SMTP as one sending unwanted mails as their content is very similar - same template asking to confirm membership.

I even considered running separate mail server under separate domain, say, forummail.tld so that confirmation e-mails would not hurt forum.tld mail server reputation.

It is increasingly difficult to run a mail server that has reputation good enough to be accepted by most free mail providers :thinking:

1 Like
4

E-mail verification based anti-spam is just security through obscurity. There is always a way around that. Same also goes for SMS, although it’s a little bit harder. They are not completely useless but they should not be used as the only criteria of trust.

I suggest a fuzzy logic based defense-in-depth approach:

  1. Implement an optional CAPTCHA widget for every submit form. This is the most basic line of defense and usually works fine
  2. Introduce new optional restrictions based on user metadata
    • Not logged in? CAPTCHA is mandatory for every submit form including registration and login
    • Connecting from a Tor exit node or a known VPN? Every submission requires manual approval. This can be done by the community with a voting system (spam/not spam) or by moderators. You can also use this data to train a local spam classification program, even better implement your CAPTCHA system based on this (i.e. Show previously classified spam posts and ask if this is spam) and kill two birds with one stone. Also thanks to federation every WF instance can talk with each other share the pool of spam posts with each other and help everyone
    • Created n new posts within m seconds? Now you have to wait m*4 seconds to create a third one and m*8 seconds for the fourth one and so on
    • Just created an account? You can create only n new posts for this month, n+2 next month, n+5 the month after that… until month m where the limit has been removed. Or optionally you can donate/buy to bypass this limitation.
  3. ???

You cannot stop spam 100% without seriously sacrificing convenience of the platform. Don’t even bother. Just make it hard enough until the spammer just says “F*ck it.” and goes somewhere else.

5

Yep, this is a great point @gytisrepecka. We see spammers using throwaway email addresses on Write.as, even though we don’t validate them. That’s why email confirmations are low on the list for me – and maybe they just don’t make sense these days, especially for all the trouble that the setup involves.

@agyild all great points. As always, we’ll want to balance this protection with usability, so I especially like your ideas for invisible constraints that most users will never encounter (e.g. restricting how often you can create posts, or silently detecting bot-like behavior).

I also like the thought of a shared pool of spam (bad) and ham (good) posts via federation – but there are plenty of risks there, from the inherent bias of any dataset to bad actors “poisoning the well” with bad data. Still a lot of food for thought here. I appreciate the input!

6

I think that what you may have miss out is to classify the website users. I`ve seen this feature on many websites: when you first register, you are being classified as a “new user”, and you have to either make several posts/submit content/be approved by moderators to get more features, including those that may allow the user to spam. I think it is really effective in preventing the spammers.

7

In addition to the above, some ideas while brainstorming what measures to take on qua.name:

Have some automatic content classifier, either standalone (like http://dbacl.sourceforge.net/ for example), implemented directly in SQL or integrated into wf directly. Bayes classification could auto-tag posts or auto-silence users (configurable per instance obviously) Sharing the classification between instances would be perfect.

Having a somewhat separate system from wf would be beneficial to keep the core system simple and not distract from the original purpose.

However, wf could support the classifier by providing ‘hooks’ in some places which would be typical to take action (user creation, post creation etc.) If some call/exec could be made at certain events in the program this would give the wf instance admin some options to choose a solution fitting to the local situation.

In addition to that wf could have a vote/classify posts ‘permission’ for some users which could help improve the automatic system.

8

I was expecting that ‘Unlisted’ posts would deter spammers, but it did not.

A way to force human interaction would be to force new accounts to post a first contribution responding to certain criteria, e.g., quote and reply to specific questions (“what brings you here?”) and poke an admin on the Fediverse when they’re done so that the admin can validate the user. This would certainly cost a bit more to spammers to get involved at this point.

9

Hello,

another possibility would be a captcha:
e.g. https://captcha.bka.li

11

User approval queue +1

New User States +1

I want to suggest bulk changes on the admin interface for the users (delete, silent, disable, approve, etc).

12

User approval queue is my fav.