Screen gallery: With Vista and IE7's one-two security punch, will the Web be harder to use?

For as long as I can remember, the architecture behind Microsoft's ActiveX software component technology (and its predecessors such as OLE and DDE) has been maligned as one of the key weaknesses in the Windows operating system. For Microsoft as well as for its customers, ActiveX has been a tiger by the tail. On the one hand, it has so much to offer in the way of dynamically loadable software components that can interoperate with most of the functionality that Windows has to offer. On the other, those pathways to such interoperation have opened doors to transgressors that might not otherwise exist. If ActiveX isn't the perfect case for studying the tradeoffs between integration, performance, and vulnerability, I don't know what is.

	Screen Gallery: See the screen gallery that shows in detail how the security in Windows Vista and Internet Explorer 7 looks to prevent the installation of rogue ActiveX components.

Now, in addition to the many other security features being ushered into userland by Windows Vista as well as Internet Explorer 7 (IE7), Microsoft's new flagship operating system and Web browser may finally have stricken the right balance between security and functionality in a way that also eliminates the vulnerabilities previously associated with ActiveX (so long as the end-user heeds Microsoft's suggested best practices as well as the incessant warnings that are flashed in front of the end-user should they mistakenly, or even purposely use technical measures to lower their guard).

But, while Microsoft has made great strides in taming the ActiveX tiger, there are still elements of the overall Web experience when using IE that are out of Microsoft's control. For example, in a series of tests that I did involving two different Web sites, each of which requires Adobe's Flash plug-in in order to complete the end-user's Web experience, the end result in terms of IE7's final security settings and the degree to which users could be exposed to future malware was different.

To Microsoft's credit, Vista and IE7 are a formidable tag team when it comes to the dynamic "plugging-in" of new ActiveX components (otherwise known as "controls") into IE7. With Vista and IE7, you can elect to override certain default security settings and increase your risk in a number of ways. But the software will nag you in ways that can't be suppressed the minute you cross Microsoft's conservative thresholds for what should and shouldn't be automatically allowed. So, in my test case, while one experience resulted in a less secure desktop configuration than the other other, IE7 went the extra mile to let me know that I was living dangerously. At that point, you can hardly blame Microsoft (as many have in the past) if something bad happens. According to Microsoft's director of Windows Product Management Gary Schare, the use cases that warrant such crossings of Microsoft's thresholds are extremely rare if they exist at all.

Even so. There remains that question of what an end-user should do when they're asked to cross that threshold as a result of their visit to an otherwise trustworthy site.  The tests, available for all to see as a ZDNet Screen Gallery, also raise at least one additional question for Microsoft regarding the order in which certain keys to the Windows kingdom should be used. Based on my experience (and perhaps you will agree), Windows Vista and IE7 currently have two permission-oriented steps (for allowing the installation of an ActiveX control) in the wrong order. More on that and Microsoft's response to the question in a minute.

The two sites I visited with a fresh installation of Windows Vista and Internet Explorer 7, each of which required Adobe's Flash Player plug-in for certain Web pages, were iFilm.com and ZDNet.com. In both cases, I was following Microsoft's best practices for working with Windows Vista by operating the PC (a Lenovo X60 Tablet PC) as a non-administrative user or LPU (lesser privileged user). When running Windows Vista as an LPU, it is nearly impossible for software to install itself or be installed by the end-user without first being interrupted by a Windows User Account Control dialog that requires administrative credentials before the installation will be allowed to continue.

For example, as evidenced by both the iFilm and ZDNet sequences, Vista stopped me dead in my tracks and asked for administrative credentials before it would allow me to continue with the installation of Adobe's Flash player plug-in for IE. But like beauty, the definition of software is in the eyes of the beholder. For example, should Firefox add-ins be considered software? Software of the sort that Windows' administrative escalation feature should get in the way of? In my tests, it didn't.

I didn't single-out iFilm for my test for any particular reason. It just so happened that iFilm's PR department sent me a press release to tell me that iFilm.com was a good site to visit if I wanted to preview the Super Bowl commercials before the Super Bowl was aired on TV. So, I went there with my recently unboxed Vista-loaded Lenovo X60 Tablet which didn't yet have Adobe's Flash Player loaded onto it. iFilm.com, which needs Flash to playback its video content, correctly detected the absence of the Flash player. But as you can see from the iFilm portion of my screen gallery, the user experience in terms of getting the Flash player installed was horrible. Not only didn't the installation work the first time, I was eventually led to a troubleshooting page on Adobe's Web site that instructed me to reset IE's security settings to a level that had Microsoft's Gary Schare telling me "Users should in no way being doing what Adobe's Web page told you to do." Schare said he'd be contacting Adobe.

Meanwhile, I checked my employer's own Web site -- ZDNet -- to see if we handled the absence of Adobe's Flash player any better. From a security standpoint, we did. Instead of having to permanently lower my guard as I did in the iFilm test, an attempt to install the Flash plug-in without making any adjustments to IE's security resulted in a simplified end-user prompt to install the plug in (using IE7's information bar). According to Schare however, I should not have even received that prompt since Adobe's Flash player is one of several "signed" ActiveX controls that Microsoft has whitelisted as being OK to install with out prompting the user to start the installation (Vista and IE7 still require permission to complete the process though). He's checking into why I may have been prompted as shown in the screen gallery.

From a usability standpoint however, ZDNet failed my own personal standards for a streamlined user experience (several unnecessary page views and clicks were required). That user experience has since been corrected. Additionally, subsequent visits to iFilm.com show that the user experience has been corrected there as well.

At a higher level, the two divergent experiences -- both of which targeted the same final goal (installing Adobe's Flash player) -- are demonstrative of how the developers of Web sites can make or break the end-user's experience when it comes to navigating Vista and IE7's heightened security. For Microsoft, much the same way it will be calling Adobe, the company may have to spend some of its resources policing Web sites to ensure that they are offering the most seamless experience given Vista and IE7's security settings. Why? Because ultimately, if people can't get the Web to work with IE7, chances are they'll point the finger at Microsoft even though Microsoft may not be the real culprit. In my call with Schare, he even acknowledged that Web site developers may have to revisit their user experiences to make allowances for the way that IE7 handles ActiveX security.

Finally, as I mentioned earlier, there was one part of the Flash player installation that was repeated in both sequences that appeared out of order to me. To Windows Vista, an ActiveX control represents software that's just like any other locally installable software. To IE7, an ActiveX control represents a plug-in. As you can see from the screen gallery, both "hosts" to Adobe's Flash player -- Windows Vista and IE7 -- required separately issued permissions from the end-user in order to complete the installation of the ActiveX control. In the case of Windows Vista, that permission is requested in the form of Windows' aforementioned User Account Control dialog that needs an administrative password before the software will be allowed to install itself.

In the case of IE7, Internet Explorer has traditionally presented an Authenticode dialog (like this one shown in the screen gallery) that (1) signals to the user whether the ActiveX control is "signed" by a valid Certificate Authority, (2) shows what the names of the software and publisher certifiably are, and (3) require the user to deliberately press the "Install" button to continue with the installation.

As can be seen from the screen gallery, in both the iFilm and ZDNet cases, Vista asks for its permission first, and then IE7 takes its turn after. Logically, this order doesn't seem to make sense. Providing an administrative password to an installation sequence is in many ways like giving that sequence the master key to Windows Vista. I asked Schare if opening Vista's most important security kimono -- the one that essentially hands over the keys to Vista's kingdom -- shouldn't be the very last last barrier that's dropped, well after the user has used the Authenticode dialog to double check the control's certifiable legitimacy. Schare said that logically, it does make sense for the order of the two dialogs to be reversed but that there may be a plausible explanation for why the order is the way it is right now. He said he'll get back to me.