Fighting Spam aka The Clone Wars

[andreslucena]

We're receiving lots of spam activity in pretty much all of Decidim installations. For that, we're changing the default behavior of the unconfirmed access email configuration, so that would be a decision of the implementers (see #8233).

The problem is that this will not solve the whole problem, as @ahukkanen pointed out in that PR:

Also, beware that some spammers also do confirm their email. In a recent cleanup in one of the smaller instances we host, there were about 1000 spam users detected. About 65% of them have confirmed their email address.

So I'm opening a Discussion to have in the same place all the proposals and so we can study them together with its Pros and Cons.

Some restrictions that we must take in account:

1. It shouldn't bring much friction to participants.
2. It shouldn't rely on third parties (like Recaptcha or Akismet)
3. It should be accessible. For instance, if we have an image captcha, then we should also offer an audio captcha

Some awesome starting points are @ahukkanen in #8233, I'm copying that here so it's easier to keep track of all the links, tradeoffs, and details:

I think there are no "sovereign" bot detection tools out there because the reliable automatic bot detections rely on behavioral data about the user or a large set of behavioral data from other users which are compared to the current user's behavior. These kinds of solutions are provided by 3rd parties and they cost money.

But there are commercial alternatives to the big G's reCAPTCHA available. If you were to create an integration layer for such tools, that might help but it does require a 3rd party paid service to work properly.

And recently I also posted this to MetaDecidim which could be self-hosted and useful to fight bots:
meta.decidim.org/processes/roadmap/f/122/proposals/16256

The text posted by these Decidim spammers is pretty similar in all instances, so I think it could be detected rather easily. But this is only after they fill in their profile information, as the spam content is generally added there (in addition to the comments). I don't think this would work during the registration process unless you compare the name and usernames to a spam database. For the registration process, I think some reCAPTCHA type of thing would be needed.

For some instances we have thought to disable public registrations completely and only allow registrations with a Finnish strong identity but obviously for instances such as MetaDecidim that wouldn't work.

#8233 (comment)

Maybe a bit off topic but regarding the captcha point above, I found this interesting discussion from Matomo issue tracker:
matomo-org/matomo#13905

Just for future reference, I'll add some notes here as well.

The creator of PHP Smart.Framework pointed out there that he had created an open source multi-method captcha that can be tested here:
http://demo.unix-world.org/smart-framework/?/page/samples.testunit/tab/0/CamelCase/Test/tab/2

It's only for PHP and only for his framework (and not accessible at least in the demo) but there are some interesting ideas to take note about.

How it works:

1. It makes the user wait 8-9 seconds (randomized), making the spamming activity less productive by making the spammers use more time (which generally costs money) to perform the spamming

2. It listens to the user behavior (how many times they have moved the mouse/scrolled the screen, how many times they have clicked/touched the screen) and if specific thresholds are hit, the user is more likely considered as a human

3. It draws few symbols + a square checkbox symbol on HTML canvas where the user needs to find the correct place to click on. Some reCAPTCHA clones do a similar thing, although G's own reCAPTCHA only uses a <div> that resembles a checkbox

4. If the user manages to find the canvas checkbox and they have enough activity on the screen, they are considered a human

5. If the user is seen as suspicious, they have to complete an icon captcha which shows a grid of icons where the user has to pick one symbol that does not belong to the set

6. If the user fails to complete the symbol-captcha, they ask the user to do a "motion captcha" where they have to draw a random symbol (triangle, x, rectangle, circle, check mark, zigzag, star, etc.) on a HTML canvas

7. If drawing fails, finally user is presented with a normal letter-captcha with voice alternative and QR code alternative that you can scan with your phone (it contains the letters to fill in)

The canvas-based methods are not generally accessible, which is why I think e.g. Google doesn't do that. It would have to be implemented differently in order to make it fully accessible.

I'm not saying all this would need to be implemented in Decidim and definitely some bots are still smart enough to pass all the tests, but just putting this here as notes for future reference. I think with bot prevention, there's really no perfect solution out there, but the idea is just to make the spamming activity harder for bots, so maybe they would rather target some easier sites instead.

It should be also noted that some spammers also hire real people from third world countries to complete these tasks for a very minimal price. But again, when making it harder for them and putting a price tag for the spamming activity, that will definitely make less spammers interested to target the website.

#8233 (comment)

Feel free to chime in with your ideas!!

[virgile-dev]

Hey there,
It's an issue we've been facing too.
We developed this gem https://github.com/OpenSourcePolitics/decidim-module-question_captcha which offers a way to implement a captcha that's WCAG compliant but it's not a 100% spambot proof.
It's been implemented on this instance : https://participer.loire-atlantique.fr/

[aramollis]

Is this captcha module ready for the current version of Decidim (0.25.2)? @virgile-dev, @paulinebessoles, @armandfardeau?

It seems that the current version in master is compatible with 0.25 by looking at:

• https://github.com/OpenSourcePolitics/decidim-module-question_captcha/blob/master/lib/decidim/question_captcha/version.rb

But maybe master is not a stable branch? We did a quick test and tried to install the module in the local development app using 0.25 and the component seems to be unavailable in the participatory spaces. But maybe we have installed the module or created its initialization file wrong.

Thx!

[armandfardeau]

Master is a stable branch until a new version is released. Please open an issue.

[lawrencemcn]

Hi @armandfardeau, @andreslucena, @ahukkanen, @aramollis

I have tried these 2 differents Captcha for decidim:

• https://github.com/OpenSourcePolitics/decidim-module-question_captcha
• https://github.com/Retrospring/hcaptcha

With both of them, it looks like we can implement the Capthca just when a user try to Create an Account on Decidim.

It looks like with Decidim it is not possible to implement a Capthca on the Log in page, to verify each time a user is logging in that he is not a robot.

Wouldn't that be a good feature to have the possibility to add a Captcha on the Log in page ?

I also tried this module https://github.com/OpenSourcePolitics/decidim-module-friendly_signup but like the others it is only at user registration and not at each user log in.

Thx

[armandfardeau]

In my opinion, slowing down the users' connection is a painful solution.

It is easier to detect harmful behaviors afterwards and to remove them (with machine learning for example)

[Quentinchampenois]

Hi,

I was thinking about some potential solutions for this problem. I have ideas for now, what about :


* Adding honeypot fields in registration form in case of automated bot (if field is answered then it is a bot) 



* Disable urls in description field of user. And maybe having a list of forbidden words that does not respect usage condition.





I keep looking for other solutions

[ahukkanen]

According to some stats I've seen, the timing of the user posts seems to be pretty effective in some contexts, such as website comments.

Make the bots wait until they can post + block e.g. comment submissions from the same user within 10 seconds (or so).

So, there would be two prevention mechanisms:

1. On every page where users can send data (registration form, comment form, proposal form, etc.), make the user wait for some seconds before accepting their post. This tricks some bots into thinking they cannot post. Randomize the time, so sometimes they have to wait 8 seconds, sometimes 10 seconds, etc. For normal users, there should be some indicator next to the submission button telling them they still have to wait few seconds.
2. When the same user sends multiple comments within 10 seconds (or so), prevent their further submissions within the same timeframe.

The first technique could be also implemented so that the bot would "think" that the content was posted, although it was silently rejected. Some of the bots are "smart" enough the check the page whether the content they just posted appeared correctly (and they will re-try until it appears). But this may be difficult to implement within the Decidim context, with the democratic guarantees, etc.

So I think just preventing it based on the timing would be sufficient within the Decidim's context. Count the time from the initial page load until the time the user submits the form -> if this is low, it's probably a bot. Then, compare the posting time to the previous entry from the same user -> if the previous entry was sent within few seconds, it's probably a bot.

There are also some other user behavioral techniques to combine with that, such as did the mouse move on the screen at all during the posting of the form. Or did the user click anywhere on the screen/keyboard before the form was posted. But that goes a bit deeper than the simple timing method which should already be a good start.

[paulinebessoles]

The timing technique seems to be a good start and I like it but I'm afraid users could be discouraged if they have to wait for each form submission. Could this method be used 2/3 times on a same user and then tag it as a bot or as a real user?
So real users wouldn't have to wait after they were tagged as such.

It's just an idea, I don't know if this would make the technical implementation harder.

[paulinebessoles]

Hi everyone!

I thought about this clone war and had an idea.
As the robots almost systematically fill in the fields in the "My account" page (About me, Personal URL, Avatar) with external links, may be we could:

1. Automatically ban those users with a hardcoded justification (using the ban feature Detect the use of spam-bots and ban non compliant users (part 1) #6696 & Detect the use of spam-bots and ban non compliant users (part 2) #6804), so they could be unbanned by an admin if needed.
2. Automatically list those users in an index in the BE in the "Participants" tab called "Spam prevention", making it easier for admins to ban them if needed.
3. Add an invisible field for humans in the "My account" page so if a robot fills it, it is automatically banned.

[andreslucena]

1. Automatically ban those users with a hardcoded justification

-1, I think that for automatic banning, we should have a really strong confidence in the system and rules. If so, we could automatically report and that a human administrator review this report and bans the participant if she agrees that's spam

3. Add an invisible field for humans in the "My account" page so if a robot fills it, it is automatically banned.

+1

[paulinebessoles]

Yes, I totally agree, I think an index for robots could answer that problem, or may be a supposed robots export in the "Participants" index to treat them easily for admins.

[armandfardeau]

Hello everyone,

We have developed a machine learning model to detect bots that works at over 99% efficiency.

We are currently looking at how we can implement it in Decidim, make it self-correcting and above all preserve the confidentiality of user data.

The idea would be to propose it as a Rake task with a connection to this service that would be accessible to the community.

The operation of the service would be simple, we would send a Json containing non-personal or anonymized data, and it would respond with a user id and a percentage of confidence on the spam character of it.

The user would be marked as spam to be confirmed by the administrator or directly blocked with a notification depending on the configuration of the system administrator, which would remain configurable in Decidim. The external service would not make any decision.

[furilo]

Any updates on this? I was thinking on ways to flag suspicious users and came with an idea similar to this: based on the assumption that usernames of spam users are characteristic, and different from normal users, Decidim could provide the model, but each site would feed its own usernames, saving the need of integrating an external service.

[armandfardeau]

Yes we have a working version available here: https://github.com/OpenSourcePolitics/decidim-spam_detection

[armandfardeau]

As you may see in the code, we use the following columns and nothing else:

'sign_in_count',
'personal_url',
'about',
'avatar',
'extended_data',
'followers_count',
'following_count',
'invitations_count',
'failed_attempts',
'admin'

We use a machine learning model that has assigned each of these attributes a weight and the probability of spam is dependent on the weight of each of these weights.

[lawrencemcn]

Hi @armandfardeau,

does the https://github.com/OpenSourcePolitics/decidim-spam_detection work alone, or we have to use a detection service like https://github.com/OpenSourcePolitics/spam_detection to make it fully functionnal ?

[armandfardeau]

It is possible to develop any API service in addition to the decidim-spam_detection module.

We use the spam_detection module to take advantage of the many python libraries for machine learning.

In this case it is not possible to use the decidim-spam_detection module alone, but you can either use our solution (by deploying it yourself) or by developing another one.

[virgile-dev]

Hi everyone,

Maybe this is a stupid idea but thought I'd give it a shot ?
As it appears spam bots create an account on Decidim to get link juice flowing to their website from highly trusted domains why don't we just delete the personal account field from my account (our analysis show that this field is mainly used by spam bots). Then It might not be as interesting for them to target decidim website ?

This said, I don't think it will stop spam bot creation instantly as decidim instances are in their list and account creation will still be enable. If they cannot put their link in their profile they might just try to put it in their comments and proposals.

[Quentinchampenois]

I agree with you, do we really know what are the spam bots' motivations ?
If it is mainly link juice, maybe we could display the personal URL not as a HTML link but plain text or even with Javascript ?

Furthermore, for now we're thinking about solutions to avoid scripted bots, but do we really know if the spam bots are automated ? If not, I think we should try to understand what is the concret objective, for now I think this is mainly for publicity / link juice rather than phishing or other.

[armandfardeau]

Hello everyone,
we have developed a very effective solution to fight against spam from link_juice profiles on decidim with a success rate of 99.99%.

https://github.com/OpenSourcePolitics/decidim-spam_detection

This is a decidim module that uses an API written in Flask to give a spamming probability to the users, if it is configured for, it can even directly block them.
We would be happy to provide an implementation for you to test, or deploy at your own convenience.

[furilo]

Very interesting! Have you seen/tested https://github.com/ruby-ml/xgboost-ruby ? Would it be feasible to have a per installation model, so we don't have external dependencies?

[armandfardeau]

Sorry for the very late reply,

I'm more in favor of using an external service than using a ruby module (for evolution and maintainability reasons)

But we are open to discussion and contribution.