A Note about the DHTML Editing Control in IE7+

Hi, I’m B. Ashok, the Product Unit Manager for Web Development Tools – we have our own team blog (http://blogs.msdn.com/webdevtools), but I wanted to post over here to discuss a change my team has made which has an effect on users of IE7+ in Windows Vista. Specifically, we are removing the DHTML Editing Control from the Windows Vista product.

The DHTML Editing Control shipped in Windows XP and Windows 2003 Server, in a file called dhtmled.ocx. This file contained two flavors of the control:

1. DHTML Editing Control (Safe for Scripting). This version of the control is marked safe to script, and can be used to provide visual editing of HTML content when browsing a web site in the Internet Explorer browser. The component GUID for this flavor of the control is: 2D360201-FFF5-11d1-8D03-00A0C959BC0A.
   
   
2. DHTML Editing Control (For Applications). This version of the control is less restricted and is typically used inside a Windows application to provide visual editing of HTML content. An example would be a C++ or Visual Basic application which hosts this component to provide visual HTML editing. The component GUID for this flavor of the control is: 2D360200-FFF5-11d1-8D03-00A0C959BC0A

In Windows Vista, we have decided to remove both flavors of this control from the operating system to reduce surface area for security attacks. In the past, this control was used as an attack vector that allowed cross site scripting (for which it had to be patched). After doing an analysis of real-world usage of the control, we have decided the best option is to remove the two flavors on the control from Windows Vista in order to make IE7+ more secure. In the near future, we will also killbit the Safe for Scripting control in IE7 in Windows XP so that it will not get instantiated from the browser.

We wanted to mention this now to give anyone who may be relying on either flavor of this control enough time to make any necessary changes prior to the final release of Windows Vista. Overall we believe usage of the control in the real world is fairly limited, however you could be impacted in one of three general ways:

1. You are using Outlook Web Access (OWA) from IE7+ on Windows Vista, and are accessing an Exchange 2000 or Exchange 2003 server which doesn’t have all the latest updates. If your Exchange server has the latest critical updates, then Outlook Web Access no longer relies on the DHTML Editing Control, and you will not encounter any issues accessing OWA from Windows Vista. However, if your Exchange server isn’t updated with the latest updates, you may not be able to compose new emails in Outlook Web Access from within IE7+ in Windows Vista Beta 2. To solve this problem, you should ask your Exchange admin to install the critical update http://support.microsoft.com/kb/911829 - this update removes OWA dependencies on the DHTML Editing Control. Once the Exchange server is patched with this update, composing emails in OWA will work fine from Windows Vista clients.
   
   
2. You are using a web site which relies on the Safe for Scripting version of the DHTML Editing Control from IE7+ on Windows Vista. In doing a web crawl search of Internet web sites, we found almost no Internet web sites using the DHTML Editing Control. However, we were unable to search web sites on Intranets, so it is possible that Intranet web sites (e.g. internal corporate web sites) may be using the DHTML Editing Control. If that is the case, the recommendation is to have those applications switch to another similar technology which utilizes the built-in editing available in Internet Explorer 6 and higher. There are several such components - http://freetextbox.com/default.aspx is one good example of one.
   
   
3. The last scenario where you might be impacted is if you are using a Windows application that relies on the DHTML Editing Control For Applications. By the RC1 release of Windows Vista, my team will be providing a separate install of the DHTML Editing Control For Applications, which can be installed on Windows Vista and will provide compatibility for Windows applications that may rely on this control. This install will only include the “For Applications” flavor of the control and will not include the “Safe for Scripting” flavor of the control. In doing so, we keep IE7+ in Windows Vista secure from potential security risks since the “For Applications” flavor of the control cannot be loaded in the browser.

Prior to the RC1 release of Windows Vista, we will also publish a whitepaper which goes into more detail regarding the removal of the control from Windows Vista, and explains how one can implement some of the changes suggested above.

To summarize, we are making these changes because we feel the overall benefit of increasing security significantly outweighs the benefits of leaving the DHTML Editing Control in Windows Vista. I encourage folks to ask questions and provide feedback so we can help anyone that may need more information about these changes. You can write to me directly at bash-at-microsoft.com if you have any questions or feedback on this change.

Thanks,
-- Bash