Using Frames More Securely


HTML frames (FRAMESETs and IFRAMEs) are a feature of all modern web browsers that enable content from multiple pages to be displayed within a single view. Historically, frames were primarily used to enable partial page updates, where page navigation was contained in one frame, and page content was contained in another. Over time, use of frames expanded to include advertising, mashup, and AJAX scenarios. Today, the majority of popular websites use IFRAMEs for myriad reasons.

From a security point of view, frames can help increase the security of web applications by creating isolation between content delivered from different sources. For instance, a Web mail account (http://mail.example.com) might choose to render HTML email within an IFRAME (http://untrusted.example.com/getmsg?msgid=1234) to ensure that any script in the HTML mail cannot execute in the context of the Web mail application delivered from mail.example.com. Instead, any script would execute in the context of the “untrusted.example.com” domain. This isolation prevents tampering with the Web mail UI, leaking user credentials and cookies, snooping on other messages, etc. 

For frames rendered in Internet Explorer 6 and later, security can be further increased by setting the frame’s SECURITY attribute to the value “restricted”.  Doing so causes Internet Explorer to treat the contents of the frame, regardless of their source, as content that should be rendered in the Restricted Sites Security Zone.  Frames running in the Restricted Sites zone cannot run script, invoke ActiveX controls, redirect to other sites, and so on. This technique is particularly useful in cases where the frame’s content cannot be assumed to be trustworthy (as in the case of web mail scenario above).

However, it is important to understand that HTML frames are not a security panacea. In order to remain secure, a website which chooses to include content from another website in a frame must generally trust that other website to be non-malicious. Otherwise, a number of security threats are exposed.

For instance, consider a web mail application containing two IFRAMEs: one that is used to display an advertisement, and one that is used to display the contents of an HTML email.

<iframe src=”http://ad.example.com/rand/1234.aspx” security=”restricted”></iframe>
<iframe src=”http://untrusted.example.com/getmsg?msgid=1234″ security=”restricted”></iframe>

In the best case, both frames are tagged with the SECURITY=”restricted” attribute to ensure that the HTML email or the advertisement cannot contain any script which might be used to navigate the user away from the web mail page to a malicious site (e.g. <SCRIPT>window.location=”http://evil.example.net/malice.htm”</SCRIPT>).

The user will likely recognize that the email frame contains content of questionable trustworthiness. While the email may contain a phishing attack or other malicious content, it is unlikely that the user will mistake such content as a part of the web mail application itself. In contrast, in the advertising case, unless there is an indication around the IFRAME indicating that the contents are an advertisement, the user could be fooled into taking an unsafe action. For instance, an ad banner could be crafted to match the web mail user-interface, containing text that suggests that there’s a system outage and the user should email their name and password to a given address. The user may mistake the content as a trusted message from the web mail application, and undertake an unsafe action.

Therefore, Web developer best practices for using frames can be summarized as:

  • If possible, do not include frames containing content from unknown/untrusted sites.
  • If possible, use the SECURITY=”restricted”attribute to reduce the privileges of content in the IFRAME.
  • If it is not already obvious to users, clearly mark any frames containing untrusted content.

Eric Lawrence
Program Manager

edit: adjusted quotes around “restricted”

Comments (52)

  1. game kid says:

    I’ll use it once it becomes part of any HTML standard.

  2. Richard says:

    "the user should email their name and password to a given address"

    If there was a system outage in the web-mail application, the user wouldn’t be able to send any email!

  3. It would be nice if this security setting could be done on a <div security="restricted"></div> for the case of things like, say, message comments!

  4. Fish says:

    So, you’re advocating the use of a proprietary HTML attribute that will only work in one browser? Where I work, we try to cater for all users including the ones using IE6 and 7, as silly as it may seem.

    So what’s happening with IE8? You’re not going to make us wait until Mix are you? I mean what’s the point of holding back information when you can release it today?

  5. FarStrider says:

    so does ie7 rss viewer act the same way since it has a nav frame & a content frame?

  6. Michael Ott says:

    You guys are acting as if you are surprised Microsoft care about web standards LOL.

    Man I can’t believe people still talk about iframes. What year is this?

  7. Michael Ott says:

    Oops! My last post should have read "…Microsoft don’t care about web standards."

    Because we all know they don’t.

  8. re: michael ott says:

    what’s wrong with discussing iframes? there are still webdevs out there using them and as long as they do, the IE team is empowered to help them write secure code for their sites.

  9. Veridique says:

    I have never used iframes. Anyway, for the webdevs who still use them, it’s good to discuss :).

  10. I’m glad to hear this. I’m still using iframes on a couple of sites. Sometimes there is no other solution to fix a ‘problem’.

  11. Daniel says:

    Glad to see it’s a IE6 legacy and nothing new.

    I think were going to get better Iframe alternatives anyway with object in IE8.

  12. Tweak Vista says:

    You think so? Maybe you’re right, I don’t know…

  13. Tei says:

    There was a article in http://thedailywtf.com/ about a guy that think the way you write (using frames for safety). This guy was not dangerous, because was a bad profesional. But you guys, Microsoft, can actually do huge damage with that idea. Not only is bad to add a propietary extension. But If people star building stuff that base is safety in this simple point of break, once security="restricted" is broken, all these pages will be broken!.

    Frames are not a safety feature. Theres very few uses for frames. Like the frame that Google images show. Littel else.

    //From a security point of view, frames can help increase the security of web applications by creating isolation between content delivered from different sources//

    NOOO!

    Theres something called "escape". If you are about tho avoid XSS inyections, you must strip the text from tags. Microsoft Internet Explorer make this harder with the support of broken tags like <sc ipt>, but is stil feasible. The response to XSS is not frames, but true escaping.

    Also, we have learned the last 5 years that a webpage is a simple document (SDI), and that how webpages works better. Your suggestion about to make webpages multiple document (MDI) will result on lots of scrollbars on screen, problems printing, problems with the navigation history, etc, etc, etc, etc, etc, etc..  There is a reason everyone and my dog avoid frames, is beacause hare bad for the web.

  14. Daniel says:

    @Tweak Vista:

    Yes. It is already possible, however, not as good as one’d wish. It has a lot of potential though!

  15. thinlight says:

    IE is not the only browser on earth. Do we need to make that clear to you? And in my opinion, now IE is the worst browser ever. If it’s not bundled with the OS, no one will use it.

  16. Frank says:

    Hmmm

    http://msdn2.microsoft.com/en-us/library/ms534622(VS.85).aspx

    Doesn’t come right out and say it, but yes, it is a proprietary attribute on frame’s and iframe’s.

    I’m with game kid, and Fish.  I’m not touching this attribute with a 10 foot pole until I see a W3C spec for it.  Last I checked here:

    http://www.w3.org/TR/html401/present/frames.html#h-16.5

    It wasn’t listed.

    To those above moaning they don’t use iframes, get with the times, they are everywhere, and they fill a void that object can fulfill.

    I’ll also agree with Fish and Daniel.  This is all very good but what does this have to do with IE8? or bug tracking?

  17. speaking of iframes says:

    This highlights one of the most annoying omissions in the IE browser.

    When content loads in an iframe, I often (especially as a developer) want to open that iframe in a separate window or tab.  When I right click, there is no option to "open this frame in a new tab" which sucks, because THIS would give me even more security, if it is running an iframe in another window.

  18. kl says:

    You’ve said it blocks redirects. How an ad in your example is supposed to redirect to advertised page when clicked?

    It blocks ActiveX, but you’ve implement Flash as ActiveX. I agree that blocking it is great idea, but that won’t fly in practice.

    So this isn’t very good for ads.

    Mashups use scripts extensively. If it blocks scripts, it isn’t good for mashups either.

    Filtering HTML in a webmail is difficult if you don’t have appropriate tool for this (HTML parser + XSLT + serializer?), so it might find its use in webmail, but then what about previous IE versions and rest of the browser world?

    This attribute encourages unsafe practices ("Hey, I can put anything there and just add this magic attribute!") which can easily backfire (I can see it already: "Critical Security Update For Internet Explorer: fixes validation of Restricted Zone to prevent malware from hijacknig Windows machines")

  19. anonymous says:

    OMG, what a bullshit. With MSIE, this scenario is always insecure, by design. You can create a new layer, position it over the other, and therefore spoof whichever content you want. Or add a transparent input field to caputre keystrokes. Or use keyboard events to capture keystrokes. Or use reference caching to inject arbitrary script into the other frame.

  20. anphanax says:

    "If there was a system outage in the web-mail application, the user wouldn’t be able to send any email!"

    You’re giving users too much credit.

    "I think were going to get better Iframe alternatives anyway with object in IE8."

    Seems like it wouldn’t do much good until IE 6 and IE 7 are out of the picture. IE, FF, and Safari all understand IFRAMEs. Use what works. Sometimes if you want to make things that work without using scripts, you have to resort to things like IFRAMEs. If people won’t use them because of some "standards" religion they participate in, that’s kind of silly to me since all the major player browsers support them.

    "Your suggestion about to make webpages multiple document (MDI) will result on lots of scrollbars on screen"

    If you design things poorly, yeah, you’re going to end up with extra scrollbars. It’s not like you can’t change the overflow on a block-level element to have scrollbars to show up. You have a valid point about the navigation / printing stuff. It’s still better than those flash-only websites (who needs to bookmark things anyways?[/sarc]).

    "IE is not the only browser on earth."

    No one said it was. Getting on a high horse and looking down on others doesn’t work when you manufacture the words of others and form conclusions based on logical fallacies.

    "You can create a new layer, position it over the other, and therefore spoof whichever content you want"

    You’ve never worked with frames have you? Sounds like they would need to inject into the parent to do that, which wouldn’t be possible if scripts were disabled. You cannot just set the z-index or position: absolute within a child frame and expect to break into the parent. Also, stop using the word "layers". This isn’t the era of Netscape 4 anymore. Also, ever seens what happens when an HTTPS and HTTP frames try and talk to each other?

    "Or add a transparent input field to caputre keystrokes."

    That input would have to have focus, for one.

  21. Speaking of frames, why doesn’t IE have options like "Show only this frame, Open frame in new window/tab, Refresh only a particular frame, Save frame as, View frame source"?

  22. EricLaw [MSFT] says:

    @gamekid: I’m curious, what are you using until then?  

    @FarStrider: The IE7 RSS viewer doesn’t directly use the SECURITY attribute. Instead, the MIME handler that implements the RSS view runs the content in the restricted sites zone using native binary mechanisms.

    @SpeakingOf: Running an IFRAME in another window does not provide any meaningful security.  The new window shares the same security context as the original window.  If it didn’t, new windows & frames from sites you care about (e.g. your bank) would not work correctly because they would not have access to their parent context (cookies/DOM/etc).

    @anonymous: Please support your claims by reporting a repro of any of these to secure@microsoft.com

    @KL: You bring up a good point: the intent of the SECURITY attribute is to protect against "0-click" attacks. Automatic redirections (META Refresh/Javascript) are blocked in the restricted sites zone.  

    If the user chooses to interact with the restricted frame, say by clicking on an A tag, navigation will take place in a new window.

    This scenario isn’t contrived: Web mail clients use this attribute today.  It has been supported by the browser for over 7 years now.

    @Tei: IFRAMES have nothing to do with MDI/SDI; using IFRAMES does not result in top-level documents that cause the problems you’ve described.

    Escaping serves as a good defense in depth IF you have control of the content.  Having said that, it’s actually much more secure to use a filtering approach rather than an escaping approach, because then you can be certain that ONLY known-safe content/tags are allowed rather than attempting to make unsafe content/tags safe.  

    In either case, it’s best to combine filtering & escaping with the SECURITY attribute.

  23. Hello Mr Lawrence,

    A lot could be said about frames, security and IE here.

    First, what I do not understand is why the enforced security is not entirely at the browser level or at the user level (via browser settings). Why does the web author has to be involved, and here, with a proprietary attribute on top of that? Ideally, you want bad (malicious) web authors/content developers or incompetent ones to *not* be able to harm the user, by default…

    —-

    There are several security settings regarding frames:

    Tools/Internet Options/Security tab/Internet Zone/Custom level…button/Miscellaneous section/

    o Access data sources across domains

    o Lauching program and files in an IFRAME

    o Navigate sub-frames across different domains

    Which one(s) correspond to security="restricted"? Why are these settings not explained in an helpfile in Help/Content and Index or elsewhere…? You would want to help, educate, empower the IE users regarding these settings, right? So, where are help content regarding these IE settings in IE helpfiles? You see, Mr Lawrence, right there, there is IMO a weakness with IE.

    —-

    "There are security problems caused by the fact that it is not visible to the user when different frames come from different sources."

    http://www.w3.org/TR/2002/WD-xframes-20020806/#s_intro

    Has Microsoft been supporting work regarding XFrames? Why bring a proprietary attribute as a "crouch" (entirely in the hands of the web author) to a security problem/concern/vulnerability?

    Where/how exactly can I report serious and objectively grave (incapacitating) bugs (like application crash, application hang) to Microsoft?

    Regards, Gérard

  24. Anonymous Coward says:

    Why couldn’t you have made a clearly proprietary CSS property so that designers could tell it’s a property that only Internet Explorer has? Something like -ie-security:restricted; wouldn’t even make the CSS validator mad.

  25. EricLaw [MSFT] says:

    @Mr. Talbot: Security ~is~ enforced at a browser level; frames are not given additional permissions above the permissions of site hosting their content.  So, if you put, say, ads.example.com in the restricted sites zone, then it is run with restricted permissions, regardless of whether or not the SECURITY=restricted attribute was applied.

    The intent of the SECURITY attribute is to permit a mash-up site to request restrictions against framed content that it either did not deliver (e.g. an injected advertisement) or that it did deliver but cannot trust (e.g. user-submitted content).  In the latter case, the SECURITY attribute protects the site (not the user) against script injection attacks that could steal its cookies, etc.

    All of the permissions you list are denied in the restricted sites zone, as are many others.  

    Users should never have any need to toggle any of these settings; the defaults are set the way they are to protect the user.

    <<Why bring a proprietary attribute>>

    The attribute in question has existed since 2001 or earlier.  There’s nothing preventing its adoption by future standards.

    <<Where/how exactly can I report serious and objectively grave (incapacitating) bugs (like application crash, application hang) to Microsoft?>>

    If you encounter a crash using IE, chances are very likely that it’s caused by a buggy add-on (the majority of crashes are).  You can track down buggy plugins by following the steps here: http://www.enhanceie.com/ie/troubleshoot.asp  

    When users choose to submit crash data to Microsoft, we collect data on the crash and can determine where the failure occurred, and if the failure is in IE itself, we can make updates to IE to prevent its recurrence.  

    If you believe you have found a security vulnerability in IE, please submit it to secure@microsoft.com

    Thanks,

    Eric

  26. Min says:

    I need your help, recently my computer has been "spam" with unwanted folders that appear out of nowhere.

    Picture: http://s76.photobucket.com/albums/j13/mana_kazuo/?action=view&current=01.jpg

    the circled on the picture appears out of nowhere, and how do i remove it?

    i’ve just run my anti-virus/etc. software, and they’ve detected a malware..

    i’ve removed it but the circled link won’t go disappear.

    Please help me.

    Thank you.

    aisub3ki@hotmail.com

  27. Fish says:

    @IE Team, you’ve been trying to convince the world that you take web standards seriously and you repeatedly remind us that you’re an opponent of "breaking the web" – now you tell the world to use an old non-standard HTML attribute that only works in IE.

    I wonder how many developers knew about the ‘security’ attribute before, and how many developers are going to start using it because of this blog post.

    Check out this thread about how the security attribute can be used by Bad People: http://www.webservertalk.com/archive380-2005-12-1308076.html

  28. Ted says:

    Some "Solution"…. Installing another browser isn’t going to magically remove malware.  Given the number of security holes in Safari, recommending it is a joke.

    "Fish", why do you think frame-busting is somehow a security feature?  It’s not.  The bad guy could just as easily proxy your html through his server.

    As for "Breaking the web", they’re talking about backward compatibility.  Since IE 6 and later support the attribute, and no other browser breaks if it’s there, this feature doesn’t "break" anything.  Read up on defence in depth!

  29. Min says:

    @IE Team: Is there any other way to remove that thing?

    Coz i prefer to use IE among other browsers(although I have Firefox)

  30. Solution says:

    I never said another browser would solve the problem, only avoid it in the future. Adware is the reason I stopped using IE and I haven’t had any since.

  31. Stifu says:

    @Anonymous Coward

    "Why couldn’t you have made a clearly proprietary CSS property so that designers could tell it’s a property that only Internet Explorer has? Something like -ie-security:restricted; wouldn’t even make the CSS validator mad."

    CSS is for styling pages, not for functionality, quite simply. Your page should still work fine with CSS disabled, too.

  32. Min says:

    Some website wont work properly if it’s not on IE.. so that’s why

  33. anonymous says:

    > Please support your claims by reporting a repro of any > of these to secure@microsoft.com

    Already done that three years ago. Microsoft decided to ignore it, and to keep on ignoring it with IE7.

    With layer I mean a "DIV", and setting the z-index is not necessary. Injection into the parent frame isn’t necessary either, since any frame to create a global event hook for keystrokes.

    Anyway, since the CLSID security bug all those things are just complicated in comparison to simply runnign arbitrary ActiveX controls.

  34. EricLaw [MSFT] says:

    @Anonymous: IE takes reports of security vulnerabilities seriously.

    Please send me (ericlaw at Microsoft) the threads you had with secure, or at least a link to the repro(s).  Thanks.

  35. Jack Scrotum says:

    Seems like the Firefox developers also like this feature. See the enhancement request #341604 on Bugzilla.

    http://bugzilla.mozilla.org/show_bug.cgi?id=341604

  36. flydish says:

    hi ,  I recentyly write an activeX which is used in IE. In the activeX, i used the CHtmlEditView. In IE6, i called

    CHtmlEditView->image to insert an image, it work normally, but i IE7.0, i called CHtmlEditView, when i insert

    an image, it can’t display the image.

    I notice that , when i inserted a jpg, png ,it worked good, but if i insert a gif, it faied.

    Is it a bug for IE7 or CHtmlEditView???

    Who know the answer??

  37. Gordon says:

    @EricLaw [MSFT]

    All good points, but there is one thing missing.

    Sending an email to ericlaw at Microsoft or secure@microsoft is NOT how a public bug tracking system works.

    If you want the community to offer up sincere, valuable information on bugs and security breaches you need to provide a sincere service to allow for uploading attachments, providing links to test cases and most importantly access to track the status of each bug, links to patches and workarounds.

    We’ve indicated on numerous occasions that we are more than happy to be part of the development/testing process, but we expect and deserve to be treated better and have access to critical information for us to do OUR job.

    You want to know about legitimate bugs so that you can fix them.  BUT we need to know (just as much) about these bugs so that we can avoid them, or workaround them, or ensure we update our systems (or client’s systems) to avoid problems.

    Waiting for a serious commitment from Microsoft.

  38. Frank says:

    Gordon… That’s silly.

    No browser tracks security bugs in public; doing so is reckless.  Mozilla security bugs are private until they are fixed.  Opera works in a similar way, as does safari.

    Now, if you want to talk about non-security bugs, fine, but don’t pretend like they’re the same thing.

  39. Micael says:

    Vocês tem que fazer como o Firefox, quando da erro no IE8 eestavam abertos sites e perde o que estava fazendo, ele salva e quando abrir-lo novamente os sites voltarão a serem abertos.

    You has that to make as the Firefox, when of the error in the IE8 open sites eestavam and lose what it was making, saved it and when to open it the sites they will come back again to be open.

  40. Micael says:

    Vocês has that to make as the Firefox, when of the error in the IE8 open sites eestavam and lose what it was making, saved it and when to open it the sites they will come back again to be open.

  41. Gordon says:

    @Frank, I’m not suggesting that a Security Bug should be tracked publicly, however it should be tracked in the same bug tracking system that all the public bugs are tracked in (e.g. 1 System)

    Thus if I have 20 bugs filed, I go to 1 location to track the status of all of them.  If a bug is flagged as security related, then *ONLY* Microsoft and I can access it, track the progress and fix for it.  If Microsoft decides after the fix has been released to also release the info on the bug, so be it.

    My point which is still quite relevant is that the "email me the issue" tactic here is not the way to do professional development of a web browser platform that thousands of developers use and depend on daily.

    If I submit a bug to Microsoft that no one else can track, whats the point.  I haven’t helped anyone with their past/present/future struggle with the issue.

  42. Webhosting says:

    In my opinion, now IE is the worst browser ever. If it’s not bundled with the OS, no one will use it…

  43. MARCOS says:

    i strongly desagree with ie is the worst browser. sure there is a list of browser not so good and i think soon we wil have a different idea about it.

  44. @Gordon

    1- The nr 1 problem with a public bug tracking system (PBTS) is that Microsoft would get a mix of bug reports regarding IE 6 specifically, regarding IE 7 specifically and regarding IE 6 and IE 7 but fixed in IE 8 (or about to). Considering that the userbase of IE is several hundreds of millions, you would get most likely a lot of noise and very little useful signal… and a huge amount of time, energy, personel to untangle all this. So, IMO, it’s not worth it *at this time*.

    Once IE 8 beta 1 is out, then it would make a lot of sense to provide a PBTS for IE 8 only and specifically and with insisting that people follow bug writing guidelines. Such IE 8 PBTS would allow to track a list of bugs occuring in IE 8 and then check/follow-up for regression.

    2- If you visit and surf places like bugs.webkit.org or bugs.kde.org or even bugzilla.mozilla.org, you will see/notice that the objective quality (usefulness, reduced testcase, clear report, etc) of bugs being reported varies a lot. I remember a regular mozilla bugzilla stating that even an important minority of confirmed bugs’ objective quality was overall not that good. Again, you want efforts/typing/time of employees to be concentrated on fixing bugs, not on untangling very poorly written webpages, on resolving as duplicates (DUP), etc..

    3- Right now, Microsoft can view, examine, investigate at least 750 bug reports – excellent bug reports regarding spec violations, well written, well built – that actually happen in IE 7. They just have to visit the webpages of Bruno Fassino, Alan Gresley, Simon Pieters, Robin Lionheart, Ingo Chao, David Hammond, Dan, Tino Zijdel, Nick Rigby, Ingo Turski, incutio.com, Mark Wilton-Jones, etc…, and my IE 7 bugs webpage. So, right now, there is *no urgent, no immediate need* to implement a PBTS. You see, there are already so many bugs being reported and bug reports with good working quality that Microsoft can go and jump immediately into *fixing* those already well-defined bugs. And here, I’m not even mentioning the official CSS 2.1 Test suite (and other official test suites) and Ian "Hixie" Hickson extensive test suite (covering CSS, DOM, HTML) for browsers.

    And here, I’m not even mentioning unsupported DOM 1 and DOM 2 attributes, methods, interfaces and unsupported CSS 2.1 properties.

    4- Microsoft’s agenda is not the web authors’ agenda nor the web standards movement’s agenda. There are some common denominator, overlapping areas of agreement when one superpose, overlap those 3 agendas. Microsoft’s main/primary goal, primacy is making its share holders happy and about profitability. Microsoft is a business, profit-driven. You can not say the same with KDE, Mozilla, WebKit, TKHTML, etc. So a solution, a perfect tool applying to them may not be transposed, transferred, just like that, to Microsoft. Even Opera does not have a *public* bug tracking system.

    Regards, Gérard

  45. @Gordon

    >we expect and deserve to be treated better

    I absolutely agree with you on this. We should have all said so starting in 2001, 2002, 2003 and 2004. The only way to communicate such "respect me better, treat me better" demand to Microsoft at that time was to download and install a better browser, at that time, like Mozilla 1.6+ or Opera 7+.

    > You want to know about legitimate bugs so that you can fix them.

    Such list of bugs is already known to Microsoft. Visit my IE 7 bugs webpage.

    > we need to know (just as much) about these bugs

    Visit my IE 7 bugs webpage. All the bugs (reproducible, with well coded testcase, links, test suites, etc) are listed.

    > so that we can avoid them,

    Install, download and use Firefox 2 (or Firefox 3) and/or Opera 9.5 and/or Safari 3.0.4. And keep your better browser updated with latest available version. Realistically speaking, there is nothing better to do *right now* to avoid them.

    > or workaround them,

    Use conditional comments. Not a perfect or ideal solution but the best right now according to a large, wide consensus. Even Microsoft suggests conditional comments.

    Above all, use true CSS forward-compatible workarounds, solutions. CSS hacks are bad, increasing DOM tree with <br> is bad, extra wrapping <div> is bad idea.

    > or ensure we update our systems (or client’s systems) to avoid problems.

    Put a browsehappy.com button or alternativebrowseralliance.com button somewhere in your webpages… and a code conformance policy webpage and an accessibility policy webpage. I’ve seen good webpages of this sort. Right now, realistically speaking, there is nothing better to do.

    Your users should not be upset just because there is a small layout glitch here, a minor misalignment, a barely noticeable layout difference (like a dashed border instead of a dotted border) between IE and other good browsers.

    Regards, Gérard

  46. Frames are useful when used correctly, almost never. However it’s obvious people in positions of power (be it assigned of self-proclaimed) abuse the required objectivity for such position: hence the lack of target attribute in XHTML without a CSS property. Another example is the vanity of the HTML5 working group to proclaim HTML5 will be the last version of HTML ever (as implied by the severally lacking Doctype which lacks a version number and thus implies it will be the last version of HTML).

    @ Gérard – I agree with your second point. Every frigin time I painstakingly made a quality report using correct terminology, accurately describing the bug, and testing it in numerous other browsers I would only see it disregarded as a duplicate of an already existing bug made by someone who might as well have been reporting it as if they couldn’t put out a fire on their head until they entered in x number of characters in x number of required fields!

    Also…WHEN has Microsoft suggested using conditional comments?

  47. John,

    Believe it or not, I’ve been trying to reach you yesterday about your MADD bug. I successfully was able to report to Microsoft Security Response Center (MSRC) a webpage

    http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/#bug92

    inspired by your September 2nd 2006 MADD webpage post in IE blog. To make a story short, yes, it can be quite difficult to report a serious problem to Microsoft.

    > WHEN has Microsoft suggested using conditional comments?

    "In mid October, the IE Blog urged developers to stop using CSS hacks to workaround IE’s problems, and start relying on Microsoft’s proprietary conditional comments."

    http://www.webstandards.org/2005/11/03/ie7-conditional-comments/

    "We ask that you please update your pages to not use these CSS hacks. If you want to target IE or bypass IE, you can use conditional comments ."

    http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx

    Regards, Gérard

  48. steve says:

    Gordon, doesn’t sound like you have a lot of customers, or you would know the problems that come with what you are suggesting. Once you start adding outsiders to your qualified persons bug list, it can be hard to stop. Best way is to use corporate relations and partner programs so Microsoft can qualify people before they can access such a thing. That leaves out little people (who might be talented), but it insures weighed opinions on the matters. If the comments across this blog are any indication, most bugs will be "IE Sucks," script kiddies will try and flood it, etc., etc.

    I think the problem is that many webdevs think that they deserve to be on the bug list because they are so smart (and thus, likely frustrated by IE’s bugs). MS must do a cost/benefit analysis to see if appeasing such a group is worth it. Personally, I can see not wanting to do that until the product is more up to date so as to eliminate all the "FF3 has xyz, you don’t, it is therefore a bug" stuff. So perhaps in the future, maybe the IE8 timeframe, it might happen. If it’s worth it to appease non paying customers. I think it is, so maybe MS will too.

  49. vincentmtb says:

    I have never used iframes. Anyway, for the webdevs who still use them, it’s good to discuss :).

  50. iframes sound practical.  I’m unconvinced as to why everybody doesn’t use them.  It’s just like user a "hacker-safe" program.

  51. Rob Scott says:

    If you want the content to be searchable and indexed, then an IFrame is not the way to go, however, they are great for delivering separate (and disparate) content, and for security reasons as you rightly state.

    I use IFrames a lot, but they are relatively limited. I also dislike the fact others can effectively show my content with their own ads / messages next to it using iframes.