Archives for posts with tag: spam

I very recently had a conversation with a client about implementing email notifications for his online community built with my software. There was, of course, an urge in him to notify users every time the equivalent of a thread is created or responded to. There was also the need for an email to go out as soon as a personal message was received.

For the latter, I was on board; but for the former, I had to make a point– no matter how subjective. My point was that I will unsubscribe from any site’s mailing list the minute I get an email with things I don’t care about. Emails are on the level with text messages for me, arriving on my phone with an envelope notification, pining to pull me away from reality the minute it arrives. And it’s not that my time is money, but because I loathe spending time reading random minutia that I hate your everyday “engaging” emails (especially when they arrive every day).

Needless to say, I made the point that when designing a product and how it will send out notification emails, it’s important to remember:

  • You’re not the only site that any given user is a member of.
  • People have vastly varying degrees of tolerance for emails meant only for getting them to your site again.
  • Don’t automatically opt users in. Unless your software is going to take me out to dinner and learn my quirks first, don’t assume you know how I like my email notifications. Instead, give me the choice and demonstrate why your notifications will be useful to me.

On a related note, LunchTable just got email notifications today, unsent until you subscribe.

$ logout

Advertisements

Recently LunchTable received an influx of spam registrations: marked by similar-looking nonsensical usernames, “real names” that didn’t match their gender, and email addresses on adult sites. I didn’t want to use CAPTCHA to mitigate this, because I personally die a little inside at each CAPTCHA encounter, so I took another route.

With a little help from StackOverflow (can’t find the link now, will update), I found a clever solution that banks on spam scripts not executing Javascript. Less than 12 hours of being live captured and prevented two spam registrations. I start by adding a hidden input field to my registration form and filling it with default text:

<input type="hidden" id="robot" name="beep-beep-boop" value="iamspam" />

Next, I add a little Javascript to change this value to a numeric value, and subsequently increment it every second (this will come in handy later):

var botZapper = function() {
    if (document.getElementById("robot")) {
        a = document.getElementById("robot");
        if (isNaN(a.value) == true) {
            a.value = 0;
        } else {
            a.value = parseInt(a.value) + 1;
        }
    }
    setTimeout(botZapper, 1000);
}
botZapper();

Finally, on the server side, I do a simply check (in PHP):

$botTest = $_POST['beep-beep-boop'];
if ( $botTest == "iamspam" || !is_numeric($botTest) || $botTest < 10) {
    // This appears to be spam!
    header("Location: /");
    exit;
}
// ...database INSERT code untouched by bots...

This checks if any of the conditions are true, indicating a bot:

  • First, if the value hasn’t changed; meaning the user didn’t have Javascript enabled.
  • If the submitted value is other textual information we didn’t expect.
  • If JS was enabled, but the form was submitted within 10 seconds.

If these tests fail, I mercilessly redirect the bot to the home page with no “fail” message! My scorn is certainly felt.

Your time threshold will definitely vary depending on the length of your form, and you will need to accommodate users without Javascript enabled at all. However, at the time of this sentence’s writing, I’ve captured four attempted spammings from China, all who never updated the hidden input field (failing at the first test).

$ logout