[pmwiki-users] An possible anti-spam measure

Patrick R. Michaud pmichaud at pobox.com
Wed Jun 7 11:31:38 CDT 2006


On Tue, Jun 06, 2006 at 07:13:35PM -0400, David Spitzley wrote:
> I just had a strange thought regarding wikispam, which I'm still 
> periodically having to scrape off my site even with SiteBlock3 
> running.  [...]
> One thought that occurs to me is that through a bit of razzle-dazzle 
> it might be possible to use the Author Required feature to block them.  
> What if PmWiki 
> * sent several different author fields with different values for the "name" property
> * assigned each author field different CSS classes, all but one of which had their "display" value set to "none"
> * only accepted input from the one visible field, and only if none of the others were filled in?

Intriguing idea.  But ultimately I'm not sure it's going to work...let's
explore a bit.

First, if we use Author Required as a means of filtering spam, that means
that PmWiki can no longer automatically fill in the "Author" field on the
form -- an author would have to manually fill it in on each edit.  Most
authors would be really annoyed by this, and it goes directly against
PmWikiPhilosophy #1.

So, instead of having to fill in the author field, what if we simply
provided three checkboxes, two of which are hidden by css, and request 
that the author check the visible box before pressing 'Save'.  That's
not too onerous.  Even better, we could send three "Save" buttons,
where the visible one works and the invisible ones don't do anything.
(Or, perhaps the invisible ones flag the IP as being a spambot -- more
on this possibility in a bit.)

So, this is nice in that a human author naturally sees and does the
right thing, but a spambot has to either figure out which button is the
visible one, or simply pick one at random and hope it works.  

Since spambots already expect to be blocked most of the time, the
"pick one at random" approach isn't a significant challenge or barrier
to them.  Even if the spambot guesses the correct button only one time
out of ten, that's good enough for the spammer.

However, if there's a penalty for guessing wrong, such as the
IP is automatically added to the blocklist, then the guessing strategy
for the spambot is much less effective, because the first incorrect
guess blocks all of the later correct ones.  And it's very unlikely
that a human will inadvertently hit one of the bogus save buttons,
since they're invisible.

However, it's not all that hard for a spambot to figure out which
button is the correct one.  The "display:none" property has to be
held *somewhere* in the document or a CSS file in order for the
browser to render it correctly, and it's not difficult for
a spambot to look at the available controls and figure out which
one doesn't have the display:none property (or whatever unique
property we set that causes one button to be visibly different
from the others).  After all, if a browser can do it, so can
a spambot.

So ultimately, I think that using CSS as an obscuration technique
just means that the spambots will evolve to figure out CSS
(if they haven't done so already).  Still, it might be
worthwhile to implement an approach like this one just to
weed out the less-sophisticated bots.

And, as you mentioned, we have to be careful about accessibility
issues; not everyone uses a graphical browser to submit content,
so we'd like to have some mechanism to make it easy to use the
"straightforward" approach when the situation warrants.  I'm
thinking about whitelisted addresses--i.e., a way to say that
"any post from x.y.z address or from an authenticated author
is allowed regardless of content."

> On a different front, does anybody have a quick way to block 
> based on an Author Name, rather than on the post content?  I've 
> got a bot by the name of Nick that drops by every few weeks 
> with a new set of addresses that bypass my filter; his 
> IP address is variable, of course...

    include_once('scripts/author.php');
    if ($Author == 'Nick') $EnablePost = 0;

Pm




More information about the pmwiki-users mailing list