Please read my blog's comment policy here.
When the IE team talks about Cross-Site-Scripting (XSS) attacks, we’ve usually grouped them into three categories
DOM-APIs like toStaticHTML enable pages to protect themselves against Type 0 attacks. The Internet Explorer XSS Filter can block Type 1 attacks by detecting reflected script and neutering it. Servers can protect themselves against Type 2 attacks using the Anti-XSS library to sanitize stored data.
Here’s a screenshot of an attack that I encountered yesterday:
Now, I’ve seen far slicker versions that mask themselves far more cleverly, such that the script isn’t ever seen. In the manner of an old game cheat, the unknowing user presses CTRL+C, CTRL+L, CTRL+V, ENTER, and the bad guy’s code runs.
These attacks often target popular social networks, and their first action upon running is to spread to all of the user’s contacts, leading to an extremely rapid infection across the social graph. Thousands of users can fall for an attack like this in a few hours. After arranging to spread to the user’s contacts, these attacks typically engage in spamming malware-distributing links or other activities that generate revenue for the bad guys. Because the script runs in the security context of the victim page, any information on the current site may be available for perusal by the attacker.
 Internet Explorer will actually strip out any script-prefix, including misspelled strings that might otherwise be autocorrected into a script prefix. Also, if there's existing content in the address bar (e.g. a j) if adding pasted content (e.g. avascript) will create a script prefix, it will still be removed.
Won't the attack simply change from "Ctrl+C, Ctrl+L, Ctrl+V, Enter" to "Ctrl+C, Ctrl+L, Ctrl+V, Home, J, A, V, A, S, C, R, I, P, T, :, Enter"?
If someone is willing to follow the first set of steps, why won't they be willing to follow some slightly more elaborate steps?
@Dawson: I'm sure that attackers will eventually try that. With every additional step, however, the success rate of the attack drops off, and some users are likely to be more suspicious when they start typing the word "script". Hence, as I mentioned, the data we're seeing vis-a-vis the relative scarcity of IE9 victims.
Additionally, in the near term, since only IE9 has this protection, the attackers have to have two sets of instructions; anything that requires the user to know what version of the browser they're using eliminates a key part of the victim demographic. (Browser detection is often beyond the capabilities of the attackers, since if they already had scripting permissions, they wouldn't need to undertake the attack).
[EricLaw]: @Jim: There's no option for this. Thanks for the feedback.
Devs still paste script directly into the address bar? F12 = all the interactivity I need.
What is the value in allowed JS to be executed directly from the address bar?
Is there a means to keep bookmarklets but disallow direct address bar execution?