Samizdat - Patches: patch #6000, antispam patch 0.1
You are not allowed to post comments on this tracker with your current authentication level.
patch #6000: antispam patch 0.1
Submitter: | Boud Roukema <boud> | ||
Submitted: | Sun 10 Jun 2007 11:09:00 PM UTC | ||
Category: | None | Priority: | 4 |
Status: | Done | Privacy: | Public |
Assigned to: | None | Open/Closed: | Closed |
Attached Files
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-07-15 | boud | Open/Closed | Open | Closed | |
2007-07-15 | boud | Status | Works For Me | Done | |
2007-06-10 | boud | Attached File | - | Added 070611_antispam-0.1_patch, #13005 |
Powered by Savane 3.13-f8d8.
Corresponding source code
Here's a basic antispam feature.
It involves 5 different files, though most of the work is done
in antispam_helper in order to try to make minimal interference
with other parts of samizdat.
The inspiration is from the twiki BlackListPlugin:
http://twiki.org/cgi-bin/view/Plugins/BlackListPlugin
Since we don't want to track IP numbers, the main part of the
twiki strategy which remains is checking the content of an
article (@content.body in a Message class object) against a
meta-list of wikispam URLs collected by the wiki community,
[but excluding a few of these which seem to be more about
internet evolution (criticism of google and yahoo) than about
real spamming...].
Suspected spam is refused with a SpamError exception through
check_content whenever e.g. someone tries to publish a message
or a reply. A random delay (default up to 120 seconds) is
used to discourage rapid repeated tries (e.g. to find a hole
in the filter).
cheers
boud
POSSIBLE TODOs:
TODO: If the spammer fails to turn off cookies, then suspected
spammers' cookies could be updated to reflect their status.
TODO: Elements to track repeated frequent attempts at spamming.
Problem: distinguish this from an ordinary user's behaviour -
difficult, since a lot of wikispamming is done by dedicated
humans presumably paid to do it.
TODO: Another possible todo would be to put in a
"rel=nofollow" tag to all a href links which have been
modified within the last e.g. 24 hours, meaning that there has
not been enough time for another user (or moderator) to check
the URL. The idea is that people do wikispam with the aim of
getting high google rank. Google in principle accepts the
nofollow tag (AFAIK it introduced it...?). So if links to
a particular website or family of websites or websites running
a particular software package systematically fail to contribute
to google rank even when they are wikispammed, then the spammers
will prioritise other, less well protected sites.
Counterarguments: Not all samizdat messages are open for editing;
this adds an extra complication to rendering messages including
a dependence on their last modification time, not just their
content; many search engines ignore nofollow tags; it weakens
the webbed nature of the web.
Note: mediawiki (or at least the wikipedia instance of it)
does something like this.
QUESTIONS:
Do we want to warn the suspected spammer or not? In this
version (0.1), the user is warned, but after a delay.
BlackListPlugin warns the user in some cases, and in other
cases gives no indication what type of error occurred.
Giving a generic user error message would give less info
to spammers and avoid helping them "improve" their sabotage
of the internet, but it would also make it harder for
genuine users who accidentally get classified as spammers
to warn the sysadmin and samizdat developers.
MORE INFO:
http://moinmoin.wikiwikiweb.de/AntiSpamGlobalSolution
http://en.wikipedia.org/wiki/Spamdexing