Author Archive

Over on the Ajax Blog, Dion Almaer passed on an important tip from Brent Ashley and Tim Aiello for AJAX developers – to have your cross-browser AJAX work better with IE7, you really should be invoking the native XMLHttpRequest (the cross-browser one) first to see if it’s available before instantiating the ActiveX control, instead of the other way around.

In addition to the reasons that Brent and Tim discovered, I’ve seen a bunch of code that creates the XMLHttpRequest object, uses it for a request, and then throws it away.  Obviously, this is a lot less performant than keeping the object around for multiple requests.  The native object's lifetime can be as long as that of the page. So you can reuse it like this:

            var  o = new XMLHttpRequest()
            o.open(“GET”, “data1.xml”,  true);
            o.onreadystatechange = foo();
            o.send();
            …….
            o.open(“GET”, “data2.xml”,  true);
            o.onreadystatechange=bar();
            o.send();

Xmlhttp.open has a “reset” semantic so the second open() call on the same object will abort the previous connection, disconnect previous event handler, and reset the object.

There's also a handy tool by Julien Couvreur for debugging XHTMLHTTPRequest calls for IE, or you can use Fiddler.

-Chris

Edit: Changed XMLHttpRequestObject() to XMLHttpRequest() in code illustration.

We often talk with our partners about all the ways they can take advantage of the extensibility in IE7. Today, Yahoo! released something new and (I think) pretty cool. “Internet Explorer 7 optimized by Yahoo!” presets the homepage and search to Yahoo properties. Of course, users can easily change the settings just as they can with the standard version that we ship. The Yahoo! version of IE7 is available now on the Yahoo site.

Yahoo! used the beta version of the Internet Explorer Administration Kit (IEAK) to customize IE7 to meet their needs. The IEAK is available to all developers and partners who want to create their own customized versions of IE7, as well as IT pros who want to use it to ease enterprise deployment. You can download it from the Microsoft Technet site.

Dean

Hello, we are Durga and Bala, from the IE IDC team. We would like to describe to you, a new feature in Internet Explorer 7 and 7+, Reset Internet Explorer Settings. We have heard from users on their need to recover Internet Explorer to a workable state if it reaches an unusable state due to spurious add-ons, incompatible browser extensions, spyware or malware. Reset Internet Explorer Settings (RIES) provides a one-button solution to get Internet Explorer settings to its workable state.

Internet Explorer 7 for Windows XP and 7+ in Windows Vista have many security enhancements which make Internet Explorer less susceptible to spyware and malware. But still browsing experience in Internet Explorer can get affected by badly written add-ons. This feature allows Internet Explorer to recover from such situations.

After RIES is run, the user will notice default settings of Home Pages, Search Scopes, Browsing History, Form Data, Passwords, Appearance Settings, Toolbars, and ActiveX controls.

To invoke RIES from IE7 and IE7+, go to Tools Menu, Internet Options, Advanced Tab and click on Reset… button. If Internet Explorer is in a state where it cannot be started, one can get to RIES from Internet Options in Control Panel.

After choosing Reset… from Internet Options, a confirmation dialog is displayed, warning the user about settings categories that will be reset during its operation. A help link on the dialog takes user to help pane explaining all settings that will be reset. When continued, a dialog provides feedback of progress on these categories and finally asks user to restart their Internet Explorer.

RIES resets four types of settings:

1. Resets browser settings:  All user-defined browser settings (includes those set by installed extensions, toolbars, and other add-ons) are reset to Internet Explorer defaults.  If the user running RIES has Admin privileges, then corresponding machine settings under HKLM are also reset to Internet Explorer defaults.  These settings include all customizations which one can make to Internet Explorer through Internet Options. For example: Security settings, Privacy settings, and Zone settings.

2. Resets Extensibility: All extensibility entry-points installed by the user are prevented from running automatically. Extensions that are loaded at IE startup (Toolbars, Browser Extensions, and Browser Helper Objects) are disabled; for ActiveX Controls their ActiveX Opt-in state is restored.

3. Clears Browsing History: RIES also clears Temporary Internet Files, Cookies, Browsing History, Form data, passwords and auto-complete data.

4. Re-applies Manufacturer Settings: RIES restores Internet Explorer customizations applied by the Original Equipment Manufacturers (OEMs) in the initial package applied to IE via IEAK (Internet Explorer Administrative Kit) or via the settings applied by OEMs during OS installation on the box.

Notes on RIES:

1. RIES resets all the user customizations from IE7. This also includes customizations done in IE6 and applied to IE7 after upgrade.

2. RIES disables all toolbars, Browser extensions and Customizations installed by the user. In order to use any of these disabled customizations, users will need to selectively enable them through Manage Add-ons dialog. Some toolbars may require two or more controls to be enabled (their corresponding Browser Helper Object and toolbar extensions) to work properly. An easy way to accomplish this from Manage Add-ons dialog is to enable all disabled controls from a publisher you trust.

3. For web-pages with ActiveX controls, the user will need to approve running specific ActiveX controls just as they did the first time these controls were encountered.

4. RIES does not clear Favorites and Feeds.  It also does not reset Connection settings as the settings can be used from other programs.

5. RIES does not affect Group Policy settings. All the Policies and Restrictions which are enforced by Administrators on a Domain are still respected in Internet Explorer after RIES. However, some policies that affect working of RIES are not respected while RIES is in progress. For e.g. even if Group Policy to “Turn off Delete Browsing History functionality” is enabled, RIES will go ahead and clear Temporary Internet Files. The policy will continue to work after RIES by disabling UI entry points to Delete Browsing History, but from within RIES context this GP is not in effect.

6. Administrators can reset Internet Explorer settings of all users by running RIES with admin privileges.  This affects browsing experience of users both currently using IE and those who open a new browsing session.  Hence, we suggest RIES by administrator be a planned action communicated to all affected users.

7. Many applications interact with Internet Explorer and may launch or embed it as needed.   For example, Outlook opens Internet Explorer when a user clicks on a hyperlink in an email. Such interactions with IE in the middle of an RIES operation can lead to unexpected results; hence we highly recommend closing all other applications and windows before running RIES.

8. If one or more of RIES tasks fail (identified by an X against the task in Progress dialog), the details of failed actions are logged. The logs files, ried.log and brndlog.txt, can be found in %USERPROFILE%\Local Settings\Application Data\Microsoft\Internet Explorer\.

In our experience, for machines where Internet Explorer is in a bad state, the most common request is to make recovery easy and automated. RIES is a step in that direction. We welcome your feedback to improve upon its functionality.

- Durga, Bala

The IE cumulative June 2006 security update is now available via Windows Update. Alternatively, you can receive this and all other Microsoft updates via the new Microsoft Update and I encourage you to upgrade to Microsoft Update if you haven’t already.

This update addresses 8 security issues: 5 remote code execution vulnerabilities, one information disclosure vulnerability, one information disclosure/spoofing vulnerability and one spoofing vulnerability. For more information on the contents of this update, please see:

Microsoft Knowledge Base article: MS06-021 – Cumulative Security Update for Internet Explorer (KB# 916281)

Details on the vulnerabilities and workarounds can be found at http://www.microsoft.com/technet/security/Bulletin/MS06-021.mspx.

This is a “Critical” update and affects all supported IE configurations from IE5.01 to IE6 for XPSP2 and IE6 for Server 2003 Service Pack 1. IE security updates are cumulative and contain all previously released patches for each version of IE. These security updates are already contained in IE7+ in Windows Vista Beta 2.

Also, there is a security update to resolve a remote code execution vulnerability in AOL binaries that shipped with Windows and IE. For more information on the contents of this update, please see:

Microsoft Knowledge Base article: MS06-022 - Vulnerability in ART Image Rendering Could Allow Remote Code Execution (KB# 918439)

Details on the vulnerability and workarounds can be found at http://www.microsoft.com/technet/security/Bulletin/MS06-022.mspx.

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 patches from Microsoft.

 - Charles Watanabe

The June Security Update for IE also contains a non-security change to the handling of ActiveX controls; this is the same functionality that was contained in the April IE Security update. However, unlike the April release, there is no publicly available Compatibility Patch. If your company has issues with the timeline of upgrading applications, please work with your Microsoft Account Team or specific ISV (application provider). Again, due to the nature of this topic, we are not taking comments on this post.

Kellie Eickmeyer

The transcript from the June 8^th chat is now available online. The chat was a lot of fun as we kept up with the frantic pace of answering the stream of questions in the hour available. Donuts, as usual, kept us going. Keep an eye on the chat schedule at http://www.microsoft.com/windowsxp/expertzone/chats/default.mspx for upcoming chats. We typically hold the IE chats on the second Thursday of every month.

Thanks to everyone who showed up for their feedback and we hope to see you at the next chat.

Cheers,
Uche

We got a lot of feedback that people were unable to add photos to their MSN Space using IE7 Beta 2. The MSN Spaces update fixes this issue while adding support for a lot of other cools things, like modules for daily tasks and those including Windows Live Gadgets.

So test it out, upload your photos and keep sending us your feedback.

- Anurag

My short interview with Window Snyder from Matasano has been posted over on their blog. Check it out!

-Christopher Vaughan

Hi, I’m Aaron Kornblum, Internet Safety Enforcement Attorney at Microsoft, and a member of Microsoft’s global team committed to help fight cybercrime and protect our customers while they are online.  As a parent, former Air Force prosecutor and civil litigator, and now in-house corporate counsel focused on Internet Safety, I am increasingly concerned by the proliferation of cybercrime and, in particular, online fraud such as phishing.  My IE colleagues have invited me to share with you the news of a milestone just reached in Microsoft’s Global Phishing Enforcement Initiative (GPEI): the sentencing of a convicted phisher to 21 months imprisonment and $57,000.00 restitution to victims in a federal prosecution directly supported by Microsoft.

First and foremost, I want to note that enforcement actions by government agencies and private companies are not a stand-alone solution to cybercrime.  A comprehensive approach is essential.  As you know, new technologies designed to halt online fraud – such as the Phishing Filter for IE and email authentication like Sender ID – are critically important to halting the spread of online threats.  Similarly, educating consumers about the dangers of phishing, spyware, etc., is also a key strategy.

However, Microsoft also believes it is crucial to help identify and pursue the persons responsible for actually hitting the “send” button to launch spam, phishing attacks, and other cybercrimes.  Microsoft’s Internet Safety Enforcement Team – a worldwide group of 65 attorneys, investigators, and other professionals – spearheads such investigations and legal enforcement actions, partners with law enforcement, and helps to deter would-be online criminals by growing public awareness of enforcement initiatives.  To date Microsoft has supported hundreds of enforcement actions worldwide against botnet operators, phishers, spammers, and spyware distributors, and partnered with government enforcement agencies with tools, training, and technical support.

In this regard, I’m reporting a significant sentence handed down by a U.S. federal judge to the first global phisher investigated by Microsoft and referred to federal authorities for prosecution.  The defendant in this case, Mr. Jayson Harris, 23, of Davenport, Iowa, was sentenced to 21 months imprisonment to be followed by a term of three years supervised release on each of two counts stemming from his earlier guilty plea to wire fraud and fraud and related activity in connection with access devices.  The judge further ordered Harris to pay restitution in the amount of $57,294.07 and to pay a $200 assessment to the crime victims fund.

From January 2003 to June 2004, Mr. Harris operated a phishing scheme by creating a bogus MSN billing website and then sending e-mails to MSN customers requesting that they visit the website and update their accounts by providing credit card account numbers and other personal information.  Mr. Harris provided a false incentive to these MSN customers that by using his (fake MSN) website, the customer would receive a 50% credit towards their next monthly bill from MSN.  The spoofed website transmitted victim data to an email account controlled by Mr. Harris.

Microsoft’s Internet Safety Enforcement Team tracked Harris across the Internet pursuing a variety of leads in North America and Europe and uncovered this scheme, ultimately referring the matter to the Federal Bureau of Investigation (FBI) for investigation.  A search warrant was executed at Harris’s residence by FBI agents and evidence of the phishing scam was found on the computers at Mr. Harris’ residence.  The investigation was conducted by the FBI and the Davenport Police Department with the assistance of Microsoft.

This case is just part of Microsoft’s Global Phishing Enforcement Initiative (GPEI), a global campaign targeting phishers across three primary areas:  Protecting Microsoft brands and domains online, Partnerships with government and industry, and Prosecuting worldwide investigations.

Importantly, I think that the Harris case clearly illustrates the value of public-private partnerships in pursuing cybercriminals such as phishers.  In fact, I’m writing this blog post from Bangkok, Thailand, where I am joining representatives of the U.S. Secret Service and other leading technology companies to share with prosecutors from across Asia about the importance of such partnerships to achieve greater impact in the fight against cybercrime.  Microsoft will continue to collaborate with law enforcement authorities worldwide to help protect people from cybercrime.  We hope this sentencing will help to keep our customers safe online and serve to have a deterrent effect on phishers and would-be phishers who consider profiting in this way.

AK

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