You are not logged in.
Pages: 1
Copied from:
http://bbs.archlinux.org/viewtopic.php?t=17304
At the moment, you need to logged on to edit, so these spammers are presumably registering accounts automatically. Therefore, we need to make the registration process tougher. Lots of tricks like those funky randomly generated images containing warped sequencies of letters/numbers. Surely there are a whole load of MediaWiki mods that add anti-spam mechanisms?
When Arch Wiki was immigrated from phpWiki to MediaWiki we thought spamming was blocked when requiring to register. But now they go for registration. I read the suggestions in the other thread and also received few links for anti-spam mods, but currently I don't see other solutions than start moderating new registered users. Anti-spam works only as long as matches a fixed url or word pattern. Easy to go around. But if configured to allow a user to register but approved by admin, same as in phpBB, could be a solution. Only how to identify a genuine user.
If there is no ready made mod, then somebody has to make.
Markku
Offline
Lots of tricks like those funky randomly generated images containing warped sequencies of letters/numbers.
Better solution than having a person having to moderate users.
People wont sign up until they need to edit/add something, and if they have to wait for that to be approved, theres a real chance they wont bother to return.
http://en.wikipedia.org/wiki/CAPTCHA
captchas, as suggested by arooaroo aint perfect, and can be bypassed, but may be enough to deter a majority of the spam. I'm sure theres captcha plugins for mediawiki.
Offline
CAPTCHA is a nice step, though. What would be -really- cool would be something created in interactive 3D. But that would require a plugin and tons of code :-p
However, using CAPTCHA, and perhaps a random authentication question (something simple, which you can find in the wiki) would perhaps be best. IMHO.
Offline
Yes, some type of user/human confirmation is required. Example in Usercb Forum, I noticed lot of spam was posted when configured for the user not to activate a newly registered account. When required, its under control.
How to do in MediaWiki? .... a user confirmation config.
Markku
Offline
And some 3 or 4 people with syslog-status who will be able to immediately delete/block the spammers
Offline
As intermediate solution, i'd like to introduce the Spammers-site in our wiki!
It is a list where everyone is able to list known spammers, and the sysops look at regularly to delete/block the spam accounts, i hope this will enhance spam fighting a bit.
ATM there are 7 accounts to be deleted...
Offline
As intermediate solution, i'd like to introduce the Spammers-site in our wiki!
It is a list where everyone is able to list known spammers, and the sysops look at regularly to delete/block the spam accounts, i hope this will enhance spam fighting a bit.
ATM there are 7 accounts to be deleted...
lets hope the spammers dont start adding genuine users to the spam list...
fck art, lets dance.
Offline
One Question:
Do the wiki admins care for the wiki? At least 1 or 2 may have a look into the wiki once a week... or is that too much?
Right now there are 14 or 15 spam accounts which are partly known since 28th of March on our Spammers site, but NOTHING happens
There are so many motivated people helping reverting the spam, but as it seems, this should not be an intermediate but ultimate solution, right?
Sad....
Offline
Sorry for the negligence.
All are blocked. I added the spammers page URL link under my archlinux link, it will remind me to check daily.
Markku
Offline
While I have removed spam I have noticed that the URL in the spam is repeatable and if it continue to be repeatable then new spam could easy be blocked from being saved with a blacklist.
It doesn't seem that hard to install it according to the documentation.
http://meta.wikimedia.org/wiki/SpamBlac … umentation
Offline
Another possibility would be to limit wiki-pages to 32 KiB... When removing spam I always get this message over my textfield:
WARNING: This page is 54 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.
Would be interesting to see what happens if we limit the "per page" filesize to 32KiB at least...
Offline
Pages: 1