-----Original Message-----
From: openguides-dev-bounces(a)openguides.org
[mailto:openguides-dev-bounces@openguides.org]On Behalf Of
Earle Martin
Sent: 25 June 2004 09:09
To: openguides-dev(a)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.