We have spam

[miguelvaara]

As we know, spambots are sending spam by making use of feedback form in Skosmos. Recently amount of spam has increased. We are very glad to hear good tips and suggestions to solve this issue 🙂

How to strengthen spam filtering

Proposal 1:
In globalconfig adjust honeypot time

Proposal 2:

In most cases spambots read directly some URLs, I belive. People are more used to click or tab and “surf” on website and they do it mainly via frontpages.
Human user:

1. Goes to Finto.fi/fi (sv, en) frontpage
   a. System: Sets up a cookie FBvisited=yes
   b. System: Expiration = 3600 sec

2. By clicking the Feedback-link on the frontpage, the user is automatically redirected to the refresh page, which sets up a new cookie FeedVisited=yes and then redirects user to the real feedback page (by refresh action in some seconds).

3. On the real Feedback-page the form is not submitted before a function X has checked the values in the cookies. If both values are yes, the form can be submitted.

4. Result: Feedback is not sent if there is no visiting on the frontpage and Feedback-link is not tabbed or clicked in certain order. Spambot likely do not follow the order -> Front page -> Feedback refresh-page. To submit the form, the user have to visit firstly on Front page and then Feedback refresh-page.

Proposal 3:

1. Sets up a cookie visited=yes if user has been visiting on some concept page but the cookie is not set up on feedback page, the feedback page is excluded.

2. On the feedback-page the form is not submitted before a function X has checked the value in the cookie. If value is yes, the form can be submitted.

3. Result: Feedback is not sent if the visiting starts on the feedback page. We can assume that bots direct actions directly in some URL (page like http://finto.fi/fi/feedback).

TO-DO

• Figure out how spambots crawl our feedback form (start it by trying to compare spam emails with Apache logs)
• Based on the results figured out above, design the best possible solution
• Coding... implementing the possible solution
• Test the solution
• Review the solution, if the test succeeded
• Push/PR (with reviewer)

[miguelvaara]

If an action sending the feedback allowed only mouse clicks we could use jQuery to listen mouse click events?

"originalEvent.detail" is true if the button is clicked by the mouse. Bots cannot click the mouse button.

---

<input id="this_does_something" type="button" value="Send feedback">
...
$('#this_does_something').click(function(e) {
  if (e.originalEvent.detail) {
    $(this).val('Clicked by mouse');
  } else {
    $(this).val('Not clicked by mouse!');
  }
});

In addition, also keyboard actions can be listened (eg. if a key is pressed): document.addEventListener('keydown', fn);

Listening the mouse clicks and the pressed keyboard keys together enable an accessible implementation - maybe.

[osma]

My suggestion for some criteria for an acceptable solution:

1. The change should not adversely affect accessibility; it should still be possible to use the feedback form on various types of browsers (desktop, mobile, text-only, text-to-speech) and with different input methods (mouse, keyboard, voice...). Usability should remain on the same level as well.
2. The change should not require storing state information on the server side, for example using session cookies. Skosmos is currently stateless (apart from some preference cookies) and we should keep it that way, because it simplifies the hosting setup a lot.
3. We should not rely on third party services (e.g. reCAPTCHA by Google), as these may have e.g. privacy issues.

I believe the accessibility criterion rules out many of the above proposed changes, for example the recent one related to mouse actions (because it should still be possible to use the feedback form without a mouse).

[miguelvaara]

I agree with you @osma. I think, all the three points you mentioned are valid. In addition to a properly functioning feedback form the points can be considered as minimum requirements.

[miguelvaara]

TO-DO

• Figure out how spambots crawl our feedback form (start it by trying to compare spam emails with Apache logs)
• Based on the results figured out above, design the best possible solution
• Coding... implementing the possible solution
• Test the solution
• Review the solution, if the test succeeded
• Push/PR (with reviewer)

[miguelvaara]

Pull request #1131 (Fix calculation of minimum time in feedback honeypot) and related Pull request #1149 (Avoid sending empty email when invoking the feedback form) hopefully help to fix the problems behind this issue.