MediaSpace Wiki

Wiki Spam

These site (MediaSpaceWiki) does not support, and will aggressively delete, any content that the owner deems to be spam. There are a variety of forms of Wiki Spam (see some of the references below for more detail), but the most common form of such spam takes the form of advertisements for other web sites that have no relationship to the editorial purpose of the wiki. Wiki Spam is a form of site vandalism (see SiteVandal) that will not be tolerated here. Frankly, while I would prefer not to do so, I will secure the site for posting with a password before I give in to the Internet criminal element that has been attempting to increase the Google rank of sites by posting pointers here.

Good discussions of WikiSpam and strategies to counter it can be found at the following sites:

• http://www.c2.com/cgi/wiki?WikiSpam This page is notable primarily because it is on the original Portland Pattern Repository (e.e. Ward's Wiki). Most useful discussion occurs elsewhere. This is pretty much as it should be, as c2 has a different editorial purpose. One notes, however, that the discussions of the generalized strategies for fighting Wiki Spam are particularly well described here. See, in particular, the page http://www.c2.com/cgi/wiki?WikiSpamSolutions.
• http://wiki.chongqed.org/WikiForum is a particularly aggressive anti-wikispam site that is taking the war back at the spammers by working to lower the page rankings associated with the sites associated with Wiki Spam pointers. Possibly the best site to go to for the latest information on Wiki Spamming technology.
• http://www.usemod.com/cgi-bin/mb.pl?WikiSpam, on another classic original wiki, Meat Ball Wiki, is another source for agressive tactics in fighting WikiSpam.
• http://openwiki.com/ow.asp?WikiSpam provides an overview of some of the simpler methods of fighting wiki spam. Most, from what I've seen this week, are easily handled by a spammer who is willing to bring a human into the equation.

The MediaSpaceWiki approach to Wiki Spam has been evolving and continues to evolve (WikiSpamBlockProblems).

1. The Spam problem started out slowly. I was generally satisfied to delete spam as it appeared until early 2004, when a particularly obnoxious spammer started throwing lots of X-Rated and Commercial Spam at this site.
2. The next approach, implemented at that time and systematically tuned since, has been to block problem Internet addresses. Early this year I supplemented that approach with the addition of SaveHistory, which both made it much easier to track down problem addresses and to keep track of borderline offenders. Address blocking is admittedly a blunt instrument approach, but it was effective until July, 2005, when the same spammer who raised the bar in early 2004 raised the bar again by implementing an array of spam robots on a broad variety of machines.
   • Posts on http://wiki.chongqed.org/WikiForum claim that this spammer has managed an IE scripting exploit that allows the spammer to use the browser of someone who accesses one of his sites to run the robot. This seems like a reasonable explanation at one level: the spammer appears to be able to add new addresses several times a day, often from very different pools and sometimes from machines that appear to be tucked behind secure corporate firewalls. There are two holes in this argument. First, I've seen evidence of other browsers, including Opera, being exploited. Second, he appears to be able to reuse addresses for long periods of time, which is inconsistent with normal browsing behavior.
   • Another possible approach is robot setup via an Internet virus or worm, perhaps even through purchase of clients from a successful cracker.
   • A third explanation, which in some ways fits the evidence better, is that the robot is running on purchased resources and is capable of periodically asking the local network to change its IP.
   • A fourth explanation, which is less likely, but possible, is that the spammer has obtained or built hardware that allows spoofing of the physical Internet address.
3. Regardless of approach, address blocking is no longer a satisfactory solution. Without going into the details of the rules, which are still evolving, I have now implemented a rule based content blocker that decides whether or not it should accept content based on its content attributes. Such implementations are not new to me (see the chapter on Rules Enforcement in computer conferencing in my doctoral dissertation (http://evolutionarymedia.com/mediumAsProcess). Since that code has gone into force, address blocking has proved unnecessary and I have since removed address based-blocks (to put that in perspective, the address-based blocking has only been invoked sixteen times in 18 months since the rules went into place.
   • I currently use three classes of rules:
     1. URL-based rules that block posting of obviously commercial content. These rules are currently very simple and can be readily enhanced if there is a need.
     2. Address-consistency rules that capitalize on inconsistencies in addressing that are commonplace when robot attacks are made. These rules have the potential to block posts from machines in badly set up DHCP-environments, but the only posts that I've seen from such spaces (usually colleges optimizing costs against service) have been my own. I have designed a solution for handling this problem which I may implement even if it remains only my problem (if only for the convenience to myself).
     3. Blocking of posts to files that are commonly targeted. This is the latest enhancement to the rules and has yet to actually fire except under test conditions. I'm sure it will, however, and sooner rather than later.
4. We continue to look for patterns in WikiSpam (see WikiSpamVariations for the patterns that I'm willing to talk about publically).