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”, “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 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:

IE7 text interpreted as HTML

In IE8, the page is rendered in plaintext:

IE8 text rendered as plain text

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: noopen

Content-Disposition: attachment; filename=untrustedfile.html

Save File Dialog

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.

IE7 new window prompt

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.

IE8 prompt prior to 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.

IE8 read-only File Path box

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.

IE8 SSL Address Bar with Domain Highlighting

IE8 SmartScreen Filter Address Bar

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: http://blogs.msdn.com/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx

Comments (128)

  1. I just posted an article about Internet Explorer 8 security features . This is based on a recent briefing

  2. Glen Lipka says:

    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?

  3. Drive-By says:

    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/

  4. Kwispel says:

    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?

  5. Mike says:

    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

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

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

  8. Vishu says:

    like the new "authoritative" content-type attribute. great job, guys! :)

  9. @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.

  10. Evert says:

    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" ?

  11. Kwispel says:

    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.

  12. Tino Zijdel says:

    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

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

    This has been reported as a spec. violation for a long time now.

    Common User Agent Problems Feb. 6th 2001

    http://www.w3.org/TR/2001/NOTE-cuap-20010206#cp-no-override-ct

    states

    "

    Respect the media type of a resource if one is explicitly given using the Content-Type HTTP header.

     Example:

       If an HTML document is returned with a Content-Type value of text/plain, the user agent must render the document as plain text without interpreting HTML elements and attributes (i.e. the HTML source must be displayed).

    "

    Also reported by Mark "Tarquin" Wilton-Jones at

    http://www.howtocreate.co.uk/wrongWithIE/?chapter=Content-type%3A+text%2Fplain

    Regards, Gérard

  14. Tino Zijdel says:

    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.

  15. 8675309 says:

    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

  16. Privacy Concerns says:

    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?

  17. Brian Smith says:

    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?

  18. kL says:

    Congratulations! These features are really impressive!

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

  20. Tim says:

    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)

  21. Tino Zijdel says:

    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…

  22. Martin says:

    <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

  23. toby johnson says:

    @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!!

  24. toby johnson says:

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

  25. Soum says:

    Why not show the name of the control when the infobar displays the ActiveX Control blocked message? Without knowing what ActiveX control is being requested by the website, how are we supposed to make the trust decision?

    True IE7 does a ballon notification when access to a blocked ActiveX control is requested. But:

    1. Ballon popups are annoying.

    2. I have never seen that mechanism to work reliably, for all sites and browser configurations.

    3. I have never seen IE8 do that.

    And when a pop-up is blocked, the infobar should give the option to let that popup open. "Temporariy allow popups from this site" isn’t enough because:

    1. Many times the popup opening is a one-off thing. There is no need to temporarily allow popups.

    2. Sites open popups in response to a form submittal. When after the submission we realize the popup is blocked, on temporarily allowing popups, the entire page reloads, so we have to fill in the form again. I know of the CTRL+ALT override. But what of cases when the page just redirects to some page else. Neither the popup opens, nor do we have the form saved so that we can try the override again!

    Why are downloads first downloaded to the temporary internet files first? I have read the June chat transcript where it was said that this is done to prevent "carpet bombing" downloads. But IE does not download files without user consent. So there is no question of silently filling up drives. And it also marks downloaded files as being from the Internet Zone, so there is no question of the files being silently executed either. Why then is this behavior still required?

  26. World says:

    Powerful new feature. Thanks and greetings!

  27. Julian Reschke says:

    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?

  28. Robin says:

    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.

  29. Good protection and it looks like IE is becoming more and more like FireFox and Opera. And that’s good thing, in my opinion.

  30. anonymous says:

    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.

  31. billybob says:

    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?

  32. Jesper Kristensen says:

    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.

  33. Walter says:

    Maybe I’m reading this whole authoratative header thing wrong, but…..

    1.) it should be a SEPARATE header, many renderers are looking for an exact match on the string "text/plain" or similar.

    2.) to be honest, the BROKEN SITES should fix their code, not extend ONE version of the BROWSER to now accept 2 standards.

    3.) what stops me (if I were evil) from serving up a virus as one file type, then set the authoratative flag to true, with a content-type that suggests something like a PDF?

    Does this tell the browser, "go ahead and launch this"…

    4.) Do other browsers render as HTML if told to render as plain text?  If so, maybe this "new" "additional" header is ok.  If not, stop trying to "fix" IE so that developers can continue to public bad/broken code and have it still work.

    "On Error Resume Next" [tm] is the WORST way to teach developers how to be good programmers.

  34. William says:

    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.

  35. Roman says:

    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.

  36. Rat says:

    While I agree that standards are valuable and should be followed, I’m not at all surprised at which of the following 2 options MS took when confronted by widespread instances of content served with the wrong MIME type, and I hardly think anyone should be surprised that any commercial enterprise, however "noble" or "evil" would choose similarly:

    1) Content sniff, making both the end users and webmaster happy, but annoying their competitors and a bunch of geeks somewhere.

    2) Serve the content wrong (and it *is* wrong, no matter how "proper" it might be), making the webmaster and the end users (their ultimate customers) irritated, but making life easier on their competitors and soothing the irritation of standards lovers.

    Of course, now that the web is more mature, and webserver configuration is less of a black art, and more people are using 3rd party hosting anyway, it’s about time for MS to get with the program and play nice.

    But it was the right decision at the time, both from a web-adoption and business standpoint. Well, ok, maybe not from a long-term business standpoint, because ultimately it’s ended up screwing them slightly — widespread bad end-user experiences with the web might have slowed its spread and left MS’s monopoly intact for longer.

  37. @Tino,

    > the argument of misconfigured webservers is still valid today (…) possible effect that users will blame the browser instead of the site and switch to a more lenient browser?

    If IE 8 becomes as compliant as other browsers(1), there will not be any choice left for the web server admin than to fix his own errors. The more Microsoft products compensate for incompetence, misconfiguration, malformed code, invalid code, etc.. the less there is a need to be competent, to be address errors and malformed code, to clean and optimize code. Microsoft has to edit proper documentation to help, to assist those who will search MSDN2 and will need assistance.

    (1) Firefox and Opera will honor the HTTP response header Content-Type: text/plain instead of sniffing the content and overriding the content-type.

    @Julian Reschke

    IE 8 beta 1 and Safari 3.1.2 fail this test:

    hixie.ch/tests/adhoc/http/content-type/014.html

    Firefox 3, Opera 9.50, Seamonkey 2.0a1 all pass such test.

    Regards, Gérard

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

  39. EricLaw [MSFT] says:

    @Kwispel: Yes, this is exactly the scenario for which the authoritative attribute was created.

    @Tino: I don’t recall seeing any examples that were served with the correct MIME-type (in agreement with the actual content type) that were rendered as HTML.  Absolutely, if the Content-Type and file’s actual type (specified by the magic bytes) were in conflict, then HTML-rendering could result, which is exactly the issue we’ve resolved here in IE8.

    You’re correct to not that if all servers were properly compliant with the HTTP-specification, the MIME-handling compatibility work would not be needed and we could turn off sniffing once and for all.  For now, however, we’re working to ensure security even while keeping compatibility.  Remember, if we significantly reduce compatibility, users would not upgrade to IE8, and then everyone would be stuck with legacy security problems indefinitely anyway.

    @Gerard: Yes, this is far from news.  As noted, this was long an important compatibility factor for IE, which is the reason that it wasn’t turned off when we considered doing so in IE6.

    @Brian: Thanks for the feedback; this is something we’ve heard a few times.  What development platform and server do you use?  (ASP/PHP/JSP? IIS/Apache/other)

    @Tim: No, due to the Mark of the Web and the Local Machine Zone Lockdown, local files no longer run with high levels of permission.

    @Soum: I’m not sure which ActiveX-blocking information bar you’re talking about, but IE does show the name of a control (if available) inside the information bar when it is blocked by default.  Only when the user has manually disabled a control everywhere (via manage addons) does IE suppress the information bar.

    As for the popup-blocking, this is much trickier than most people realize.  We cannot simply allow exactly the blocked popup, because the popup was never created to begin with.  That means that any script that tried to do window.open got a null back.  This means that the script that tried to interact with the popup is almost certainly broken in a way that won’t get fixed if the popup is later created due to user-override.  

    As for why we download to the TIF first, there are a lot of reasons for this, most of which are somewhat more complicated than I’d want to get into here.  The key reasons are to ensure that the file is available for download resumption, if needed, and that the content is marked as being from the proper zone (which only happens elsewhere after the download is complete).  That vast majority of scenarios are not meaningfully impacted by the fact that the download is buffered to the TIF.

    @Julian: The comment and line at the top of Hixie’s test pushes the tag that we would recognize as HTML (the <h1> tag) out of the buffer that we sniff for content type (the first 256 bytes).

    @billybob: Not sure what you’re getting at.  You should use W3C standards.  

    @Walter: Any client looking for an exact match in a response header shouldn’t be doing so. By definition, HTTP headers have multiple tokens in them.  Allowing a separate response header (rather than a token) seems to be a recurring theme here, which is great feedback for us.  Thanks.

    As for your scenario #3, if you were to do this, we would treat it as a PDF.  Your PDF viewer would then refuse to run the content, because it’s not a PDF.

    @William: This work is all about protecting users.  Users may opt out of the additional warning if they’d like.  I will say, however, that I have yet to encounter ANY protocol handler that hasn’t had at least one bug, so this is a good general defense-in-depth.  

    @Roman: Your first file opens in notepad because that’s how the .log file type is configured on your machine.  You can remove that association if you’d like, or configure .log files to require confirmation before opening from the web.  In your second example, what "longwinded error message" do you see?  This text opens fine inside IE as plaintext for me.  If you’re correct in noting that the problem is that we’re sniffing the type, the problem can be corrected either by fixing your file association, or preventing sniffing as described in this post.

  40. 8675309 says:

    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

  41. 8675309 says:

    they reason why i suggested Microsoft FTM is because trying to download the 3 parts to the vista image can be time consuming

  42. Julian Reschke says:

    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?

  43. Hypotheek says:

    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!

  44. Filed as bug 354921 at

    connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=354921

    Regards, Gérard

  45. Soum says:

    @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 ]

  46. Soum says:

    As for the pop-up blocking scenario, I realize that the user-override will not undo the script’s handling of the null from window.open, but this will be useful in situations when the "work" was supposed to be done by the HTTP request, not the script. Like the scenario I mentioned earlier – submitting a form (especially when the pop up blocker is set to high).

  47. Soum says:

    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.

  48. Soum says:

    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 )

  49. William says:

    EricLaw says:

    @William: This work is all about protecting users.  Users may opt out of the additional warning if they’d like.  I will say, however, that I have yet to encounter ANY protocol handler that hasn’t had at least one bug, so this is a good general defense-in-depth.  

    And the user is going to know that the protocol handler has a bug in it, and so they should say ‘no’?  Are protocol handlers are inherently more insecure than file-type/mime-type ActiveX controls that the user also installed, where you can theoretically disable the warning (not working for me in IE8 beta1, but supposedly you can do that)?  Or are they just less common, so making them annoying sounds like an ok trade off?  The ever escalating hassling the user for security decisions ever increases the tendency for people to just hi "ok" on every dialog box.

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

  51. Brian Smith says:

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

  52. Roman says:

    EricLaw: the message I see is:

    "Internet Explorer cannot download tdwtf.fpl from eternallybored.org.

    Internet Explorer was not able to open this Internet site.  The requested site is either unavailable or cannot be found.  Please try again later."

    You don’t see it because (I suppose) you don’t have foobar2000 installed, which is .fpl associated with.

    My point is that IE shouldn’t try to interpret the document based on its extension, when there is a more reliable source. In this case the HTTP headers clearly say that it’s not a foobar playlist, but a text file.

    And the end result is that I can’t access the file, ergo frustration.

    P.S. I just tried removing the extension association (after which the log did display), and then adding it back again. There is no error message now, but a standard "Open or save" dialog. However this is still not the desired behaviour.

    Also, you must understand that "remove the association" is a… "substandard" solution.

    Thanks for caring.

  53. Mitch 74 says:

    [rant]I can’t believe I was being blasted last week because I mentioned content sniffing as a security concern, and now it’s on its way to be fixed (well, at least, some of it – and I wasn’t blasted for that alone, all right).[/rant]

    Why force an extra parameter? As others said, it’s exactly the same thing as what you originally proposed for Super Top Fully Standards Compliant mode, meaning an HTTP header setting…

    Well, it’s not: since the matter of CSS compliance comes after the resource has started loading (thus, after the ‘sniffing’ stage), IE already ‘knows’ if the resource is HTML or… anything else. So, it was merely an extra step done on doctype switching.

    However, 2 points could be argued on this.

    – there are currently no public website that still use text/plain for HTML resources (you can thank Firefox, Safari and Opera for that),

    – those that are still used are probably parts of intranets, where a server option isn’t as difficult to enforce as the one on a more public server.

    Even then, IE 6’s dismal security records and the painful wakeup call that was IE7 might just make the migration not as painful. Moreover:

    – since the ‘run as IE7′ HTTP header still exists and will probably be used, why not make use of that one to enable sniffing in IE7 mode only? That’s what this mode is here for, isn’t it?

    – if there is still no header when IE 8 goes RTM, it’s because the sysadmin probably ran tests, or everything still runs – probably because the developer made a modicum of cross-browser tests, and the problem just doesn’t apply!

    – it’s no more difficult to add an HTTP header rule than it is to set up an rclocal AddType rule, either in IIS or Apache, so I think you’re actually making it harder than it looks.

    – setting up a crawler that looks for discrepancies in a domain is quite easy, fast, and a good idea anyway.

    Conclusion.

    IE 8 could use Mozilla’s or Opera’s or Webkit’s scheme: only sniff CSS or Jscript content loaded from a Quirks mode resource. To help the migration, provide a crawler (a PHP or ASP script would be enough) that crawls through all the links in a domain, compares HTTP headers to actual resource type, and displays what it found – with proposed solutions depending on the server signature and location. It could also be made part of the next IE Developer toolbar, to allow developers to fix their networks now.

    Note.

    It would be a good idea, if you intend to go forward with that HTTP parameter scheme of yours, to at least stop IE from lying when the parameter is present: stop that ‘*/*’ nonsense!

    Other matters.

    ECMAscript 3.1 can’t exist, because ECMA doesn’t have minor revisions of norms, and ECMAscript 4 as it is currently developed by Mozilla (Gecko), Apple (Webkit), Adobe (Flash), and Opera (Presto) was vigorously criticized by Chris Wilson (see http://blogs.msdn.com/cwilso/archive/2007/11/02/my-opinion.aspx, and follow the links in the article).

    What’s up on that side?

    Oh, and I second Mike’s remark: why use attachEvent in an example, then say ‘when in doubt use W3C’? Are you saying IE 8 will support the W3C event model? If that’s the case, yippeee! If not, that’s a glaring contradiction that would require clarification.

    Nice answers in this post, interesting features, but it raises even more questions.

    Mitch

  54. Chad Grant says:

    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.

  55. Tino Zijdel says:

    Eric: I put online a testcase: http://therealcrisp.xs4all.nl/exploit/test.html

    This tests various scenarios, please also compare in other browsers. The images are valid images but some are specifically crafted to contain script in places where it is possible: the png-file uses a comment-extension and in the gif-file the color allocation table was tweaked (this is non-compressed in gif).

    I mentioned that in some cases a valid image using a valid mimetype caused IE to render it as HTML (thus executing the script embedded); I have to be more specific about that: it seems that this only occurs using IE6 on win2000 and when you open the image in a seperate window. It does not happen in IE7 on winXP so this already seems to be fixed either on the OS-level or browser-level (but not backported to the older version as a security fix).

    You will notice that in testcase 1 to 8 IE will only render the images with the correct (or experimental x-png) mimetype. Testcase 3, 4, 6, 7 and 8 will give you a javascript alert when opened seperately in the browser.

    At least Firefox and Opera show all of these as images, also when opened seperately (which also proves that these browser *do* perform content-sniffing, even on text/plain).

    Testcase 9-12 are basically the same as 5-8 but in this case it is not a tweaked gif-file, IE treats all of them as gif-images.

    This tells that the content-sniffing in IE prefers a ‘HTML-signature’ above image signatures and disregards the fact that these files clearly also contain binary (non-printable) data. The current fix in IE8 will afaik only solve the execution of the script in testcase number 8 and 13 when linked to directly and it may break testcase number 12 (depending upon how restricted the ‘upsniff’ is).

    Testcases 13-16 just show how IE at this moment ignores any Content-Type when something remotely looks like HTML whereas other browsers do seem to get away honouring the Content-Type.

    It looks to me that Microsoft better rethink it’s content-type sniffing algorithm in general. I have some tips:

    - don’t check for textual types when the mimetype indicates binary data (that also fixes testcase 8 and 13 but is broader than IE’s current fix which apparently only involves image-types)

    - also don’t check for textual types when a file contains binary data and/or matches a signature for some binary format (that could fix all of testcases 3, 4, 6, 7 and 8)

    - try to make an assessment of the necessity to still sniff text/plain directives (when it was not determined to be a binary file). It know seems to me that ‘backwards compatibility’ is still the prevalent message, but that this isn’t actually based on factual data. If by all means you can prevent introducing proprietary HTTP extensions (and thus by default continue to be non-conformant) it would be worth the effort imo.

    "Remember, if we significantly reduce compatibility, users would not upgrade to IE8, and then everyone would be stuck with legacy security problems indefinitely anyway."

    sorry, I can’t resist: when IE8 doesn’t match the users’ expectations they may well be upgrading to Firefox/Opera/Safari which in the end would be better for the web because we (webdevelopers) can than more easily ignore Microsofts’ proprietary extensions and *really* focus on standards. I am again disappointed by the fact that Microsoft (I don’t mean you, Eric, personally) is *again* implementing it’s own proprietary stuff without even mentioning it to the W3C working groups in which MS is a participant. IE may still have a major marketshare, but you don’t have a monopoly on the web anymore…

  56. Tino Zijdel says:

    @Gerard,

    > If IE 8 becomes as compliant as other browsers(1), there will not be any choice left for the web server admin than to fix his own errors. The more Microsoft products compensate for incompetence, misconfiguration, malformed code, invalid code, etc.. the less there is a need to be competent, to be address errors and malformed code, to clean and optimize code. Microsoft has to edit proper documentation to help, to assist those who will search MSDN2 and will need assistance.

    I’m all with you here :)

    > (1) Firefox and Opera will honor the HTTP response header Content-Type: text/plain instead of sniffing the content and overriding the content-type.

    Which is not true as my testcases above prove: a valid image served with text/plain will be shown as an image by those browsers which proves that they *do* sniff on text/plain

  57. Paul Nankervis says:

    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.

  58. DDr says:

    Can information bar show more information like how many pop-up windows and the URL of the website.

  59. FixMe says:

    @Walter – 3.) what stops me (if I were evil) from serving up a virus as one file type, then set the authoratative flag to true, with a content-type that suggests something like a PDF?

    The "auhoritative" feature is a bad idea. Who came up with this?

    You’re trying to fix a problem that doesn’t exist.

    A basic principle of security is to never trust claims from "the other party" anyway.

    Besides, is it valid to insert arbitrary keywords in standardized HTTP headers?

    @toby johnson: 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".

    @Walter 4.) Do other browsers render as HTML if told to render as plain text?  If so, maybe this "new" "additional" header is ok.  If not, stop trying to "fix" IE so that developers can continue to public bad/broken code and have it still work.

    A browser should never try to render text/plain as if it were HTML, even when the content "is" HTML.

    The browser should use the MIME type to determine how to present the content, period.

    The whole point of MIME types is to inform the user agent about the content type, so it DOESN’T have to figure it out by itself.

    Sadly, IE has been very creative with interpreting MIME types… :|

    This single "IE hack" has "allowed" many webpages to work "fine", eventhough they contain many mistakes.

    The solution is simple: use the MIME type, remove all "creative" detection code, at least in "IE8 standards mode", but preferrably altogether.

    You can’t expect to have people fix their websites if they can get away with wrong HTML/CSS/Javascript/MIME-types, etc…

    Btw, I’d love to see browsers show a message (perhaps in the status bar, with a nice red background color) to indicate that a webpage’s (X)HTML/CSS/Javascript contains errors.

    Oh ya, and while you’re at it, allow us to allow pop-ups/ActiveX installation WITHOUT reloading the entire site.

    Installation of certain ActiveX plug-ins, e.g. Dell DRAC virtual-KVM plug-in, can be really difficult/impossible with the *unnecessary* reload. Imagine Windows Vista restarting an entire application whenever you authorize something with a UAC prompt …

  60. @FixMe: "what stops me (if I were evil) from serving up a virus as one file type, then set the authoratative flag to true, with a content-type that suggests something like a PDF?"

    Then the virus would be opened by Acrobat, and it would do whatever it does when it encounters malformed PDF–show an error message. No harm done.

    "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’."

    Actually all the other major browsers do it. They just do it to lesser degrees.

    http://www.w3.org/html/wg/html5/#content-type-sniffing

    See numerous comments on this very page for test cases that clearly demonstrate this.

    (Note: I’m not affiliated with the IE team, I just happen to work at the same 80,000+ person company)

  61. Timebombed IE8 Virtual PC images expire in 1 hour says:

    Timebombed IE8 Virtual PC XP images expire in 1 hour.

    So much for testing IE8 out this week!

  62. nick says:

    IE6 JS Error on IE Blog Line 541

    WT.hp=document.body.isHomePage(location.href)?"1":"0";

    Object not defined (specifically .isHomePage() method)

    It really sucks to have to support old versions of IE, we know.

    (one more reason why IE8 has to really come through on supporting specs) so that we aren’t stuck in 2014 supporting more bad code from IE8.

    However ***I’m sure*** that won’t be an issue, because IE8 will support proper prototyping on all objects, thus we’ll be able to fix IE bugs that slip into RTM shipments ourselves.

    ***yeah, ain’t holding my breath on this one, that would be waaaaay to smart a move.

  63. Chris Quirke says:

    "I’m just walking my dog, I didn’t know this was a restricted military area – sorry!"

    "Oops, yes I did accidentally drop three Rohypnols into your beer – sorry!"

    Reality check: Most folks "navigate" the web via search results, not explicit URL; the sites they reach, aggregate content from other sites, and malware attacks good sites not only via redirection, but by infecting them, too.

    It’s time to stop treating misrepresented web content as an "honest mistake".  Please stop colluding with web authors (who are probably malicious) to spoof our systems!

    So I’d like to see more file type discipline.  If there’s a mis-match between file name extension, MIME type, and actual content as per sniffed headers, then I want to know about it; don’t gloss this over and roll the dice.

    I understand it’s common practice to describe various content as "text", and if so, then you’d need to work around that – but it’s better to do so in a way that is consistent with other browsers and standards.

    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.

  64. Julian Reschke says:

    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.

  65. Chris Quirke says:

    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.

  66. Julian Reschke says:

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

  67. Mitch 74 says:

    I guess sniffing could be used as a security feature, instead of a security problem: if content is announced as text but contains strange characters, download as-is and don’t parse, with a warning.

    The other way, if announced as binary but contains text (or doesn’t comply) will merely result in an "invalid format" error anyway.

    The sniffing is less of a problem on ‘passive’ content type mismatch, as is the case with text/plain and text/html; both are basically text, but then one very simple thing could be used: keep sniffing, but allow the user to change parsing method:

    "resource <nameofresource> is described as text/plain, but seems to be text/html. Parse with HTML filter instead? Yes/Alway/No/Never [X]Always ask when resource doesn’t match announced type"

    That’s what Opera does on XHTML that doesn’t validate against its DTD (fallbacks to HTML), it could be generalized.

    Prerequisite: the sniffer should run in an independent thread and be kept extremely simple – to prevent exploits and browser crashes. Default action should be to stick to announced resource type.

    Mitch

  68. FixMe says:

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

  69. Julian Reschke says:

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

  70. Roman says:

    Can I suggest a compromise?

    Instead of relying on Yet Another IE-only thing, how about treating "text/plain" as authoritative if a charset attribute is used? So plain "text/plain" is sniffed, but "text/plain; charset=charset=utf-8" isn’t.

    Since the latter requires some sort of configuration, it’s unwise to assume that the document is not of the type specified. And since explicit charset is a good thing anyway, you’re going to get less flak for it (just guessing 8=]).

    Of course, this doesn’t solve the problem with other content-types, but from this comment thread I gather that most problems are with text/plain.

  71. @FixMe

    > I’d love to see browsers show a message (perhaps in the status bar, with a nice red background color) to indicate that a webpage’s (X)HTML/CSS/Javascript contains errors.

    I made that suggestion many times, in many forums (particularly at channel9’s wiki) and sadly, it seems now obvious that, even as an add-on, it won’t be implemented in IE 8.

    Webpage Quality indicator icon

    "Implement a feature which will report back to the user if a page uses valid code, has markup and/or parsing CSS errors: some sort of a Webpage Quality indicator icon (smiley or green check for valid page, frown or red ‘X’ when invalid) on the statusbar (or somewhere else) which when clicked would report more info to the user and give him more options among which one would be to validate the page with the W3C validator. Implement something like HTML Tidy as an extension or an option into IE 7 and for IE 7 users.(…)"

    channel9.msdn.com/Wiki/InternetExplorerStandardsSupport/

    Also reported and explained at

    channel9.msdn.com/Wiki/InternetExplorerFeatureRequests/

    and

    channel9.msdn.com/Wiki/InternetExplorerBugs/

    (under heading "Built-in Webpage Quality indicator icon")

    There were others who also reported roughly the same suggestion. Note that now several browsers have some features close to that. Amaya 9+ reports markup code errors and CSS parsing errors. Firefox 1.5+, Opera 9.x, Icab 2+ report CSS parsing errors.

    Regards, Gérard

  72. Michael says:

    Will IE8 have Thumbnail Previews for Tabs?

    This is a must have!!!

    Firefox and Opera can do this!

  73. Need Help !!! says:

    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.

  74. Kristen [MSFT] says:

    @ 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

  75. tmp says:

    Currently using Firefox 3 but making the switch when IE 8 comes out. Just want to know if IE 8 already have the following feature below

    undo close tab = better than searching history.

    copy link location = easier than right clicking a link then selecting properties.

    highlight text then search by context menu = better than typing word in search box.

    drag&drop text from search box = better than typing it

    spelling correction

  76. KB938127 says:

    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.

  77. venkat says:

    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.

  78. handan says:

    document.attachEvent(‘onmessage’,function(e) {  

     if (e.domain == ‘weather.example.com’) {

         spnWeather.innerHTML = window.toStaticHTML(e.data);

     }

    }

    why not support addlistenevent?

    why?

  79. Justine says:

    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

  80. Joel says:

    On the "onmessage" event in the above (bad – non-standards) code example why is the message handled on the document level?  Would this interaction not be on the window level?

    The XMLHTTPRequest is on the window level, so why would the (cross-site) version of this be at a different level? especially when it is accessed via window.XDomainRequest , not document.XDomainRequest.

    Where are the official docs for this window.toStaticHTML(String str) method?

    Also is this .toStaticHTML() method in the IE8 Beta 1 release? I can’t find it.

    Finally – please ensure all future code samples posted are NOT using legacy proprietary IE (non-standards) code.  If you want to post using a wrapper, or pseudo code with a link to a D.I.Y. function thats fine too.  However your "commitment to standards" line will not win any credibility if you continue to promote proprietary code samples from 2001.

  81. Claire says:

    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.

  82. EricLaw [MSFT] says:

    @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

  83. Jimmy says:

    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.

  84. Mitch 74 says:

    @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

  85. CaSe_InSeNsItIvE says:

    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.

  86. 8675309 says:

    fire fox without addons is fine with addons that are buggy it isnt fine

    also the IE team need another way of distributing the vpc images because well if the internet connection cuts out for a sec. you have to restart the download. they should use the Microsoft file transfer manager that was built for MS connect betas eg. WHS beta

  87. Frank Grimes says:

    Jack.. as much as I share your frustrations, resulting to abuse is totally unacceptable.

  88. Michael says:

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

  89. 8675309 says:

    like i said in other posts just enable microsoft File Transfer Manager for ie vpc image download page

  90. two things says:

    Two Things.

    1.) Anoying JS error on this blog:

    Line 318: var anch=document.links[i].href+"";

    2.) Can we PLEEEEEEAAAAAAASE have an option to open new tabs, at THEEEE EEEEEND of the tab set!  When opening links on tab 1 of 5, in a new tab, and I expect them to go at the end where all the rest of my new tabs go, and have done in every other browser and IE6 with addon toolbars… it is painful to have them load next to the tab I’m on, and completely ruins the cronological order of the tabs based on when they opened.

    PS if someone has an addon for IE that fixes item #2 above, please advise as I would like to fix this ASAP.

  91. Chris says:

    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 (?)

  92. n/a says:

    Instead of even extending the list of IE-specific bugs that were once features, couldn’t you just add _one_ more header option:

    X-IE-Stupidity: off (on for the backwards behavior)

    that really,really,really turns on standard behavior (standard mode regardless of DocType, no header sniffing, XML parser when confronted with XML, don’t request favicon.ico, display title attribute in image tooltip, fully support data: URIs and whatever turns out to be an IE5-8 "bug" a.k.a. misfeature  tomorrow) ?

  93. Alhambra says:

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

  94. Vadim says:

    FireFox without addons is fine.

    Will IE8 have Thumbnail Previews for Tabs?

  95. EricLaw [MSFT] says:

    @Vadim: Even IE7 has thumbnail previews for tabs.  Hit CTRL+Q to see them.

  96. Jack says:

    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

  97. Ancient says:

    I’m using a laptop with Vista SP1 and large fonts (120 DPI) enabled.

    After installing latest and freshest IE8 Beta 1, I noticed that some external programs started to show the text blurry as if IE8 messed up with the system components in some way. One notable example is Skype (v.3.8.0.139). Even after uninstalling IE8, the text in those external programs still remained blurry. Only System Restore helped to fix this.

    Another DPI related issue in IE8: even though the text is shown nicely in web sites, the images though are abruptly pixelized – using standard 100% zoom. This is not correct.

    It’s also weird that IE7 & XP handled increased DPI much better compared to IE7 & Vista. The latter is a joke because the DPI setting in most websites often looks to be completely or partially ignored.

  98. 8675309 says:

    what a good feature to see again is a highlighter built into ie again

  99. EricLaw [MSFT] says:

    @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?

  100. ksa says:

    any surprises coming in IE 8 Beta 2 to like a Download Manager or is the feature the same as beta 1

  101. EricLaw [MSFT] says:

    @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…

  102. Daniel says:

    @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"?

  103. Jack says:

    "@Jack: The only comments that are deleted are obscene, contain offensive language, or are "spam" links unrelated to the topic of web browsers."

    Yeah, and I should take your word for it right? Because you ‘ve never lied as a company now, ever…

    "I’m not exactly sure what you’re referring to with regard to CTRL+S functionality?  Did this behave much differently in IE6?"

    I was under the impression that ie6 had a ctrl s hotkey mapping to save functionality. If it was not so, then all the worse. ARE YOU SAVING CTRL S . WHY CAN’T YOU PEOPLE GET ONE SIMPLE THING RIGHT, YOU HAVE TONS OF POST WITH BLAH BLAH THIS AND BLAH BLAH THAT AND FOR SOME REASON YOU HAVE TO FRUSTRATE ABOUT 85% OF HUMANITY WITH NOT IMPLEMENTING A SIMPLE THING RIGHT. ARE YOU SAVING CTRL S FUNCTIONALITY FOR SOMETHING ELSE? CAN YOU PLEASE ANSWER MY QUESTION? WHY IS ALMOST EVERY APP. IN WORLD USING CTRL S AND NOT IE? WHY DO I HAVE TO WASTE A FEW HOURS EVERY MONTH IN TOTAL TO CHOOSE SAVE FROM THE MENU?

    IS IT SOME SORT OF SADISM FROM THE PART OF MS? CAN YOU PLEASE TELL ME WHAT IT IS? WHY DO YOU ALWAYS AND CONSISTENTLY GET THE SIMPLEST THINGS WRONG?

    HOW ABOUT SAVING IN THE BACKGROUND FUNTIONALITY? WHY DO I HAVE TO WASTE ANOTHER FEW HOURS WAITING FOR EACH PAGE TO BE SAVED (PER MONTH OBVIOUSLY) AND IN THE MEANTIME JUST LOOK AT THE DIALOG BOX WITHOUT BEING ABLE TO RESUME MY BROWSING?

    HOW COME ALL YOU GENIUSES HAVEN’T THOUGHT OF A SIMPLE SAVE IN THE BACKGROUND LIKE ALL OTHER PROGRAMS DO?

    IS IT STUBBORNNESS? IS IT RETRIBUTION FOR ALL THE CRAP YOU GET FROM PEOPLE LIKE MYSELF, FOR NOT BEING AS HIP AS APPLE SAY?

    BECAUSE I CAN’T THINK OF A SIMPLE REASON WHY IN THIS DAY AND AGE IN 2008 WHEN HADN’T IT BEEN FOR YOUR COMPANY’S STRONGHOLD ON EVERYTHING SOFTWARE IN THE INDUSTRY WE WOULD HAVE BEEN LIGHT YEARS AHEAD IN COMPUTER HUMAN INTERACTION, I CAN’T THINK OF A REASON WHY YOU CAN’T IMPLEMENT EVEN THE SIMPLEST FUNCTION IN A RATIONAL, SIMPLE, ELEGANT WAY.

    CAN SOMEBODY PLEASE EXPLAIN TO ME WITHOUT HIDING BEHIND YOUR FINGER?

  104. handan says:

    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!

  105. Harold says:

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

  106. Steve says:

    @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

  107. EricLaw [MSFT] says:

    @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!

  108. Brandon says:

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

    LAME, a new window is annoying. We have the yellow bar up our butts, download blocking, page refreshing, new processes, popup alerts. I mean does the IE team not want their browser to be user friendly…seriously.

  109. Ted says:

    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.

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

  111. Internet Explorer 8 – Security

  112. Hyper corrective browser will probably do more harm than good.

  113. IEBlog says:

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

  114. The next beta for Internet Explorer has been released for broad distribution to the public, according

  115. IEBlog says:

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

  116. The second beta version of IE8 was released on August 27th. It is working well in testing so far. Only

  117. IEBlog says:

    Sunava Dutta here, a program manager focused on improving AJAX in the browser! Now that Internet Explorer

  118. 译时代 says:

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

    IE8bet…

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

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

  121. IEBlog says:

    Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approached

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

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

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

  125. Безопасность IE8: защита от вредоносного ПО с помощью фильтра SmartScreen В прошлом году мы опубликовали

  126. I attended Scott Charney&rsquo;s keynote this morning at RSA &ndash; Moving Towards End to End Trust

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