Reverse Turing Test fights spam
This is incredibly cool. A couple of times in the past, I've posted about Reverse Turing Tests -- little online tests that screen out 'bots by forcing users to prove that they're human. It's a simple idea: You ask a user to look at an online graphic of a stretched or distorted word, and type in what they see. Humans are great at visual-recognition, and can do this effortlessly; 'bots can't. (I wrote a story for Wired last fall about how Yahoo is using one of these tests.) In the discussion boards here at Collision Detection, a bunch of people mused on whether it'd be possible to use such a system to help screen out spam.
As it turns out, that's the very idea behind Spam Arrest, a new spam-screening service. Pay them $20 every six months, and they'll implement at Reverse Turing Test that acts as a sort of firewall between you and anyone trying to email you. As they describe the process in their FAQ:
When an email arrives from an unknown sender, a reply email is sent back asking the sender to verify themselves by clicking on a link to the Spam Arrest website. (View Screenshot)
The link takes them to a page where they are instructed to type in a word that is shown in a picture (View Screenshot).
This step prevents automated systems, such as those used to send spam, for authorizing themselves, yet is very easy for any human to complete.
Obviously, the problem is in situations where the person trying to email you can't be bothered to do the test and validate themselves as human. But then again, if they can't be bothered to do 10 seconds of extra work to communicate with you, maybe you don't want to communicate with them.
Posted by Clive Thompson at June 30, 2003 05:58 PM
| TrackBack
True, but you only have to do the verification once, and you're verified permanently; every time you send email to that person again, it gets through.
Plus, I think you can manually enter approved email addresses into the system, so you could quickly input all the mailing lists you belong to.
But some variables are immortal. These variables are declared outside of blocks, outside of functions. Since they don't have a block to exist in they are called global variables (as opposed to local variables), because they exist in all blocks, everywhere, and they never go out of scope. Although powerful, these kinds of variables are generally frowned upon because they encourage bad program design.
When a variable is finished with it's work, it does not go into retirement, and it is never mentioned again. Variables simply cease to exist, and the thirty-two bits of data that they held is released, so that some other variable may later use them.
This back and forth is an important concept to understand in C programming, especially on the Mac's RISC architecture. Almost every variable you work with can be represented in 32 bits of memory: thirty-two 1s and 0s define the data that a simple variable can hold. There are exceptions, like on the new 64-bit G5s and in the 128-bit world of AltiVec
