• Home Page
• Computer Blog
• Chess Blog
• Exercise & Diet Blog
• Theology Blog
• Islamic Terrorism Blog
• Contact Us

IE8 Security Part II: ActiveX Improvements

Hi, I’m Matt Crowley, Program Manager for Extensibility with Internet Explorer. The team was very excited to be at the RSA security conference last month discussing the security features of Internet Explorer 8 Beta 1. In this, the second part of the IE8 Security blog series, I describe the ActiveX improvements in IE8 and summarize the existing ActiveX-related security features carried over from earlier browser versions.

Per-User (Non-Admin) ActiveX

Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges. This improvement makes it easier for an organization to realize the full benefit of User Account Control by enabling standard users to install ActiveX controls used in their day-to-day browsing.

If a user happens to install a malicious ActiveX control, the overall system will be unaffected, as the control was installed only under the user’s account. Since installations can be restricted to a user profile, the risk and cost of compromise (and, in turn, the total cost of administering users on a machine) will be lowered significantly.

Per-User ActiveX was designed with compatibility in mind—most existing ActiveX controls will not have to be rewritten to benefit from this feature; the only change will be repackaging. As in Internet Explorer 7, when a webpage attempts to install a control, an Information Bar is displayed to the user.

By clicking on the information bar, users can choose to either install the control machine-wide, or install it only for their own user account. The options in this menu will vary depending on the packaging of the control and the rights of the user.

The available options depend on Group Policy settings for per-user ActiveX installations and whether or not the control has been packaged to allow per-user installation.

While this feature offers the possibility of lowering total cost of ownership, IT Administrators running managed environments may elect to disable this feature via Group Policy. For more information regarding Per-User ActiveX, please refer to the Non-Admin ActiveX Controls article in MSDN’s IE8 Beta 1 Whitepapers.

ActiveX Opt-In

Recognizing that any binary extensibility mechanism increases attack surface, ActiveX Opt-In was introduced with Internet Explorer 7.

By default, ActiveX Opt-In disables most controls on a user's machine. When the user encounters a Web page with a disabled ActiveX control, they will see an Information bar with the following text: "This website wants to run the following add-on "ABC Control" from "XYZ Publisher". If you trust the website and the add-on and want to allow it to run, click here …" The user can then choose to enable the ActiveX control from this Information bar.

ActiveX Opt-In allows some controls to run by default:

• A small list of common controls intended for use in the browser.
• Controls which were used in IE on a user’s machine before upgrading to IE8.
• Controls which are installed through IE.

For more information on ActiveX Opt-In, please refer to the MSDN Article Best Practices for ActiveX.

Per-Site ActiveX

When a user navigates to a Web site containing an ActiveX control, IE8 performs a number of checks, including a determination of where a control is permitted to run. This check is referred to as Per-Site ActiveX, a defense mechanism to help prevent malicious repurposing of controls. If a control is installed, but is not permitted to run on a specific website, an Information Bar appears asking the user whether or not the control should be permitted to run on the current website.

Users can use the Information bar to allow the control for a specific Web site or allow the control for all Web sites.

IT Professionals administering a system of computers running Internet Explorer 8 may choose to preset allowed controls and their associated domains. Such settings can be configured using Group Policy.

For more information regarding Per-Site ActiveX, please refer to the Per-Site ActiveX article in MSDN’s IE8 Beta 1 Whitepapers.

Enforcing Per-Site with ATL SiteLock Technology

If your ActiveX control is designed for use only on your web site, then locking it to the domain of that Web site will make it harder for other sites to repurpose the control in a malicious manner. See Developing Safer ActiveX Controls Using the Sitelock Template for more information.

Reducing Exploit Risk with DEP/NX, “Killbits,” and Servicing

Working with your processor and Windows, IE8 helps reduce the exploitation of vulnerable controls through Data Execution Prevention. See the previous post in this series, IE8 Security Part I: DEP/NX Memory Protection, for more information on how to ensure that your ActiveX controls are DEP/NX compatible, as well as information on how to opt-in to other available protections.

If a vulnerable control has been exploited, IE has included a poison-pill option—the “killbit”— to block usage of specific controls within the browser. Vendors who are aware of a vulnerability in their control should contact Microsoft to setup a killbit for a future software update package. For more information, please refer to Knowledge Base article 240797, How to stop an ActiveX control from running in Internet Explorer.

As with standard desktop software, it is important to keep controls up-to-date to ensure compatibility with newer systems and lower the risk of compromise through evolving security threats. For more information on updating ActiveX controls, please refer to the IE Blog entry Good Practices for ActiveX Updates.

Working with Users through Manage Add-Ons

While most end users aren’t aware of the inner-workings of ActiveX controls or their enterprise policy on them (if applicable), users are able to find out information about the controls installed for use in Internet Explorer through Manage Add-Ons. It is important for developers to ensure that their controls are not only performant and secure, but also open in the information they provide.

Controls are identified by Name, Publisher, Version, and Class ID within the Manage Add-Ons interface. Given this, control developers are encouraged to include this metadata in release builds of their controls.

For more information on making sure that your ActiveX control properly conveys information about itself to users, please refer to Christopher Vaughan’s post Add-on Management Improvements in Internet Explorer 8 as well as the MSDN Article Best Practices for ActiveX.

Thanks for your help in ensuring your ActiveX controls are secure!

Matthew David Crowley
Program Manager
Internet Explorer Extensibility

IE and Windows XP Service Pack 3

Hi.

My name is Jane Maliouta and I am the Deployment PM for IE8. You might remember my recent blog on Installing IE8. Today I am here to tell you about Windows XP SP3 (XPSP3) and how it’ll work with the various released versions of Internet Explorer.

Windows XP SP3 contains some new updates, and a number of bug fixes and security improvements. You can learn more about XPSP3 features by reading the white paper located here. We expect XPSP3 will be publicly available shortly and want you to have this information prior to its final release to the web.

Internet Explorer 6 Users

XPSP3 will continue to ship with IE6 and contains a roll-up of the latest security updates for IE6. If you are still running Internet Explorer 6, then XPSP3 will be offered to you via Windows Update as a high priority update. You can safely install XPSP3 and will have an updated version of IE6 with all your personal preferences, such as home pages and favorites, still intact.

If you are currently running IE7 or IE8 on  Windows XP SP2 (XPSP2) and you are thinking of upgrading to XPSP3, read on.

Internet Explorer 7 Users

If you are currently running IE7 on XPSP2, Windows Update will offer you XPSP3 as a high priority update. If you choose to install XPSP3, Internet Explorer 7 will remain on your system after the install is complete. Your preferences will be retained. However, you will no longer be able to uninstall IE7. If you go to Control Panel->Add/Remove Programs, the Remove option will be grayed out.

This behavior is by design and here is why. When we install IE7 on Windows XP SP2, we backup the existing IE6 files in an uninstall directory.  Those IE6 files are the ones that shipped on XPSP2 plus all the security updates you’ve installed while using IE6. Windows XP SP3 contains a newer version of the Internet Explorer 6 files. If you have XPSP3 on your system and uninstall IE7, your system would revert to the backed up (older) version of the IE6 files rather than the newer XPSP3 version. You would end up in a mixed file state in Windows where most files would be the upgraded XPSP3, except for the IE6 files restored when uninstalling IE7. This state is not supported and is very bug prone. To ensure a reliable user experience, we prevent this broken state by disabling the ability to uninstall Internet Explorer 7.

If you must uninstall IE7 after you have upgraded to XPSP3, then you have to first uninstall XPSP3, and then uninstall IE7. After this series of uninstalls, you will be reverted back to a XPSP2, and a stable version of IE6, so feel free to upgrade to XPSP3 again.

If you install IE7 after you install XPSP3, then you will be able to uninstall IE7 at any point and be reverted to the newer IE6 version that ships in XPSP3. The restriction on uninstalling only applies to when you install a Windows Service Pack release on top of a standalone IE release.

Keeping this in mind, you might want to uninstall IE7, upgrade to XPSP3 and then install IE7 again so you can uninstall IE7 in the future if need be.

Internet Explorer 8 Beta 1 Users

Installing IE8 Beta1 on Windows XP SP3  is fully supported, so go ahead and upgrade your computers to XPSP3 and then install IE8 Beta 1 to try out our new features. You will be able to uninstall IE8 Beta 1 at any point to revert back to either IE7 or IE6 depending on what you were using before.

However, if you already have IE8 Beta 1 installed on XPSP2, Windows XP SP3 will not be offered to you via Windows Update. This is because after you update your system to XPSP3, you will no longer be able to uninstall IE8 Beta 1 and the Remove option will be grayed out under the Add/Remove programs in Control Panel. The reason is the same as in IE7 case described above. Since people are more likely to uninstall beta software, we strongly recommend uninstalling IE8 Beta 1 prior to upgrading to Windows XP SP3 to eliminate any deployment issues and install IE8 Beta 1 after XPSP3 is on your machine.

Thanks,

Jane Maliouta
Program Manager

What Happened to Operation Aborted?

What caused the operation aborted error?

1. The HTML file is being parsed
2. Script is executing
3. The executing script attempts to add, or remove an element from an unclosed ancestor in the markup tree (not including the script block's immediate parent element).

<html> <body> <div> <script type="text/javascript"> var newElem = document.createElement('foo'); document.body.appendChild(newElem); </script> </div> </body> </html>

What we did in Internet Explorer 8 Beta 1

• The operation aborted error was a modal dialog. The dialog was not actionable by any user.
• Dismissing the operation aborted dialog caused Internet Explorer to navigate to an error page. This prevented any potential debugging of the affected page.

Interoperability observations and feedback request

<html> <body> <div id="container1"> <div> <span id="span1">First block of text</span> <script type="text/javascript"> document.body.removeChild(document.getElementById('container1')); </script> <span id="span2">Second block of text</span> </div> </div> <div id="container2"></div> </body> </html>

What can you do?

1. Moving your script execution to a function that is invoked after parsing is complete (e.g., onload)
2. Adding the defer boolean attribute to the script block (this defers execution of the script content until parsing is complete)
3. Limiting your tree modifications to the script-element's immediate parent
4. Moving the location of your script block to a child of the body (this usually solves most problems, while allowing the most flexibility in terms of scenarios).

Give Your Eyes a Treat

If you’re a developer, there’s an easy way to give your eyes a rest and make yourself more productive. Use the Consolas font Microsoft developed specifically for you.

When we began work on a project to create a new set of fonts which would take maximum advantage of ClearType, we decided to develop a fixed-pitch font for developers - because no one ever thought of their needs, and we realized a highly-readable fixed-width font would make their lives a lot easier.

We call them the C* fonts because their names all begin with C (for ClearType), and we spent a lot of research and development time making them as readable as possible.

Look at the difference Consolas makes, for instance, in the CMD.EXE window. Here’s what the standard 8 x 12 pixel raster font looks like…

… and here’s Consolas

You’ll see Consolas doesn’t get you as many lines on a screen – but it’s so much clearer and better to read that it’s well worth the tradeoff.

Bryn Spears on the Internet Explorer team gave me the following simple instructions to turn on Consolas in the CMD Window:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v 00 /d Consolas

logoff

 Note: In Windows Vista, you need to run the reg command from an elevated command prompt.

When you log back in, Consolas will be an option in the “Command Prompt” Properties.  (n.b., Bryn tells me it actually shows up before you relog, but it won’t work.)

You can install Consolas on your Windows system even if you don’t have Vista or Office 2007 with a free download from Microsoft.com

The Windows International fonts team is working on another version that’ll support Vietnamese, and also the line draw characters that we made to support the console window.

Bill Hill
Program Manager
Internet Explorer

Edit: changed logout to logoff

April Chat with the IE Team on Thursday

Join members of the Internet Explorer team for an Expert Zone chat this Thursday, April 17^th  at 10.00 PDT/17.00 UTC. These chats are a great opportunity to have your questions answered by members of the IE product team.

If you can’t join us online, all chat transcripts are published here. Allow approximately 7-10 days following a chat for the transcript to go live.

Hope you can join us on Thursday!

Kristen Kibble
Program Manager

April Chat with the IE Team on Thursday

Join members of the Internet Explorer team for an Expert Zone chat this Thursday, April 17^th  at 10.00 PDT/17.00 UTC. These chats are a great opportunity to have your questions answered by members of the IE product team.

If you can’t join us online, all chat transcripts are published here. Allow approximately 7-10 days following a chat for the transcript to go live.

Hope you can join us on Thursday!

Kristen Kibble
Program Manager

April Chat with the IE Team on Thursday

Join members of the Internet Explorer team for an Expert Zone chat this Thursday, April 17^th  at 10.00 PDT/17.00 UTC. These chats are a great opportunity to have your questions answered by members of the IE product team.

If you can’t join us online, all chat transcripts are published here. Allow approximately 7-10 days following a chat for the transcript to go live.

Hope you can join us on Thursday!

Kristen Kibble
Program Manager

HTML and DOM Standards Compliance in IE8 Beta 1

With the release of IE8 Beta 1, I'm pleased to be able to talk about the first round of improved standards compliance and bug fixes in IE's HTML and DOM support for the new IE8 standards mode. Doug hinted at some of these improvements, and I wrote a little bit about them in the IE8 Beta 1 whitepapers here and here. In this post, I'd like to enumerate the 'change list' (of sorts) here on the blog in response to requests for such a list that I received at MIX08. Personally, I've been long-awaiting this release because of what I know it means to web developers (like myself) that have had to code around a lot of IE's DOM quirks for many years.

For IE8, I have really focused on the HTML and DOM Core standards and concentrated on building a solid cross-browser compatible foundation for many of the APIs that are already supported by Trident. This effort to fix some of the cracks in IE's foundation has been a long time in coming, and I believe it's a critical and necessary first step before adding on additional standards support.

For IE8 Beta1, we looked at many community-provided bug reports and found that the top pain-points were related to IE's attribute handling (with a few prominent exceptions like getElementById). Therefore, attribute-handling has served as the 'theme' for the set of issues to tackle in IE8. We probably won't be able to fix all of the community-reported bugs in the DOM in this release (there are many), but we want to make sure that we get to the worst offenders first. Help us out by submitting or voting on the bugs that you feel are most impactful to your business.

HTML/DOM Standards Compliance in IE8 Beta 1

Note: I use HTML5 nomenclature for DOM attribute/content attribute.

Big-impact improvements in Beta 1

Within the scope of attribute-related fixes, the following address some of the well-known, oft-cited, compliance issues in IE's HTML and DOM support.

1. <BUTTON> type attribute defaults to 'submit' rather than 'button' in IE8 standards mode.
   
2. setAttribute now uses the content attribute name (rather than the DOM attribute name) for applying an attribute value (also camelCase no longer required).
   • This fixes the commonly reported issues regarding the 'style', 'class', and 'for' attributes not working.
     
3. getElementById finds only elements with matching id (not name) and performs case-sensitive matching.
   
4. <BUTTON> value attribute text now submitted iin form submit in IE8 standards mode. IE7 standards mode continues to submit the innerText.
   
5. <OBJECT> now supports native image loading (see the whitepaper for more details).
   
6. <OBJECT> now supports fallback for two additional scenarios: HTML embedding and native image loading (where the HTML/image resource cannot be loaded, i.e., 4xx-5xx HTTP response codes. ActiveX controls still do not support fallback (see the whitepaper for more details).
   
7. URL-type DOM attributes separated from content attributes. For example: <A>.href (DOM attribute) != <A>.getAttribute('href') (content attribute). You will find that all URL-type DOM attributes return an absolute URL, while the content attribute returns the string that was provided in the source. These changes apply to the Attr.value and getAttributeNode as well. Specifically:
   • The following element's DOM attributes now return absolute URLs: applet [codebase], base [href], body [background], del [cite], form [action], frame [src, longdesc], head [profile], iframe [src, longdesc], img [longdesc], ins [cite], link [href], object [codebase, data], q [cite], script [src].
   • The following element's content attributes now return relative URLs: a [href], area [href], img [src], input [src].

Consistency and reliability with Standards and other browsers (attribute-related) in Beta 1

Many reported (and some not-reported) issues with IE's attribute handling involve the NamedNodeMap interface object (object.attributes), correct DOM attribute reflection of content attributes, and case-sensitivity. In principle, the standards indicate that HTML documents are case-insensitive, while DOM Core-related APIs are case-sensing--they depend on the underlying document rules to determine their sensitivity. To resolve ambiguities, I appealed to the most common behavior of other browsers.

1. <element>.attributes.getNamedItem no longer creates Attr objects that don't exist in the collection (returns null when an attribute is not found).
   
2. Radio button fixes:
   • Dynamically setting the 'name' attribute on a radio button now correctly applies that radio to same named group (old known-issue fixed in Quirks, IE7, and IE8 standards modes).
   • Radio buttons without a name attribute can now be selected by the user in IE8 standards mode (I found it interesting that the code revealed this to be an old Netscape compatibility issue).
     
3. <FORM> enctype DOM attribute now supported. Reflects the enctype content attribute.
   
4. Checkbox fixes:
   • Inserting checkboxes into the tree (and moving them around the document) no longer resets the 'checked' state with the 'defaultChecked' state.
   • The 'defaultChecked' DOM attribute now reflects the 'checked' content attribute. The 'checked' DOM attribute affects both the intrinsic behavior on screen and the form's submitted value.
   • Parsing operations on the 'checked' content attribute always affect both the 'checked' and 'defaultChecked' DOM attributes. (For example, removeAttribute('checked') sets 'checked' and 'defaultChecked' to false, setAttribute('checked', 'checked') sets both DOM attributes to true (as if the element were being re-parsed).
     
5. getAttributeNode now correctly populates the .value property of the returned Attr object for all attributes (whether .specified=true or not).
   
6. removeAttribute now uses case-insensitive comparisons.
   
7. <P> element now closes when <TABLE> is encountered (ACID 2 compliance).
   
8. <LINK> rel content attribute now finds 'alternate' token in any location in the string (ACID 2 compliance).

Additional compliance and feature completion in Beta 1

1. <BASE> href no longer applies a 'new' document base if the supplied URL is a relative URL (relative URL being defined as not having a schema ['http:'] and a hostname ['/' or 'domain']).
   
2. Title attribute now preferred (over alt) when specified as the popup tooltip for images and maps (img, input, object, and area elements).
   
3. When retrieving Boolean attributes by name, the value is now correctly reported as the canonical attribute name (e.g., checked='checked').
   
4. Implemented hasAttribute (case insensitive matching) which is the suggested workaround while the NamedNodeMap is under construction.
   
5. Completed the Attr interface (of DOM L2 Core) by implementing ownerElement.
   
6. Completed the interfaces for object, iframe, and frame (DOM L2 HTML), by implementing contentDocument. Note: like contentWindow, this property will not allow cross-domain access to the inner content.
   
7. HTMLCollection fixes:
   • 'item' API is no longer overloaded to accept strings and act like 'namedItem'. 'item' now only accepts numerical indexes (or tries to convert a string to a numerical index as is JavaScript behavior).
   • 'namedItem' no longer returns collections if more than one named item is found. Instead, the first matching (case-insensitive) element is returned.
   • As IE8 does not implement all collections using the HTMLCollection interface, the following exceptions currently exist: elements [HTMLFormElement], rows/tbodies [HTMLTableElement], rows [HTMLTableSectionElement], and cells [HTMLTableRowElement].

Known Issues

A significant bug in our JavaScript invoke code path in IE8 Beta 1, causes some JavaScript calls to inadvertently revert to IE7 compatibility mode and therefore make it appear as if some of the aforementioned bugs are not actually fixed. :( This has personally affected some of my tests that pass DOM objects (like HTMLCollections) through a function parameter for testing--I mention this only by way of example. While you will see this bug fixed in Beta2, it may indirectly impact your own testing--I recommend checking for the existence of document.querySelector to see if your script execution has reverted to IE7 compatibility mode before concluding that IE8 Beta1 has not fixed a particular bug (the Selectors API is only visible to IE8 standards mode).

Known issues we are planning to address in Beta 2

At a minimum, all previously available functionality in the DOM will be restored in Beta 2.

1. setAttribute still does not work with event handlers.
   
2. <element>.attributes.length fails. The IE8 NamedNodeMap object is in the middle of an overhaul.
   
3. Many TABLE-related API are 'not implemented' as of Beta1. As critical pieces of the IE8 layout engine come online, these APIs are being re-enabled:
   • rows/tbodies [HTMLTableElement], rows [HTMLTableSectionElement], cells [HTMLTableRowElement].
     
4. <OBJECT> elements don't fall back on cross-domain security failures.

Known issues we are not planning to change in IE8

1. <OBJECT> is not parsed in a cross-browser compatible way (parsing stops at the OBJECT, whereas other browsers continue parsing all the fallback content and make it available. No support for this parsing behavior is planned for IE8; I'll take this opportunity to ask for real-world scenarios that can help me prioritize this feature.
   
2. <OBJECT> elements cannot be 'reactivated' by dynamically correcting the attributes that caused the original fallback. Again, your feedback on the potential benefits/use-cases for this feature appreciated.

Acknowledgements

I'd like to acknowledge the amazing work done by all the IE developers and testers that make it possible to push a button and get IE7 compatible behavior for each of these significant changes.

Also, special thanks to PPK for updating his compatibility tables to showcase some of the work that we've done.

And there's more to come.

Regards,

Travis Leithead
Program Manager
IE8 Object Model

IE8 Security Part I: DEP/NX Memory Protection

Hi, I’m Eric Lawrence from the Internet Explorer Security Team. With the RSA security conference kicking off this week, I wanted to start sharing more information about the security features and benefits of Internet Explorer 8 Beta 1. Over the next several weeks, we’ll blog in greater detail about some of the security improvements in Beta 1, such as the new Safety Filter, greater control over ActiveX controls, and new AJAX features for safer mashups (XDomainRequest and XDM). This is not a complete list of our security investments for the release; we will have more to talk about during future milestones.

Internet Explorer 8 security features target three major sources of security exploits: social engineering, Web server, and browser-based vulnerabilities. This post will cover IE8 Data Execution Prevention (DEP), a feature that mitigates browser-based vulnerabilities.

DEP/NX Memory Protection in Internet Explorer 8
Internet Explorer 7 on Windows Vista introduced an off-by-default Internet Control Panel option to “Enable memory protection to help mitigate online attacks.”  This option is also referred to as Data Execution Prevention (DEP) or No-Execute (NX). 

We have enabled this option by default for Internet Explorer 8 on Windows Server 2008 and Windows Vista SP1 and later.

DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable.  DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. No additional user interaction is required to provide this protection, and no new prompts are introduced.

DEP/NX Compatibility
For Internet Explorer 7, DEP/NX was disabled by default for compatibility reasons.  Several popular add-ons were not compatible with DEP/NX and would crash when Internet Explorer loaded them with DEP/NX enabled.  The most common problem was that these add-ons were built using an older version of the ATL library.  Before version 7.1 SP1, ATL relied upon dynamically generated code in a way not compatible with DEP/NX.  While developers of many popular add-ons have since released updated extensions compatible with DEP/NX, some add-ons may not be updated before Internet Explorer 8 becomes available.

Fortunately, new DEP/NX APIs have been added to Windows Server 2008 and recent Windows Service Packs to enable use of DEP/NX while retaining compatibility with older ATL versions.  These new APIs allow Internet Explorer to opt-in to DEP/NX without causing add-ons built with older versions of ATL to crash. 

In rare cases where an add-on is not DEP/NX compatible for reasons other than outdated ATL usage, a group policy option will be available to allow an organization to opt-out of DEP/NX for Internet Explorer until an updated version of the broken add-on can be deployed.  Local Administrators can control DEP/NX by running Internet Explorer as an Administrator and unchecking the Tools > Internet Options > Advanced > “Enable memory protection to help mitigate online attacks” option.

Checking Your Protection
You can see which processes are protected by DEP/NX on Windows Vista Task Manager’s Process tab; on earlier versions of Windows, you can use Process Explorer.  In either case, ensure that the “Data Execution Prevention box” is checked in the View > Select Columns menu.

Developer Call to Action
If you build Internet Explorer add-ons, you can help ensure users enjoy a smooth upgrade to IE8 by taking the following steps today:

1. If your code depends on older versions of ATL, please rebuild it with ATL v7.1 SP1 or later (Visual Studio 2005 includes ATL 8.0)
   
2. Set the /NXCompat linker option to indicate that your extension is compatible with DEP/NX
   
3. Test your code with DEP/NX enabled using IE8 Beta 1 on Windows Vista SP1. (Alternatively, test with IE7 on Windows Vista after enabling the DEP/NX option. To enable DEP/NX for IE7: Run IE as an administrator, then set the appropriate checkbox in the Tools > Internet Options > Advanced tab)
   
4. Opt your code into other available defenses like stack defense (/GS), safe exception handling (/SafeSEH), and ASLR (/DynamicBase)

Thanks for your help in securing the web!

Eric Lawrence
Program Manager

IE Automatic Component Activation Now Available

The IE Automatic Component Activation (IE ACA) update is now available as part of the April 2008 Internet Explorer Cumulative Update. The "click to activate" behavior, formerly required for ActiveX controls embedded in some webpages, is now permanently removed from Internet Explorer.  For detailed information on IE ACA, see our blog post from last November announcing this update.

This update replaces the IE ACA previews released in December 2007 and February 2008.

Thanks,

Jefferson Fletcher
Product Manager

IE April Security is Now Available

The IE Cumulative Security Update for April 2008 is now available via Windows Update. Alternatively, you can receive this and all other Microsoft updates via the new Microsoft Update. I encourage you to upgrade to Microsoft Update if you haven’t already to ensure that you receive the latest updates for all Microsoft products.

This update addresses 1 remote code execution vulnerabilities. This security update addresses this vulnerability by modifying the way Internet Explorer handles HTML and validates data. For detailed information on the contents of this update, please see the following documentation:

• Microsoft Security Bulletin MS08-024
• Microsoft Knowledge Base Article 947864

This update is rated “Critical” for IE5.01, IE6 Service Pack 1 on Windows 2000, IE6 on Windows XP, IE7 on Windows XPSP2 and IE7 in Windows Vista, IE6 on Windows Server 2003, and IE7 on Windows Server 2003.

As a reminder, IE security updates are cumulative and contain all previously released updates for each version of Internet Explorer.

I encourage everybody to download this security update and other non-IE security updates via Windows Update or Microsoft Update. Windows users are also strongly encouraged to configure their systems for automatic updates to keep their systems current with the latest updates from Microsoft.

Terry McCoy
Program Manager
Internet Explorer Security

IE8 Beta 1 For Developers Now Available in Chinese (Simplified) and German

The IE team is pleased to announce the availability of Chinese (Simplified) and German versions of Windows Internet Explorer Beta 1 for Developers. The two languages released today are fully localized versions of the IE8 English Beta 1, released March 5, 2008. They carry with them the same improved CSS 2.1 support, better scripting performance, and other features and improvements that the English beta 1 developer release contains.

Download links:

• IE8 Beta 1 Chinese (Simplified) for Developers 
• IE8 Beta 1 German for Developers

Supported Platforms:

This release is supported on the same platforms as the previous IE8 Beta 1 English release. Here are the supported operating systems:

• Windows Vista
• Windows Vista SP1 (final version only - Currently available to MSDN and TechNet Plus subscribers and Volume License customers)
• Windows XP SP2
• Windows XP SP3 (RC2 candidate - Build 3311 or higher)
• Windows XP Professional x64 Edition
• Windows Server 2003 SP2
• Windows Server 2008 (final version only)

For install guidelines, please see the "How to Install the German or The Chinese (Simplified) Builds of Internet Explorer" section of the Windows Internet Explorer 8 Beta 1 release notes here.

Please note that each international version may only be installed on its native language operating system or on English versions of the operating system with the native language’s Multi-language User Interface (MUI) installed. You can learn more about Multi-language User Interfaces (MUI) here.

We value your expertise and look forward to hearing your feedback on this Developer Beta release! Online support is available through the IE Beta Newsgroup and you can sign up through MS Connect to vote on IE8 Beta bugs. You can report a webpage problem and also request to be added to the IE Technical Beta Program by following instructions found at the bottom of the IE8 Beta Feedback blog post.

Hope you enjoy this Beta release for developers as much as we do!

Vishwac Sena Kannan
International Program Manager
Internet Explorer

edit: removed underline from section headers

Designing for Add-on Performance

As we worked towards the recent release of Internet Explorer 8 Beta 1, the IE team focused hard on performance. As part of our effort to improve IE, our investigations have revealed several add-on performance problems. In this post, I want to share some of the common themes that we have discovered.

First, I would like to thank those of you who have provided feedback on this blog, in the IE Beta NewsGroup, and around the web. The Internet Explorer team has been working hard on performance in IE8 and it is great to see the results of some of our early investments. We still have room (and plans) to improve, but for now you can find out more about the performance improvements in IE8 Beta1 from our developer whitepapers.

If you are new to the world of developing IE add-ons and want some background material, here are a few great links to get you started:

• Building Browser Helper Objects with Visual Studio 2005
• Building Stable Browser Extensions
• Add-on Development

Broadly speaking add-on performance issues typically impact IE users in two areas:

1. Opening/Closing the IE window or individual tabs
2. Browser responsiveness

Opening and closing speeds are largely impacted by add-ons performing lots of expensive work every time they are created. One particularly common problem is that add-ons check for updates during either browser startup or shutdown.

Registry misuse has been a common problem leading to poor responsiveness. Many add-ons perform expensive registry operations that can reduce Internet Explorer’s responsiveness.

In the sections below I discuss these two areas and provide some guidance for designing performance into add-ons.

Add-on Initialization and Checking for Updates

• Principle 1: Be lazy – give hard work to another thread
• Principle 2: Don’t pay a toll every time you start the car

During startup, Internet Explorer checks the registry for installed add-ons. When IE detects an installed Browser Helper Object (BHO) or toolbar it calls CoCreateInstance to instantiate each installed and enabled add-on. Essentially, Internet Explorer creates add-ons as inproc servers, executing in the context of IE’s main UI thread. For backwards-compatibility Internet Explorer follows these steps for every opened tab. This behavior is important for several reasons, and you’ll see why as I discuss some of the most popular problems encountered by add-ons.

Be lazy – give hard work to another thread

One common trend in many of the popular add-ons today is integration with online content. Maintaining this integration with live data invariably entails some update mechanism. In many of the cases we have investigated, add-ons perform synchronous update checks when IE hands control over to the add-on’s SetSite implementation during initialization.

From my description of how add-ons are initialized in Internet Explorer, you can guess what the potential impact is from these types of update checks. Consider the following flow:

1. IE begins initialization
2. IE detects that the Foo Toolbar has been installed
3. IE calls the Foo Toolbar’s SetSite method
4. Foo Toolbar contacts http://foo.example.com to check for updated content
5. Foo Toolbar returns control to IE
6. IE continues initialization and displays the user’s homepage

See the problem yet? Consider step 4 above – what happens if the Foo Toolbar finds lots of content that needs to be updated, if the user’s connection to the content server is slow, or if the user is working offline? The answer is, (since add-ons execute in the context of the UI thread), that the toolbar can cause IE to become unresponsive for long periods of time or can lead to IE’s startup and shutdown times inflating faster than a balloon at a clown convention.

A better approach is to create a worker thread that can perform the content update asynchronously. The preferred way is to use SHCreateThread (when developing an add-on in C++) as follows:

STDMETHODIMP SetSite(IUnknown* pUnkSite)
{

if (pUnkSite != NULL && IsUpdateRequired())
{
        SHCreateThread(Update, NULL, CTF_COINIT | CTF_PROCESS_REF, NULL);
}
else
{
         // Release cached pointers and other resources here.
}
 // Return the base class implementation
return IObjectWithSiteImpl<CHelloWorldBHO>::SetSite(pUnkSite);

}
DWORD WINAPI Update(LPVOID pParam)
{
            DWORD dw = 1;
            // Perform update here
           return dw;

}

DWORD WINAPI IsUpdateRequired()
{
           DWORD dw = 1;
            // Perform a low-cost check here to verify that an update should be 
            // performed. This can be accomplished by checking a registry key.  
           return dw;

}

Notice that in the above example SetSite creates a new thread to execute the Update method. Using this approach SetSite does not run the risk of blocking the UI thread for extended periods of time, and the add-on is still able to update its content. Also notice that by establishing a suitable frequency for update checks (for example, every 2 or 3 days) add-ons can be updated quickly without forcing users to pay the price of the update check with every browser or tab opening.

Adopting this approach can help move long-running operations off of IE’s main UI thread and can lead to better perceived performance. It is important to remember, however, that moving to a worker thread is not a panacea. There are many potential issues, including the possibility that numerous expensive cross-thread COM calls could outweigh the benefit of moving to a worker thread.

Pay the toll when you get to the booth

Handing off long-running operations to a worker thread helps avoid UI hangs. Nevertheless, users may still pay an avoidable up-front cost every time your add-on is initialized. Users often start IE without taking advantage of the updated content. In these cases both the users and content providers are paying extra costs associated with the update checks without any commensurate dividend.

When performing content updates an extreme approach would be to pay the costs only when users have explicitly announced that they want new content – by clicking on the “Check for Updates” menu item, for example. That solution is, however, unrealistic in many cases because it could compromise the add-on’s performance. For example, consider a user clicking on a drop-down menu, and having to wait a second to view the associated drop-down while updated content is downloaded – yikes!

There are a variety of techniques that more effectively balance user experience and up-front costs. For example, toolbar developers might want to consider moving their update checks out of SetSite entirely and do them either the first time the user mouses over the toolbar, or update on a fixed schedule. Exact solutions will vary from add-on to add-on, so it’s important to stay creative and try to avoid forcing fixed costs on users whenever possible.

In almost every case there is a way to avoid doing lots of work in either SetSite or in an OnDocumentComplete handler. Taking the extra time to push work out of these areas is a great way to avoid performance problems and ensure that users are happy to install your add-on.

Using the Registry

• Principle 3: Caching is your friend
• Principle 4: Break the habit – Don’t flush!

Caching is your friend

Using the registry is sometimes reminiscent of the Macarena circa 1996 – a few people knew the steps, fewer people were actually good at it, but neither of those facts prevented everyone else from taking part. Registry overuse is common among Windows applications, and we have been working hard to reduce our registry accesses with IE8.

Overusing the registry is discouraged because the overhead of registry operations can be significant – opening, reading, and closing a cached key can cost tens of thousands of cycles. Since it is relatively common for individual add-ons to perform hundreds, thousands, or even tens of thousands of registry accesses during startup, these costs can quickly add up to a noticeably slower browser.

Fortunately, it is possible to reduce the cost of using the registry. First and foremost, optimize for the common case. It is very likely that most registry values are not going to be changed during the course of an add-on’s execution, so reading the value once and then maintaining a cache can significantly reduce the number of individual registry accesses.

Where it is not possible to eliminate registry accesses, you can often reduce the cost of the remaining operations. It turns out that accessing keys using full registry paths (e.g. HKEY_LOCAL_MACHINE\Foo\Bar) can be two to three times as expensive as using relative paths, depending on number of levels separating the target key from the provided root. Add-ons typically have the vast majority of their settings available under a key or a small set of keys. For example, suppose an add-on wanted to retrieve the associations used by IE. The following registry keys would need to be accessed (under HKEY_LOCAL_MACHINE):

\SOFTWARE\Microsoft\Internet Explorer\Capabilities\FileAssociations
\SOFTWARE\Microsoft\Internet Explorer\Capabilities\MIMEAssociations
\SOFTWARE\Microsoft\Internet Explorer\Capabilities\UrlAssociations

Using the Win32 method RegOpenKey each of the regkeys could be accessed with the following snippet of code (using FileAssociations as an example):

HKEY hk;

RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities\\FileAssociations", &hk);

The remaining keys could be accessed in a similar fashion using HKEY_LOCAL_MACHINE as the root. However, a better approach in these cases is to create a handle to the Capabilities key and then perform additional relative-path RegOpenKey operations to retrieve the remaining values, as follows (again, using FileAssociations as an example):

HKEY hkRoot;

RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities", &hk);

HKEY hkFileAssoc;
RegOpenKey(hkRoot, L"FileAssociations", &hkFileAssoc);

Break the habit - Don’t flush!

Lastly, in the past we have seen add-ons using the RegFlushKey to ensure that their registry values were in fact pushed out to disk. In some cases this is done in an attempt to maintain state between two instances of an add-on running in separate tabs or windows.

As noted in the MSDN documentation for RegFlushKey, there is rarely a need to use this API. Furthermore, calling RegFlushKey can be surprisingly expensive as it will ensure that all the data backing the registry has been written to disk. That activity may take hundreds of milliseconds to return control to the calling program. Even worse, accesses to the registry will be blocked while it completes.

As a result, calls to RegFlushKey can have an impact not only on IE but can reduce performance throughout the system. Rather than flushing the registry, add-ons using the registry for synchronization between instances can use RegNotifyChangeKeyValue to maintain state. Larry Osterman and Raymond Chen have blog posts on (mis)use of the registry that are worth reading for more detail:

• Psychic Perf Analysis, or "RegFlushKey actually DOES flush the registry key" by Larry Osterman
• The performance cost of reading a registry key by Raymond Chen

I hope my guidelines on improving add-on performance help you understand some of the common problem areas we have encountered. Thanks for contributing great add-ons to the Internet Explorer ecosystem, and I look forward to your comments.

Christian Stockwell
Program Manager
Performance Geek

Internet Explorer 8 Beta 1 for Developers – Standards Highlights Part 2

With Internet Explorer 8 Beta 1 for Developers now out in the wild, we have received a good deal of positive feedback regarding our plans for CSS. The feedback includes the need for the specifics around CSS support for IE8 Standards Mode for both the current Beta and what is projected for the final release. This information allows you, the developer community, to test your sites and give quality feedback for features that are actually implemented in the current beta release. These details are posted up on MSDN in the following document:  CSS Compatibility and Internet Explorer.

Once again, we thank you for your support and passion for building great products.

Doug Stamper
Principal Program Manager Lead
Internet Explorer Developer Experience Team

Internet Explorer 8 and Adaptive Zoom

What You Can Expect

Digging In A Little Deeper

• Fonts and text: The glyph itself is not scaled. Rather, the font size is scaled and then the appropriate glyph is used. The important thing to note is that fonts do not scale linearly by design. For example, if text at 12pt is scaled to 110%, the resulting font size is calculated as 13.2pts. However this font size does not exist, therefore it is rounded to the nearest available size – 13pt.
• Fixed, auto and relative sizing: Dimension scaling is one of the most important improvements in IE8’s Adaptive Zoom. Dimensions specified using absolute units (e.g.: in, cm, mm, etc) or device and font dependent units (e.g.: px, ex, em, etc) are scaled as per the zoom level. Therefore, at 200%, 100px becomes 200px and 20pt becomes 40pt. Content-dependent dimensions, i.e. percent and auto, are not scaled as they are computed during layout. Therefore, at 200%, a width of 50% of the viewport does not become 100% of the same. This is a marked change from Zoom in IE7.
• Positioning: Positioned elements grow and shrink like in-flow elements. However their new position is determined by the properties set, and the offsets used. An absolutely positioned element, if offset to the left by 100px, will shift towards the right when zoomed in. It is possible for it to go off screen.

Similarly, floats will be positioned with respect to their container as per the normal rules of CSS. If the width of the container changes with zoom, then the position of the float will change. Zooming of adjacent floats is exactly like resizing the window – if the width of the viewport is not large enough to accommodate the floats, the last one in markup will drop to the next line.

• DHTML properties: In IE7 zoom, some properties were treated as physical (e.g.: mouse coordinates) while others were logical (offset). This implementation essentially required web developers to be aware of or manually calculate the zoom state based on the property being used. In IE8 zoom, all DHTML properties are now assumed to be logical. This enables some key scenarios such as fly-out menus and “drag-and-drop”. There are a few known issues, such as the incorrect scaling with screen.width and screen.height, that were not addressed in Beta 1. These will be fixed in a future release.

Getting Your Site Ready For Internet Explorer 8 Zoom

• At what point do horizontal scrollbars appear? Does the user need to scroll to read a single line of text?
• Does content quickly go off screen because of fixed sizing and positioning?
• Does the overflow:hidden value on any elements make content inaccessible?
• Do fly-out menus adapt to available screen real estate, or do options go off screen making them inaccessible to the user?

Add-on Management Improvements in Internet Explorer 8

One of our goals with Internet Explorer 8 was to improve the experience of managing add-ons by bringing more types of add-ons into the management experience, and to make that experience more usable. Originally introduced in Windows XP Service Pack 2, we've updated the management UI in a big way for IE8.

Here's a screen shot of the new UI:

A familiar interface…

When you look at the Manage Add-ons UI, you'll probably feel comfortable with it quickly - it looks a lot like a Windows File Explorer window or the Control Panel in Windows Vista. You choose a category of object types from the left to view that list on the right. Select any item in the list and the details pane at the bottom will display information about the selected add-on.

Most changes you make in Manage Add-ons take effect immediately, although some (like disabling a toolbar or explorer bar) might still require you to restart Internet Explorer.

… with lots of improvements over IE7

You can resize the window to fit your screen resolution and personal preference, and can choose custom columns, grouping, and sorting order. These preferences will be remembered the next time you open Manage Add-ons.

Additionally:

• You can select multiple Add-ons from the list (CTRL+click or drag to multi-select)
• The list supports right-click context menu actions
• Details about add-ons can be copied to the Windows clipboard and into email, a document editor, or a spreadsheet so you can share the list with tech support (or friends or family) more easily

No updates are required to existing controls to show up in this list

Developers do not need to make changes to existing controls to continue to be managed in IE8. However, with the richer set of information and controls put in the hands of the user in IE8, control authors might wish to provide more detailed information with their controls. While the same set of information (such as publisher or version) is available in IE8 as was available in IE7, now it's easier for users to view it. Add-ons without sufficient information (like an empty publisher name or version number) are often removed or disabled by users.

Add-on developers should read this article and this blog post about ActiveX best practices for more information on how to properly develop IE add-ons.

It's easier to get information about installed add-ons and find new add-ons with IE8

More detailed information about installed add-ons is available at a glance with IE8. We've also added links to make it easy to accomplish common tasks:

• Find more add-ons with a single click. Just click "Find more add-ons…"
• Don't know what an add-on does? Click "Search for this add-on via default search provider" and we'll help you find information about it online via your current default search provider
• Want to know more about add-ons in general? Click "Learn more about add-ons"
• Clicking "More information" displays more detailed technical information about installed add-ons, including file names, versions, and other properties. You can even view or clear the list of websites that ActiveX controls are allowed to run on for per-site installed ActiveX controls
• Right-click any add-on to get easy access to common actions (like enable or disable)

New types to manage

In Internet Explorer 8, the list of add-ons you can manage has been expanded to include Explorer Bars, Search Providers, and Activities.

Explorer Bars

Explorer Bars are an extensibility type like toolbars that are supported by previous versions of Internet Explorer and IE8, but not listed in Manage Add-ons prior to IE8. With IE8 they are available so you have more control over what's running in your browser.

Search Providers

In IE7 we added support for OpenSearch Search Providers, but they had their own, separate management window. We've kept the functionality of the management experience for Search Providers in IE8, but moved it here. IE8 helps you to quickly see what Search Providers are installed, which is your default, and where it is sending information when you submit a search. Additionally, you can change the order that Search Providers are listed (IE7 always sorted them alphabetically).

Internet Explorer 8 continues to support the OpenSearch standard for Search Providers. You can read more about OpenSearch here.

Activities

Activities, which are new to IE8, are also managed from the Manage Add-ons window. Just like Search Providers, you can view, manage, and remove installed Activities, find new Activities, and learn more about Activities directly from this window.

Managing Add-ons in No Add-ons Mode

IE7 and IE8 support "No Add-ons Mode," a troubleshooting mode. When you run IE this way, no 3^rd party code runs, which allows you to do things like disable troublesome controls or repair Windows via Windows Update (which is why that control is allowed to run in this mode). You can start No Add-ons Mode in a few ways:

• Type iexplore -extoff in the Run box on the Start menu
• Click "Internet Explorer (No Add-ons)" under All Programs -> Accessories -> System Tools
• Right-clicking the IE icon on the Start Menu (if IE is your default browser) and selecting "Browse Without Add-Ons"

In IE7 you couldn't run Manage Add-ons while in No Add-ons Mode, but in IE8, you can. In fact, if you click the information bar that appears when you're running in No Add-ons Mode, it offers a quick and convenient access point to Manage Add-ons:

Remember, No Add-ons Mode is designed for troubleshooting IE. It's probably not the way you want to experience websites all the time, as a lot of important functionality is often provided via add-ons.

To exit No Add-ons Mode, simply close that browser window.

In Summary

We designed the Manage Add-ons interface to be more comprehensive in the types of objects it manages and the types of actions you can take. I'm interested in hearing any questions and feedback about this new management experience. Just leave a comment in the blog and I'll read it!

Thanks!

Christopher Vaughan
Program Manager

WebBrowser Control Rendering Modes in IE8

Many commonly used applications and Windows system components depend on the MSIE WebBrowser control to render webpages from within their program. Unlike live sites, pages loaded within these controls are typically static resources stored in libraries and executables on a system. While webmasters can easily alter their site to render properly in the new version of IE, many software vendors do not have the resources to instantly push out new versions of their applications with updated internal pages. In order to ensure that these existing applications remain in working order, IE8 renders pages running within instances of the WebBrowser control in IE7 Standards Mode by default.

Per-Application WebBrowser Control Rendering Settings

The test container shown above uses the IE7 Standards Mode run by default within WebBrowser control containers. While this mode works well with existing applications, developers building new applications may want to use the new IE8 Standards rendering mode as shown below.

When an executable loads an instance of the WebBrowser control it scans the registry to check whether the executable wants IE7 Standards or IE8 Standards mode.

To run a WebBrowser control in IE7 Standards Mode, insert the following values into the registry:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_NATIVE_DOCUMENT_MODE]

"MyApplication.exe"=dword:11170

To run in IE8 Standards Mode insert the following registry value:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_NATIVE_DOCUMENT_MODE]

"MyApplication.exe"=dword:13880

In both of these instances, MyApplication.exe should be replaced with the name of the executable that will be running WebBrowser controls in a specified mode.

User-Agent String and WebBrowser Quirks Mode Rendering Issues

Specification of an IE rendering mode also applies to IE5 Quirks Mode. To run instances of a WebBrowser control in IE5 Quirks Mode, insert the following value into the registry:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_NATIVE_DOCUMENT_MODE]

"MyApplication.exe"=dword:C350

Due to a known bug in the IE8 Beta 1 build, the User-Agent String returned by the browser instance will state that it is “MSIE 8.0” (as shown in the screenshot above). Knowledge Base Article 183412 provides a workaround for this scenario.

IE Version Targeting and WebBrowser Rendering Modes

As with webpages displayed in an IE window, pages hosted in a WebBrowser control can also override rendering settings by using the X-UA-Compatible meta tag to specify a rendering mode. For more information on formatting and values for the version targeting META tag see Scott Dickens’ latest post here.

Matthew David Crowley
Program Manager
Internet Explorer Extensibility

IE8 Beta Expert Zone Chats

After a successful run with the IE7 beta, we’re bringing back our monthly online Expert Zone Chats with members of the IE team. The first is this Thursday, March 20^th at 10:00 PDT/17:00 UTC. These chats are a great opportunity to have your questions answered and hear from members of the IE product team.  In case you miss the chat, a transcript will be published afterward and available online.

As we saw with the IE7 beta, these chats are a lot of fun and we hope you can join us online.

Kristen Kibble
Program Manager

Installing IE8

• Windows Vista
• Windows Vista SP1 (final version only - Currently available to MSDN and TechNet Plus subscribers and Volume License customers)
• Windows XP SP2
• Windows XP SP3 (RC2 candidate - Build 3311 or higher)
• Windows XP Professional x64 Edition
• Windows Server 2003 SP2
• Windows Server 2008 (final version only)

• Open the Windows Control Panel and click Add or Remove Programs
• Select Windows Internet Explorer 8 Beta 1 and click Remove
• Your computer will be reverted to IE6 + previous IE6 security updates or IE7 + previous IE7 security updates
• You can confirm that by going to Tools->Help About next time you launch IE
• Be sure to check for any new security updates

• Open Control Panel and click Programs
  • Click Programs and Features, and click View installed updates, and then select Windows Internet Explorer 8
  • Click Uninstall this update
• Your machine will be reverted to IE7 + previous IE7 security updates
• You can confirm that by going to Tools->Help About next time you launch IE
• Be sure to check for any new security updates

• KB943302 –This update is required for Vista RTM installs only. It will be installed for you automatically as long as you leave the “Install the latest updates” option checked when going through the Setup Wizard.

If this update is not on your computer when you try to launch IE8, you will be prompted to manually install this KB.

• KB946501 –This update is required for multi-core XPSP2 x86 computers only. Similar to the one above, this update will be installed for you automatically as long as you keep the “Install the latest updates” option checked when going through the Install Wizard.

If this update fails to install or you unselect the checkbox, you will not be able to install IE8 until this update is on the computer.

The IE8 Favorites Bar

• In addition to adding a link through the "Add to Favorites" button, you can drag and drop links onto the Favorites bar, drag the webpage icon from the Address bar to the Favorites bar or drag a link from a webpage directly to the Favorites bar.
• You can rearrange items on your Favorites bar by dragging items from one spot to another or by creating folders and organizing your favorite links, WebSlices, and feeds by dragging and dropping items into the folders.
• When an item within a folder updates, you will see the updated status on the folder itself. If a folder is unbolded, you will know that nothing has updated within that folder without even opening it.
• Navigating with the Favorites bar is convenient as well. To put focus on the first item on the Favorites bar, press ALT+B.
• Like regular links, the Favorites bar supports tab and window shortcuts. For example, you can Ctrl+Click or Middle-click on an item (or a folder) on the Favorites bar and this item (or the contents of this folder) will open in a new tab (or tabs) in the background.
• Similarly, Ctrl+Shift+Click on an item on the Favorites bar will open up this item in a tab in the foreground.

IE8 and Loosely-Coupled IE (LCIE)

• Tabs are isolated from the frame, and are located in separate processes This gives IE the opportunity to isolate many failures to the tab process, thereby reducing the amount of damage done to the rest of your browsing session.
• The frame and the broker object are located in the same process This is a win for startup performance. The broker object is responsible for examining a URL, and determining if it should be loaded under protected mode or not, and launching IE at the appropriate integrity level. We no longer have to wait for the protected mode broker object’s process to startup before loading the rest of the browser.
• Low and Medium integrity tabs can reside in the same UI frame The Windows Integrity Mechanism operates on a per-process basis. Now that we can place tabs into their own processes, we can turn protected mode on or off on a per-tab basis. This is a big usability improvement. You no longer need separate browser windows to view sites in and out of protected mode.