Moodle

Preventing spam in user profile descriptions

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.9.4, 2.0
  • Fix Version/s: STABLE backlog
  • Component/s: Administration
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE, MOODLE_20_STABLE

Description

Reading the 'Moodle Security' discussion (http://moodle.org/mod/forum/discuss.php?d=109366) I got an idea how to prevent spam entries in user profile descriptions.

Whats the problems? Spammer and perhaps sometimes students add advertising or banned words in their profiles. This is a problem for open systems. We have a partial solution for this if we hide the profiles for not logged in guys. This makes it uninteresting for most spammer. But it will be a problem for other users if they see this entries.

We have a solution with the censorship filter. Here we can add words that are hidden by a filter. But we don't have a system to fill up the list automatically. On the other side the use of this filter needs to much resources if it works on every page.

My idea is the following:

  • A new type of filter checks automatically each new or changed entry in a description field of a user profile against a blacklist of banned words. Is a list entry found the admin gets an information via mail. The check can be done while saving the entry or daily by a cron job. An alternative is a manually check started by the admin. Perhaps it is simple search in the DB table.
  • If an admin see a problematic word he can add it to a list of censored words and can report it to a central blacklist. B2evolution ( a multiblog system) does this (http://manual.b2evolution.net/Antispam_tab#First_always_keep_your_antispam_table_up_to_date.).
  • Admins can enable/disable /create a individual blacklist, manually updated from the central blacklist or automatical updated from the central blacklist on a daily or weekly base.
  • Perhaps we need an additional option to define which fields should be searched.

Issue Links

This issue is duplicated by:
MDL-12738 Html code can be included in the description field of the profile allowing link to other sites and providing extensive opportunities for abuse Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ralf Hilgenstock added a comment -

Comment from atwyatt (via mail):

[...]
As you say, perhaps the tracker discussion is the more important when it comes to actually fashioning a solution.

I am, however, interested in your take on how far a partner should go to help a client deal with spam defacement. I think it is a legitimate question for prospective clients, and one that many of us (myself included) would take for granted. This would cause hard feelings on both sides!

With regard to the censorship filter, I quit using it after about 1 day. It was marking all kinds of partial words in black, even parts of words that had nothing to do with the "censored" word. I think that the dictionary and the recognition algorithm was not sophisticated enough (that was back with moodle 1.5).

Also, the censorship might need to be restricted to certain modules. For example, some might want it only on the profiles and not anywhere else on the system (we would probably choose that, since we are a university). Admins should be able to choose this, I think.

I also think it would be good for this filter to check for multiple links. Like on wordpress; you can set a maximum number of links (2 or 3) after which is is flagged as suspicious. I believe wordpress also flags a large amount of text as suspicious. However, in both cases, the owner of the wordpress blog can moderate the comment. If we did have something like this, I would like admins to have the ability to selectively release or delete. And this kind of user should be permanently deleted and all associated data expunged. Shouldn't be hard, since they (so far as I can tell) don't post anywhere except the profile.

I am sure there is much more that I haven't thought about. We don't have an external spam problem since we lock down our system to batch created accounts. However, we COULD have a profile problem among our users. Therefore, I would like to see some tools to alert admins that there might be a problem. The more automated the identification is the better, but we need selective delete control.

[...]

Show
Ralf Hilgenstock added a comment - Comment from atwyatt (via mail): [...] As you say, perhaps the tracker discussion is the more important when it comes to actually fashioning a solution. I am, however, interested in your take on how far a partner should go to help a client deal with spam defacement. I think it is a legitimate question for prospective clients, and one that many of us (myself included) would take for granted. This would cause hard feelings on both sides! With regard to the censorship filter, I quit using it after about 1 day. It was marking all kinds of partial words in black, even parts of words that had nothing to do with the "censored" word. I think that the dictionary and the recognition algorithm was not sophisticated enough (that was back with moodle 1.5). Also, the censorship might need to be restricted to certain modules. For example, some might want it only on the profiles and not anywhere else on the system (we would probably choose that, since we are a university). Admins should be able to choose this, I think. I also think it would be good for this filter to check for multiple links. Like on wordpress; you can set a maximum number of links (2 or 3) after which is is flagged as suspicious. I believe wordpress also flags a large amount of text as suspicious. However, in both cases, the owner of the wordpress blog can moderate the comment. If we did have something like this, I would like admins to have the ability to selectively release or delete. And this kind of user should be permanently deleted and all associated data expunged. Shouldn't be hard, since they (so far as I can tell) don't post anywhere except the profile. I am sure there is much more that I haven't thought about. We don't have an external spam problem since we lock down our system to batch created accounts. However, we COULD have a profile problem among our users. Therefore, I would like to see some tools to alert admins that there might be a problem. The more automated the identification is the better, but we need selective delete control. [...]
Hide
Permalink
Martin Dougiamas added a comment - - edited

Eloy had an elegant idea which I think was based on another idea that Wyatt posted in the forums, which I can sum up like this:

When showing the profile page, if a courseid isn't defined (this is the public view) and the current user is not enrolled in any courses then replace the profile description with something like "This profile description will not be shown until this person is enrolled in at least one course". Going further we could completely hide that field from the editing page using the same criteria to prevent people even entering in a description in the first place (while the current description is still blank).

The whole thing could be controlled by a new admin config variable that defaults to being activated.

Filtering would still be required for some sites (like moodle.org) so let's keep talking about those solutions, but this simple idea would certainly help keep spamming off sites with closed courses.

I added it as a subtask for separate discussion: MDL-17143

Show
Martin Dougiamas added a comment - - edited Eloy had an elegant idea which I think was based on another idea that Wyatt posted in the forums, which I can sum up like this: When showing the profile page, if a courseid isn't defined (this is the public view) and the current user is not enrolled in any courses then replace the profile description with something like "This profile description will not be shown until this person is enrolled in at least one course". Going further we could completely hide that field from the editing page using the same criteria to prevent people even entering in a description in the first place (while the current description is still blank). The whole thing could be controlled by a new admin config variable that defaults to being activated. Filtering would still be required for some sites (like moodle.org) so let's keep talking about those solutions, but this simple idea would certainly help keep spamming off sites with closed courses. I added it as a subtask for separate discussion: MDL-17143
Hide
Permalink
Eloy Lafuente (stronk7) added a comment -

Asigning this "meta" bug about anti-spam measures to Petr... so he'll be able to document it in security forum and so on once all subtasks are closed.

Ciao

Show
Eloy Lafuente (stronk7) added a comment - Asigning this "meta" bug about anti-spam measures to Petr... so he'll be able to document it in security forum and so on once all subtasks are closed. Ciao

People

Vote (4)
Watch (3)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.