So I worked on the CAPTCHA field control last night, and got enough to where it compiled correctly (after its conversion from a WebPart), and actually deployed it alright. I still have some cleanup to do since I would rather reduce the code bloat that is in right now left over as remanants from the intial WebPart idea. Either way it worked, so I am happy.
So I sent it out to a friend last night in Arizona since he is generally pretty forgiving if I break something in his system, somewhat important since I really didn’t test that much outside of my local VM development environment. While it worked ok, he basically said he just plain doesn’t like the idea of CAPTCHA.
His basic reasons behind not liking it is because CAPTCHA images become increasingly difficult to read (due to text warping), and posting a comment can start to become a battle when trying to start a discussion. His main point is that the verification system should begin interrogation on the machine, not with the user.
I agree and I disagree with his statements. The CAPTCHA field control is meant as a first step in the right direction, and is something that will always be under development. Eventually, the SBSP bundle (which includes the CAPTCHA control) will include more elegant, neat solutions. One that I had in mind is a cryptographic solution that instead leverages AJAX or something similiar for verification. On a certain time increment, SharePoint will select a chunked number request (similiar to something like a GUID). When a listform page is called from a SharePoint site object, the AJAX call will firstly run decryption routines on itself, then on the stored GUID, and retrieve the GUID value which does some general pattern matching. No match, no comment post. Time-outs would also be clutch to ban IP’s.
These things are planned, however will not be built into the first release of SBSP. They will eventually be there though.