Microsoft's Security Vulnerability Research & Defense team (SVRD) have recently posted information online about the Cross Site Scripting (XSS) filter to be incorporated into Internet Explorer 8 when it is released.
There are the three main conditions that the SVRD team have identified as being necessary to be met in order for the filter to be effective.
Compatibility
The filter needs to have as close to zero impact on normal content and Web traffic as possible. The reality is that there will be some level of impact as the filter is tweaked in an ongoing process to find the right balance between security and usability. Too much of an impact to basic traffic could result in the user rushing to turn the filter off as quickly as possible. Not stopping enough XSS attacks and the filter may as well not exist.
Security
Basically the SVRD team are using this approach to describe resistance to polymorphic XSS attacks. It should not be a simple matter to bypass the filter's protection through simple modification of an existing attack.
Performance
Having the filter active should not introduce too much of a performance hit to the browser, or else the user will again rush to disable it. The requirement for performance means that certain models and approaches are not going to be suitable and so some compromise needs to be met.
As with a lot of technology where there are three criteria to be satisfied, it's not going to be possible to have a product strong in all three areas without at least some compromise. Where that compromise ends up being will be seen once the filter reaches widespread usage, but the rest of the architecture post gives some hints as to where those compromises were made.
Performance requirements meant that the implementation method for the filter has moved from being a MIME filter, where it intercepted requests and responses before the rendering engine had a chance to display the content, to actually forming a part of MSHTML.
This little factoid is more important than the in-browser support itself. It means that any future application that is developed to render HTML / Web content using Microsoft's MSHTML should be able to access integrated XSS filtering (provided that Microsoft make the API for accessing it readily available).
To compare, it would be like integrating an XSS filter for Safari into the WebKit system component and making it available for all OS X applications wanting to render HTML, or into the Gecko (Mozilla family), KHTML (Konqueror and original source for WebKit), Presto (Opera, Adobe), or other HTML rendering engines.
One of the more intriguing design decisions is not to assess content that is set to be rendered as an image. Because of IE's historical issues with MIME-type sniffing and mangling, this sounds worse than it actually is. One of the changes to be introduced with IE 8 is a new way of assessing MIME-types, especially if a script is masquerading as an image file (something earlier versions of Internet Explorer, including IE 7, would have tripped up on).