-----Original Message----- From: openguides-dev-bounces@openguides.org [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Earle Martin Sent: 25 June 2004 09:09 To: openguides-dev@openguides.org Subject: [OpenGuides-Dev] Spam, node history and recent changes

I see london.og has had some spam put on it (thanks Kake and Ivor for undoing the damage). I just made myself look a muppet by forgetting how our front-page recent changes box works and trying to commit a page change with a different summary so the spam wouldn't appear on the front page - only, of course, that didn't work because the listing doesn't collapse multiple occurrences of the same node.

This is a problem, because it means spammers can attack any page and be _guaranteed_ to be on the site's front page for a while, until they've been pushed off the bottom of the list.

So, can I propose that on the _front_ page, we collapse multiple occurrences of any single node so that only the most recent change is listed? This would probably necessitate a slight phrasing change to "ten most recently changed pages".

Agreed we should compress multiple changes to the same page. After all, people only get to see ten of them.

While we are at it, I think we should also filter out "null edits" (and not saving them). As it is, we do see plenty of null edits appearing in RecentChanges, on the front page, and in change histories of individual pages.

Regarding suppressing pages appearing on the front page, I suggest that we provide the facility to make the "change type" of a particular version editable after the event. That way, we can change unwanted edits to "minor tidying".

Also, it's been pointed out (on http://www.usemod.com/cgi-bin/mb.pl?WikiSpam ) that once the spammer makes a modification, it stays in the page history forever, and thus stays accessible to search engines, justifying the attack in the first place. There are two ways to combat this, I think: (a) make history pages not available to search engines (which I think should be the case anyway, because they contain mistakes and other crud - so I'll make this happen), and (b) let site administrators delete particular _versions_ of a page, perhaps just by replacing the content with "deleted", rather than actually removing it - that way it could show up on the page history as "(deleted)" or some such.

(a) I agree totally.

(b) We want perhaps to make this a soft delete, or archive the dead text somewhere else in case we need it for legal reasons.