Tony Schreiner's WebLog : Internet Explorer

Download the IE7 Beta 2 Preview!

tonyschr — Tue, 31 Jan 2006 21:31:00 GMT

The IE blog has announced the availability of the first public beta for IE7: IE7 Beta 2 Preview.

This preview isn't intended to be widely used by the general public, but if you're reading this blog you're probably technical enough to try it. Over the next few weeks I'll post about some of the features I've been working on. Posts on the IE blog will be intended for a wider audience, whereas any I personally make here will be more informal and technical.

Last but not least, for general questions and feedback you will get the best response by using the newsgroup for IE7 and file bugs using the instructions provided in this IE blog post. (Unfortunately I'm unable to answer everybody's questions when they email me directly.)

Toolbar Compatibility Debugging Walkthrough

tonyschr — Tue, 10 Jan 2006 03:14:00 GMT

In the past I’ve found debugging walkthroughs useful for picking up new techniques. In that spirit here’s a quick rundown of a bug I was investigating today that may have some useful tidbits.

This was a crash in IE that involved a toolbar that I didn’t have the source code for. The issue was that if you clicked in the toolbar’s edit box and later closed the browser, IE would crash.

It was crashing while trying to call Release() on a pointer to the toolbar and initially looked like a reference counting issue, either in IE or the toolbar code itself. This type of bug can be tricky to track down in your own code, so given that this bug straddles legacy IE code and external toolbar code I closed my door and prepared for the worst. :-)

I started out by turning on full pageheap using gflags.exe, which is part of the standard debugging package, and repro’d the bug. This was to ensure that the crash wasn't a side-effect of heap corruption, and that I was debugging the right thing.

Next I put a breakpoint on the toolbar’s Release(). Since I don't have the source I had to track this down manually:

0:005> kP 1

ChildEBP RetAddr

01eaeab0 0074f7fb xxxxx!xxxx::_xxxxxxx(

struct IUnknown * ptb = 0x020f3940)

0:005> dds 0x020f3940

020f3940 10031b44 toolbar!DllMain+0x27d24

020f3944 10031b2c toolbar!DllMain+0x27d0c

020f3948 10031b18 toolbar!DllMain+0x27cf8

020f394c 10031af8 toolbar!DllMain+0x27cd8

020f3950 10031ad8 toolbar!DllMain+0x27cb8

020f3954 10031f50 toolbar!DllMain+0x28130

020f3958 00000003

[...]

0:005> dds 10031b44

10031b44 1000cc90 toolbar!DllMain+0x2e70

10031b48 1000cdd0 toolbar!DllMain+0x2fb0

10031b4c 1000cdf0 toolbar!DllMain+0x2fd0

10031b50 1000ce20 toolbar!DllMain+0x3000

[...]

I could have also unassembled the code and traced the logic, but I've found that it's often faster to just use "dds" to dump interesting-looking addresses. "dds" is especially useful for dumping the stack when symbols are incomplete (or the stack is corrupt) and for tracking down objects on on optimized builds where the debugger gets confused. (When you have symbols and dump an address it will be immediately obvious from the vtable whether you're looking at the right object.)

The IUnknown interface has three methods: QueryInterface(), AddRef(), and Release(), in that order. Given the dump of the vtable I assumed toolbar!DllMain+0x2fd0 was the Release() function and confirmed by unassembling it. It looked right, so I put a breakpoint on just before the return:

0:005> u toolbar!DllMain+0x2fd0

[...]

1000ce15 8b06 mov eax,[esi]

1000ce17 5e pop esi

1000ce18 c20400 ret 0x4

1000ce1b cc int 3

0:005> bp 1000ce18

and then re-ran the repro. For brevity I’ve left out many of the calls and removed redundant output. ‘eax’ holds the return value of Release() so you can see that it’s winding down to the point of doing the final Release() (at which point the object will delete itself).

0:005> g

Breakpoint 1 hit

eax=00000004 ebx=020f39ec ecx=020f395c edx=00000850 esi=020f3d84 edi=00000000

eip=1000ce18 esp=01eaf4cc ebp=00000000 iopl=0 nv up ei pl nz na pe cy

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000203

toolbar!DllMain+0x2ff8:

1000ce18 c20400 ret 0x4

0:005> g

Breakpoint 1 hit

eax=00000003 ebx=014ab010 ecx=020f395c edx=10031b18 esi=0224000a edi=00000008

0:005> g

Breakpoint 1 hit

eax=00000002 ebx=014ab010 ecx=020f395c edx=10031b44 esi=0224000a edi=00000008

0:005> g

wn IEFRAME CDocObjectView::DestroyViewWindow(): Destroying Host Window

Breakpoint 1 hit

eax=00000001 ebx=00000000 ecx=020f395c edx=00803e30 esi=020f3d04 edi=020f9328

0:005> g

Unable to remove breakpoint 1 at 1000ce18, Win32 error 487

"Attempt to access invalid address."

The breakpoint was set with BP. If you want breakpoints

to track module load/unload state you must use BU.

(564.db0): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

Unable to remove breakpoint 1 at 1000ce18, Win32 error 487

"Attempt to access invalid address."

The breakpoint was set with BP. If you want breakpoints

to track module load/unload state you must use BU.

Ah ha! This wasn’t what I was looking for, but you can see that before we do the final release -- or crash -- the debugger complains that a breakpoint is set in a module that has been unloaded. The crash happens shortly after this and is simply caused by trying call into the module after it’s been unloaded.

So why was it unloaded? Let’s put a breakpoint on the module unload and re-run the repro and find out:

0:005> sxe ud:toolbar

0:005> g

[...]

Breakpoint 1 hit
eax=00000001 ebx=00000000 ecx=020f395c edx=00803e30 esi=020f3d04 edi=020f9328
eip=1000ce18 esp=01eafa98 ebp=00000000 iopl=0         nv up ei pl nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000203
toolbar!DllMain+0x2ff8:
1000ce18 c20400           ret     0x4

0:005> k

*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll -

ChildEBP RetAddr

WARNING: Stack unwind information not available. Following frames may be wrong.

01eafcf4 7c80aa7f ntdll!KiFastSystemCallRet

*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ole32.dll -

01eafd08 77513442 kernel32!FreeLibrary+0x19

01eafd14 77513456 ole32!CoFreeUnusedLibraries+0xa9

01eafeb8 77513578 ole32!CoFreeUnusedLibraries+0xbd

01eafec8 775133a2 ole32!CoFreeUnusedLibrariesEx+0x2e

01eafeec 007ab40f ole32!CoFreeUnusedLibraries+0x9

01eaffb4 7c80b50b xxxxx!xxx::_xxxxxxxx+0x3af

It’s being unloaded when IE’s code calls CoFreeUnusedLibrariesEx() when the window is closed. This is code I'm not super-familiar with, but I presume we’re doing it to trigger the unloading of DLLs for BHOs, toolbars ActiveX controls, and so on, to free up memory. However, we still have properly reference counted pointers to the toolbar so it shouldn’t be unloading quite yet.

According to MSDN CoFreeUnusedLibrariesEx() calls DllCanUnloadNow(), which is supposed to return S_FALSE if the DLL is not yet ready to be unloaded. Let’s set a breakpoint, step through the function, and see what it’s returning in this scenario:

0:005> bp toolbar!DllCanUnloadNow

0:005> g

[...]

Breakpoint 0 hit

eax=00000000 ebx=00000001 ecx=77606074 edx=00000000 esi=014a6dd0 edi=77606068

eip=10008fd0 esp=01eafd20 ebp=01eafd30 iopl=0 nv up ei pl zr na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

toolbar!DllCanUnloadNow:

10008fd0 8b0d3c1c0410 mov ecx,[toolbar!DllMain+0x37e1c (10041c3c)] ds:0023:10041c3c=00000000

0:005> p

[...]

0:005> p

eax=00000000 ebx=00000001 ecx=00000000 edx=00000000 esi=014a6dd0 edi=77606068

eip=10008fdd esp=01eafd20 ebp=01eafd30 iopl=0 nv up ei pl zr na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

toolbar!DllCanUnloadNow+0xd:

10008fdd c3 ret

As you can see by looking at ‘eax’ this function is returning 0, which is S_OK. I believe this is the cause of the bug.

After reviewing recent changes that I had made in IE7 I found that one of them caused us to hold onto the toolbar object longer than we used to. In previous versions of IE we happened to always do the final Release() before calling CoFreeUnusedLibrariesEx(), masking the bug in the toolbar. The fix in this case, for better or worse, was to update the code so that we release earlier like we used to.

Thoughts? Are these types of walkthroughs interesting or useful? If so I’ll do more of them.

Internet Explorer in XP SP2 RC2

tonyschr — Wed, 16 Jun 2004 05:15:00 GMT

First, I'll join everybody else in announcing that XP SP2 RC2 is available for download! If you've put off installing it, now's the time to give it a shot and test all of your favorite applications and web sites. Most of the work recently has been on bug fixes, and compatibility fixes in particular. If there's anything that doesn't work by now it will probably not work in RTM unless you notify both Microsoft and the vendor (or web site administrator).

Below are a few of the changes in IE for RC2 (since RC1). This list is very incomplete - I'll try to post a follow-up entry or two to cover some of the changes I missed or that are in areas I'm less familiar with.

Information Bar Updates

When the Information Bar blocks an ActiveX control, the name and publisher are now included in the warning text. If the control has a visible area in the page, similar text will also be shown in that area, and users can right-click in that space to show the context menu to install the control. This change was made to increase discoverability and help the user make a better decision about whether to proceed to the Authenticode dialog.

We also implemented an application compatibility fix to handle the common scenario where a web site detects that the ActiveX installation failed and redirects to an error page. In this case, users will be shown a version of the Information Bar on the redirected page, and clicking the "Install ActiveX Control" menu will navigate back to the page where the control was suppressed and allow the Authenticode dialog to be shown. The end user experience is not smooth, but this unblocks a large number of web pages that were redirecting on failure.

As a last resort, holding down the CTRL key is a universal workaround for pages that have tricky logic that eluded our attempts to unblock something after it's been suppressed by the Information Bar. This works for ActiveX controls, file downloads, and pop-up windows.

Other minor changes (I don't recall if these were in the last public release or not):

Users will now receive a dialog the first time the information bar is shown so that it is more discoverable, particularly for people who rely on screen readers and may not otherwise be aware that content will be blocked by modeless UI.
There's now a close button on the bar just in case it gets in the way.
There are now two independent security zone settings for whether to suppress the ActiveX install prompt and whether to suppress non user-initiated file downloads.
When the Information Bar is shown, the cursor briefly changes to an arrow plus the icon that is shown in the bar.
We added (and tweaked, and tweaked) sounds for the Information Bar and pop-up blocker.

Manage Add-ons Updates

The Manage Add-ons dialog now shows more useful columns by default, including the name of the add-on, the publisher, and the file that implements the add-on. You can also choose to display columns for additional information such as the CLSID and the folder that the file is located in.

Pop-up Blocker Updates

Jeff Davis can detail the changes here. The primary one that I worked on was to enable ActiveX controls such as Flash launch new windows for user-initiated actions. Previously these were all blocked because IE did not detect mouse clicks or key presses within windowed controls.

New Pet Peeves Fixed

The disappearing status bar bug should be gone for good. We also fixed most of the scenarios where the URL you were typing in the address bar would get stomped or disrupted if a navigation happened while you were typing.

(Edit: Made it clearer that these are just changes made between RC1 and RC2. See the official documentation and other blog entries for a more complete list of changes made in SP2.)

High DPI in IE: Tip & Mystery Solved

tonyschr — Wed, 05 May 2004 07:53:00 GMT

On his blog (and in a comment on my 120 DPI post) Omar points out a super-secret registry tweak make IE do extra scaling in high DPI mode. IE already adjusts for well-written web pages, but if you're using high DPI and still feeling cramped on some sites, you might want to give it a shot.

I don't like it because it has a tendency to distort graphics, and it makes some fonts too big for my displays, but it's good to know about. I mentioned an alternative in my own comments a few weeks ago, but I suspect not many people saw it. For the occasional web sites that hard code small font sizes, here's a very simple “per-page zoom” workaround:

1) Create a local file (i.e. c:\web\zoom200.htm) that has the following script:

<script language="JavaScript">
external.menuArguments.document.body.style.zoom="200%";
</script>

2) Add it to the right-click menu in IE, by adding a registry key:

Key: "HKCU\SOFTWARE\Microsoft\Internet Explorer\MenuExt\Zoom 200%"
Value (Default): "c:\web\zoom200.htm"

Adjust the zoom percentage and file locations as needed and then restart IE. Now when you right click on a page the menu should have a new option to “Zoom 200%”. Clicking on that will zoom the entire page, including graphics and (most) controls. A 125% or 150% zoom is probably more reasonable for normal reading; I've created several zoom levels in this way. Unfortunately zoom has a few issues with font kerning/spacing, selection, controls, and an overall lack of polish, which is why you don’t see this exposed directly in the browser yet.

Internet Explorer Wiki

tonyschr — Sun, 18 Apr 2004 02:31:00 GMT

Channel9 now has a section dedicated to IE. Jump on in!

http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerFeedback

IE in XP SP2 (Part 4): Opting-in to IE Security Features

tonyschr — Wed, 31 Mar 2004 02:45:00 GMT

Many of the security features I've mentioned in previous entries are opt-in, so if you have a custom application that hosts the web browser control you won't automatically be impacted by them. But what about the many great applications that host the web browser control, such as MyIE2, Avant Browser, or iRider? In those cases the developer may want to turn on some or all of the new security features during install. Advanced users can do this too.

The easiest way to enable the IE security features for an application is to use the "FeatureControl" registry keys described on the XP SP2 RC1 Preview site, with a more complete list on MSDN. As an example, lets say you use MyIE2 and want to opt-in to the Information Bar, block non-user-initiated file downloads, block ActiveX install prompts, and lock down the Local Machine Zone. Use regedit to set the following values:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_SECURITYBAND] "MyIE.exe"=dword:00000001 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_RESTRICT_ACTIVEXINSTALL] "MyIE.exe"=dword:00000001 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_RESTRICT_FILEDOWNLOAD] "MyIE.exe"=dword:00000001 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_LOCALMACHINE_LOCKDOWN] "MyIE.exe"=dword:00000001

You can also add these in HKLM if you want them to affect all users. After adding these registry keys restart MyIE and navigate to a web site that tries to do one of these things... Information Bar!

Similarly, let's say that you work in a company that has a mission critical application built on IE that is broken because of one of these security features. Using the same technique you can selectively disable them for the iexplore.exe or explorer.exe processes until you are able to update the application.

Curiously, in writing this blog I discovered that Avant Browser is also named "iexplore.exe", so by default it will inherit all of the IE security features. So is that a feature or a bug?

Reminder: This is preliminary information and subject to change. This isn't official documentation, just stuff I think people will find interesting.

IE in XP SP2 (Part 3): Web Site Compatibility

tonyschr — Tue, 30 Mar 2004 07:24:00 GMT

Microsoft cares a lot about application compatibility. So does the IE team, but we have an additional burden: web site compatibility. I think I can safely say that there are more web sites (intranet and internet) than there are applications, and many of them are built in a way that is closely tied to specific IE functionality.

While we really try to avoid making changes that affect compatibility, security is one thing that takes precedence. This means that with the large number of security fixes and features in XP SP2 some web sites will break. Between now and RTM things should get a little bit better, but we can't provide workarounds for every web site, and even when we can provide workaround the experience may not be as smooth as it was before.

In other words, if you're a web site developer or you have an application that hosts the web browser control you should strongly consider installing XP SP2 RC1 to test it out. Similarly, if your users are reporting bugs, don't discount them because they're running a pre-release version of XP SP2.

Below are some common types of problems that you should try to avoid.

Authenticode

As noted in earlier posts, IE no longer immediately launches the Authenticode dialog when it encounters an <OBJECT> tag. Instead, there is a more subtle non-modal piece of UI known as the Information Bar that lets the user know a control is present. This causes problems when web sites specifically rely on there being a modal dialog that blocks the web page. Example issues:

Scripting an ActiveX control immediately after instantiating it, assuming the user will install it. (The user will get a script error, as they would if they clicked "No" pre-SP2.)
Detecting that the ActiveX control wasn't successfully installed and navigating to an error page. In XP SP2 you'll navigate away from the page that gives the user the ability to install the control via. the modeless UI.
Having the first instance of the ActiveX control after a form submit. In order for the user to install the control they now have to refresh the page, potentially doing a second submit. (Bonus points if the second form submit causes a duplicate purchase of an expensive product.)

Fortunately for web developers, ActiveX controls only need to be installed once. Make that experience work and you don't have much else to worry about here.

Pop-up Windows (non-user-initiated)

The best thing is to simply avoid showing pop-up windows. This shouldn't be news to anybody as there are literally dozens of pop-up blockers out there (in addition to being built into most major 3rd party browsers), but we've encountered plenty of sites that don't function well when pop-ups are blocked. Example issues:

Redirecting when a pop-up is blocked.
Instantiating an ActiveX control from a pop-up, especially if you close the window if it fails.
Having one pop-up launch another pop-up in another domain. (Bonus points if the second pop-up attempts to install an ActiveX control or download a file, and the chain of pop-ups does a cascading close when the control is blocked.)
One-time pop-ups that the user needs to see, but can't be replayed even after refreshing the page.

Downloads

As noted in earlier posts, non-user-initiated downloads are blocked by default. This is something I haven't seen other browsers do and it may require a few download sites to adapt. Fortunately there's plenty of time before most users will have XP SP2. Example issues:

Instead of launching the download directly, using the link to navigate to a page that kicks off the download using a timer.
Creating a timeout, after which the server refuses to cough up the file. I've seen pages where I can start the download if I click the Information Bar within five seconds, but not after that.
Launching a download from a pop-up window.

HTML Dialogs

The Information Bar is a component of the web browser control and will not show up if you host mshtml directly, therefore some of the above items may be blocked outright with easy no end-user workaround. showModalDialog() and showModelessDialog() are where most web sites will encounter this.

MIME Type Handling

I'm not as familiar with this feature, I've run into problems caused by the security restrictions on a few web sites. The primary issue is servers that are misconfigured to send the type "text/plain" for binary file types such as streaming video or music.

Local Machine Zone Scripting

As mentioned in part 2, this is one of the most impactful changes. Again, I'm not intimately familiar with this feature, but if you're doing any kind of scripting from local HTML files that get launched in Internet Explorer (or shell Explorer) you should look into the documentation for XP SP2 RC1 for how to use "mark of the web" and other mitigations.

Of special note here are Explorer Bars and Desk Bands. We've seen several instances where these require the user to use the Information Bar to unblock script/content. In some cases the Information Bar is barely clickable due to the size.

IE and Shell teams are hiring

tonyschr — Tue, 30 Mar 2004 01:12:00 GMT

Want to work in one of the best teams at Microsoft? Both the Shell (as in Explorer, not cmd.exe (or Monad)*) and Internet Explorer teams are hiring SDEs and SDETs. Heck, maybe you could be the one who helps implement tabbed browsing, rendering transparent PNG files, or CSS 2.0.** :-)

Microsoft is hosting an Interview Roadshow and will be holding interviews for these positions in the New York area on April 26th-28th.

* Who knows, they might be hiring too.
** Standard disclaimer applies. I really don't know exactly what you would be working on, but these got your attention didn't they?

Security prompt on downloaded files in XP SP2

tonyschr — Mon, 22 Mar 2004 03:50:00 GMT

In a response to my first blog entry on IE in XP SP2, Tom Gilder notices another new security prompt on downloaded files for XP SP2:

Also, whilst on the subject of XP SP2, if you download a signed EXE to the desktop and run it, it gives you a security dialog. But if you do the same with an unsigned EXE, it runs it without a prompt - is this a bug?
...
Er, actually, ignore that - now seems to be working again. But if you save an EXE locally and then click open on the completed download dialog, it never shows any of the security warnings, now that surely is a bug? :)

This functionality is similar to the prompt that is shown when you immediately run an executable from the download prompt in IE. If you are using NTFS, downloaded files will now be marked with information about the zone the file originated from. The shell team did some work to extend ShellExecute so that it will prompt when you later run a file that was downloaded and saved from the internet. As with the secondary download prompt, this is defense in depth and should be used to verify the publisher of the executable, but it is not a security prompt that you can rely on to always protect you from running dangerous files. For example, you could download a .cmd file from a web site that formats your hard drive or erases all of your personal files, and you may not get the secondary prompt.

So regarding the first potential issue, my guess is that in one case the file was saved to an NTFS partition and in the other case it was either saved onto a FAT32 partition or was copied in a way that caused it to lose the zone information. If this is not the case, please drop me an email or file a bug report through the standard channels. The second issue certainly was a bug. It has been fixed but did not make the RC1 build.

I'm interested in hearing peoples opinions on the value of this feature and how we could make it more useful (and secure) in the future.

IE in XP SP2 (Part 2): Information Bar - Stopping the modal dialog madness

tonyschr — Sun, 21 Mar 2004 20:43:00 GMT

The Information Bar is a new piece of UI that shows up when potentially dangerous actions on a page have been blocked. It appears between the toolbar and the content window, and looks a bit like the bar that appears in Outlook 2003 and MSN 8/9 to block images from email messages.

The following are some of the actions blocked by the Information Bar.

ActiveX Install Prompts

In Part 1 I discussed some of the changes made to Authenticode to enhance usability and allow you to block publishers you don't trust. What I didn't mention is that in most cases you won't even see the dialog anymore, because the Information Bar will appear first!

If you're like me, you're wary about installation dialogs for a couple of reasons. First, there's always the possibility you might miss-click and accidentally install something that could be spyware/malware. Next, even though you know not to install unsolicited software, do your friends and family that use your computer understand this? Also, what happens when they stray from mainstream sites and reach a malicious page that bombards them with multiple ActiveX install prompts in an attempt to trap them into installing the software? We've changed some of the plumbing for Authenticode to help prevent multiple prompts, and you can now hold down Esc to both cancel the dialog and stop loading the page, but the the Information Bar goes further by simply not showing the dialog unless you request it.

When you click the bar you're presented with a menu from which you can install the ActiveX control. This temporarily turns off the block and refreshes the page, at which point you will get the Authenticode dialog.

One case that will bypass the Information Bar in this scenario is when a page is using a control that is newer than the one you already have installed. Since you have already trusted the software we permit the Authenticode dialog to show immediately in order to promote upgrades, particularly because upgrades often contain security fixes. A control will only be considered an upgrade if it uses the same CLSID as a control that is installed and it has been signed with the same certificate as the installed control. This helps prevent malicious sites from bypassing the Information Bar by making their control look like an upgrade.

Non-user-initiated Download Prompts

Like ActiveX, if a page tries to push a file download on you, again raising the possibility that you will run (or save and later run) unsolicited software, it will be blocked by the Information Bar. The logic for whether to block downloads is similar to the logic for blocking pop-up windows, so if you directly click a link you'll get the file download dialog unimpeded. Some download sites will have to adapt to this new behavior.

On a side note, we have also turned on the option to verify the signature on certain types of files such as EXEs. This means that when you run software from the download dialog you may get a secondary prompt that shows the same information as the Authenticode dialog (i.e. name and publisher from the digital signature). This prompt helps certify that the file is, indeed, from who it says it is from. File attachments in Outlook Express and a few other scenarios will get the same treatment.

Blocked Pop-up Windows

As with blocked downloads, Jeff Davis is much more qualified to talk about this, but I'll mention a couple of things.

First, the pop-up blocker is now on by default! When a pop-up window is blocked the Information Band will appear, and from there you replay the pop-ups, always allow pop-ups for the site, and configure the pop-up blocker. The first thing I do from here is turn off the Information Bar for pop-ups. They're so common, and so infrequently wanted, that I prefer the lighter weight option of just showing the status bar icon.

ActiveX Control Blocked Errors

If you've ever tried to browse the web with elevated security settings (or on Windows 2003 server) you know that it can be a frustrating experience because of the frequent message boxes stating that "An ActiveX control has been blocked...". Now this'll be pulled into the Information Bar, giving you a less intrusive user experience. Unlike most of the other items in Information Bar, this is not actionable. There is currently no way to temporarily lower your security settings to get the ActiveX install prompt.

This also means that if you're really paranoid, install the interesting/useful ActiveX controls like Flash, and then to go "Tools/Internet Options...", "Security" tab, "Custom Level" (for Internet), and set "Download signed ActiveX controls" to Disable. Now you have no chance of accidentally installing ActiveX controls and the browser is still usable.

Local Machine Zone Lockdown

Local Machine Zone Lockdown is one of the most impactful security mitigations in IE for XP SP2. It deserves an entire blog entry (or several), but, briefly, LMZ Lockdown affects the explorer.exe and iexplore.exe processes, and places severe restrictions on on things such as executing script and running ActiveX controls in the local machine zone (i.e. a local .html file). When the lockdown is in effect you will see the Information Bar with a menu item that lets you temporarily disable the lockdown by reverting to the old Local Machine Zone settings for that instance of the browser.

----

That's all for now. Note that there may be more (or fewer) actions blocked by the Information Bar in the future, and I haven't necessarily covered them all.

In designing and building these IE security features we've spent a lot of time trying to find the right balance between allowing sites to do what they need (preserving site compatibility), and giving the users more control. This is a very fine line; anything we do to stop the "bad guys" also has the potential to break the "good guys" if they are doing something similar, but for legitimate reasons. Between now and RTM you can expect site compatibility to get a bit better as we implement (safe) workarounds for common scenarios, but if you're a web developer you should not rely on it.

Do you think this will make browsing the web more secure? What about reducing the proliferation of spyware/malware?

IE in XP SP2 (Part 1): Authenticode - No, and never again!

tonyschr — Sun, 21 Mar 2004 09:29:00 GMT

As you probably know by now, XP SP2 RC1 is publicly available at http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.mspx. Over the next week or so I'll give an overview of a few of the security features the browser UI team has been working on.

The first I'll mention is the revamped Authenticode dialog:

Besides the overall cleanup (the old dialog was difficult for many people to understand), the most noticeable enhancement is the addition of the "Never install software from..." radio button which lets you (finally!) blacklist publishers you don't like. After you've blacklisted a publisher you'll never again be prompted to install an ActiveX control signed with that publisher's certificate. Instead, a harmless icon will show in the status bar to indicate that a control has been blocked.

If you click the status bar icon you'll be brought to the Manage Add-ons dialog, another new security feature in IE which gives you control over all types of browser add-ons including ActiveX controls, Browser Helper Objects, and Toolbars. From here you can de-blacklist the publisher of a control that has been recently blocked, but the main purpose is to let you enable and disable add-ons that may be spyware/malware or causing crashes or other undesirable behavior. You can also get to this dialog from the "Tools/Manage Add-ons..." menu.

There are quite a few security tweaks to Authenticode in addition to what I've mentioned above. One that you may eventually get blocked by is the change to block the installation of invalidly signed ActiveX controls. A control usually gets into this state as the result of file corruption or tampering, and as such they are no more trustworthy than unsigned controls which have always been blocked in the Internet and Intranet zones. Although invalidly signed controls are uncommon, they're not as rare as they should be because the old Authenticode dialog just gave a text warning and still allowed you to install the control. For this reason we've added a setting that allows you to bypass the new block -- primarily for corporate intranet scenarios where mission-critical apps may have been deployed with invalidly signed controls (we had a few of these ourselves) -- but I'm not going to tell you where it is because you shouldn't turn it on. :-)