BuddyPress.org

Well! “SI CAPTCHA Anti-Spam” not really works. Spammers registration keep coming. The number of a day has been reduced but still can’t stop them. I assume the spammer bots may smart enough to OCR the words in CAPTCHA or could listen to the audio assist then they could generate a correct input to pass the registration. So I set CAPTCHA to “high” level and uncheck the audio option. The last 24 hours I got 10 spam registers. I wonder if a plug-in can spell check the field input may help eliminate most of these spammers.

Yeah! I believe they are spam accounts. They are keep coming from all over the world. I have just install plugin “SI CAPTCHA Anti-Spam” on all three wpmu web sites. It should stops the spam bots if you are not “human”….lol. Thanks all you guys!

@r-a-y Thanks for that! Getting some errors.

This shows in the admin

Warning: Invalid argument supplied for foreach() in /home/me/public_html/mysite/wp-content/plugins/cubepoints-buddypress-integration/cubepointsBP.php on line 74

This shows on the front end when I go to the activity page

Warning: Invalid argument supplied for foreach() in /home/me/public_html/mysite/wp-content/plugins/cubepoints-buddypress-integration/cubepointsBP.php on line 74

Line 74 is:
foreach ( $bpcpspamlist as $spammer_id ) {

This is what I put in.

http://pastebin.com/5qDXuCvv

@r-a-y This is what I came up with and the echo prints out this “Banned Users: Array” am I even close? lol

function my_bp_update_post_add_cppoints() {
global $bp;
$bpcpspam = array($bpcpspamlist);

$getspamlist = get_option( ‘bp_spammer_cp_bp’ );
$bpcpspamlist = explode(“,”, $getspamlist);

echo(‘Banned Users: ‘ . $bpcpspamlist . “
“);

if ($bp->loggedin_user->id != get_option( ‘bp_spammer_cp_bp’ ) ) {
foreach ($bpcpspam as $bpcpspamlist) {
if( function_exists(‘cp_alterPoints’) ){
cp_alterPoints($bp->loggedin_user->id, get_option(‘bp_update_post_add_cp_bp’) );
cp_log(‘Comment’, $bp->loggedin_user->id, get_option(‘bp_update_post_add_cp_bp’), BuddyPress);
}
}
}
}
add_action(‘bp_activity_posted_update’,’my_bp_update_post_add_cppoints’);

@thekmen @r-a-y

Tried going about this another way. Still not working correctly. Says user id 59 is not a spammer, but that user is marked as so. Any ideas?

I tried to echo it out. Nothing comes out for the user id ..
echo(‘User ID: ‘ . $bp->loggedin_user->id . “n”);

/* *********************** START Spammmer! ********************************* */
global $bp;
// 59 for testing
// if( $bp->loggedin_user->id == get_option(‘bp_spammer_cp_bp’)){

global $current_user;
global $user_id;

if ($userinfo->ID == 59) {

function my_bp_update_post_add_cppoints() {
if( function_exists(‘cp_alterPoints’) && is_user_logged_in() ){
cp_alterPoints(cp_currentUser(), 0 );
cp_log(‘Comment’, cp_currentUser(), 0, BuddyPress);
echo ‘spammer
‘;
echo(‘User ID: ‘ . $user_info->ID . “n”);
}
}
add_action(‘bp_activity_posted_update’,’my_bp_update_post_add_cppoints’);

} else {

// Add Points for a update
function my_bp_update_post_add_cppoints() {
if( function_exists(‘cp_alterPoints’) && is_user_logged_in() ){
cp_alterPoints(cp_currentUser(), get_option(‘bp_update_post_add_cp_bp’) );
cp_log(‘Comment’, cp_currentUser(), get_option(‘bp_update_post_add_cp_bp’), BuddyPress);
echo ‘spam free
‘;
echo(‘User ID: ‘ . $user_info->ID . “n”);
}
}
add_action(‘bp_activity_posted_update’,’my_bp_update_post_add_cppoints’);

}
/* *********************** END Spammmer! ********************************* */

@r-a-y

I tried this as well. Not the desired outcome.

if ( !$no_grav ) {

Went back to this, because I’m sure I am getting closer .. When I test this with an account has an existing avatar, it still gives me points.

// Avatar Anti-Spam
global $bp;
$avatar_dir = ‘avatars’;
$avatar_dir = apply_filters( ‘bp_core_avatar_dir’, $avatar_dir, $object );
$item_id = $bp->displayed_user->id;
$object = ‘user’;

$avatar_folder_url = apply_filters( ‘bp_core_avatar_folder_url’, str_replace( WP_CONTENT_DIR, BP_AVATAR_URL, BP_AVATAR_UPLOAD_PATH ) . ‘/’ . $avatar_dir . ‘/’ . $item_id, $item_id, $object, $avatar_dir );
$avatar_folder_dir = apply_filters( ‘bp_core_avatar_folder_dir’, BP_AVATAR_UPLOAD_PATH . ‘/’ . $avatar_dir . ‘/’ . $item_id, $item_id, $object, $avatar_dir );

if ( file_exists( $avatar_folder_dir ) ) {
// Avatar has been upload so zero points

// ZERO Points for Avatar Upload if they already uploaded at least 1
function my_bp_avatar_add_cppoints() {
if( function_exists(‘cp_alterPoints’) && is_user_logged_in() ){
cp_alterPoints(cp_currentUser(), 0 );
cp_log(‘Avatar Uploaded’, cp_currentUser(), 0, BuddyPress);
echo ‘zero points’;
}
}
add_action(‘xprofile_avatar_uploaded’,’my_bp_avatar_add_cppoints’);

} else {

// Add Points Avatar Upload
function my_bp_avatar_add_cppoints() {
if( function_exists(‘cp_alterPoints’) && is_user_logged_in() ){
//cp_alterPoints(cp_currentUser(), get_option(‘bp_avatar_spam_add_cp_bp’) );
cp_alterPoints(cp_currentUser(), get_option(‘bp_avatar_add_cp_bp’) );
cp_log(‘Avatar Uploaded’, cp_currentUser(), get_option(‘bp_avatar_add_cp_bp’), BuddyPress);
echo ‘add points’;
}
}
add_action(‘xprofile_avatar_uploaded’,’my_bp_avatar_add_cppoints’);

}

My great worry these days is that the dev community is being compelled to fix problems with usability of core BP, as much or more so than extending what’s there.)

And which is one of my concerns too, and is evident in many posts on this site with developers rushing out fixes to usernames for example as is perceived as being a problem highlighted by one person.

What worries me is that moving forward in this manner is not necessarily the best approach to developing a rock solid core app as you have perceived issues being dealt with in a slightly haphazard manner and the setting up or configuring of BP dependent on finding many and various disparate third party snippets of code.

I’m sure Andy&co are focused too an extent on fixing problems but also it may well be a case that ‘Problems’ are not necessarily perceived as problems- part of the reason I thought that this thread was a necessity; to try and flesh out what were considered existing UI/design flaws and provide that as good solid feedback to work from. I note that in the ‘roadmap’ it states that there are periods of consultation? to garner feedback for version features, I would like to see that process in action and to see developers helping guide these future releases; as I agree that it’s now not simply about adding ‘Features’ but far more importantly on providing a core that works and that developers may extend upon.

It feels as though BP is reaching a momentous milestone or crux point in it’s development, and that perhaps the core dev team ought to take a breather, take time out and review what is right and what is wrong and that needs addressing. Foxly made the point well in his ‘ spammers are coming'(sic) thread discussing his suggested approach to tackling the spam issues surrounding BP where he asserts that BP is reaching this crux point where if it wants to grow from simply a “Science project for hobbyist sites” to a fully mature app that can serve business / enterprise it has to tackle certain issues and is why he considers taking some time to tackle this issue he sees with spam is of paramount importance. I would not disagree with Foxly for one moment and what he has reported on thus far on the issue is commendable but I do not think a developer should be tackling this, taking time out from working on hugely useful ‘Feature’ plugins to work on something that – if is agreed to be an issue that must be dealt with – is essentially a core development issue and really ought to be handled by the core development team not by a third party developer (Obviously this is not to say it won’t be as things are in early stages and speculative at this point)

So, yes extending must slow down for a while and issues of a UI / design nature must be thrust to the fore and I would hope there is a means of collating some of the very apposite and useful comments and suggestions that have appeared so far in this thread.

I think, overall, the core devs have approached BP development in the most effective order possible.

There really isn’t much point in adding spam protection to a platform nobody uses, and nobody would be using BP if the core developers had spent the past two years hardening it with spam protection instead of adding member-centric features.

But we’ve hit “critical mass” now …and we have to deal with the spam problem before BP is ready to move from a science experiment people use on hobby sites to a “platform” that developers can use for serious commercial endeavors. And I’m willing to throw a sizable chunk of dev time at it to help make that happen.

Anyhow, at this point I’ve written the first draft of the proposed changes to the forum, and what I need now is everyone to read through it and post their feedback.

Seriously.

Because if something in the proposal doesn’t work for your application …or you can think of a better way to do it… you’d better get a post up NOW before we start writing code.

Thanks!

^F^

PART 3 – STRONG -vs- WEAK METHODS

When it comes to spam on BP sites, you’ll see all sorts of stuff posted on blogs saying “change [whatever] on your site and your spam problem will disappear”.

Truthfully, a lot of these tricks will actually work …for a while… but eventually, the spammer makes a minor change to their bot, and they’re back in business. In fact, many of the leading blog spamming packages include sophisticated logging features to catch the errors that “uniquely configured” blogs generate and help the spammer quickly fix the “problem”.

If we’re going to have a reliable anti-spam solution for BuddyPress, we should probably focus on “Mathematically Strong” methods, not on “Obfuscation” and “Moving Things Around”. That way, we won’t have to constantly change our spam protection methods.

Changing Page Slugs

Many people recommend changing the page slugs on BP installations to reduce spam. While this is certainly easy to do, you of course need to give your users *links* to those page slugs somewhere on your site so they can actually visit the pages. And if users can follow the links, so can a spam bot.

Changing page slugs is kind of like boarding-up the front door of your house, installing a new door in the side of your house, and then attaching a piece of string from the front door to the side door of so everyone can find the new door.

The “change your page slugs” approach seems to come from the “change your admin menu URL” technique. Changing your admin menu URL is actually a *strong* protection technique. Since there is no link to it anywhere on the site and you’re the only one that knows the URL, it’s like having two passwords on your admin login. An attacker would have to try billions of URL’s to find it.

Not so with all the other URL’s on your site. They have to be linked off other pages so your users can find them.

Adding Fake Form Fields

Many people recommend adding a few extra fields to forms throughout your site (sign-up, login, post to group, etc) and “hiding” these fields using CSS. If any of the “trap” fields are filled out, in theory, you’ve just detected a bot, because a normal user would never see the fields and fill them out.

This approach *might* defeat a very simple bot that searches every web page it can find for forms, and fills every field in every form with random spam; but it will not defeat a bot that understands CSS or is specifically targeted at BuddyPress, especially considering that BuddyPress is *open source*.

Don’t think bots can analyze CSS? Read this: http://www.google.com/support/webmasters/bin/answer.py?answer=66353

A bot designer can simply read through the BP source code and discover the names of the fields that should be filled in and the names of the fields that should be left empty.

To use our “house” analogy, adding extra form fields is like installing 3 front doors on your house and rigging two of them with grenades …then hanging a big red “out of order” sign on the the two rigged doors so your friends don’t use them.

Obviously if your friends can read the signs, so can your enemies.

JavaScript Proof of Work

Javascript proof of work (Wp Hashcash) defeats spammers by making visitor’s web browsers solve a math problem in JavaScript before they are allowed to post.

Because everyone knows spam bots can’t run JavaScript.

http://forums.digitalpoint.com/showthread.php?t=1124949
http://www.scrapebox.com/
http://blogcommentdemon.com/
http://www.senuke.com
http://www.botmasternet.com/more1/

Except when they can.

There’s also the issue of what to do with visitors that don’t have JavaScript enabled.

The WordPress and BuddyPress development teams have put an epic amount of work into ensuring both platforms will work reliably when JavaScript isn’t available. Requiring users to have JavaScript to post any kind of content to the site nullifies much of this work.

Proof-of-work was a great idea back in 1997 when spammers ran hundreds of attack threads from a single server and solving the JavaScript math problems slowed it to a crawl.

In 1997, we’d be dealing with a single spammer running 1000 attack threads against the site. Because the spammer was running 1000 threads, each of which would have to solve the JavaScript problem, they would effectively be penalized 1000 fold over a normal user. The end result is they would only be able to run a few threads before their computer slowed to a crawl and their spamming abilities would be sharply limited.

Epic win for site.

Unfortunately, things are different in 2010.

Spam bots have become the tool of choice for basement SEO marketers. Instead of a few members of the “spam elite”, we’re dealing with tens of thousands of “do it yourself” spammers each running 1 attack thread using the new “automatic backlink software” they just picked up for $29.00 off some random SEO website. Instead of fighting one spammer splitting their resources across a thousand threads, we’re fighting a thousand spammers running a single thread dedicated *just to our site*.

Skipping a ton of math, what this means, is that in order to cause a spammer a 1-second delay while their computer solves our JavaScript challenge, we have to cause each of our *legitimate users* a 1 second delay while *their* computer solves our JavaScript challenge. And, considering the 3 to 5 second database lag I see on 90% of the BP sites I visit, the challenge would need to take much longer than a second to have any merit at all …otherwise page refresh time would be the limiting factor, not the JS challenge.

So what happens when a user visits the site using a computer that is much slower than a typical desktop …say a mobile phone or an old laptop? The challenge would take proportionally longer to complete. A challenge that requires 5 seconds to solve on a desktop PC, could take 30 seconds on an iphone …and 30 second response times would not make for an enjoyable user experience.

Overall, proof-of-work challenges are probably not a good choice in the 2010 Internet landscape.

Mathematically Strong Methods

In the next post, I’ll cover the specific details of the methods I’ve proposed for the BP spam solution, and why they will defeat most spam attacks.

^F^