Categories
Technology Weblogging

Close your trackbacks

Recovered from the Wayback Machine.

After a couple of test trackbacks yesterday, I knew that today most likely we would start seeing trackback spam, and so it has proved.

I would suggest that people turn off trackback capability if they’re concerned about receiving spam, until safeguards are put on this other rather huge, gaping hole into our sites.

Update

Matt also noted the trackback problems today, and mentioned about the only viable approach to the problem being a content-specific solution. Which means blacklists based on words.

We’ve already seen that these aren’t particularly effective. They’ve blocked legitimate comments based on fractions of words triggering the filter; they don’t stop crapflooding; they add processing burden on to already over burdened systems; and they’re too easily manipulated to filter on legitimate domains.

Now, we’re looking at doing the same with trackback.

What’s the best approach? Well, with trackbacks, you have a lot more ability to add intelligent safeguards because no one trackbacks anonymously. One can check back at the site to make sure the trackbacked URL is legitimate, or send an email to the track backer confirming the trackback. If this doesn’t defeat the trackback spammer who actually build sites with the permalinks included, then just plain moderate trackbacks.

Unlike comments, trackbacks are removed from the flow of conversation, so if one doesn’t show up immediately, no harm.

In addition, even the most popular post doesn’t receive more than 20-30 trackbacks, at most. It’s no burden to manage the posting of trackback manually. And of course, trackbacks, as with comments, should have throttles in place to prevent being crapflooded.

Why do we have to make things more complicated then they have to be? The more moving parts, the more we’re at the mercy of the spammers.

Trackback moderation — simple, easy, works.

Categories
Technology

Coding on the hoof

Recovered from the Wayback Machine.

This last week I’ve been heavily into development, trying to get OsCommerce to agree to operate a certain way, in addition to doing some really strange things to the version of WordPress in use at Bb (changes which will then get ported to Wordform). In fact, you may see things break here and there, off and on, as I’ve decided to do all my coding ‘live’ — directly to my working weblogs.

This is contrary to traditional development practices. Normally the rule is to code in a separate space and then roll out a nicely polished, tested, finished, fairly stable working copy. However, I thought it might be interesting for non-technologists to see what an application looks like as it undergoes changes.

I sometimes think we, the techs, hide what goes on behind the scenes too much–fostering a myth that an application is solid-state when really its bits and pieces stuck together. Hopefully, we manage to stick the bits together in a way that they actually do something useful, but that’s not always the case.

It’s frustrating for users to hit a bug in software, and when they do, they wonder how this bug could be missed and/or why isn’t the developer just “…putting out a quick fix”. What happens, though, with many bugs, is that trying to fix the code in one spot can break it in three other places because the code is really bits and pieces, stuck together in a way that hopefully works, but in this case, doesn’t.

It then becomes equally frustrating for the developer to try to explain to the user that there are so many moving parts to an application of any size, there is no such thing as ‘bug free’ code. In addition, the ‘quick fix’ the user asks for could take a month of developer time because it’s connected to half a dozen other bits of code all of which need to be changed–so they shouldn’t hold their breath.

For the next month, as I work at creating all sorts of new goodies (for WordPress, Wordform, and other weblogging tools), you can watch me break, repair, break, and then repair again my own weblog installations; all the while comfortably knowing its my site, my weblogs, my code that’s falling apart, not yours. Sort of like you being an observer behind one-way glass, and me being the insane patient under treatment.

Speaking of coding on the hoof, you saw it here first: iProngs and prodcasting.

Categories
Technology

Comment goodies

Another package I’m working on is a set of files that will add all my comment functionality to a WordPress 1.22 installation. This includes the functionality developed by others–live preview (from Chris Davis) and spellchecking (incorporated from Cold Forged) — in addition to my own modifications, such as being able to edit a saved comment. I’m also adding the rich HTMLEdit functionality to the edit page for the saved comments.

I am unsure about some of the other functionality, though. For instance, I won’t be able to provide my individual moderated comments because this requires changes in the admin page. That kind of functionality you’ll get from Wordform when I’m finished with the pre-alpha-beta-newbie-baby 0.0001 release, by the end of this week, or beginning of next.

But I can provide my backend comment spam prevention that, first of all, renames the backend comment posting file to something new; it then checks to see if more than so many comments have been posted in the last hour, and last day (limits that can be modified to your own preferences). If so, throttles kick in and the comments are rejected. This will prevent the problems with “10,000 comments, all at once” problem that has plagued Movable Type so severely.

In addition, I have functionality that will test the age of the post, and if it’s over so many days old (again configurable), it will put the next comment into moderation, and then close the post.

With both of these controls in place, I have very little problem with spam. Well, other than the new breed of spammer that is now running mock weblogs, with hidden links to porn sites and making individual comments, just like a real weblogger.

Would this backend protection be of use, and should I add it to the package?

The comments package is for WordPress 1.22 — the new Floating Clouds theme for 1.3 will have some of this included, automatically. It should be easily configurable, drop in and play, though it will require replacing your existing wp-comments.php page.

Categories
Technology

Packaged goodies

Per long overdue requests from several people, I’ve finished up a WordPress 1.22 template featuring the ‘floating clouds’ design. Additionally, I created a separate package that just provides the files necessary to do the random background image. You can see the basic floating clouds design at the development site, at http://word122.forpoets.com. I’m not linking this directly, as I will be blowing this site away when finished all my development. You can copy the complete template, or just the background image portion.

To install the complete template, make a backup of your index.php and wp-comments.php file. Then download and unzip the gzip-tar file; no worries if you’re not into the Unix thing– Mac’s Stuffit and Winzip can handle the file format. Just make sure you save the file with Firefox, and not have the browser open it directly — this can be troublesome at times.

From the material I’ve provided, copy the files index.php and wp-comments.php, in addition to the ‘look’ subdirectory, to your main WordPress 1.22 directory. You’ll also want to copy the plugin file, recent-comments.php, to your WordPress plugin directory (it should be wp-content/plugins off the main WordPress installation).

Once the files are in place, go into your admin, and activate the plugin, “Get Recent Comments”. This provides the functionality for getting recent comments in the sidebar, which is not provided in WordPress 1.22.

(If you haven’t upgraded to 1.22, you should do this first — there are security fixes in 1.22 you’ll need.)

After that, open the main index.php file in your browser, and you should have a site that looks like the one mentioned earlier. You can then add items to the sidebar, remove items, and modify the colors and look as you want.

If you’re just interested in the background image functionality, access this file instead and again unzip it, either to your server or your local PC. The file contains several images, which I’ve provided just as test images until you get the background switcher going. After that, you can replace the images with your own. Just make sure to update the photos.txt file to reference your images, not the ones provided.

For each page you want to use the dynamic background, add a link to the clouds.php file, using the following, but changing it for your domain and URL:

<link rel=”stylesheet” media=”screen” href=”http://weblog.burningbird.net/look/clouds.php” type=”text/css” />

This link should follow any other stylesheet you’re using for your site. When you next access your site, you should start to see the dynamic imaging take effect. If not, check to make sure that the photos.txt and images are in place, and the image files are named correctly in the file.

If you want the image to appear somewhere other than the upper left corner, adjust the CSS in the clouds.php file to whatever you prefer — lower right, upper middle, whatever. Totally up to you.

I achieve the effect I do with my site by adding a vignette to a photograph, in addition to adding some transparency. When using Photoshop, this is achieved by using the Elliptical Marquee tool to create an oval selection on the photo, and then choosing Select and Feather to ’smudge’ the edges. I cut the image and create a new one, with the appropriate background color. I copy the cut image from the original photo, and then adjust the transparency of the pasted image.

However, you don’t have to have Photoshop for this. There are several free and shareware applications that will allow you to add vignetting and transparency to a photo.

Stay tuned for a 1.3 theme based on Floating Clouds. Note that this design will validate as transitional XHTML, as long as the text in the posts is valid.

Categories
Technology Weblogging

Comment spam prevention in Wordform

I believe that, eventually, most comment spam strategies will have to have a system-wide component in place to truly combat this problem — something to watch for comment spam patterns happening on a server, and throttle accordingly. However, that’s something that can’t really be handled with the application. So, I’ll focus on what I can do in Wordform.

My comment spam protections are not going to include a blacklist, in any shape or form. These require too much processing, and are too vulnerable to corruption. Instead, I’ll use a variety of techniques that combined should protect a site — even a heavily hit site.

First, I’ve added individual comment moderation so that you can turn moderation on for a specific post, or a group of posts. When this is turned on, a message will show near the comment form stating that the comment is currently moderated.

Next, I’m adding new capability to search in comments for those that fall into a range of dates, and then be able to delete all comments that match a search criteria. With this, if you do get hit, it should be easier to delete the spam.

(I’m also adding a one-touch button to globally approve, or delete, all moderated comments.)

The comment posting page will have a throttle that can be configured in options. This throttle will check the number of comments received within a certain period of time, and if the count exceeds a value that the user can specificy, will either moderate the comment, or deny it (again, something that can be configured). At Burningbird, the throttles are no more than ten comments in a minute (a WordPress option); and no more than 50 comments in a day (my option). These two values can be changed, and I’m also adding a maximum count for number of comments allowed in an hour. All of this will prevent ‘crapfloods’, which can overwhelm a site, and even a server.

Currently I’m using database queries for the comment throttle I have at Burningbird, but for Wordform, I’ll be using other caching methods to hold timestamps and comment counts. This should make the throttle lightweight and robust.

I’m also adding a configurable option to either close or moderate all comments over a certain number of days old. I use this with Burningbird, whereby the first comment to a post over so many days old gets moderated, and then the post gets closed. This has eliminated probably about 98% of my comment spams, while still giving me the option of determining (from this last comment), whether I want to keep the post open, but moderated.

A new functionality for Wordform not currently implemented at Burningbird is the ability to close a discussion. By closing a discussion, the post (or the web site) is temporarily put into a lock-down form, where only those people who have previously written published comments can add new comments. When they do, the comment is posted immediately. If a person hasn’t added a comment previously (based on the person’s email, which is a requirement for lock-down, though it’s not printed), their comment will be put into moderation.

Finally, I’m experimenting around with a new comment spam prevention method that I’m calling “Stealth Mode”. However, this is one item I am leaving for a “Ta Da!” moment when I release Wordform’s first alpha release.

(Most of these comment spam moderation techniques will also apply to trackbacks. I’m currently wavering on my support of pingback, which is really nothing more than recording a link, and this is accessible via the vanity sites.)

Between all of these–Throttle, Lock-down, individual and weblog moderation, better comment management, closing older posts, and Stealth Mode–the comment spam problem should end up being no more than a minor irritation in Wordform. Then if I can just get people to accept that comment spam is not an invasion of a person’s personal space, and that it’s a way of life and to not spend so much time fretting about it, we’ll have the comment spam problem managed.