I discovered arbitrary code execution holes in Firefox, Internet Explorer, and Opera that involve human reaction time. One version of the attack works like this:

The page contains a captcha displaying the word "only" and asks you to type the word to verify that you are a human. As soon as you type 'n', the site attempts to install software, resulting in a security dialog. When you type 'y' at the end of the word, you trigger the 'Yes' button in the dialog. I made a demo of this attack for Firefox and Mozilla.

Another form of the attack involves convincing the user to double-click a certain spot on the screen. This spot happens to be the location where the 'Yes' button will appear. The first click triggers the dialog; the second click lands on the 'Yes' button. I made a demo of this attack for Firefox and Mozilla.

These types of attack work on any security dialog that can be triggered by untrusted content. The attack is most useful in a dialog where one of the buttons means "Yes, let this untrusted content run arbitrary code". Firefox has such a dialog in the form of the extension installation (XPI) dialog. Similarly, Internet Explorer has the ActiveX installation dialog and Opera has an "Open" button for downloaded executables. Programs other than browsers might also be vulnerable.

Firefox's solution, from bug 162020, is to delay enabling the "Yes"/"Install" buttons until three seconds after the dialog appears. I believe that this is the only possible fix other than completely denying untrusted content the ability to pose the dialog. Unfortunately, this fix is frustrating for users who install extensions often.

Some users have been intentionally lowering the delay to 0 seconds, which frustrates me. These users think the delay was added merely to force everyone to read the dialog. It surprises me that these users were not able to figure out the security hole given the fix. Ironically, advanced users are the most susceptible to these attacks, because they type and double-click faster than they react to unexpected stimuli.

It might be possible to lower the delay to less than three seconds, making it less annoying, without jeopardizing security. Designing experiments to determine the minimum "safe" delay would be tricky. You would want to do everything an attacker could do to increase participants' reaction time: give them a complicated task, make new rectangles appear every second to make the dialog less unexpected, etc.

It might make sense to make the dialog appear only after the user clicks a statusbar indicator that means "This web site wants to install software". This would get rid of the problem of choosing a delay, and it wouldn't require users who want to install extensions to wait.