IE8 Security Part V: Comprehensive Protection

a-foton » IE8 Security Part V: Comprehensive Protection

a-foton » IE8 Security Part V: Comprehensive Protection — Wed, 02 Jul 2008 19:09:29 GMT

PingBack from http://blog.a-foton.ru/2008/07/ie8-security-part-v-comprehensive-protection/

Internet Explorer 8 security features

SuperSite Blog — Wed, 02 Jul 2008 19:31:51 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Glen Lipka — Wed, 02 Jul 2008 20:09:19 GMT

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?

re: IE8 Security Part V: Comprehensive Protection

Drive-By — Wed, 02 Jul 2008 20:44:01 GMT

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/

re: IE8 Security Part V: Comprehensive Protection

Kwispel — Wed, 02 Jul 2008 20:44:47 GMT

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?

re: IE8 Security Part V: Comprehensive Protection

Mike — Wed, 02 Jul 2008 23:24:26 GMT

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

Der sicherste Internet Explorer aller Zeiten

TheUndeadable entwickelt — Wed, 02 Jul 2008 23:34:13 GMT

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

Der sicherste Internet Explorer aller Zeiten

TheUndeadable entwickelt — Wed, 02 Jul 2008 23:35:00 GMT

re: IE8 Security Part V: Comprehensive Protection

Vishu — Thu, 03 Jul 2008 00:19:35 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Geoffrey Sneddon — Thu, 03 Jul 2008 00:20:46 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Evert — Thu, 03 Jul 2008 00:31:47 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Kwispel — Thu, 03 Jul 2008 01:26:57 GMT

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>

This page renders as HTML source code (text) in IE8.

</body>

</html>

---

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

re: IE8 Security Part V: Comprehensive Protection

Tino Zijdel — Thu, 03 Jul 2008 01:43:16 GMT

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

File served with Content-Type: text/plain but rendered as HTML anyway

Gérard Talbot — Thu, 03 Jul 2008 01:45:19 GMT

> 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

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

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

Regards, Gérard

re: IE8 Security Part V: Comprehensive Protection

Tino Zijdel — Thu, 03 Jul 2008 02:18:47 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

8675309 — Thu, 03 Jul 2008 02:33:57 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Privacy Concerns — Thu, 03 Jul 2008 03:14:57 GMT

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?

re: IE8 Security Part V: Comprehensive Protection

Brian Smith — Thu, 03 Jul 2008 03:19:13 GMT

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?

Good job!

kL — Thu, 03 Jul 2008 03:25:00 GMT

Congratulations! These features are really impressive!

re: IE8 Security Part V: Comprehensive Protection

Laurens Holst — Thu, 03 Jul 2008 03:36:35 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Tim — Thu, 03 Jul 2008 03:37:32 GMT

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)

re: IE8 Security Part V: Comprehensive Protection

Tino Zijdel — Thu, 03 Jul 2008 04:00:19 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Martin — Thu, 03 Jul 2008 06:36:18 GMT

<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

re: IE8 Security Part V: Comprehensive Protection

toby johnson — Thu, 03 Jul 2008 07:09:44 GMT

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

re: IE8 Security Part V: Comprehensive Protection

toby johnson — Thu, 03 Jul 2008 07:12:59 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Soum — Thu, 03 Jul 2008 08:09:22 GMT

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?

re: IE8 Security Part V: Comprehensive Protection

World — Thu, 03 Jul 2008 09:29:38 GMT

Powerful new feature. Thanks and greetings!

text/html sniffing

Julian Reschke — Thu, 03 Jul 2008 09:34:47 GMT

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?

re: IE8 Security Part V: Comprehensive Protection

Robin — Thu, 03 Jul 2008 10:44:34 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Andrey Moraru — Thu, 03 Jul 2008 11:29:33 GMT

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

re: IE8 Security Part V: Comprehensive Protection

anonymous — Thu, 03 Jul 2008 12:24:40 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

billybob — Thu, 03 Jul 2008 14:02:56 GMT

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?

re: IE8 Security Part V: Comprehensive Protection

Jesper Kristensen — Thu, 03 Jul 2008 15:40:56 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Walter — Thu, 03 Jul 2008 17:19:13 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

William — Thu, 03 Jul 2008 17:47:39 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Roman — Thu, 03 Jul 2008 18:38:47 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Rat — Thu, 03 Jul 2008 19:16:04 GMT

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.

File served with Content-Type: text/plain but rendered as HTML anyway

Gérard Talbot — Thu, 03 Jul 2008 19:33:41 GMT

@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

File served with Content-Type: text/plain but rendered as HTML anyway

Gérard Talbot — Thu, 03 Jul 2008 19:39:33 GMT

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

re: IE8 Security Part V: Comprehensive Protection

EricLaw [MSFT] — Thu, 03 Jul 2008 19:42:53 GMT

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

IE Image

8675309 — Thu, 03 Jul 2008 19:43:52 GMT

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

re: IE8 Security Part V: Comprehensive Protection

8675309 — Thu, 03 Jul 2008 19:59:00 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Julian Reschke — Thu, 03 Jul 2008 20:52:50 GMT

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?

re: IE8 Security Part V: Comprehensive Protection

Hypotheek — Thu, 03 Jul 2008 21:09:34 GMT

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!

File served with Content-Type: text/plain but rendered as HTML anyway

Gérard Talbot — Thu, 03 Jul 2008 21:26:17 GMT

Filed as bug 354921 at

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

Regards, Gérard

re: IE8 Security Part V: Comprehensive Protection

Soum — Thu, 03 Jul 2008 21:35:56 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Soum — Thu, 03 Jul 2008 21:37:50 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Soum — Thu, 03 Jul 2008 21:38:50 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Soum — Thu, 03 Jul 2008 21:43:56 GMT

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 )

re: IE8 Security Part V: Comprehensive Protection

William — Thu, 03 Jul 2008 21:47:34 GMT

EricLaw says:

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.

re: IE8 Security Part V: Comprehensive Protection

Geoffrey Sneddon — Thu, 03 Jul 2008 22:17:36 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Brian Smith — Thu, 03 Jul 2008 22:18:37 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Roman — Thu, 03 Jul 2008 22:24:26 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Mitch 74 — Fri, 04 Jul 2008 02:03:49 GMT

[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

re: IE8 Security Part V: Comprehensive Protection

Chad Grant — Fri, 04 Jul 2008 03:37:27 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Tino Zijdel — Fri, 04 Jul 2008 03:53:18 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Tino Zijdel — Fri, 04 Jul 2008 04:17:27 GMT

@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

re: IE8 Security Part V: Comprehensive Protection

Paul Nankervis — Fri, 04 Jul 2008 10:18:52 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

DDr — Fri, 04 Jul 2008 18:13:15 GMT

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

re: IE8 Security Part V: Comprehensive Protection

FixMe — Fri, 04 Jul 2008 20:32:06 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Joe Cheng [MSFT] — Fri, 04 Jul 2008 21:20:49 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Timebombed IE8 Virtual PC images expire in 1 hour — Fri, 04 Jul 2008 21:59:06 GMT

Timebombed IE8 Virtual PC XP images expire in 1 hour.

So much for testing IE8 out this week!

re: IE8 Security Part V: Comprehensive Protection

nick — Sat, 05 Jul 2008 00:21:10 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Chris Quirke — Sat, 05 Jul 2008 05:39:42 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Julian Reschke — Sat, 05 Jul 2008 10:21:44 GMT

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

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.

SysClean.com interprested as text by IE

Chris Quirke — Sat, 05 Jul 2008 11:41:05 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Julian Reschke — Sat, 05 Jul 2008 11:52:39 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Mitch 74 — Sat, 05 Jul 2008 11:55:42 GMT

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

re: IE8 Security Part V: Comprehensive Protection

FixMe — Sat, 05 Jul 2008 12:16:51 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Julian Reschke — Sat, 05 Jul 2008 12:28:03 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Roman — Sat, 05 Jul 2008 16:23:33 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Gérard Talbot — Sat, 05 Jul 2008 20:27:54 GMT

@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

re: IE8 Security Part V: Comprehensive Protection

Michael — Sun, 06 Jul 2008 17:18:50 GMT

Will IE8 have Thumbnail Previews for Tabs?

This is a must have!!!

Firefox and Opera can do this!

re: We Need Help !!!

Need Help !!! — Sun, 06 Jul 2008 18:52:42 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Kristen [MSFT] — Sun, 06 Jul 2008 20:14:44 GMT

@ 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

re: IE8 Security Part V: Comprehensive Protection

tmp — Mon, 07 Jul 2008 04:39:02 GMT

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

Where the hell is KB938127 for IE7 on XP SP3

KB938127 — Mon, 07 Jul 2008 05:44:44 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

venkat — Mon, 07 Jul 2008 07:30:51 GMT

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 add\remove 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.

re: IE8 Security Part V: Comprehensive Protection

handan — Mon, 07 Jul 2008 11:07:25 GMT

document.attachEvent('onmessage',function(e) {

if (e.domain == 'weather.example.com') {

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

}

why not support addlistenevent?

why?

re: IE8 Security Part V: Comprehensive Protection

Justine — Mon, 07 Jul 2008 16:28:12 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Joel — Mon, 07 Jul 2008 17:20:08 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Claire — Mon, 07 Jul 2008 23:30:18 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

EricLaw [MSFT] — Tue, 08 Jul 2008 01:38:01 GMT

@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

re: IE8 Security Part V: Comprehensive Protection

Jimmy — Tue, 08 Jul 2008 06:12:18 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Mitch 74 — Tue, 08 Jul 2008 12:49:27 GMT

@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

re: IE8 Security Part V: Comprehensive Protection

CaSe_InSeNsItIvE — Tue, 08 Jul 2008 17:43:26 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

8675309 — Tue, 08 Jul 2008 18:13:29 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Frank Grimes — Wed, 09 Jul 2008 21:33:49 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Michael — Thu, 10 Jul 2008 05:17:29 GMT

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

re: IE8 Security Part V: Comprehensive Protection

8675309 — Thu, 10 Jul 2008 17:22:20 GMT

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

re: IE8 Security Part V: Comprehensive Protection

two things — Thu, 10 Jul 2008 23:55:13 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Chris — Fri, 11 Jul 2008 18:18:13 GMT

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

Getting IE to adhere to standards and be bug-compatible

n/a — Fri, 11 Jul 2008 19:25:44 GMT

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

"authoritative" is good, but....

Alhambra — Fri, 11 Jul 2008 19:32:26 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Vadim — Sat, 12 Jul 2008 01:34:11 GMT

FireFox without addons is fine.

Will IE8 have Thumbnail Previews for Tabs?

re: IE8 Security Part V: Comprehensive Protection

EricLaw [MSFT] — Sat, 12 Jul 2008 01:40:58 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Jack — Sat, 12 Jul 2008 06:37:42 GMT

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

IE8 bug with DPI

Ancient — Sat, 12 Jul 2008 14:38:01 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

8675309 — Sat, 12 Jul 2008 21:19:57 GMT

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

re: IE8 Security Part V: Comprehensive Protection

EricLaw [MSFT] — Sat, 12 Jul 2008 22:48:07 GMT

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

re: IE8 Security Part V: Comprehensive Protection

ksa — Sun, 13 Jul 2008 03:55:58 GMT

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

re: IE8 Security Part V: Comprehensive Protection

EricLaw [MSFT] — Sun, 13 Jul 2008 06:11:45 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Daniel — Sun, 13 Jul 2008 10:44:45 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Jack — Mon, 14 Jul 2008 10:44:13 GMT

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

re: IE8 Security Part V: Comprehensive Protection

handan — Mon, 14 Jul 2008 13:52:38 GMT

I do is to web map programming, the map shows that this is the use of the mosaic map TABLE

eg:

<table>

<tr>

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

re: IE8 Security Part V: Comprehensive Protection

Harold — Mon, 14 Jul 2008 18:19:50 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Steve — Mon, 14 Jul 2008 18:28:26 GMT

@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

re: IE8 Security Part V: Comprehensive Protection

EricLaw [MSFT] — Mon, 14 Jul 2008 18:56:40 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Brandon — Tue, 15 Jul 2008 19:37:56 GMT

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

re: IE8 Security Part V: Comprehensive Protection

Ted — Tue, 15 Jul 2008 20:08:30 GMT

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.

re: IE8 Security Part V: Comprehensive Protection

Geoffrey Sneddon — Wed, 16 Jul 2008 00:09:15 GMT

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

Internet Explorer 8 - Security

Timeless Journeys — Fri, 18 Jul 2008 14:11:40 GMT

Internet Explorer 8 - Security

The hyper corrective browser

Capping IT Off — Sat, 26 Jul 2008 16:06:59 GMT

Hyper corrective browser will probably do more harm than good.

IE8 Performance

IEBlog — Wed, 27 Aug 2008 02:19:42 GMT

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

Consumers Begin Using Internet Explorer 8 Beta 2

US ISV Developer Evangelism Team — Thu, 28 Aug 2008 20:16:52 GMT

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

IE8 Security Part VI: Beta 2 Update

IEBlog — Wed, 03 Sep 2008 07:48:15 GMT

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

Microsoft further improves security in IE8 Beta 2

Harry Waldron - Microsoft MVP Blog — Sun, 07 Sep 2008 03:06:05 GMT

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

Updates for AJAX in IE8 Beta 2

IEBlog — Tue, 07 Oct 2008 03:40:50 GMT

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

IE8 Beta2 AJAX 的更新（一）（IE8 Beta2 Hand-on Lab）

译时代 — Sat, 11 Oct 2008 19:34:01 GMT

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

IE8bet...

IE8 Beta 2: изменения в AJAX

Блог команды разработчиков Internet Explorer 8 — Thu, 23 Oct 2008 23:40:46 GMT

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

QWПроизводительность IE8

Блог команды разработчиков Internet Explorer 8 — Mon, 27 Oct 2008 10:16:50 GMT

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

Trustworthy Browsing with IE8: Summary

IEBlog — Tue, 02 Dec 2008 02:36:24 GMT

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

Internet Explorer 8 Beta 의 AJAX 업데이트

IE8 팀 블로그 — Fri, 27 Feb 2009 09:30:03 GMT

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

IE8 보안 5부 : 통합 보호

IE8 팀 블로그 — Tue, 17 Mar 2009 11:53:40 GMT

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

Internet Explorer 8 보안 6부: Beta 2 업데이트

IE8 팀 블로그 — Tue, 17 Mar 2009 11:57:59 GMT

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

IE8 Security Part IX - Anti-Malware protection with IE8’s SmartScreen Filter

Блог команды разработчиков Internet Explorer 8 — Mon, 30 Mar 2009 22:57:19 GMT

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

End to End Trust and Windows 7

Windows Security Blog — Tue, 21 Apr 2009 20:52:53 GMT

I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust

The tastiest dog food yet

Блог команды разработчиков Internet Explorer 8 — Wed, 20 May 2009 17:26:25 GMT

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