Internet Explorer Flaw, Transparency, and App Compat
“After IE Attacks, Microsoft Eyes Security Betas” is by Al Sacco at CSOOnline. He has a lot of good orientation and background. Then take a look at Mike Reavy’s “Third party solutions to the Internet Explorer CreateTextRange vulnerability.” Mike runs MSRC, and it’s a pleasant surprise to see him acknowledging customer fears with a post that ends:
Customers of course can weigh the risk of deploying a third party “patch” but it’s unclear what impact this will have on the system. Addressing the vulnerability, as well as working with partners to address attacks, are a few of the main things that we’re working on and we’ll keep you up to date as progress is made.
That was pleasant enough, but then later
yesterday, Mike Nash, who runs the Security Technology Unit, chimed in with “An update on the IE ActiveX change.” That post contains this interesting tidbit:
So when we release the next cumulative IE security update, customers will only be able to interact with Microsoft ActiveX controls loaded in certain web pages after manually activating their user interfaces by clicking on it or using the TAB key and ENTER key.
So that’s very cool. Making ActiveX controls less dangerous is a fine thing. (I’m curious, though, what the user experience will be, and how easily people will be convinced to hit tab-enter?) I’m also really sort of confused by this decision:
Interactive controls are ActiveX controls that provide user interfaces. When a web page uses the APPLET, EMBED, or OBJECT elements to load an ActiveX control, the control’s user interface is blocked until the user activates it. If a page uses these elements to load multiple controls, each interactive control must be individually activated.
When a control is inactive, it does not respond to user input; however, it does perform operations that do not involve interaction. If, for example, you open a web page that uses Microsoft Windows Media Player to play a music file, the music plays after the page loads. You cannot interact with Windows Media Player until the control’s user interface is activated, as shown in the following figure.
From “Activating ActiveX Controls” on MSDN.
So, that’s sort of confusing to me. It sounds like ActiveX controls run, but to interact with them, you need to hit a special key first. App compat is broken, but the apps are allowed to run without controls? Why not delay the activation of the ActiveX until the user presses a key? Isn’t this a great opportunity because application compatability is breaking anyway to make a substantial change to the way ActiveX controls are activated that better protects customers?
(I wrote this two weeks ago, and forgot to hit “post.”)