Subscribe: IEBlog
Added By: Feedage Forager Feedage Grade B rated
Language: English
add  beta  call  context menu  context  createurlmoniker  file  new  search  security  update  uri  user agent  user  windows 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: IEBlog


The Microsoft Internet Explorer Weblog

Last Build Date: Wed, 27 Sep 2006 12:28:05 +0000


More Add-Ons: NewsGator Desktop Sync (Beta)

Fri, 22 Sep 2006 07:02:00 +0000

Add-ons for the IE platform are more than just toolbars, custom browsers and find-on-page add-ons. The edges of what you can do with the platform are virtually unlimited. Earlier this year at Mix06, Greg Reinacker and Walter VonKoch demo’d a tool for synchronizing the RSS platform state with your NewsGator online account. On Monday, Nick Harris (no relation) at NewsGator announced that the tool, renamed “NewsGator Desktop Sync” is available for general beta. From his post: “Desktop Sync is a system tray application that keeps your feeds, folders and read states synchronized between NewsGator Online and the Windows RSS Platform. This means that any application that uses the Windows RSS Platform will be automatically synchronized with your NewsGator Online account!” Of course, since IE7 uses the Windows RSS Platform, this is a great way to roam the feeds you read in IE from one machine to another. Check out Nick’s post for information on where to download and where to give feedback on the tool. Pick it up and try it out. Be sure to check out the many other add-ons at and let us know what you think. Mark Harris Lead Program Manager - Extensibility [IMAGE]

September Chat Transcript Now Available

Fri, 22 Sep 2006 06:28:00 +0000

Hey all, Here’s the link to the transcript for the September Expert chat: We will be holding another chat in November for those of you who couldn’t make this one. Information about our upcoming chats can be found at: Cheers, Uche Enuha Program Manager [IMAGE]

The IE7 User-Agent String

Wed, 20 Sep 2006 07:29:00 +0000

In April 2005, we blogged about the new Internet Explorer 7 User Agent string sent to websites by the browser to identify itself. Since our original blog posting, we have also posted two new articles on the topic to MSDN: Understanding User-Agent Strings, and Best Practices for detecting the Internet Explorer version. A quick recap: * On Windows XP SP2, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) * On Windows 2003 Server, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2) * On Windows Vista, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Over the last eighteen months, most sites that had previously blocked the new version of Internet Explorer have been updated, and we’re happy to report that the vast majority of Internet sites are now accessible using IE7. There are a few remaining sites which fail to recognize IE7 because they are performing exact string matches to look for specific IE version strings. Those checks will need to be removed or updated to accommodate IE7. The Best Practice document linked above provides suggestions. To enable you to workaround any remaining sites that block access to Internet Explorer 7, we developed the User Agent String Utility. The utility comes in the form of a small executable that opens an IE7 instance that sends the IE6 user agent string. It also provides a mechanism for you to report problem web sites to Microsoft so that we can follow up with the affected site owners. Please download the tool and give it a try. We look forward to your feedback! Eric Lawrence [IMAGE]

IE7 Dialog Sizes - A Quick Update

Tue, 19 Sep 2006 07:30:00 +0000

This is just a follow up to my recent post about dialog sizing in IE7. Based on your feedback regarding the minimum dialog height restrictions, my team re-evaluated our position and changed the minimum height from 150 to 100 pixels. We think this change: * Reduces application compatibility issues where dialogs were coded to the IE6 minimum height * Is more consistent with other browsers’ minimum height providing more consistency for content developers Again, we appreciate your constructive feedback. Keep it coming. -Travis Trident/OM [IMAGE]

Direct Animation Overflow and IE7

Fri, 15 Sep 2006 13:45:00 +0000

A researcher posted a vulnerability against IE6 yesterday that uses random input to create a heap overflow in a Direct Animation object. Our team is testing a security update right now to fix this overflow, but in the meantime you can keep your systems safe from this vulnerability by disabling ActiveX controls in the internet zone. If you’re a desktop administrator responsible for a set of desktops, you can publish a more tactical fix by disabling the control. If you have the ability to set registry keys on user desktops, the following key will disable the vulnerable object: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D7A7D7C3-D47F-11D0-89D3-00A0C90833E6}] "Compatibility Flags"=dword:00000400 The fact that the research community found this bug is a credit to them, evidence of the continued creativity going into tools like HD Moore’s metasploit. I admire their creativity but I do think a public disclosure is a missed opportunity to work together on the problem. Security researchers like Dan Kaminsky and Mark Litchfield want the same thing as the security engineering teams. Researchers want to find inventive new attacks and see their creations fixed elegantly by the security engineering teams. I welcome and challenge more researchers to come participate in the process, you can start with a mail to The good news in yesterday’s disclosure is that IE7 is safe against this attack and many of the other recent attacks on IE6. The input of the security community had a deep impact on the security strategy for IE7. As we worked with researchers to strengthen the core of the IE7 codebase against threats, we also eliminated threats on the periphery by reducing the attack surface that we expose to malicious websites. Most notably, IE7 reduces attack surface by disabling most ActiveX controls on the system by default. We actually went a step further with Direct Animation control and effectively remove it when you install IE7. While we’re reducing the attack surface from ActiveX, pragmatists will realize that ActiveX controls and other binary extensions are a part of client software for the foreseeable future. ActiveX controls are important and can be built just as safely as any other client code. I’m in frequent contact with the engineering teams for the most commonly used active controls on the internet like Adobe Flash, Apple Quicktime, the RealPlayer, WMP, the Sun JRE and Adobe Acrobat. They are also working with the security research community. They are making the same type of investments to strengthen their controls against attacks. Some developers will re-enable less commonly used controls for particular scenarios on some systems. Since the default for most ActiveX controls in IE7 is off, the value of an ActiveX vulnerability like the one reported yesterday will start to approach zero. Rob Franco Lead Program Manager [IMAGE]

IE7 Phishing Filter Update

Fri, 15 Sep 2006 08:02:00 +0000

Greetings! I’m Raghava Kashyapa, Program Manager for the Microsoft Phishing Filter technology in IE7. As you might already know - it is important to use the latest versions of IE7 to get the benefits of all the changes we have made over the past year since the release of the first public beta. We made improvements to the client based on feedback and want to ensure users use these new and improved builds of the browser. The impact of these improvements means that older IE7 beta versions prior to IE7 Beta 2 (versions 7.0.5296.0 and older) will no longer work with the Phishing Filter Service. This primarily affects anyone who is still using IE7 Beta1 and the IE7 Beta 2 Preview. If you’re running any of the affected old builds, you will notice a “phishing filter service is unavailable” icon on the bottom right corner of your browser window: Phishing Filter Service Unavailable Dialog Recent builds, including all versions newer than IE7 Beta2 (build 7.0.5346.0 and upwards) will be unaffected. To get the most up to date improvements I would strongly encourage you to download and install the latest version of IE7. Cheers, Raghava Kashyapa Program Manager [IMAGE]

CreateURLMoniker Considered Harmful

Wed, 13 Sep 2006 08:31:00 +0000

While working on IE7 application compatibility, we’ve seen many cases of interesting and strange invalid file URIs. I believe a substantial amount of responsibility for the confusion over file URIs lies with the deprecated urlmon.dll function CreateURLMoniker. This function is used by Windows application developers mainly to convert a string URI into an object that can be used to obtain the data represented by the URI. CreateURLMoniker does a couple of horrible things to file URIs that if misused can lead to security bugs. For those application developers who have used this function in the past allow me to describe what’s wrong with CreateURLMoniker and what to use instead. Solution If you’re not a Windows application developer or you’re not interested in the details and don’t plan on reading any further here is the solution up front: Use CreateURLMonikerEx with the flag URL_MK_UNIFORM instead of CreateURLMoniker to avoid problems with file URIs. The problems with CreateURLMoniker were discovered sometime ago and this flag was introduced to allow people to switch to a valid URI parser that will do the correct thing with file URIs. We couldn’t switch to using the valid URI parser without breaking a huge number of applications that depend on this functionality. Additionally, if what you’d like to do is convert between a file URI and Windows file path, the shlwapi.dll functions PathCreateFromUrl and UrlCreateFromPath will do this correctly. Problems The first problem concerns the IMoniker output of CreateURLMoniker. A call to IMoniker::GetDisplayName will produce a string containing an invalid file URI. It will be in the form that Zeke named Legacy File URI and described on his blog. This form cannot be parsed with a general URI parser and as such may not be compatible with some APIs. The second problem concerns the input to CreateURLMoniker. CreateURLMoniker will decode any percent-encoded octet (except ‘%00’) in a file URI or Windows file path provided as input. This means that the URI you get out of CreateURLMoniker in IMoniker form may not necessarily be equivalent to the URI provided. As noted in the URI standard you can’t decode just any percent-encoded octet and expect to get an equivalent URI back. If that were the case there wouldn’t be any point to percent-encoding in URIs. Since CreateURLMoniker will decode ‘%25’ to its corresponding ‘%’ the process is not idempotent. This means that applying CreateURLMoniker to a URI again and again may produce a different URI each time. Examples For example given the following Windows file path, the corresponding correct file URI, and the output from CreateURLMoniker follow: Original Path: C:\Documents and Settings\davris\Project100%28years.xsl Correct URI: file:///C:/Documents%20and%20Settings/davris/Project100%2528years.xsl CreateURLMoniker Result: file://C:\Documents and Settings\davris\Project100(years.xsl Note that the result from CreateURLMoniker identifies a file named “Project100(years.xsl” rather than the intended file name “Project100%28years.xsl”. As noted above CreateURLMoniker is not idempotent. For example, starting with the following Windows file path and passing each resulting string back through CreateURLMoniker gives the following sequence of results: Windows file path: C:\foo%25252544.txt CreateURLMoniker call 1: file://C:\foo%252544.txt CreateURLMoniker call 2: file://C:\foo%2544.txt CreateURLMoniker call 3: file://C:\foo%44.txt CreateURLMoniker call 4: file://C:\fooD.txt This can lead to security problems in which one portion of a system believes its working with one URI while another portion of the system that has run its URI through CreateURLMoniker a different number of times believes its working on a different URI. Changes in IE7 In IE7 we still cannot change CreateURLMoniker to use [...]

Update Available for IE 5.01, IE 6.0 SP1, and IE 6.0 on Server 2003

Tue, 12 Sep 2006 07:01:00 +0000

This morning we re-released three versions of our August 2006 cumulative security update (MS06-042). As I had written about before, the original release of MS06-042 introduced a new security vulnerability for IE 6.0 SP1 users which we addressed in a subsequent re-release. However, with the increased scrutiny this release received, a security researcher responsibly disclosed to us that a similar vulnerability was also discovered in IE5.01 on Windows 2000, IE 6.0 SP1 (in a different location), and the original release of Windows Server 2003 (not SP1). This re-release fixes that vulnerability. This update is available through all of our normal release channels including Windows Update, Automatic Update, Download Center and our deployment tools such as WSUS. We recommend all affected customers install the update immediately. Users running Windows XP SP2, Server 2003 SP1 or any of the IE7 betas, IE7 Release Candidate 1, or Windows Vista are not affected and do not need to take action. This release and the need for subsequent re-releases have certainly been a learning experience for us. This update cycle has not been an example of our best work, but as I mentioned earlier we have used this experience to improve our processes and increase transparency to ensure all of our releases are of the quality we expect and our customers deserve. Tony Chor Group Program Manager edit: removed Download Center link [IMAGE]

RSS Secure by Design

Mon, 11 Sep 2006 09:31:00 +0000

One of the reasons we went to Blackhat last month was to show how the Security Development Lifecycle (SDL) has changed the way that Microsoft builds products. I talked about how we’re reducing attack surface with features like ActiveX opt-in, improving code quality and building-in Defense in Depth with Protected Mode. I didn’t get a chance to cover the new RSS feed support but I think the RSS team’s work is a great example for anyone building a new client to handle RSS feeds and a case study in how much Microsoft has changed product development. The RSS team put a set of security principles in place before they set out to build their feature, they meticulously modeled the way that data would flow through their components and their developers were determined to build the feature to spec. Designing security upfront has helped the RSS team keep the same basic architecture in place since day-1 and pass security test suites with flying colors so far. I would never expect a feature to be “bulletproof” but I credit the RSS team with applying tough security principles and state-of-the-art tools to get this far. If you handle feeds, as a developer or just as user, take a look at Sean’s latest post for more on what they did. Rob Franco Lead Program Manager [IMAGE]

September IE Expert Zone Chat

Mon, 11 Sep 2006 09:00:00 +0000

Just wanted to remind everyone that the IE team will be having our Expert Zone chat on Thursday September 14th at 10.00AM PDT (5.00PM GMT). We’ll also post the transcript shortly after the chat for those of you who can’t make it. Cheers, Uche Enuha Program Manager [IMAGE]

Extending IE Quick and Dirty

Thu, 07 Sep 2006 12:00:00 +0000

As a scripting junkie at heart, I set out to write an extension in script for IE7: inline search – searching the document for text while I type. Before you get too excited, this does not replace the Find functionality in IE7. It’s just me getting excited about scripting. After investigating the different places I could extend IE with script, I decided to implement inline search as a context menu. All I had to do was create an HTML or JavaScript file with my script in it and add keys to the registry as described below. My context menu item appears whenever I right-click the page. When the user chooses "Inline Search" from the context menu, the "Find" dialog is displayed. As soon as she starts typing, it highlights the search terms on the document in yellow with black text. By default the first instance of the search term found is called the "current" instance, and is highlighted in aqua. Pressing "" (Next) buttons changes the current search term. When the user closes the dialog, all the search terms are returned to their original coloring. The Script Context menu scripts execute in the context of the current page. Once you get a handle to the DOM from window.menuArguments.document, you can do whatever you want with DHTML – rewrite the page, highlight text, display additional UI, or even call web services. With a handle to the DOM, the script is pretty straight-forward. At each keyup event, it searches the document and highlights matching terms. On pages with framesets, it only searches in the context of the frame that was right-clicked on. Also, for performance reasons, it only searches for terms that are at least 2 characters long. I use the DOM method execCommand to change the background color of the page around the highlighted text to yellow and the text to black. The relevant code for searching the text is below. function findStrings() { // With each character press, search for the text typed // in the search box. var sz = new String(txtFindText.value); var rgFoundText = new Array(); // array of ranges where text is found var iMatchFlags = findFlags(); // whole word/match case/etc. // performance optimization - don't look for less than 2 character words if (sz.length >= 2) { // enable next/prev buttons btnFindNext.disabled = false; btnFindPrev.disabled = false; var trTextRangeToSearch = g_Doc.body.createTextRange(); while (trTextRangeToSearch.findText(txtFindText.value, ALL_CHARS, iMatchFlags)) { // add them to our array rgFoundText.push(trTextRangeToSearch.duplicate()); // search for the next occurrence trTextRangeToSearch.collapse(false); } // call my local function to draw the screen // with our search terms highlighted redrawScreen(rgFoundText); // keep track of text we found g_rgFoundText = rgFoundText; } else { // disable the next/prev buttons btnFindNext.disabled = true; btnFindPrev.disabled = true; } } Registering with IE With your script in hand, the next step is to tell Internet Explorer to include your script in the context menu. To register a context menu item, you add a key to the HKCU\Software\Microsoft\Internet Explorer\MenuExt, with the name you want to see in the context menu. The default value of this key should be a URL pointing to the script to execute. If you add a DWORD value under this key called "Flags" with the value 0x1, the script will execute as if it were launched from a call to showModalDialog. Below are the relevant lines from my installer batch file which registers the inline search script attached to this post. This code registers a context menu item named “Inline Search”, which executes the file “C:\Program Files\IEXTNSN\findonpage.htm”. The “Flags” value makes it execute as if it had launched from a call to showModalDialog(). reg ADD "HKCU\Software\Micros[...]

IE Developer Center Refresh

Fri, 01 Sep 2006 09:21:00 +0000

We've just completed a redesign and refresh of the IE Developer Center on MSDN. The goal is to make it easier to find IE related developer content and even includes an updated photo of me with the neon blue 'e' behind me that you can find in the lobby of our building on the Redmond campus! We've worked to make some of the essential links such as reference material easier to find and we will be promoting different content on the front page regularly making it well worth visiting on a regular basis or subscribing to the RSS feed. We have also made two MSDN forums to get support for web development and extension development for IE. These will be great resources if you have questions and people are encouraged to answer anything they know the answer to. If you have bugs to report or feedback to provide the links on the support page remain the best place to go. Some articles along with numerous reference pages have also been updated with IE7 content over the last few months. In particular the Zentech page demonstrating the CSS improvements in IE7 is now available. As always all feedback on how we can improve documentation is appreciated. Thanks, Dave Massy Program Manager [IMAGE]

Search in IE7 RC1

Thu, 31 Aug 2006 09:05:00 +0000

Last time I posted about search I talked about our new extensibility mechanisms: window.external.AddSearchProvider, and Search Discovery. Today I’d like to talk about enhancements we made since that post, and point you to a tool that you can use to create your own custom providers. To recap the last post: In Beta 2, window.external.AddSearchProvider gave website authors the ability to put a link on their page to prompt users to add a new search provider. We locked this call down using logic similar to how we lock down pop-up windows to ensure it would not be abused by bad sites. Since then we have added a few additional features. window.external.IsSearchProviderInstalled Since Beta 2 we received feedback that sites really do not want to show those links for the people who already have their providers installed: similar to how our homepage API works. To make life better for site authors we introduced a new API: window.external.IsSearchProviderInstalled. A site author can use this API to see if their provider is already on the search provider list and also check to see if it is the default. In order to protect your privacy we created this API in a way that sites can only ask about providers with the same top level domain. For instance: can ask if any search provider is installed, but cannot ask if a provider is installed. For more details on this API please check out the MSDN article. OpenSearch Referrer Extension In Beta 3 we did not have a good mechanism to tell search providers whether the query came from the search box or the address bar. OpenSearch has an extension for this (the referrer extension) and RC1 supports it. Here's an example for the following OpenSearch URL: If the query came from the address bar IE will replace "{referrer:source?}" with "IE-Address", and if it came from the search box we replace it with "IE-SearchBox" allowing search providers to track which IE 7 entrypoint their search came from. Search Discovery Sound If you recall from my previous post, Search Discovery is a feature web sites can use to ‘suggest’ search providers in your search provider dropdown. When you navigate to a site that supports Search Discovery the search button dropdown will change color, and the discovered provider will appear within the dropdown. Since we introduced this feature we have seen adoption on various sites around the web. A great example of a site that recently started supporting Search Discovery is Yahoo! Tech. In Beta 3 we did not have a fully accessible notification for Search Discovery; we only had the ability for the button to light up. In RC1 we added the ability to set a sound for this action. It is off by default, but you can set this sound where you set other windows sounds (the “Sounds and audio devices” properties from the Windows Control Panel). From this properties dialog select the “Sounds” tab and add a sound to the “Search Provider Discovered” event within the “Program events” box. Build your own provider Shifting gears slightly, another piece of feedback that we’ve heard is that people would like to know how to add custom providers not necessarily shown on the Windows Search Guide. We hope that eventually your favorite site will leverage Search Discovery or AddSearchProvider, but until then you can add a specific provider yourself using this tool. Have fun, and keep browsing! Aaron Sauvé Program Manager [IMAGE]

Notes on the interaction of ClearType with DXTransforms in IE7

Thu, 31 Aug 2006 09:00:00 +0000

Hello again, this is Peter Gurevich, IE PM for ClearType (among other things, as my blog posts have shown). Today I want to give you a little heads up on an issue we have seen with DXTransforms and ClearType, and let you know what we have done to ensure good readability of text in IE. During our testing we noticed that DXTransforms are sometimes applied to elements that contain text (now rendered in ClearType). As our users also noticed, the ClearType text then looks extremely blurry - unfortunately these two technologies just don’t mix well. This is because the basic convolution transform used by DXTransforms does not take into account the spatial nature of ClearType. To ensure good readability of Text in IE, in the Release Candidate build we decided to disable ClearType on elements that use any DXTransform. We will render the text in those elements as aliased text, in order to increase readability. The rest of the text in the page will render with ClearType. This may explain why some sites (or portions of sites) will render as aliased text, rather than ClearType. Thanks, and I look forward to continuing to use your feedback to improve IE. Peter Gurevich Program Manager [IMAGE]

IE7, IE6 & The Windows Lifecycle

Wed, 30 Aug 2006 08:07:00 +0000

I’ve been getting questions from folks lately who are wondering what will happen to IE6 (SP1) when IE7 ships. “Will Microsoft continue to provide security updates for IE6 after IE7 ships?” “Will customers have to migrate to IE7 by some point in time?” The answer is simple: IE6SP1’s support policy will not change when IE7 ships. Everywhere that IE6SP1 is supported today, IE6SP1 will continue to be supported until the OS it ships with expires. Are you running IE6SP1 on Windows 2000 SP4? You will continue to get support for IE6SP1 until Windows 2000 expires (slated expiration: 2010). Are you running IE6SP1 on Windows XP SP1? You will continue to get support there until it expires in October. If you’re running IE6 for Windows XP Service Pack 2, you can stay with that version of IE for as long as Windows XP SP2 is around. I would continue listing versions of Windows, but I think you get the idea. Additionally, users will not be forced to migrate to IE7 when it’s released. Of course, we hope our users will upgrade – we’re proud of IE7 and are excited to see it ship! But, if you don’t want to move, you won’t have to. We will continue to keep our IE6 customers secure for those of you who can’t or don’t upgrade to IE7. As previously mentioned, Windows Update’s Automatic Updates will offer IE7 to everyone by default, but it won’t force you to install it. I’ve blogged about this before as well in case you want to see what I said about the lifecycle 18 months ago. And as always, be sure to check out our official lifecycle site for a full list of products, dates, and definitions. Thanks, Christopher Vaughan [IMAGE]