Matijs Erisson:

Malcolm Wallace writes:

...

...

...

... And avoid getting screwed up by malicious folk?

... but I believe there are a number of people who regularly review all the "Recent Changes" and undertake to 'undo' any malicious/inaccurate modifications.

I suspect this would end up adding /more/ work to central maintainers, rather than less.

Recently the Haskell Wiki went from anonymous edits to logged-in edits because of the tremendous amount of wikispam, so I agree with this. On the good side, it's easy to create an account.

I don't think restricting editing to registered users is a significant turn off if registration is simple.

On the bad side, at some point spambots will notice this too.

We can use the same techniques that web sites like slashdot.org use to prevent bots from registering accounts. Manuel

The public comment/wiki spam problem is easily solved. Use JavaScript to generate a value and put it in a hidden form field. Check for that value server side, if it's there then allow the post otherwise disallow. Most if not all bots don't have JavaScript engines. On 16/11/2005, at 10:15 PM, Neil Mitchell wrote:

...

I don't think restricting editing to registered users is a significant turn off if registration is simple.

It really really is a turn off. Sometimes when I spot a mistake, and I'm at a computer where I haven't logged in to hawiki, I don't bother fixing it. No one wants to have yet another account, to fill in their personal details yet again.

I appreciate spam is a problem, but turning off unregistered users is a trade off - less content, less spam, less open to people joining - its not a free solution.

Thanks

Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 16-nov-2005, at 13:14, Wolfgang Jeltsch wrote:

Am Mittwoch, 16. November 2005 12:33 schrieb Scott Weeks:

...

The public comment/wiki spam problem is easily solved.

Use JavaScript to generate a value and put it in a hidden form field. Check for that value server side, if it's there then allow the post otherwise disallow.

Most if not all bots don't have JavaScript engines.

But not all users use JavaScript.

A nicer solution might be to have the server generate a distorted image of a key (as is done with user registration to combat automated user generation) that should be typed in for an edit to be accepted (if you are not logged in). Doei, Arthur. /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching

On 16/11/05, Philippa Cowderoy wrote:

On Wed, 16 Nov 2005, Arthur van Leeuwen wrote:

...

A nicer solution might be to have the server generate a distorted image of a key (as is done with user registration to combat automated user generation) that should be typed in for an edit to be accepted (if you are not logged in).

This comes with accessibility issues, much as any other text represented by images, only more so as the whole point is to fool OCR software.

Surely we wouldn't use captchas on edits by registered users, so there'd still be a way for those users with vision problems to make edits, they'd just have to log in. If people want to use captchas as part of the process in signing up for an account, then there should be an alternate mechanism for people with accessibility issues. I wonder how well an audio version of the captcha test would work -- one could probably rig up festival to generate sounds of words linked alongside the distorted picture which blind users could listen to and type into the field. It's unfortunate, but if you don't put a little bit of effort into defending your forms, they will eventually get quite a lot of spam. Cleaning up 600+ pages by hand takes quite a lot of effort, even with the ability to revert. Mass reverting would be another way to try to deal with it. Another way to raise the bar a bit perhaps would be to randomise the names of the form controls slightly, so that a spambot couldn't just use the same names for things every time, it would have to properly load the page and scrape the names out. - Cale

On 18/11/05, Wolfgang Jeltsch wrote:

Am Mittwoch, 16. November 2005 20:02 schrieb Cale Gibbard:

...

[...]

...

It's unfortunate, but if you don't put a little bit of effort into defending your forms, they will eventually get quite a lot of spam. Cleaning up 600+ pages by hand takes quite a lot of effort, even with the ability to revert.

Is the wiki spam problem really that big? If yes, I would really wonder how Wikipedia deals with it. Since I have never come across a spammed Wikipedia article, it's hard for me to imagine that wiki spam is such a big problem.

Wikipedia has a page just to keep track of where the vandalism is currently happening. See: http://en.wikipedia.org/wiki/Vandalism_in_progress There's a ridiculous amount of vandalism going on at any one time, it's just that the wiki is so huge that it's only a tiny fraction of the content, and it has so many users that things move quickly. Yes, HaWiki has been hit several times now with large spamming runs, often where nearly every page got hit. Normally someone who is watching with permissions to do so will edit LocalBadContent and put a stop to it, and clean things up, but it's not uncommon to have to clean 100 pages, and when I got home one day, every page on the wiki had been spammed (700+), and some of them twice, once by a different spammer. This sort of thing is what prompted making all the pages immutable to users not logged in.

...

[...]

...

Another way to raise the bar a bit perhaps would be to randomise the names of the form controls slightly, so that a spambot couldn't just use the same names for things every time, it would have to properly load the page and scrape the names out.

This would mean modifying the wiki software, right? This in turn would cause problems with, for example, security updates.

Perhaps the changes could be made upstream. Also, if people are considering writing wiki software in Haskell, it's something to take into account. - Cale

Neil Mitchell writes:

It really really is a turn off. Sometimes when I spot a mistake, and I'm at a computer where I haven't logged in to hawiki, I don't bother fixing it. No one wants to have yet another account, to fill in their personal details yet again.

I appreciate spam is a problem, but turning off unregistered users is a trade off - less content, less spam, less open to people joining - its not a free solution.

Yeah, I see your point. The problem was that each automated spam change had to be manually undone. The latest unreleased version of MoinMoin has batch undo features for just this reason, I'll see if I can install it onto haskell.org Assuming I get it installed, I'll give batch-undo privileges to the most active wiki users. Up till now Cale Gibbard, Thomas Jaeger, and I have done most of the boring spam removal work. I probably won't have time to do this before the weekend though. -- Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said: You could switch out the unicycles for badgers, and the game would be the same.