Hi! I’m Eric Lawrence, Security Program Manager for Internet Explorer. Last Tuesday, Dean wrote about our principles for delivering a trustworthy browser; today, I’m excited to share with you details on the significant investments we’ve made in Security for Internet Explorer 8. As you might guess from the length of this post, we’ve done a lot of security work for this release. As an end-user, simply upgrade to IE8 to benefit from these security improvements. As a domain administrator, you can use Group Policy and the IEAK to set secure defaults for your network. As web-developer, you can build upon some of these new features to help protect your users and web applications.

As we were planning Internet Explorer 8, our security teams looked closely at the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. While we were building new Security features, we also worked hard to ensure that powerful new features (like Activities and Web Slices) minimize attack surface and don’t provide attackers with new targets. Out of our planning work, we classified threats into three major categories: Web Application Vulnerabilities, Browser & Add-on Vulnerabilities, and Social Engineering Threats. For each class of threat, we developed a set of layered mitigations to provide defense-in-depth protection against exploits.

Web Application Defense Cross-Site-Scripting Defenses

Over the past few years, cross-site scripting (XSS) attacks have surpassed buffer overflows to become the most common class of software vulnerability. XSS attacks exploit vulnerabilities in web applications in order to steal cookies or other data, deface pages, steal credentials, or launch more exotic attacks.

IE8 helps to mitigate the threat of XSS attacks by blocking the most common form of XSS attack (called “reflection” attacks). The IE8 XSS Filter is a heuristic-based mitigation that sanitizes injected scripts, preventing execution. Learn more about this defense in David’s blog post: IE8 Security Part IV - The XSS Filter.

XSS Filter provides good protection against exploits, but because this feature is only available in IE8, it’s important that web developers provide additional defense-in-depth and work to eliminate XSS vulnerabilities in their sites. Preventing XSS on the server-side is much easier that catching it at the browser; simply never trust user input! Most web platform technologies offer one or more sanitization technologies-- developers using ASP.NET should consider using the Microsoft Anti-Cross Site Scripting Library. To further mitigate the threat of XSS cookie theft, sensitive cookies (especially those used for authentication) should be protected with the HttpOnly attribute.

Safer Mashups

While the XSS Filter helps mitigate reflected scripting attacks when navigating between two servers, in the Web 2.0 world, web applications are increasingly built using clientside mashup techniques. Many mashups are built unsafely, relying SCRIPT SRC techniques that simply merge scripting from a third-party directly into the mashup page, providing the third-party full access to the DOM and non-HttpOnly cookies.

To help developers build more secure mashups, for Internet Explorer 8, we’ve introduced support for the HTML5 cross-document messaging feature that enables IFRAMEs to communicate more securely while maintaining DOM isolation. We’ve also introduced the XDomainRequest object to permit secure network retrieval of “public” data across domains.

While Cross-Document-Messaging and XDomainRequest both help to secure mashups, a critical threat remains. Using either object, the string data retrieved from the third-party frame or server could contain script; if the caller blindly injects the string into its own DOM, a script injection attack will occur. For that reason, we’re happy to announce two new technologies that can be used in concert with these cross-domain communication mechanisms to mitigate script-injection attacks.

Safer Mashups: HTML Sanitization

IE8 exposes a new method on the window object named toStaticHTML. When a string of HTML is passed to this function, any potentially executable script constructs are removed before the string is returned. Internally, this function is based on the same technologies as the server-side Microsoft Anti-Cross Site Scripting Library mentioned previously.

So, for example, you can use toStaticHTML to help ensure that HTML received from a postMessage call cannot execute script, but can take advantage of basic formatting:

document.attachEvent('onmessage',function(e) { 
  if (e.domain == 'weather.example.com') {
      spnWeather.innerHTML = window.toStaticHTML(e.data);
  }
}

Calling:

window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

will return:

This is some <b>HTML</b> with embedded script following... !

Safer Mashups: JSON Sanitization

JavaScript Object Notation (JSON) is a lightweight string-serialization of a JavaScript object that is often used to pass data between components of a mashup. Unfortunately, many mashups use JSON insecurely, relying on the JavaScript eval method to “revive” JSON strings back into JavaScript objects, potentially executing script functions in the process. Security-conscious developers instead use a JSON-parser to ensure that the JSON object does not contain executable script, but there’s a performance penalty for this.

Internet Explorer 8 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford’s json2.js API). The JSON.stringify method accepts a script object and returns a JSON string, while the JSON.parse method accepts a string and safely revives it into a JavaScript object. The new native JSON methods are based on the same code used by the script engine itself, and thus have significantly improved performance over non-native implementations. If the resulting object contains strings bound for injection into the DOM, the previously described toStaticHTML function can be used to prevent script injection.

The following example uses both JSON and HTML sanitization to prevent script injection:

<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
      var xdr1 = new XDomainRequest();
      xdr1.onload = function(){
           var objWeather = JSON.parse(xdr1.responseText);
           var oSpan = window.document.getElementById("spnWeather");
           oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
                             + objWeather.Weather.Forecast.Tonight + "</b> in <u>" 
                             + objWeather.Weather.City+ "</u>.");
      };
      xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
      xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>

…even if the weather service returns a malicious response:

HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1

{"Weather": {
  "City": "Seattle",
  "Zip": 98052,
  "Forecast": {
    "Today": "Sunny", 
    "Tonight": "<script defer>alert('bang!')</script>Dark",
    "Tomorrow": "Sunny"
  }
}}

MIME-Handling Changes

Each type of file delivered from a web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (e.g. image, text, application, etc). For compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. In some cases, Internet Explorer reports a MIME type different than the type specified by the web server. For instance, if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, IE determines that the content should be rendered as HTML. Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is an important compatibility feature.

Unfortunately, MIME-sniffing also can lead to security problems for servers hosting untrusted content. Consider, for instance, the case of a picture-sharing web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, etc.

To combat this problem, we’ve made a number of changes to Internet Explorer 8’s MIME-type determination code.

MIME-Handling: Restrict Upsniff

First, IE8 prevents “upsniff” of files served with image/* content types into HTML/Script. Even if a file contains script, if the server declares that it is an image, IE will not run the embedded script. This change mitigates the picture-sharing attack vector-- with no code changes on the part of the server. We were able to make this change by default with minimal compatibility impact because servers rarely knowingly send HTML or script with an image/* content type.

MIME-Handling: Sniffing Opt-Out

Next, we’ve provided web-applications with the ability to opt-out of MIME-sniffing. Sending the new authoritative=true attribute on the Content-Type HTTP response header prevents Internet Explorer from MIME-sniffing a response away from the declared content-type.

For example, consider the following HTTP-response:

HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;

<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>

In IE7, the text is interpreted as HTML:

In IE8, the page is rendered in plaintext:

Sites hosting untrusted content can use the authoritative attribute to ensure that text/plain files are not sniffed to anything else.

MIME-Handling: Force Save

Lastly, for web applications that need to serve untrusted HTML files, we have introduced a mechanism to help prevent the untrusted content from compromising your site’s security. When the new X-Download-Options header is present with the value noopen, the user is prevented from opening a file download directly; instead, they must first save the file locally. When the locally saved file is later opened, it no longer executes in the security context of your site, helping to prevent script injection.

HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html

Taken together, these new Web Application Defenses enable the construction of much more secure web applications.

Local Browser Defenses

While Web Application attacks are becoming more common, attackers are always interested in compromising ordinary users’ local computers. In order to allow the browser to effectively enforce security policy to protect web applications, personal information, and local resources, attacks against the browser must be prevented. Internet Explorer 7 made major investments in this space, including Protected Mode, ActiveX Opt-in, and Zone Lockdowns. In response to the hardening of the browser itself, attackers are increasingly focusing on compromising vulnerable browser add-ons.

For Internet Explorer 8, we’ve made a number of investments to improve add-on security, reduce attack surface, and improve developer and user experience.

Add-on Security

We kicked off this security blog series with discussion of DEP/NX Memory Protection, enabled by default for IE8 when running on Windows Server 2008, Windows Vista SP1 and Windows XP SP3. 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. You can read more about this defense in the original blog post: IE8 Security Part I: DEP/NX Memory Protection.

In a follow-up post, Matt Crowley described the ActiveX improvements in IE8 and summarized the existing ActiveX-related security features carried over from earlier browser versions. The key improvement we made for IE8 is “Per-Site ActiveX,” a defense mechanism to help prevent malicious repurposing of controls. IE8 also supports non-Administrator installation of ActiveX controls, enabling domain administrators to configure most users without administrative permissions. You can get the full details about these improvements by reading: IE8 Security Part II: ActiveX Improvements. If you develop ActiveX controls, you can help protect users by following the Best Practices for ActiveX controls .

Protected Mode

Introduced in IE7 on Windows Vista, Protected Mode helps reduce the severity of threats to both Internet Explorer and extensions running in Internet Explorer by helping to prevent silent installation of malicious code even in the face of software vulnerabilities. For Internet Explorer 8, we’ve made a number of API improvements to Protected Mode to make it easier for add-on developers to control and interact with Protected Mode browser instances. You can read about these improvements in the Improved Protected Mode API Whitepaper.

For improved performance and application compatibility, by default IE8 disables Protected Mode in the Intranet Zone. Protected Mode was originally enabled in the Intranet Zone for user-experience reasons: when entering or leaving Protected Mode, Internet Explorer 7 was forced to create a new process and hence a new window.

Internet Explorer 8’s Loosely Coupled architecture enables us to host both Protected Mode and non-Protected Mode tabs within the same browser window, eliminating this user-experience annoyance. Of course, IE8 users and domain administrators have the option to enable Protected Mode for Intranet Zone if desired.

Application Protocol Prompt

Application Protocol handlers enable third-party applications (such as streaming media players and internet telephony applications) to directly launch from within the browser or other programs in Windows. Unfortunately, while this functionality is quite powerful, it presents a significant amount of attack surface, because some applications registered as protocol handlers may contain vulnerabilities that could be triggered from untrusted content from the Internet.

To help ensure that the user remains in control of their browsing experience, Internet Explorer 8 will now prompt before launching application protocols.

To provide defense-in-depth, Application Protocol developers should ensure that they follow the Best Practices described on MSDN.

File Upload Control

Historically, the HTML File Upload Control (<input type=file>) has been the source of a significant number of information disclosure vulnerabilities. To resolve these issues, two changes were made to the behavior of the control.

To block attacks that rely on “stealing” keystrokes to surreptitiously trick the user into typing a local file path into the control, the File Path edit box is now read-only. The user must explicitly select a file for upload using the File Browse dialog.

Additionally, the “Include local directory path when uploading files” URLAction has been set to "Disable" for the Internet Zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path C:\users\ericlaw\documents\secret\image.png, Internet Explorer 8 will now submit only the filename image.png.

Social Engineering Defenses

As browser defenses have been improved over the last few years, web criminals are increasingly relying on social engineering attacks to victimize users. Rather than attacking the ever-stronger castle walls, attackers increasingly visit the front gate and simply request that the user trust them.

For Internet Explorer 8, we’ve invested in features that help the user make safe trust decisions based on clearly-presented information gathered from the site and trustworthy authorities.

Address Bar Improvements

Domain Highlighting is a new feature introduced in IE8 Beta 1 to help users more easily interpret web addresses (URLs). Because the domain name is the most security-relevant identifier in a URL, it is shown in black text, while site-controlled URL text like the query string and path are shown in grey text.

When coupled with other technologies like Extended Validation SSL certificates, Internet Explorer 8’s improved address bar helps users more easily ensure that they provide personal information only to sites they trust.

SmartScreen® Filter

Internet Explorer 7 introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites. For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks millions of phishing attacks per week) and developed the SmartScreen® Filter. The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software which attempts to attack your computer or steal your personal information. SmartScreen works in concert with other technologies like Windows Defender and Windows Live OneCare to provide comprehensive protection against malicious software.

You can read more about the new SmartScreen Filter in my earlier post: IE8 Security Part III - The SmartScreen Filter.

Summary

Security is a core characteristic of trustworthy browsing, and Internet Explorer 8 includes major improvements to address the evolving web security landscape. While the bad guys are unlikely to ever just “throw in the towel,” the IE team is working tirelessly to help protect users and provide new ways to enhance web application security.

Please stay tuned to the IEBlog for more information on the work we’re doing in Privacy, Reliability, and Business Practices to build a trustworthy browser.

Onward to Beta-2 in August!

Eric Lawrence
Program Manager
Internet Explorer Security

Hi, I'm David Ross, Security Software Engineer on the SWI team.  I’m proud to be doing this guest post on the IE blog today to show off some of the collaborative work SWI is doing with the Internet Explorer team.

Today we are releasing some details on a new IE8 feature that makes reflected / “Type-1” Cross-Site Scripting (XSS) vulnerabilities much more difficult to exploit from within Internet Explorer 8. Type-1 XSS flaws represent a growing portion of overall reported vulnerabilities and are increasingly being exploited “for fun and profit.”

The number of reported XSS flaws in popular web sites has skyrocketed recently – MITRE has reported that XSS vulnerabilities are now the most frequently reported class of vulnerability. More recently, sites such as XSSed.com have begun to collect and publish tens of thousands of Type-1 XSS vulnerabilities present in sites across the web.

XSS vulnerabilities enable an attacker to control the relationship between a user and a web site or web application that they trust. Cross-site scripting can enable attacks such as:

• Cookie theft, including the theft of sessions cookies that can lead to account hijacking
  
  
• Monitoring keystrokes input to the victim web site / application
  
  
• Performing actions on the victim web site on behalf of the victim user. For example, an XSS attack on Windows Live Mail might enable an attacker to read and forward e-mail messages, set new calendar appointments, etc.

While many great tools exist for developers to mitigate XSS in their sites / applications, these tools do not satisfy the need for average users to protect themselves from XSS attacks as they browse the web.

XSS Filter -- How it Works

The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.

With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification like the following:

The page has been modified and the XSS attack is blocked.

In this case the XSS Filter has identified a cross-site scripting attack in the URL.  It has neutered this attack as the identified script was replayed back into the response page.  In this way the filter is effective without modifying an initial request to the server or blocking an entire response.

As you may imagine, there are a number of interesting and subtle scenarios that the filter must handle appropriately. Here are some examples:

• The filter must be effective even if the attack is adjusted to leverage artifacts of common web application frameworks.  Ex: Will an attack still be detected if certain characters in a request are dropped or translated when replayed in the response?
  
  
• In performing filtering our code must not introduce new attack scenarios that would not otherwise exist.  Ex: Imagine the filter can be forced to neuter a closing SCRIPT tag.  In that case, untrusted content on the page might then execute as script.

And of course in addition to all of this we need to effectively counter all the XSS attack vectors not already addressed by other XSS-Focused Attack Surface Reduction measures.

Compatibility is critical. This feature was developed with the understanding that if it were to “break the web,” we could not enable the feature by default. Or if we did, people would turn it off and get no benefit. We really want to provide as much value as possible to the maximum number of users.

If Internet Explorer’s Application Compatibility Logging is enabled, all XSS Filter activity can be viewed using the Microsoft Application Compatibility Toolkit.

Web developers may wish to disable the filter for their content. They can do so by setting a HTTP header:
X-XSS-Protection: 0

Ultimately we have taken a very pragmatic approach – we choose to not to build the filter in such a way that we compromise site compatibility. Thus, the XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea.  This is similar to the pragmatic approach taken by ASP.Net request validation, although the XSS Filter is able to be more aggressive than the ASP.Net feature.

Assuming negligible site compatibility and performance impact, the fact that our filter effectively blocks the common “><script>… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.

Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8. (Not to mention the IFRAME SEO Poisoning attacks we protect against as well!)

I will go into more details on how the filter works, its history, its limitations, and some lessons learned during the development process over on my blog in the coming weeks.

David Ross
Security Software Engineer

As someone whose email address is posted in thousands of forum posts, newsgroup discussions, and blogs, I get a lot of spam. Of the spam I receive, a significant number of messages represent phishing attacks. Most of these lures aren’t very clever or convincing, but phishing has become a simple numbers game—hosting phishing sites is cheap, and even if only a few users fall for any given phishing attack, attackers will profit by increasing the volume of phishing campaigns.

In Internet Explorer 7, we introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites, and worked with partners to introduce Extended Validation certificates that light up the address bar when users visit sites with verified identity information. Beyond the Phishing Filter, Microsoft has also published educational materials on identifying phishing scams, and developed a strategy to attack phishing at multiple levels.

For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks over a million phishing attacks weekly) to develop the SmartScreen® Filter, a replacement that improves upon the Phishing Filter in a number of important ways:

• Improved user interface
• Faster performance
• New heuristics & enhanced telemetry
• Anti-Malware support
• Improved Group Policy support

I’ll describe each of these in the sections that follow.

Improved User Interface
First, we’ve simplified the opt-in experience for the SmartScreen Filter, integrating the option into the IE first-run experience. After first-run, you can later change your preferences easily by using the option on the classic Tools menu.

Next, the bold new SmartScreen blocking page offers clear language and guidance to help you avoid known-unsafe websites. Here’s a screenshot from a recent phishing site I encountered:

The “Go to my homepage” link enables you easily to navigate away from the unsafe website to start browsing from a trusted location. If you instead choose to ignore the SmartScreen warning by clicking the “Disregard and continue” link, the address bar remains red as a persistent warning as long as you are on the unsafe site.

If you uncover a new phishing site, you can submit it for analysis using the “Report Unsafe Website” option on the Tools menu. In the unlikely event of a false-positive, you can provide feedback using the “Report that this is not an unsafe website” link on the blocking page or by clicking the “Unsafe Website” flyout in the address bar.

Improved Performance
As a part of our overall investment in improving performance across Internet Explorer, we’ve made several performance tweaks to the SmartScreen Filter to improve its speed and lower its impact on browser performance. Detection of unsafe sites happens in parallel with navigation, so you can confidently surf the web without being forced to make a tradeoff between speed and safety.

New heuristics & telemetry
As attackers have evolved their phishing sites in an attempt to avoid being recognized and blocked, the SmartScreen Filter has also evolved to catch more phish than ever before. New heuristics, developed with help from security research teams across Microsoft, are able to evaluate more aspects of web pages to detect suspicious behavior. These new heuristics, combined with enhanced telemetry, allow the URL Reputation Service to identify and block phishing sites faster than ever.

In rare cases, SmartScreen will request feedback on sites of unknown reputation, as shown in this screenshot:

User feedback about unknown sites is collected by the SmartScreen web service and quickly evaluated to block new phish as they are discovered in the wild.

Anti-Malware Support
The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software that attempts to attack your computer or steal your personal information. There are many types of malware, but most types can impact your privacy and security. The SmartScreen anti-malware feature is URL-reputation-based, which means that it evaluates the servers hosting downloads to determine if those servers are known to distribute unsafe content. SmartScreen’s reputation-based analysis works in concert with other signature-based anti-malware technologies like the Malicious Software Removal Tool, Windows Defender, and Windows Live OneCare, in order to provide comprehensive protection against malicious software.

If you are lured to a site known to distribute malware, the SmartScreen blocking page is displayed and indicates that the server is known to distribute unsafe software:

On the other hand, if you click on a direct link to a download (from an instant message, for instance) hosted by a known-malicious site, the Internet Explorer download dialog will interrupt the download to warn you of the threat:

SmartScreen’s anti-malware feature complemented by the IE8 features that combat malicious repurposing or exploit of browser add-ons, helps to protect you from a full range of malicious websites.

Group Policy Support
Group Policy can be used to enable or disable the SmartScreen Filter for Internet Explorer users across an entire Windows domain. A new Group Policy option is available that allows domain administrators to block users from overriding SmartScreen Filter warnings. When Group Policy restrictions are enabled, the option to override the SmartScreen warning screen is removed from the blocking pages and download dialog.

Privacy
As outlined in Dean’s post last week, Privacy is a core component of trustworthy browsing. As with IE7, Microsoft remains committed to helping ensure users’ privacy while providing protection from unsafe websites. URL data submitted to the SmartScreen web service for evaluation is transmitted in encrypted format over HTTPS. The data is not stored with a user's IP address or other personally identifiable information. Because user privacy is important in all Microsoft's products and technologies, Microsoft has taken steps to help ensure that no personally identifiable information is retained or used for purposes other than improving online safety; data will not be used to identify, contact, or provide advertising to users. You can read more in our privacy statement.

Conclusion
Web criminals are increasingly relying on social engineering attacks to engage in their criminal enterprises, but we’re working hard to deliver the tools to help keep you safe on the web. The IE8 SmartScreen Filter is designed to combat both phishing and malware sites while protecting your privacy and enabling high-performance browsing. I strongly recommend you enable the SmartScreen Filter and give it a spin in IE8 Beta 2, due in August.

Please stay tuned to the IEBlog for further posts on IE8 Security improvements!

Eric Lawrence
Program Manager
Internet Explorer Security

This blog post frames our approach in IE8 for delivering trustworthy browsing. The topic is complicated enough that some context and even history (before we go into any particular feature) is important, and so some readers may find this post a bit basic as it’s written for a wide audience. In previous posts here, we’ve written about IE8 for developers: the work in standards support, developer tools, script performance, and more. In future posts, we’ll write about IE8 for end-users (beyond the benefits of improved performance, activities, and Web Slices). This post starts a series about trustworthy browsing, a topic important for developers and end-users and everyone on the web. By setting the context and motivation with this post, the next posts that dive into the details of IE8 will build on this foundation.

Trustworthy refers to one of our overall goals: provide the most secure and most reliable browser that respects user choice and keeps users in control of their machine and their information. For reference, Microsoft’s framework for Trustworthy Computing in general spans four areas: security, privacy, reliability, and business practices.

Security is often where the trust discussion begins. Narrowly, security in this context means “as the user browses the web, the only code that runs on the user’s machine is code that the user allows to run". For example, when the user visits “www.somebadsite.com” the site should not be able to just run “virus.exe” and infect the user’s machine with malware. IE7 made a lot of progress on security, starting with Protected Mode and developing IE to be “secure by design, secure by default” as part of the following SDL requirements. IE7 was the first browser to support Extended Validation certificates to help protect users from deceptive websites, as well as delivering anti-phishing protection, International Domain Name support with protection from deceptive websites, a richer SSL experience and support for stronger SSL cipher algorithms, ActiveX opt-in, and great integration with Parental Controls in Windows Vista. We have done even more security work in IE8 to address the evolving threat environment.

Privacy is a complex topic that more often than not puts one party in conflict with another. If security boils down to “the user is in control of what code runs on the machine,” then privacy boils down to “the user is in control of what information the browser makes available to websites". Many people immediately think of “cookies” at this point because so much discussion and early work around privacy focused on the specific implementation of cookies. Cookies and cookie protection are definitely one aspect of the online privacy discussion. IE6 included innovative work implementing the P3P web standard (from the W3C), and both IE6 and IE7 use it to block cookies from websites that don’t have a privacy policy that complies with the user’s settings. It’s a great example of a privacy protection in use today on the web. In IE7, deleting cookies as well as other information that shows where the user has been on the web is much easier.  That said, there’s more to online privacy than cookies, as cookies are only one implementation of content that can disclose information to websites. In some discussions, people have also described IE7’s Phishing Filter as a privacy feature because it helps protect users from sharing information. The larger challenge here is notifying users clearly about what sites they’re disclosing information to and enabling them to control that disclosure if they choose. As we talk more about privacy, we will broaden the discussion to include additional protections from sharing information that the browser can offer users.

Reliability is relatively simple: the browser should always start, find the Internet, and show web sites without crashing. We define reliability to mean “as the user browses the web, the browser performs well and does not terminate unexpectedly". End-users really don’t care about the cause of instability in the system – malformed web pages (see the old Slashdot article that this post refers to, for example) or third-party extensions (like toolbars; see this post about IE7’s “No Add-ons” functionality) – they just want the browser to work. In addition, when something does go wrong, an important part of reliability is how gracefully the browser recovers from the unexpected. Another aspect of reliability is that sites continue to render correctly. We’ll post more here about the work we’ve done to make IE8 more robust, as well as more interoperable and compatible at the same time.

Business practices guide decisions we make in designing and distributing our products. The key principle here is respecting user choice. For example, when a user installs a new version of IE, IE respects the user’s choice of default search engine. In IE, the user can add or remove different search providers using OpenSearch, a public and open standard that some other browsers have chosen to support as well. IE respects the user’s choice of system defaults (Windows Vista’s “Default Programs” functionality, as well as Windows XP’s Set Program Access Defaults). Explicitly asking the user before installing a new version of IE is key to respecting the user’s browser choice. 

Ultimately, trustworthy browsing is about enabling users to be in control and respecting the choices users make. Specifically, it’s about enabling users to be in control of their machine, of their browser, of their settings, of their experience, of what data they share with whom when. Each part of trustworthy browsing involves an industry-wide challenge. For example, security is an industry challenge; every browser on the web faces attacks.

While all these statements may sound inherently obvious to some readers, these topics are so important that we thought it would be good to talk in general about how we think about them overall.  Over the coming weeks this blog series will talk about how we’re making progress against these challenges, to set the stage for the release of IE8 Beta 2 in August.

Thanks,

Dean Hachamovitch
General Manager
Internet Explorer

Edit: removed hyperlink

Today we released the IE June Cumulative Security Update for Internet Explorer 8 Beta 1 for Developers on Windows Update. For detailed information on the contents of this update, please see the following documentation:

• IE Blog Post: IE June Security Update Now Available
• Microsoft Knowledge Base Article 950759

If you are using IE8 Beta 1 for Developers, we encourage you to download this security update through Windows Update  or the Microsoft Download Center today.

Terry McCoy
Program Manager
Internet Explorer Security

Edit: removed "today" from first sentence

As I mentioned in my post on Cross Document Messaging, client side cross domain request is an important area of interest for AJAX developers looking for ways to avoid expensive server side proxying calls. While Cross Document Messaging is useful for allowing third party components or gadgets embedded in a page to communicate/converse using script on both sides, other cross domain scenarios like web services require access to cross domain content using network requests from a client side web application. For example, you may want to use your client side map based mashup to pinpoint Chinese restaurants for your current neighborhood. This could require the mashup to request a text file from Zagat.com with the locations of Zagat rated restaurants in the area which can then be superimposed on the map.

Along those lines, a few proposals and implementations exist like XDomainRequest in IE8, JSONRequest and the W3C’s Web Applications Working Group’s Cross Site XMLHttpRequest (CS-XHR) draft specification, which combines an Access control framework with XMLHttpRequest or other features. While XDomainRequest is focused on enabling anonymous access of third party public data, Cross Site XMLHttpRequest has added functionality and consequently enables a broader set of scenarios that may appeal to the developer who may choose to use cross domain authentication and access control among other features.  As can be expected with securing a large cross section of cross domain scenarios, a number of concerns have been identified with the CS-XHR draft by the web development community, the IE team members and members of the Web Apps Working Group. For a list of our recent feedback on security on CS-XHR and our take on important security principles in cross domain, please read our Security Whitepaper on Cross Domain. The paper also covers best practices and guidance for developers who will choose to build on the current draft if it’s supported by a future browser. Note that issues here are currently being discussed and some concerns may be mitigated as the draft evolves.

Meanwhile, your participation in the Web Apps Working Group can add a broader perspective and help raise further issues in the draft so that browser vendors like us can implement it in the future, so if you want to help, sign up with the Web Applications Working Group public alias!

For all those of you who would like cross domain public data and want it soon, there’s XDomainRequest in IE8. We’d love to hear feedback on XDR, and from projects that have been built using it. Hit the comments section with links or just email them to me. I’ll be blogging more about this feature in a few weeks!

Sunava Dutta
Program Manager

As James and I mentioned in our blog post What’s coming in IE8 for IT Pros?, IE8 can now be slipstreamed into Vista and Window Server 2008 OS images. If you manage the desktop images for your organization, slipstream saves you time by simplifying the task of adding Internet Explorer 8 and any IE updates. If you’re adding Internet Explorer 7 to a Windows XP image you’ll typically install XP and then add IE7 before capturing the image -this can take 2 hours! With IE8 and Windows Vista, you are able to integrate IE8 into the image file of the original operating system in about 15 minutes. No more booting the OS image, manually installing IE and re-capturing the image. The slipstreaming support also extends to IE8 cumulative updates and language packages. Slipstreaming IE8 into an OS image will only be supported on Vista and Windows Server 2008 platforms. Windows XP and Windows Server 2003 do not currently offer a solution for slipstreaming Windows components, which are built using update.exe.

Here are the steps to create a Vista image with IE8 being the out of box browser by default. You can try this yourself with IE8 beta1.

Preparation

1.  Install Windows Automated Install Kit

The Windows Automated Install Kit (WAIK) is a tool available for Vista and Windows Server 2008 to manage and customize OS images. This is the tool you’ll be using to slipstream IE8. Download a version of WAIK that matches your local machine configuration (not the image you’ll be slipstreaming IE8 into).

Note: Using a WAIK x64 bit version for a Vista x86 image will not work. For more information, please refer to the WAIK Readme.

2.  Create the Vista directory

Copy the Vista directory from the CD onto your local machine.  

3.  Create 3 temp folders: Mount, Pkg, Sandbox

You can name each folder whatever you want, however remember the purpose of each folder created.

For this example, I created:

c:\slipstreaming\mount
c:\slipstreaming\pkg
c:\slipstreaming\sandbox.

Your final folder structure should look something like this:

4. Download IE8 Beta 1

Download IE8 Beta1 to your local machine from here. For this example, I saved the IE8 Beta1 exe in c:\Slipstreaming\IE8x86en

5. Extract and expand the MSU file

From the IE8 exe file:

• To extract the MSU, in the command prompt run this <IE8.exe path> /x: <folder you want the MSU to be placed>. For example: c:\Slipstreaming\IE8x86en\IE8-WindowsVista-x86-enu.exe /x: c:\Slipstreaming\IE8x86en
  
  
• To expand the MSU, in the command prompt run this expand.exe <path to the IE8.MSU> -F:* <pkg folder>. For example: expand.exe c:\Slipstreaming\IE8x86en\IE8.MSU -F:* c:\Slipstreaming\pkg

Slipstream

1. Mount the Vista install image to your temporary location.

In the command prompt, run this imagex.exe /mountrw install.wim <imagenumber> <mountfolder>

For this example: I am slipstreaming IE8 into Vista Ultimate which has the imagenumber = 4. The command I ran is as such "C:\Program Files\Windows AIK\Tools\x86\imagex.exe" /mountrw C:\Slipstreaming\VistaSP1x86en\sources\install.wim 4 C:\Slipstreaming\mount

If you don’t know the image number of the OS image you are using, you can use the arbitrary large number instead of 4 in the command above like this: imagex.exe /dir c:\VistaRTM\sources\install.wim 20. This triggers help information to be displayed. From the output in your command prompt, choose the SKU that you are using and the IMAGE INDEX is the <imagenumber> that you need.

2. Slipstream IE8 into the Vista image.

If you are using Vista Gold image, you need to change a read only attribute flag prior to executing a slipstream command: attrib -R "<mountfolder>\Windows\Offline Web Pages"

For example: attrib -R "C:\Slipstreaming\mount\Windows\Offline Web Pages"

Now, you are ready to slipstream IE8. Run this in the command prompt: pkgmgr.exe /n:<package folder>\WindowsVista-KB#-NEUTRAL.xml /o:”<mount folder>;<mount folder>\windows” /s:<sandbox> /l:<where you want the log file to be stored>. Ensure the pkgmgr.exe you use is the one installed with the WAIK tools.

For example: "c:\Program Files\Windows AIK\Tools\x86\Servicing\pkgmgr.exe" /n:"c:\Slipstreaming\pkg\Windows6.0-KB944036-x86.xml" /o:""c:\Slipstreaming\mount";"c:\Slipstreaming\mount\windows"" /s:"c:\Slipstreaming\sandbox" /l:"c:\Slipstreaming\slp.log"

Once the slipstreaming command is finished successfully, the slp.log will say “exit code 0x00”.

Remember to add the read only attribute flag back after slipstreaming is complete if using a Vista Gold image: attrib +R "<mountfolder>\Windows\Offline Web Pages"

For example: attrib +R "C:\Slipstreaming\mount\Windows\Offline Web Pages"

3. Save the changes.

Use imagex.exe to save the changes: imagex /commit /unmount <mountfolder>

For this example: "c:\Program Files\Windows AIK\Tools\x86\imagex.exe" /commit /unmount c:\Slipstreaming\mount

You are all done!!! The Vista install image on your local machine is the new Vista build with IE8 slipstreamed.

Since IE8 is part of the Vista image, you can customize it by creating an answer.xml file and running Vista setup with unattend option as such: <VistaPath>\setup.exe /unattend:<answer.xml path>

The Unattended Windows install option enables customization of the OS install, and the answer.xml file provides the “answers” for customizations and drives the unattended install.

You can find more about unattend installs and answer files here:

• Unattended Documentation (This documentation is also included in the WAIK)
• IE Settings customizable via unattend

After you install the final image, IE8 beta1 will appear under installed updates as such and can be uninstalled in the same way as when installing IE8 standalone.You will be reverted to IE7 if you choose to uninstall IE8.

Thanks,

Jane Maliouta
IE Deployment Program Manager

Join members of the Internet Explorer team for an Expert Zone chat next Thursday, June 19th  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. Thank you to all who have attended the chats to date!

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

P.S. Upcoming IE chat dates for July and August 2008 are posted here. If circumstances arise that cause us to reschedule a chat, I'll give fair warning on the IE Blog and provide the new date.

Yesterday at Tech Ed IT Pro 2008 in Orlando we announced some of the enhancements we’re making in Internet Explorer 8 to help IT Professionals deploy and manage IE8 within their organization. We wanted to share those with the IT Pros on our blog.

Over the last year we’ve surveyed over 2000 IT Professionals to understand their concerns and priorities for deploying and managing desktops and software within their organization. We learned that IT Pros have a lot of things to worry about - more than 30 different concerns came up. However, some topics arose considerably more frequently than others. Here are the top ones:

• Deployment and implementation of new technology
• Managing updates and upgrades
• Application compatibility
• Security of data, network and systems

Internet Explorer 7 already has a pretty strong deployment and management story. For IE7 IT Pros are able to:

• Generate customized builds that include company’s settings and branding by using Internet Explorer Administration Kit(IEAK)
• Centrally manage browser settings through group policy
• Use common deployment infrastructures like Windows Update, Windows Server Update Services, Systems Management Server and Active Directory

In addition to deployment and management support, IE 7 introduced a number of features intended to help your users browse more safely and hence protect your corporate data, network and systems:

• Phishing Filter
• ActiveX Opt-in
• Extended Validation Certificates

IE7 did a lot to address the concerns of the IT Professionals but we felt there were some places we could improve. Yesterday, we announced some of our new features:

Slipstream Support in Internet Explorer 8

We got consistent feedback from customers that deploying Internet Explorer 7 as part of Windows XP is hard. Many IT Pros want to update their Windows XP images to contain IE7 by default, so IE7 gets installed as part of the OS install. To do that the IT Pros need to boot their existing images of Windows XP, install IE7 and then recapture the image. This process roughly takes 2 hours per image.

With Internet Explorer 8 and Windows Vista you’ll be able to “Slipstream” Internet Explorer 8 into a Vista image so that when you deploy Vista it already contains Internet Explorer 8. To slipstream IE8 only takes 10-15 minute per image. You’ll also be able to slipstream IE8 cumulative updates so that you are shipping the most up to date and secure image.

Look out for a forthcoming post to learn more about Slipstreaming IE8.

Application Compatibility and Internet Explorer 8

You have seen a lot of discussion on this blog about our decision to ship Internet Explorer 8 with standards mode switched on by default. Today, not all sites are built to conform to web standards so we’ve given end users and developers control over how sites display in IE8.

How about IT Professionals? For one, we're adding new events to the Application Compatibility Toolkit (ACT) that help you detect and resolve potential issues between IE8 and your internal applications and web sites. For another, we're providing Group Policy settings that help you control, with great granularity, those settings that most impact compatibility. Lastly, we're looking at how to intelligently solve this problem for intranets - providing the greatest application and web site compatibility while still maintaining our core tenets of security, performance, and reliability.

Security in Internet Explorer 8

The Internet has changed the way that people live and work. People are spending more and more time on the web but this growth in web usage also attracted people who have malicious intent. From phishing scams to sites which install malware, the web can be a dangerous place to be. Who hasn’t had to jump across the keyboard/mouse to stop a friend or loved one visiting a phishing site or installing a piece of suspicious software? What happens when that person doesn’t have their tech-savvy friend watching over their shoulder?

Did you know that more than $3 billion has been lost in Phishing scams? The browser – and particularly in IE8 - plays an important role in helping protect users against a range of attacks, from social attacks like phishing to browser based exploits.

Rather than cover those features here, we’ve already posted information about some of the ways we’re helping your users browse more safely:

• Per User and Per Site ActiveX
• Cross Document Messaging

There’s more to come around security in later blog postings.

Updates to the IEAK

The internet Explorer Administration Kit (IEAK) enables IT Pros to customize IE for their company’s needs. You might be familiar with this tool since it was available for IE6 and IE7. In IE8, IEAK is getting a facelift. We have fixed a number of bugs and added some enhancements to improve the performance of IEAK. IEAK8 will support custom IE8 builds for new platforms: Vista and Windows Server 2008 and new IE8 features like Activities and Web Slices.

Stay tuned for a follow-up blog post that will contain more detail about IEAK8.

Wrap Up

We plan to include all of the above mentioned features in our Beta 2 release which is planned for August 2008. As always when developing software, features can get cut or postponed if we find bugs that affect ship quality but right now we’re on track to have these features for Beta 2.

IE7 was a great browser to deploy and manage in an enterprise or business environment. With IE8, we’re doubling down on that investment to make sure that we have the best browser to deploy and manage in an enterprise environment.

Jane Maliouta - IE Program Manager
James Pratt - IE Product Manager

Bill Gates’ recent Tech Ed keynote and Tony Chor’s follow-up blog announced that IE8 Beta 2 will be available in August in many languages. We are encouraging sites to get ready for Beta 2 prior to release as it will present a big jump in IE8 browsing traffic.

What does “getting ready for IE8” mean for web sites?  IE8 displays content in IE8 Standards mode – its most standards-compliant layout mode – by default.  In previous blog posts, we’ve discussed how this aligns with our commitment to Web standards interoperability. However, browsing with this default setting may cause content written for previous versions of IE to display differently than intended. This creates a “get ready” call to action for site owners to ensure their content will continue to display seamlessly in IE8.

The preferred response to this call to action is to update the site to ensure that IE8 is provided with standards content fitting the DOCTYPE. However, we know it is very important to give site owners the chance to update site content on their schedule without affecting user experience. As such, we provide a meta-tag that tells IE8 to display an entire site or a specific page like it did in IE7.

In IE8 Beta 1, that option is the “IE=7” X-UA-Compatible tag, which instructs IE8 to display content in IE7 Standards mode. However, the scenario this doesn’t address is when IE=7 is applied as an HTTP header to a site that contains Quirks mode pages. The IE=7 HTTP header will force all pages – both Quirks and Standards – to display in IE7 Standards mode. Developers using this header while updating their sites would then have to add the “IE=5” <META> tag to each page they want to keep in Quirks mode. This logic is fine for many websites. However, if a site has lots of Quirks mode pages, or for the case where pages with frames host a mix of Strict and Quirks mode content – as brought to light by IE8 Beta 1 user feedback – the compatibility opt-out adds a bit more work than we intended.

In response to the great IE8 Beta 1 feedback we’ve received so far, we are introducing the “IE=EmulateIE7” tag to address this problem. EmulateIE7 tells IE8 to display standards DOCTYPEs in IE7 Standards mode, and Quirks DOCTYPEs in Quirks mode. We believe this will be the preferred IE7 compatibility mode for most cases. Support for IE=EmulateIE7 is available now as part of the IE June Security Update for IE8 Beta 1. Installing this update will enable you to verify you’ve applied the EmulateIE7 tag to your site correctly.

In summary, IE7 compatibility support looks as follows:

Content Value

Details

IE=7

Display in IE7 Standards mode; Already supported in the IE8 Beta 1 release

IE=EmulateIE7

Display standards DOCTYPEs in IE7 Standards mode; Display quirks DOCTYPEs in Quirks mode; Available through the IE June Security Update for IE8 Beta 1

There are two ways to implement this tag:

• On a per-site basis, add a custom HTTP header

X-UA-Compatible: IE=EmulateIE7

• On a per-page basis, add a special HTML tag to each document, right after the <head> tag

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Implementing the HTTP header is beneficial if a site owner wants most of their site to render as it did in IE7 or if there are no plans to update site content. Inclusion of this header honors any Quirks mode pages that belong to the site.

Using the meta-tag on a per-page basis is beneficial when the publisher wants to opt-in specific pages to render as they did in IE7.

NOTE: The X-UA-Compatible tag and header override any existing DOCTYPE. Also, the mode specified by the page takes precedent over the HTTP header. For example, you could add the EmulateIE7 HTTP header to a site, and set specific pages to display in IE8 mode (by using the meta-tag with content=”IE8”).

Using the IE=EmulateIE7 compatibility tag is a simple way for users to continue their current experience when browsing your site until you can update with more standards-compliant content.  Although adding this tag will prevent most display issues, you may also need to update your site to properly detect IE8.  To learn more about IE8 document compatibility and browser detection, check out the IE Compatibility Center.

Jefferson Fletcher
Product Manager
Internet Explorer

P.S.: Here are some links to reference for adding custom HTTP headers on various versions of IIS and Apache servers:  IIS7.0, IIS6.0, Apache 2.2, Apache 2.0, Apache 1.3

The IE Cumulative Security Update for June 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 vulnerability and 1 information disclosure vulnerability. This security update addresses these vulnerabilities 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-031
• Microsoft Knowledge Base Article 950759

The security update is rated Critical for Internet Explorer 6 Service Pack 1; Internet Explorer 6 on supported versions of Windows XP; and Internet Explorer 7 on supported versions of Windows XP and Windows Vista. The security update is rated Important for Internet Explorer 5.01 on Microsoft Windows 2000 Service pack 4, and Moderate for all other supported releases of Internet Explorer. 6

If you are currently using Internet Explorer 8 Beta 1 for Developers, please see Microsoft Knowledge Base Article 951804 for update details. 

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

In addition to the features for developers we showed in IE8 Beta 1, we’ve been working on great new features for consumers and IT professionals (as well as doing even more cool stuff for developers). I’m happy to announce that we’re on track to deliver IE8 Beta 2 this August when you’ll get a chance to see what we’ve been up to in these areas. Furthermore, in order to help us get even more feedback for this global product, we’ll be releasing Beta 2 in over twenty languages within a month of the initial release. This is a big step up from the three languages we released for beta 1 and much more than we ever did during IE7.

On behalf of the team, I’d like to thank you all for your help with beta 1. Since we released Beta 1 in March we’ve had over two million downloads so far with lots of good, useful feedback. We’ve been listening to that feedback and making improvements to our work on an interoperable platform that has full CSS 2.1 support, faster script performance, and significantly more capable developer tools as well as our cool new features like Activities and Web Slices. We’ve learned a lot from this first beta – keep the comments coming please!

Between now and August, there are a few ways you can prepare your sites for Beta 2. First, take advantage of Activities and Web Slices on your site. Second, make sure your site looks great in IE8; as you may recall, IE8 will use our new, more standards-compliant layout and rendering engine for strict doctype pages by default. This may cause IE8 to layout pages differently than IE7 did. If you haven’t had a chance to test your pages yet or don’t want to make changes yet, remember that you can have your site tell IE to use our IE7 layout engine for your strict doctype pages by adding the X-UA-Compatible http header to your HTTP headers or on a per document basis. You can learn more about how to ensure site compat with IE8 on our new IE Compat pages.

Tony Chor
Group Program Manager

P.S. In case you’re curious here’s the list of languages/locales we’re planning on for beta 2. We’ll keep evaluating the list based on our progress.

Arabic
Chinese (Hong Kong)
Chinese (Simplified)
Chinese (Traditional)
Czech
Danish
Dutch
English
Finnish
French
German
Greek
Hebrew
Hungarian
Italian
Japanese
Korean
Norwegian
Portuguese (Brazil)
Portuguese (Portugal)
Polish
Russian
Spanish
Turkish
Swedish

Edit: Add "released" to second paragraph; replaced "host" with "HTTP" in last paragraph

Related to the IE Blog post around mashups in Internet Explorer 8, the Jscript team has a great post on ECMAScript, Security and Mashups over on their blog. Check it out!

Kristen Kibble
IE Program Manger

Hello, I’m Sunava Dutta and I’m the Program Manager focused on improving our AJAX scenarios in IE8. In this short post I’ll introduce you to a feature we’re implementing in the browser that enables safer mashups. The Same Origin Policy (SOP) requires that browsers prevent script from accessing the contents of another domain to prevent cross site script attacks. Web sites today, like Facebook and Live among others, allow users to drag and drop third party ‘gadgets’ or applications to their page. As the BBC News reports, there are many challenges to doing so safely. These components are usually embedded third party scripts. Unfortunately these third party scripts run with the same privileges as the parent page and can potentially access personal data, cookies and other credentials. Attempts are currently underway to secure such script based applications. Other forms of embedding applications exist such as inserting the gadget in an IFrame, however while these are more secure they can’t communicate with the page and aren’t as useful.

In order to allow rich mashup scenarios where components can exchange information and permissions with the parent page, the IE team and other members of the HTML 5.0 Working Group are developing a cross document messaging feature. Communication using strings is enabled by a postMessage method. Hosting pages or gadgets are advised to check the origin domain of the content before inserting it in its DOM. For more details, please refer to our MSDN Dev Center Article on cross document messaging.

Sunava Dutta
Program Manager

Edit: added "more" to last sentence in first paragraph

Join members of the Internet Explorer team for an Expert Zone chat this Thursday, May 15th  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

Hi all,

Last week, I blogged about installing Windows XP SP3 and how it affects different versions of Internet Explorer (See my earlier blog post here). Today I will be discussing installing branded/custom versions of IE7 on machines with Windows XP SP3 installed. This post is primarily aimed towards folks who use the Internet Explorer Administration Kit 7 (IEAK7) to create custom IE7 packages, like Internet Service Providers (ISPs) and web developers. If you ever installed the IEAK7, built a custom version of IE7 or distributed a version of IE7 to others, this post is for you.

When installing a branded version of IE7 (like the one you get on a Comcast or Qwest CD when you sign up for their services) on Windows XP SP3 machine for the first time, the IE7 install might fail with the following error:

“Process 'xmllitesetup.exe /quiet /norestart /er  /log:C:\WINDOWS' exited with exit code 61681”<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

The reason is that the IE7 package you are trying to install uses old IE7 files. As you may recall, in October of 2007 we released an IE7 update, which in addition to turning on the menu bar by default and removing WGA validation also addresses the XMLLite issue above.

XMLLite.dll is one of the components that ships with IE7. This DLL is necessary to run IE7, and IE Setup installs this component as part of IE7 installation. XPSP3 contains an updated version of XMLLite.dll, so when you try to install an older version of IE7 on XPSP3 machines, IE Setup fails to install XMLLite since it’s already on your system; hence, you get the error. In the IE7 update, we modified the install logic to only install XMLLite if it’s not already present on the system.

Call To Action

If you produce custom IE7 packages, you need to ensure that those packages will install successfully on Windows XP SP3. You can either try installing IE7 on a Windows XP SP3 system, or for a quick test, you can verify the cache of the IE7 files that were downloaded when generating custom IE7 packages. To verify the cache, on the machine that has the IEAK7 installed, go to C:\Program Files\Microsoft IEAK 7\Download\Win32\<Language>\iebin and search for IESetup.msi or IEBrand.msi.

If those files are not present, then you need to perform the following:

1. Download the new IEAK7 available at TechNet.
2. Run the new IEAK7 wizard.
3. Open the INS file you generated for custom IE7 packages. (You can re-use an existing ins file or create a new one, in which case this step is optional.)
4. On the Automatic Version Synchronization screen, click on the Synchronize button. This step downloads the latest IE7 setup files that it will use to generate a new branded package.
5. Complete the rest of the wizard, and click Finish.

The new packages will be created in the directory you specified during the beginning of the IEAK Wizard. These new packages will work on XPSP3, so you are ready to distribute them to all your customers.

Thanks,

Jane Maliouta
Program Manager

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

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

Have you ever seen this dialog while surfing the web in Internet Explorer?

You browse to your favorite news site. The content starts loading, you've already started reading the headline, and then it happens. Those of you familiar with the operation aborted dialog know that it spells sudden doom for the website you're currently viewing. Unsuspecting users have no idea what it means and simply click 'OK' and then watch in horror as the web page they were just reading disappears; only to be replaced by an navigation error screen. More savvy users move the dialog out of the way so that they can finish reading what was visible before they too accept the inevitable...

This dialog (and its side-effects) is gone in Internet Explorer 8 Beta 1.

What caused the operation aborted error?

The operation aborted dialog in Internet Explorer 7 is triggered by an HTML parsing exception that occurs when all the following specific conditions are met:

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).

You can see that each of these conditions is true in the following example markup:

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

The HTML file is being parsed, and encounters a script block. The script block contains inline script which creates a new element and attempts to add it to the BODY (document.body.appendChild(newElem)) element before the closing BODY tag has been encountered by the parser. Note that if I removed the highlighted DIV element, then this problem would not occur because the script block's immediate parent would be BODY, and the script block's immediate parent is immune to this problem.

Unfortunately the operation aborted dialog was always thrown at the top-level of a web page, even if the problem occured in an iframe. In fact, in most scenarios that we encountered, ad injection in an iframe was usually the root cause of this error. After the user dismissed the error dialog, Internet Explorer would navigate away from the page.

What we did in Internet Explorer 8 Beta 1

In Internet Explorer 8, our goal is to change the behavior that previously caused the following problems:

• 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.

When the HTML parser throws the operation aborted exception, rather than announce this error to the world, Internet Explorer 8 Beta 1 discreetly tucks this information away into the list of script errors associated with the webpage and stops parsing HTML and running script at that point. We also tried to provide a little more help to those developers who encounter this error (but don't read the IE blog) by including the KB article number in the text that describes this problem:

HTML Parsing Error: Unable to modify the parent container element before the child element is closed (KB927917)

A simple web search for "KB927917" in major search engines will usually turn up the corresponding Knowledge Base article as the first hit. That article describes the specifics of this problem and available workarounds.

Interoperability observations and feedback request

It's intriguing to observe the parsing behavior of various browsers in these situations, as it's not universally consistent. For the scenarios involving adding elements to an open container (e.g., appendChild), the appropriate behavior seems very straightforward--just add the element. Future markup encountered by the HTML parser (