> the x and y positions of the mouse. If the user is actually using the
> mouse over the browser window, it could be assumed that a real person
> is there.
What about screen readers? People that browse using a keyboard
instead of a mouse? It's almost never a good idea to assume the
presence of a mouse in any type of software, let alone on the Web.
Great point. Using the event.keycode's in addition to the mouse x &
y's would work well in this case. Soon as the user starts
entering/changing in any of the data in one of the form fields it
could be caught. Checking both would be added insurance, while having
one or the other would be fine as well.
> Package that info with something secure like a
> public/private key such as with an open timestamp as well as another
> one encrypted with a secret key. Then check to ensure that they are
> grabbing the page within the last 10 minutes before posting, which
> would remove any sort of cached logic.
I often open multiple tabs (e.g. from an RSS reader) and browse
through them at my leisure. Something like that would have to be
awfully seamless so as not to annoy the user.
Similar to the suggestion above. If someone enters something in the
form, do remember that's the whole point of this, then using AJAX the
secure value could be regenerated to add an additional amount of time
before they hit submit. Actually, with that metric, it could be way
shorter as you would be only measuring the time between the last time
they changed a form value until they hit submit.
And also, try suggesting ideas too. I appreciate a challenge, but
let's try and make this a group effort to find a solution shall we?