The navcancl.htm local resource is used by the browser when for some reason a navigation to a specific page is canceled.
When a navigation is canceled the URL of the specific page is provided to the navcancl.htm local resource after the # sign. For example: res://ieframe.dll/navcancl.htm#http://www.site.com.

Microsoft Mistake #1: Using a nonstandard mechanism to pass parameters to a page.

The navcancl.htm page then generates a script in the "Refresh the page.” link in order to reload the provided site again when the user clicks on this link.
It is possible to inject a script in the provided link which will be executed when the user clicks on the “Refresh the page.” link.

Microsoft Mistake #2: Having a DOM-Based XSS Exploit standard in every version of IE7.

Luckily, Internet Explorer now runs most of its local resources (including navcancl.htm) in “Internet Zone”, so this vulnerability cannot be exploited to conduct a remote code execution.

Ok, well this is better... wait a second, did they just say "most" resources? Hmmmm

Unfortunately, there is also a design flaw in IE7. The browser automatically removes the URL path of the local resource and leaves only the provided URL. For example: when the user visits res://ieframe.dll/navcancl.htm#http://www.site.com, IE7 will show http://www.site.com in the address bar.

... ... are you kidding me?

Microsoft Mistake #3: Allowing the address bar to say its pointing at one URL when its really pointing at another

To perform a phishing attack, an attacker can create a specially crafted navcancl.htm local resource link with a script that will display a fake content of a trusted site (e.g. bank, paypal, MySpace).
When the victim will open the link that was sent by the attacker, a “Navigation Canceled” page will be displayed. The victim will think that there was an error in the site or some kind of a network error and will try to refresh the page. Once he will click on the “Refresh the page.” link, The attacker’s provided content (e.g. fake login page) will be displayed and the victim will think that he’s within the trusted site, because the address bar shows the trusted site’s URL.

Ok, seriously now. I've meet the security PM for IE7 and he is a cool guy and all, but I'm seriously wondering if IE team actually cares about security. Ignoring the implications of their mistakes, I simply fail to understand how things like mistake 1 or mistake 3 make it through a code review on a project that was "redesigned from the ground up with security in mind." You mean to tell me that you actually have code in your app that allows the URL in the address bar and the URL of the content you are displaying to become unlinked? Are you smoking crack?