IE8 Security Part V: Comprehensive Protection

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", "https://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 nosniff directive 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;
X-Content-Type-Options: nosniff

<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 nosniff directive 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: noopenContent-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

Update 6/23/09: In IE8 Beta 2, the nosniff directive was moved to a new header; we have updated the code example here.  More info is in this newer blog post: https://blogs.msdn.com/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx

Comments

• Anonymous
  July 02, 2008
  PingBack from http://blog.a-foton.ru/2008/07/ie8-security-part-v-comprehensive-protection/

• Anonymous
  July 02, 2008
  I just posted an article about Internet Explorer 8 security features . This is based on a recent briefing

• Anonymous
  July 02, 2008
  I tried to post a comment on a previous entry you guys put up in 2005 on PNG implementation, but comments were disabled. http://blogs.msdn.com/ie/archive/2005/04/26/412263.aspx I found a bizarre bug when stretching a PNG file in IE7, that only happens on some browsers and not others. Detail: http://commadot.com/ie7-png-problem/ Would it be possible for you guys to stop making my life miserable?  Please?

• Anonymous
  July 02, 2008
  All these "comprehensive protections" are useless when IE is so poorly coded. See the latest vulnerability affecting both IE7(fully patched) and IE8b1(fully patched). http://secunia.com/advisories/30851/

• Anonymous
  July 02, 2008
  Maybe it's time to disable MIME-sniffing when there is a valid Content-type header present. Other browsers don't have this feature and seem to be doing fine. Are the sites on those few antique webservers really that important?

• Anonymous
  July 02, 2008
  What is this bit of code? "document.attachEvent" I can't seem to find any reference to this in the published specifications for manipulating the DOM via ECMAScript. http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html There is an addEventListenter() method... I'm sure this is what you meant to use in your code example (demonstrating good code practice) It's one thing to not support the standards correctly, its another to finally admit that IE doesn't support them, but to "promote" code examples that make use of proprietary non-standard API's shows very bad form. First Yellow Card Issued. Mike

• Anonymous
  July 02, 2008
  Der IE 8 wird der sicherste Internet Explorer aller Zeiten! Ungelogen! IE8 Security Part V- Comprehensive Protection: XSS-Protection, XDomainRequest, HTML/JSON Sanitization, MIME-Handling, DEP, File Upload IE8 Security Part IV- The XSS Filter: XSS-Filt

• Anonymous
  July 02, 2008
  Der IE 8 wird der sicherste Internet Explorer aller Zeiten! Ungelogen! IE8 Security Part V- Comprehensive Protection: XSS-Protection, XDomainRequest, HTML/JSON Sanitization, MIME-Handling, DEP, File Upload IE8 Security Part IV- The XSS Filter: XSS-Filt

• Anonymous
  July 02, 2008
  like the new "authoritative" content-type attribute. great job, guys! :)

• Anonymous
  July 02, 2008
  @Kwispel: What other browsers are you talking about? Firefox, Safari, Opera all do Content-Type sniffing. It is outright needed for web compatibility. Also, bear in mind that "few antique webservers" actually means (to use my area as an example) c. 50% of all Atom/RSS feeds.

• Anonymous
  July 02, 2008
  how about applying the XSS filter on urls where the contenttype is sniffed as 'text/html'. Also, have you guys looked into the "Site Security Policy" ?

• Anonymous
  July 02, 2008
  Geoffrey Sneddon; If I open a PHP page with the code below, Opera and FF show it has a textfile because of the "text/plain" content-type header. IE ignores/overrides the header and shows it as a HTML file with can be annoying sometimes.

<?php header('Content-type: text/plain'); ?> <html> <body bgcolor="#AA0000"> This page renders as HTML source code (text) in IE8. </body> </html>

And I think most feeds use some kind of xml mimetype.

• Anonymous
  July 02, 2008
  Hi Eric, I see you finally went with my argument last year that you should not treat any file that's declared to be a binary format by it's mimetype as something else :) I sent you examples then of completely valid GIF and PNG files that even served with the correct mimetype(!) were sniffed to be HTML when linked to (iso embedded) - it was then regarded by Microsoft to be 'by design' and we wrote about it on our site: http://tweakers.net/nieuws/47643/xss-exploit-door-microsoft-betiteld-als-by-design.html (Dutch) I would really still like to know why IE did content-sniffing anyway in those cases where the file was a valid image and was served with the correct mimetype. In any case, these points still apply:

• if a file is served with a mimetype that suggests binary data, don't treat it as something else
• don't ever do sniffing beforehand when a valid mimetype is given (except for text/plain)
• when a file obviousy contains binary data (eg non-printable characters) don't display it as some text or markup format, or at least post a warning

• Anonymous
  July 02, 2008
  The comment has been removed
• Anonymous
  July 02, 2008
  Gérard: yes you are right, it is a spec-violation to do content-sniffing when a mimetype is given, but the argument of misconfigured webservers is still valid today. It's a status-quo that every browser-vendor is facing:

• do we do the right thing and honour the mimetype and not do content-sniffing, with the possible effect that users will blame the browser instead of the site and switch to a more lenient browser?
• or do we try to fix obvious mistakes made by administrators in order to give the user of our browser a better experience? I'm not sure if the current status of the web will be favourable to the former these days, I'm not the one who would like to make that judgement call... I do however think that IE's current content-type sniffing is less than optimal and that that's a security concern. I'm glad MS is finally recognizing that.

• Anonymous
  July 02, 2008
  i tried to download the smallest IE Image but because im using WiFi it cut out & the download stalled so could enable microsoft FTM for the vpc images

• Anonymous
  July 02, 2008
  All VERY good; keep it going. However, (I know its a bit too late in the development process) but i would love a feature, where cookies, authentication sessions, etc expire and are deleted after a number of days automatically! Like history, the user chooses how long information is stored. Anyone know of an addon?

• Anonymous
  July 02, 2008
  The authoritative=true feature is great, but it would be a lot easier to implement if it was a separate header (e.g. X-Content-Type-Authoritative). Is there any way that this could be changed?

• Anonymous
  July 02, 2008
  Congratulations! These features are really impressive!

• Anonymous
  July 02, 2008
  I second Brian on his comment above. It would be easier if it was just a separate header, instead of an additional parameter to all MIME-types. ~Grauw

• Anonymous
  July 02, 2008
  Re X-Download-Options: noopen, If it was a malicious file and you force it to be saved to the local disk prior to being opened, wont it open in the Local Zone? Isnt that bad? :o (No idea on my part if it is or not though)

• Anonymous
  July 02, 2008
  I do think it's strange to have a parameter in the HTTP Content-Type header say: "no really, I /do/ mean this Content-Type and nothing else". That either means that the current HTTP-spec isn't sufficient, or that Microsoft is trying to overcome some problems with the current specification. Either way it is striking that Microsoft doesn't seek assistance in the W3C HTTP WG but instead again chooses to implement it's own proprietary solutions. If every vendor should choose this route we'd be stuck with dozens of different proprietary HTTP headers and arguments we'd have to send out to 'please' every single piece of software that has anything to do with internet-content. Clearly this is not the path that we should follow...

• Anonymous
  July 02, 2008
  <quote><p>Gérard: yes you are right, it is a spec-violation to do content-sniffing when a mimetype is given, but the argument of misconfigured webservers is still valid today. <p>It's a status-quo that every browser-vendor is facing: <p>- do we do the right thing and honour the mimetype and not do content-sniffing, with the possible effect that users will blame the browser instead of the site and switch to a more lenient browser?

• or do we try to fix obvious mistakes made by administrator </quote> Is this really still a problem? In the many years I have used firefox, I have newer seen a problem due to misconfigured mime types. So let's try a challange: If you know that this is still a problem, try to mention 3 websites that does not work without mime sniffing, but which work with mime sniffing in ie7. Martin

• Anonymous
  July 02, 2008
  @Geoffrey: not sure you understand what Kwispel is saying... other browsers trust the Content-Type header, even if the extension is different. So if a web server sends an .html file with Content-Type image/gif, it will be rendered as a GIF image and not an HTML file. But IE, unlike every other major web browser, thinks it should ignore the Content-Type header when it can "figure out" what the page "really meant". This whole "Standards Compliance" thing is really killing you IE devs, huh? You can't simply follow the spec, you have to go and do things differently so it won't "break old stuff". Just when we get hope that you will do the right thing and break old, poorly-coded sites that should be broken, we now get news that you're adding more non-standard headers! You even admitted that you shouldn't be doing this back in 2005, but you do because "the whole idea of the mime-sniffing logic was to make it easier for an average Joe to put up a personal website without worrying about mimetype details even when web servers and ISPs have random default configurations." http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx PLEASE STOP TRYING TO BREAK THE WEB SO THAT "AVERAGE JOES" CAN PUT UP BROKEN CODE AND HAVE IT WORK!! Broken code should be fixed, not "guessed at". Why is this so difficult for Microsoft and the IE team to grasp?! What makes you think that requiring servers to add a "nosrsly=true" to the Content-Type is going to help resolve the issue? Don't you see that this is EXACTLY THE SAME as your ridiculous "broken by default unless you include our non-standard tag" approach to IE8 that was thankfully reversed? Read the standard, design IE to the standard, and require web developers to adhere to the standard! Yes, there is going to be some pain in the interim, but you've apparently already accepted that, so please stop this nonsense!!

• Anonymous
  July 02, 2008
  @Tino: "It's a status-quo that every browser-vendor is facing: do we do the right thing and honour the mimetype and not do content-sniffing, with the possible effect that users will blame the browser instead of the site and switch to a more lenient browser? or do we try to fix obvious mistakes made by administrators in order to give the user of our browser a better experience?" No, that's not correct. ONLY IE does mime-type "sniffing". All the other browsers honor the Content-Type header if it's there. It's time that IE got on board.

• Anonymous
  July 02, 2008
  The comment has been removed

• Anonymous
  July 02, 2008
  Powerful new feature. Thanks and greetings!

• Anonymous
  July 02, 2008
  I'm a bit surprised that the example given shows IE7 doing content-sniffing for text/html, while it clearly doesn't do it for this test: http://hixie.ch/tests/adhoc/http/content-type/013.html What's the difference?

• Anonymous
  July 02, 2008
  What we need is some sort of Non-Proliferation treaty. I think we can all agree that stuff like content-sniffing is ultimately bad for the web, so it would be cool to see browser manufacturers agree to reduce it gradually in step with each other.

• Anonymous
  July 02, 2008
  Good protection and it looks like IE is becoming more and more like FireFox and Opera. And that's good thing, in my opinion.

• Anonymous
  July 02, 2008
  Suggestion: How about allowing USERS instead of site owners/developers to configure right-click disable using JavaScript? Suggestion #2: It would make end users' life more easy if IE were to ship with a separate MIME type association editor for commonly encountered file types across the web (PDF, XPS, ZIP and all the media file types). Users at time want them to be different from the OS file type settings. Several apps installed on the user's computer don't respect the browser MIME associations.

• Anonymous
  July 02, 2008
  So now my customers have 3 choices...

1. Use these IE only standards
2. Sniff the browser, serve IE standards to IE and W3C standards to everyone else.
3. Use W3C standards and hope that the IE team really are committed to supporting standards. Option 1 ignores 40% of their customers. Option 2 costs twice as much. Option 3 will be an unknown quantity. Which option should my customers choose?  I do not feel qualified to advise them anymore so maybe someone from Microsoft help us out here?

• Anonymous
  July 03, 2008
  authoritative=true is a great step in the right direction. But could you make a separate header? It would be easier if I could just put it in my web servers configuration file without having to fix server side scripts, which override the Content-Type header. It would be great if you made it opt-in instead of opt-out of content type sniffing, but I guess you cannot do that. You could at least reduce the sniffing to places that other browsers also implement, like CSS in quirks mode and RSS.

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  Is there a way to opt-out of the extra warnings for application protocol handlers?  I see no reason to assume that those are any more dangerous than mime-type handlers, and in both cases they were installed by the user, so they aren't a case where the code is supposed to be untrusted.  This and the "Punish user installed ActiveXs that don't add an super-extra-mega-special registry key" don't seem like security features but just serve to hassle developers to make them upgrade and retest every time IE upgrades.  And it further seems to let Microsoft white-list their programs but third-party developers can't do anything.

• Anonymous
  July 03, 2008
  Speaking about content types... I've noticed that if IE 7 (and 8) are directed to a page with .log extension, it automatically downloads the file and opens it in Notepad. Example: http://www.rglug.org/irc/2005-06-06.log. (Random link, found through Google.) You can clearly see that the content type for this document is "text/plain; charset=ISO-8859-1", why does IE insist on opening it in Notepad? This is especially horrendous when the file uses Unix-style linebreaks. Another example: http://eternallybored.org/tdwtf/tdwtf.fpl. The content type is "text/plain; charset=utf-8", yet IE refuses to open it, with a long-winded error message. Why? My guess is because .fpl is associated with foobar2000 on this computer, and fb2k can't open the file, because it's not a real playlist. Please, can we have as less content type guessing as possible? It frustrates not just web devs, but everybody else.

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  An even much better testcase is hixie.ch/tests/adhoc/http/content-type/sniffing/013.txt where Firefox 3, Opera 9.50, Safari 3.1.2, Seamonkey 2.0a1 all pass this test and where only IE 8 beta 1 fails. Gérard

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  I tried downloading the smallest IE Image but because im using WiFi it cut out & the download stalled so could they enable microsoft FTM for the vpc images

• Anonymous
  July 03, 2008
  they reason why i suggested Microsoft FTM is because trying to download the 3 parts to the vista image can be time consuming

• Anonymous
  July 03, 2008
  Eric: thanks for the explanation. I think it is a good thing that MS recognizes that servers should have control. On the other hand, I'm not sure that a new MIME type parameter is the right thing to do it; it fills Content-Type with garbage (sorry), and it is problematic to register for all MIME types at once (you did plan to register it, right?). A separate header may be much simpler to deploy. Also, wrt the process: I think it would be a good idea to propose and discuss these things in the open before announcing software releases (even beta). Finally, even if IE can't stop doing content sniffing for now, it would be great to hear that MS tries to reduce the number of cases where it does occur. If FF2 and FF3 can get away with less, why can't IE?

• Anonymous
  July 03, 2008
  It seems that the "browser wars" finally opened up. Hope you guys bring the browser to the next level of safety, speed and usability soon!

• Anonymous
  July 03, 2008
  Filed as bug 354921 at connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=354921 Regards, Gérard

• Anonymous
  July 03, 2008
  @EricLaw: Thanks for your response. I apologize I did not explain fully. Regarding the ActiveX control problem, I was referring to the situation when both a pop-up as well as an ActiveX instantiation was blocked. The information bar reads something like "Pop-up blocked. Also to protect your security, Internet Explorer blocked other content from this site." I don't see any way of knowing what "other content" was blocked. [See http://www.divshare.com/download/4861341-88e ]

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  For the intermediate bufferring to TIF, there are two usability problems. First is for files where I can do something with the partial data, e.g., say a media file. I can open the file and preview it while it is being downloaded. If it is a large media file, it sometimes becomes important. Actually, that the file is first downloaded to TIF isn't the problem here. That it is hard to find is the problem. How about a sub folder in TIF where active downloads go (and use the original filenames), and use a junction point/symlink to link to that folder from an easily accessible location / or a button to open that location? Secondly, moving the file from TIF to the download location is a hard-disc intensive operation. For large files, the problem is non-trivial.

• Anonymous
  July 03, 2008
  If you do not wish to continue this discussion here in case you fear that it might go off the topic of this blogpost, I would be happy to switch to email. ( soum [at] live [dot] in )

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  For all those saying no other browser does MIME type sniffing, take a look at something like http://hixie.ch/tests/adhoc/http/content-type/images/001.gif — this is actually a PNG image. If it is displayed at all, MIME type sniffing it going on.

• Anonymous
  July 03, 2008
  @Julian, I like Microsoft's approach of "see what we did, propose a better solution if you don't like it." It is the same approach the browser vendors are using (look at the Surfin' Safari blog, for example). Otherwise, it takes forever to get people to agree on something; look how slowly HTTPbis and the HTML WG are progressing, for example. @EricLaw, I use all of those and more--right now, mostly Java and Python behind Apache. I would prefer to be able to use mod_headers to set a header on all responses coming from my front-end servers and be done with it, instead of having to rewrite Content-Type headers.

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  I think you're missing signifigant part of the problem as far as phishing goes. The domain could be blahblah.com and be totally valid .... with html and look and feel of pay pal. (The phishing filter requires the site to have been reported as a phishing site) I would suggest adding some sort of UI indications on ALL password fields that indicate "This password field is for blahblah.com" People are easily fooled by the surrounding HTML, even the best of us may not see notice the domain. But as we type our password and it says "blahblah.com" instead of "paypal.com" we would instantly know something was up! I think this would be more effective than the phishing filter. Especially for very targeted phishing attacks.

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  The comment has been removed

• Anonymous
  July 03, 2008
  Is there any chance of getting an option to block iframe or script access which come from a different server/domain? This is because there is an increasing trend for legitimate sites to be hacked to contain iframe links to malicious domains which attempt to install malware - usually hosted on overseas domains. For me I would like the option of being able to block these background page accesses similar to how the noscript add-on for Firefox works. I realize that this can break some sites which grab advertising content or access counters from other domains - but for me I would like a way to ensure that when I visit a particular domain, that all of the page content has come from just that domain! Obviously this will not suit everyone and needs to be optional.

• Anonymous
  July 04, 2008
  Can information bar show more information like how many pop-up windows and the URL of the website.

• Anonymous
  July 04, 2008
  The comment has been removed

• Anonymous
  July 04, 2008
  The comment has been removed

• Anonymous
  July 04, 2008
  Timebombed IE8 Virtual PC XP images expire in 1 hour. So much for testing IE8 out this week!

• Anonymous
  July 04, 2008
  The comment has been removed

• Anonymous
  July 04, 2008
  The comment has been removed

• Anonymous
  July 04, 2008
  Chris: Regarding: "For an example of how wrong IE8's guesswork can be, try downloading Trend's SysClean.com from this site... http://www.trendmicro.com/download/dcs.asp This is a Windows executable, dressed up as a .COM file, and clearly binary in nature.  Firefox sees it as a .COM and downloads (not "opens") it as a .COM; IE7 opens it as a page and downloads it as .TXT, while IE8 tries to do the same, and gets lost in la-la land." I have to note that this resource is served as text/plain: HTTP/1.x 200 OK Server: Apache Etag: "360ef072099c8b95c72ca7cfbbeb1f2f:1214996387" Last-Modified: Wed, 02 Jul 2008 10:59:33 GMT Accept-Ranges: bytes Content-Length: 4709623 Content-Type: text/plain Date: Sat, 05 Jul 2008 07:19:29 GMT Connection: keep-alive So in theory, trying to diplay is as text is the right thing.

• Anonymous
  July 04, 2008
  Thanks, Julian; I was wondering what was going on there! This is interesting, as the tone of these comments suggests web browsers should do as other browsers do, and that what they do is trust the stated MIME content without "sniffing" and override. So, if I understand you correctly, we have a .COM file (that's internally .EXE) MIME-wrapped as if it were text... and IE interprets that as text while FF doesn't?   Is that because FF is acting on the file type derived from file name extension, or sniffed content that smells binary rather than text? It's almost as if FF is sniffing while IE (both 7 and 8) is sticking to standards.  Hmm.

• Anonymous
  July 04, 2008
  > This is interesting, as the tone of these comments suggests web browsers should do as other browsers do, and that what they do is trust the stated MIME content without "sniffing" and override. Well, the others sniff, too. And the HTML5 specification encourages them to do so. > So, if I understand you correctly, we have a .COM file (that's internally .EXE) MIME-wrapped as if it were text... and IE interprets that as text while FF doesn't?   Yes. > Is that because FF is acting on the file type derived from file name extension, or sniffed content that smells binary rather than text? I think the latter. > It's almost as if FF is sniffing while IE (both 7 and 8) is sticking to standards.  Hmm. So much for of black&white world view.

• Anonymous
  July 04, 2008
  The comment has been removed

• Anonymous
  July 04, 2008
  @Julian Reschke: So in theory, trying to diplay is as text is the right thing. Given the text/plain content-type, it should be displayed as text. However, the webserver should definitely not serve this file as "plain/text", it clearly isn't. Btw, when I clicked the link (IE8 beta 1 on Vista x64), it downloaded the file as .COM ("MS-DOS application"). IE didn't try to display it as plain/text.

• Anonymous
  July 04, 2008
  @FixMe: > Given the text/plain content-type, it should be displayed as text. Yes. > However, the webserver should definitely not serve this file as "plain/text", it clearly isn't. Yes. It's misconfigured, and that kind of misconfig encourage/forces UAs to sniff. > Btw, when I clicked the link (IE8 beta 1 on Vista x64), it downloaded the file as .COM ("MS-DOS application"). IE didn't try to display it as plain/text. Indeed, but it does so in IE7. So this is the case where MS is adding more content sniffing. Bad.

• Anonymous
  July 05, 2008
  The comment has been removed

• Anonymous
  July 05, 2008
  The comment has been removed

• Anonymous
  July 06, 2008
  Will IE8 have Thumbnail Previews for Tabs? This is a must have!!! Firefox and Opera can do this!

• Anonymous
  July 06, 2008
  Hi, I have installed early IE8 on my new Compaq PC. Now, I'm having trouble installing IE8 beta 1 on vista(home edition). It says "A previous build of Internet Explorer8 is already installed on your computer. You must remove it before installing the latest verison of Internet Exploerer 8" I can't hardly find IE8 uninstall. This drives new PC users insane.

• Anonymous
  July 06, 2008
  @ Need Help !!! Please see Jane's post: Installing IE8. There is a section with instructions on how to uninstall IE8 for Vista. http://blogs.msdn.com/ie/archive/2008/03/13/installing-ie8.aspx

• Anonymous
  July 06, 2008
  The comment has been removed

• Anonymous
  July 06, 2008
  Almost three months have passed with NO updated patch KB938127 for IE7 on XP SP3. MS please do your work quicker and better to protect users. Thanks.

• Anonymous
  July 06, 2008
  I found some bugs in IE8  which I hope will be fixed these are bugs I found 1.IE8 beta crashed with googletoolbar1 in the interexplorer browser prior to IE8beta install.So google toolbar1 is not comaptable with IE8 beta so I removed that form addremove programs and its working fine now. 2.The scrooling of webpage is not good with mouse its not properly scrolling webpage,check this also. 3.When I close IE8 unexpectedly when i opens again it asks for restore session which not good for privacy ,I hope this will be fixed.and nobody don't want thier privacy email passwords all info will aceessbile when click restore ,so Restoring session should be modified.

• Anonymous
  July 06, 2008
  document.attachEvent('onmessage',function(e) {    if (e.domain == 'weather.example.com') {      spnWeather.innerHTML = window.toStaticHTML(e.data);  } } why not support addlistenevent? why?

• Anonymous
  July 07, 2008
  One more well written explanation of why Firefox is, and always will be safer than IE. http://weblogs.mozillazine.org/asa/archives/2008/07/more_reasons_to.html

• Anonymous
  July 07, 2008
  The comment has been removed

• Anonymous
  July 07, 2008
  I'd also like a new Virtual PC (XP) image to test IE8 beta1 on. The current image constantly complains that it is expired and reboots.

• Anonymous
  July 07, 2008
  @Claire: The new VPCs are here: http://www.microsoft.com/downloads/details.aspx?FamilyID=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en   You can find these by visiting http://msdn.microsoft.com/IE/ and then clicking the "Downloads" tab. @Joel: toStaticHTML() was added for Beta-2, which will be available in August.   You're correct to note that per the current HTML5 spec, you should attach the onMessage handler to the window rather than the document. @Justine: I'd agree that's its important to keep up-to-date on patches, and WindowsUpdate/Automatic Updates makes that very easy for IE users.  Upgrading to the latest available version is also a good practice. @venkat: #1: Did you try with the latest version of the Google toolbar? #2: This is a known issue in Beta-1. #3: If desired, you can turn off Automatic Crash Recovery using Tools / Internet Options / Advanced. @tmp: Stay tuned for beta-2 in August. @Roman: It's an interesting suggestion, although it's true that some might complain that using charset for this purpose is a bit random.   @FixMe: "never trust claims from "the other party" anyway." I don't think you understand the threat.  The threat with the Content-Type sniffing is to the SERVER (by way of XSS), not to the client.  Hence, the server has no user-security-compromising reason to lie.  The problem is that legacy servers do lie-- not due to malice, but due to misconfiguration. "allow us to allow pop-ups/ActiveX installation WITHOUT reloading the entire site." It's a fine idea, but generally, it won't work.  The problem is that script/code on the page quite likely depended on proper initialization of the object, so when the blocked attempt to instantiate the object returned null, that null gets cached away by script on the page and the script is broken.  Hence the requirement that a reload occur. @Chad Grant: Another fine idea, but unfortunately one that won't work.  The problem is that there's no reliable way to know a priori where the form submission is going to go, because script can retarget the form.  Alternatively, the bad guy could simply point the form at the legitimate PayPal site, and simply sniff users' keystrokes as they type into the page (because his domain owns the form).   The SmartScreen Filter attacks this problem at the source by blocking the phishing site; it doesn't matter how many different sites try to phish, there's no limit to the number SmartScreen can block.   Of course, you're correct to note that the best defense is user-education; hence our investments in EV certificates and the "Green bar" which you'll see at Paypal.com to help you identify the real site. @Mitch74: The EcmaScript 3.1 proposal is tracked here: http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft&s=douglas

• Anonymous
  July 07, 2008
  My IE8 can't install beta 1. I have great idea for IE8.  Can we have anti-registry changer button with IE8? I like to have tiny anti-registry changer button right next to "Quick Tabs" botton. I want something that protects registry and see startup program. Everytime I press Alt-Ctrl-Del. I can't hardly see tiny spyware, malware, etc. It's make me hard to shop online.

• Anonymous
  July 07, 2008
  @EricLaw: thanks for the link. Where can we find anything about planned improvements for the event model in IE? Considering the amount of events the IE model can handle (and how), it really seems strange that the W3C model isn't supported, now that there is a big breakthrough standards-wise in IE8. From my tinkering with both models, it seems that:

• IE can handle event target detection ('this' in a function attached to an event can work in a fashion - add a detect and a substitute local variable at the top of each function)
• some objects in IE are already able to handle both event capturing and event bubbling (see the way objects handle the CSS :hover pseudo element when parents and children both have it) Blocking:
• different objects don't behave the same depending on basic events (can be fixed in Uber Standards Mode)
• in IE6, due to the way UI elements could be GDI objects, event misfires could be tricky (but fixing them started in IE7 - buttons and form elements for example respected z-index - how far along is it?) What else? Is there even prototype code to support it in development at MS, even if not planned for IE8? Security is nice, correct CSS support is nice too, but the event model is probably the most glaring difference left between IE and other browsers. It would really be nice to have an IE build with this, as you'd be guaranteed to have it heavily tested right away. You'll tell me, if the page was programmed to test for the presence of this or that object, it shouldn't matter much. Still, that makes complex website testing ever more complex. Oh, and supporting non-standard-but-widely-implemented-and-useful DOMContentReady would be cool :) Mitch

• Anonymous
  July 08, 2008
  I'm sorry but IE just doesn't cut it for me. Firefox is the best browser there is. You guys seriously need to reconsider all your objectives. IE is one buggy piece of code work. I don't have anything against you but consider making IE open source. It will make a massive difference.

• Anonymous
  July 08, 2008
  The comment has been removed

• Anonymous
  July 09, 2008
  The comment has been removed

• Anonymous
  July 09, 2008
  @8675309 If you download the VPC images via Firefox or another good browser, they come with a download manager that will resume where the download broke off in these scenarios. Many a request has been entered for IE to implement such a feature, but as of IE8 Beta One it was still not anywhere to be seen. I certainly hope that MS is listening... otherwise the 5 second download of the Firefox installer will become more and more popular.

• Anonymous
  July 10, 2008
  like i said in other posts just enable microsoft File Transfer Manager for ie vpc image download page

• Anonymous
  July 10, 2008
  The comment has been removed

• Anonymous
  July 11, 2008
  I'm proud to announce that you lost 8 more people (I think this is close to 70 people now converted over within the last 3 months, just by me) to Firefox after I showed them how terrible IE6-IE7 is in comparison. Also gave them a heads up on IE8, just keep doing what you are doing and Firefox/Safari/Opera (any other browser which cares) will be toppling IE8 over as well. Good luck, keep the process going (?)

• Anonymous
  July 11, 2008
  The comment has been removed

• Anonymous
  July 11, 2008
  "authoritative" attribute on Content-Type seems to be good. But... Even if IE8 released, servers host untrusted contents without "authoritative" attribute will still survive. (like some antique servers hosting their contents as 'text/plain'.) I think information-bar and per-domain opt-in (like popup blocker feature on IE7) is better solution. Thanks.

• Anonymous
  July 11, 2008
  FireFox without addons is fine. Will IE8 have Thumbnail Previews for Tabs?

• Anonymous
  July 11, 2008
  @Vadim: Even IE7 has thumbnail previews for tabs.  Hit CTRL+Q to see them.

• Anonymous
  July 11, 2008
  HEY HOW ABOUT STOP DELETING COMMENTS THAT DON'T PORTRAY YOU IN A POSITIVE LIGHT? HOW ABOUT ALSO GETTING SOME OF THE BASICS RIGHT, LIKE BRINGING BACK CTRL S, SAVE, FUNCTIONALITY IN IE? WHAT ARE YOU PEOPLE THINKING? HOW HARD IS IT FOR YOU TO GET ONE COMMON SENSE THING RIGHT

• Anonymous
  July 11, 2008
  The comment has been removed

• Anonymous
  July 12, 2008
  what a good feature to see again is a highlighter built into ie again

• Anonymous
  July 12, 2008
  @Jack: The only comments that are deleted are obscene, contain offensive language, or are "spam" links unrelated to the topic of web browsers.   I'm not exactly sure what you're referring to with regard to CTRL+S functionality?  Did this behave much differently in IE6?

• Anonymous
  July 12, 2008
  any surprises coming in IE 8 Beta 2 to like a Download Manager or is the feature the same as beta 1

• Anonymous
  July 12, 2008
  @ksa: We're not disclosing the specific beta-2 feature set at this time, but we have promised that there are additional end-user-focused features coming in Beta-2.  Please stay tuned...

• Anonymous
  July 12, 2008
  @EricLaw [MSFT]: Is an estimated release date of Beta 2 available, e.g. could you tell it's early, middle or late August, or is this yet unclear/"closed"?

• Anonymous
  July 13, 2008
  The comment has been removed

• Anonymous
  July 13, 2008
  I do is to web map programming, the map shows that this is the use of the mosaic map TABLE eg: <table> <tr> <td> <img src = "0_0.png" </ td> <td> <img src = "0_1.png" </ td> <td> <img src = "0_2.png" </ td> </ tr> </ table> But when I open this page often do not show the picture, I must be in the picture of regional mouse click can show that, Firefox can be directly displayed without onclick, I do not know what it is because I am distressed!

• Anonymous
  July 14, 2008
  @Ancient: to fix your font issues in IE you need to disable the default setting for ClearType. All of your webpages/applications will look much better with this feature turned off (and things won't look artificially bold when they are not) Unfortunately management wasn't convinced (in enough time) to disable this by default in IE. We've yet to see a single example at any demo/conference where ClearType looks better than normal rendering on any screen type. MS ClearType is Microsoft Bob's & Clippy's Red headed stepchild.

• Anonymous
  July 14, 2008
  @Jack - Yes, this is a regression bug in IE7.  It was pointed out in IE Feedback several times during IE7 development but was ignored. I'll check and see if it is still broken in IE8 (and if there isn't a bug already filed, file a new one) @handan - I'm not sure if you example got de-HTML'd or not, but you'll want to make sure that; 1.) your image tag is properly closed <img... /> 2.) the HTML table element has default padding and spacing applied unless you override them.  Just set cellpadding="0" cellspacing="0" to reset this. Other than that, I'm not too sure what the issue is... you need to give a bit more info. Thanks

• Anonymous
  July 14, 2008
  @Jack: As you can see by looking at the File menu, the "Save" command is usually disabled in lieu of "Save As."  The reason for this is simple: In Windows, "Save" will save a document back to its current location, while "Save As" will save a document to a new location.  Since, as a web user, you almost never have permission to save a document directly to the web server, and instead want to save the document somewhere else (e.g. your local computer), "Save As" is what you want to do. You suggestion to support "background save" is a good one, thanks!

• Anonymous
  July 15, 2008
  The comment has been removed

• Anonymous
  July 15, 2008
  Brandon: Perhaps you ought to learn to read?  The point that they're making is that the new window was removed for IE8.  Furthermore, it's not like many people even encountered that window anyway.  Taking your trolling elsewhere.

• Anonymous
  July 15, 2008
  @EricLaw: Sure, there shouldn't be any additional security risks involved with sniffing the Content-Type, but there's more likely to be a security bug in JScript than when displaying a file as text/plain (but, yeah, the issue of trusting the server is bogus as you need to assume the file is malicious whatever format it is, whether it claims to be that format of not). It's a good reason to reduce the amount of sniffing done anyway (perhaps to the extreme of HTML 5, perhaps not).

• Anonymous
  July 17, 2008
  Internet Explorer 8 - Security

• Anonymous
  July 26, 2008
  Hyper corrective browser will probably do more harm than good.

• Anonymous
  August 26, 2008
  Hi! I’m Christian Stockwell, and I’m helping to improve Internet Explorer performance. In the past few

• Anonymous
  August 28, 2008
  The next beta for Internet Explorer has been released for broad distribution to the public, according

• Anonymous
  September 02, 2008
  Now that Beta 2 has released, I want to provide a short update on some of the smaller security changes

• Anonymous
  September 06, 2008
  The second beta version of IE8 was released on August 27th. It is working well in testing so far. Only

• Anonymous
  October 06, 2008
  Sunava Dutta here, a program manager focused on improving AJAX in the browser! Now that Internet Explorer

• Anonymous
  October 11, 2008
  WindowsInternetExplorer8Beta2的一个主要目标是去提高开发者的开发效率，IE8开发人员通过提供跨浏览器以及一些强大的应用程序API去达成这个目标。 IE8bet...

• Anonymous
  October 23, 2008
  С вами Сунава Дутта (Sunava Dutta), программный менеджер Internet Explorer. В мои обязанности входит

• Anonymous
  October 26, 2008
  Добрый день! Меня зовут Кристиан Стоквелл (Christian Stockwell) и в команде IE я занимаюсь вопросами

• Anonymous
  December 01, 2008
  Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approached

• Anonymous
  February 26, 2009
  이이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의

• Anonymous
  March 16, 2009
  &#160; &#160; 안녕하세요! 저는 인터넷 익스플로러 보안 프로그램의 책임자인 에릭 로렌스라고 합니다. 지난 화요일, 딘(Dean)이 신뢰성 높은 브라우저 에 대한 저희의 생각을

• Anonymous
  March 16, 2009
  Internet Explorer 8 Beta 2 가 공개되어, 개발 팀에서 몇가지 최신 보안에 관한 소규모 변경에 대한 업데이트 정보를 간단하게 전해드립니다. Internet Explorer

• Anonymous
  March 30, 2009
  Безопасность IE8: защита от вредоносного ПО с помощью фильтра SmartScreen В прошлом году мы опубликовали

• Anonymous
  April 21, 2009
  I attended Scott Charney&rsquo;s keynote this morning at RSA &ndash; Moving Towards End to End Trust

• Anonymous
  May 20, 2009
  Самые вкусные консервы их тех, которые я когда-либо пробовал Хотя эта статья адресована ИТ-администраторам,