Re: [drupal-devel] Dealing with spam (was rel=nofollow)
All that is good, but introduces another problem: If a spammer knows a filter or a subset of it, it is trivial to write a generator for spam based on the filter.
All that is being shared with the MT blacklist and the custom filters is regexes for domains. Spammers are spamming to promote web sites that sell something/make them money. Yes, they can alias a million domains to one site, so blocking one, and telling them how we block it means they move on to another. Sub-domains are free. But if they keep changing the url they are spamming, it screws their chances of getting a good google rating for it. They are then competing against every surviving post for their old domain. And their competitors. And legitimate sites of interest... If we use a /closed/ domain regex blacklist, then when they swap url each web of trust has to update individualy, and as pointed out, spammers will get onto lots of webs of trust. They'll blacklist their competitors (which actualy works to our advantage ;-)) to boost their chances of success. And work round the filters. If each WOT has to update itself on it's own, it'll take longer to cleanse the net of a new spam url. With a public system like the MT blacklist, one webmaster notices, updates his core site (if it's drupal powered that pushes out to all sites under his control, plus the sites of his friends and colleagues, which push out to...) and notifies the master list. Other sites read the updates regularly and then blacklist it themselves. It's a fast way of rushing a block to everywhere. Speed is the key with this, not privacy. If spammers learn that when they spam a new url, a baysian filter will pick up their spam message, generate a regex, notify a core, which will notify all other sites, which will then block it for the future, and remove it in the past... then url spamming this kind will eventualy die. Pipe dream? Yes, it's a war and the spammers are as resourceful and organised as the CMS/Blog engine developers. They'll find a new way to spam. But with a bit of luck, it won't involve comment/http-referer attacks. Cheers, Mike -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .
All that is good, but introduces another problem: If a spammer knows a filter or a subset of it, it is trivial to write a generator for spam based on the filter.
All that is being shared with the MT blacklist and the custom filters is regexes for domains.
Speed is the key with this, not privacy. Indeed.
If spammers learn that when they spam a new url, a baysian filter will pick up their spam message, generate a regex, notify a core, which will notify all other sites, which will then block it for the future, and remove it in the past... then url spamming this kind will eventualy die. Yes, that is the scenario, what I'm about is that in drupal, wordpress you already have those bayesian filters, so exchanging actual spammy content, rather than just the regex for the url, should and will play an advantage for catching this particular spam, and similar to it.
What I don't like about exchanging hard rules is that you will end up with a unified database of urls, regexes, whatever - there are the other methods as well. Hard rules, means clever peolple will find a way around them - just look at the progress of the email spam fight. Spam's real aim is PR, but not always in a direct way. A lot of spammers are spamming in order to downgrade the PR of their competitors. They are fighting a war of their own. What I suggest is that having diversity of trained agents, regardless of implementation - hardcoded regexes, you typical statistical filter (Bayes, Fisher-Robinson, CRM114, whatever), some yet unknown filter (I'm working on some algorithms as well, a bit of shameless self promotion). This diversity creates uncertainty for what to target, what will not be picked up quickly by the community. If you are to fight it on your own it makes no point - you will loose in the long run due to lack of resources. If you use a communal exchange - then the community overall stands a very good chance. A kind of FUD measures, but this time for the spammers. In the short run the regex exchange is going to work. It is a quick radical measure. Its downside is the downside of every overtrained learning algorithm. It looses precision big time, especialy in an evolving system. It does not adapt well. A brief comparison: regex exchange - surgery; content exchange between learning systems - holistic medicine. I would prefer the second in most of the cases, but surgery still has its valid place for rapid intervention, life saving, etc...
Pipe dream? Yes, it's a war and the spammers are as resourceful and organised as the CMS/Blog engine developers. They'll find a new way to spam. But with a bit of luck, it won't involve comment/http-referer attacks. And as smart, and are fighting this for a longer time.
Cheers, Vlado -- Vladimir Zlatanov <vlado@dikini.net>
These parts are of particular interest to me:
What I don't like about exchanging hard rules is that you will end up with a unified database of urls, regexes, whatever... Hard rules, means clever peolple will find a way around them - just look at the progress of the email spam fight.
In the short run the regex exchange is going to work. Its downside is the downside of every overtrained learning algorithm. It looses precision big time, especialy in an evolving system. It does not adapt well.
A brief comparison: regex exchange - surgery; content exchange between learning systems - holistic medicine.
I was thinking some more about these adaptive filters that learn and the sharing of spam posts/comments between sites. It seems to be like the p2p model would work really well in this case. Just as we had proposed doing a sort of "trusted sites" system where you exchange regexps with your trusted network of sites (which, to my thinking, seems inherently *more* risky than just dealing with spam locally), the way that we could leverage spammers' own behavior would be to syndicate an unpublished feed between trusted sites of ONLY spam content. I mean, that way, if someone taps your "spam feed", who cares?! BUT, if Drupal can tap into Spread Firefox's spam.rss feed, Drupal's learning filters would learn that much faster -- and in real time, because as SFX gets hit, Drupal would have the content from the feed which has been pre-identified as spam. Thus when and if the spammer moves to Drupal, Drupal will be one step ahead of them, having learned from SFX. Thoughts? Chris
Op vrijdag 21 januari 2005 21:39, schreef Chris Messina:
I mean, that way, if someone taps your "spam feed", who cares?! BUT, if Drupal can tap into Spread Firefox's spam.rss feed, Drupal's learning filters would learn that much faster -- and in real time, because as SFX gets hit, Drupal would have the content from the feed which has been pre-identified as spam. Thus when and if the spammer moves to Drupal, Drupal will be one step ahead of them, having learned from SFX.
That was ecactly my concern and idea. I found that on all my sites that were hit by spam (the five sites I maintain) the spam was exactly the same. My most popular of the five was hit first. But the other four had to be learned to handle the *exact same spam messages*. I beleive sites like sfx can me considered as "master brains", since they learn trought a much bigger educating audience, but also becuase they are much more interesting spam targets. I did not thing of spreading things like regexps etc. Merely about tokens etc. Bèr -- Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
That was ecactly my concern and idea. I found that on all my sites that were hit by spam (the five sites I maintain) the spam was exactly the same. My most popular of the five was hit first. But the other four had to be learned to handle the *exact same spam messages*.
I beleive sites like sfx can me considered as "master brains", since they learn trought a much bigger educating audience, but also becuase they are much more interesting spam targets. I did not thing of spreading things like regexps etc. Merely about tokens etc.
I was doing some 'related' work the last couple of days. Granted it is not spam filtering, but it is about learning to classify text. Having a network of trusted RSS/RDF feeds will be great to propagate 'learnable' things, in this particular case spam. It can be even better if we have source tracking, and some content_id, which is unique for the whole network. Think of the chain site 1 RSS feed -> site 2 RSS feed -> site 3 RSS feed -> site 1. Such a network will surely be diverse enough, to confuse a generator, but interconnected enough to be efficient. I was doing some thinking on the Bayesian + regex/custom filter strategy spam.module uses. It would be really good to mod the learning and rating algorithms in order to account for the immediacy of the regex short term, and the effect it has on the learned spam. Does anyone have any statistics on this? Cheers, Vlado -- Vladimir Zlatanov <vlado@dikini.net>
On Mon, 24 Jan 2005 13:08:46 +0000 Vladimir Zlatanov <vlado@dikini.net> wrote: [...]
I was doing some thinking on the Bayesian + regex/custom filter strategy spam.module uses. It would be really good to mod the learning and rating algorithms in order to account for the immediacy of the regex short term, and the effect it has on the learned spam. Does anyone have any statistics on this?
Can you explain what you mean by this? I don't understand what you're proposing. -Jeremy
On Mon, 2005-01-24 at 08:24 -0500, Jeremy Andrews wrote:
On Mon, 24 Jan 2005 13:08:46 +0000 Vladimir Zlatanov <vlado@dikini.net> wrote:
[...]
I was doing some thinking on the Bayesian + regex/custom filter strategy spam.module uses. It would be really good to mod the learning and rating algorithms in order to account for the immediacy of the regex short term, and the effect it has on the learned spam. Does anyone have any statistics on this?
Can you explain what you mean by this? I don't understand what you're proposing. Sorry
facts: Custom filters are immediate - equivalent to true or false. Bayesian filter accumulates evidence What I propose is to ammend the learner by using something like: if the custom filter says BAD and me not this is an error, so I need to learn it. This way the learner will change its behaviour to accomodate the new BAD thing into its statistics. There is a second possible addition to use a simple 'meta'-evaluator, which uses the results of all filters - beayesian and others to judge the content. This way it can change the weight of individual filters with time, so certain filters might expire. Such an evaluator 'theoretically' has the potential to improve the overall model, without adding a significant performance cost. Jeremy, I have a suggestion to change a bit the code of the Baeysian filter, do you want me to post is as a patch/feature or send you an email. It is not ready as a patch at the moment - it is part of that classifier I was mumbling about a month ago, but it might(tm) speed up the evaluation of the spam probability. Can't benchmark it properly at the moment. Cheers, Vlado -- Vladimir Zlatanov <vlado@dikini.net>
Jeremy, I have a suggestion to change a bit the code of the Baeysian filter, do you want me to post is as a patch/feature or send you an email. It is not ready as a patch at the moment - it is part of that classifier I was mumbling about a month ago, but it might(tm) speed up the evaluation of the spam probability. Can't benchmark it properly at the moment.
What the hell, I think it is better to paste the code, it might need more work on it. ==================================== function _naiveBayes($tokens) { $probs = array(); $drift = variable_get('spam_min_drift', 40); $max = variable_get('spam_max_tokens', 40); $num=0; //a rewrite of the original - it should not reduce the quality of the //predictions, while it has the potential to increase speed. Speed //difference depends on the speed of execution of asort() and the //number of interesting tokens considered the added comparison and //evaluation in SQL //$drift - minimal drift from the median - a soft-ish shoulder of the // filter //$max - maximum number of tokens to evaluate, a hard shoulder of the // filter foreach($tokens as $token){ //1. may be beneficial not to include $max or make it larger //2. the sql syntax should be relatively portable to postgres, // but haven't checked the details $result = db_query("SELECT probability FROM {spam_tokens} WHERE token='%s' AND (ABS(50 - probablility) >= %d) AND last >= %d SORT BY (ABS(50 - probability) LIMIT %d)", $token,$drift, $max); while($p=db_fetch_object($result)){ if( $p->probability ) { $p->probability = variable_get('spam_unknown_probability',40); } $probs += $p->probability; $num++; } } $rating = ($probs + $weight) / $num; if ($rating > 99) $rating = 99; else if ($rating < 1) $rating = 1; return $rating; } ======================================= -- Vladimir Zlatanov <vlado@dikini.net>
On Mon, 24 Jan 2005, Vladimir Zlatanov wrote: [...]
facts: Custom filters are immediate - equivalent to true or false. Bayesian filter accumulates evidence
Not a complete fact. There are four possible settings "always spam == true", "usually spam == probably true", "usually not spam == probably false", "never spam == false".
What I propose is to ammend the learner by using something like: if the custom filter says BAD and me not this is an error, so I need to learn it. This way the learner will change its behaviour to accomodate the new BAD thing into its statistics.
This would be simple to do. Certain events could force the filter into TEFT mode for a given spam. ie, if matching "always spam" or "never spam". In particular, I like this as it would auto-train the URL filter. I've given this thought already, and it's one of several improvements I have planned.
There is a second possible addition to use a simple 'meta'-evaluator, which uses the results of all filters - beayesian and others to judge the content. This way it can change the weight of individual filters with time, so certain filters might expire. Such an evaluator 'theoretically' has the potential to improve the overall model, without adding a significant performance cost.
Currently the module simply combines the total of all filter methods, and decided whether or not a given message is spam based on that total. I understand your proposal to adjust a given filter method if it's in disagreement to the overall overage of all filter methods. However, I'm not sure if this is realistic. The filter methods aren't really compatible -- it's perfectly normal for one filter method to suggest a message is not spam, and for anothe rfilter method to suggest it's not spam. (For example, if a message doesn't have any URLs, the URL filter and the URL counter will always say this is probably not spam. That is correct for these filter methods.)
Jeremy, I have a suggestion to change a bit the code of the Baeysian filter, do you want me to post is as a patch/feature or send you an email. It is not ready as a patch at the moment - it is part of that classifier I was mumbling about a month ago, but it might(tm) speed up the evaluation of the spam probability. Can't benchmark it properly at the moment.
The best thing to do is to open an issue in the spam project. I know you have already emailed the idea, but please still open an issue. I will be busy the next few days, and by opening an issue you can be sure I don't forget to look at this... Thanks, -Jeremy
participants (6)
-
Bèr Kessels -
Chris Messina -
Jeremy Andrews -
Jeremy Andrews -
mike＠fuckingbrit.com -
Vladimir Zlatanov