Understanding Enhanced Protected Mode

Last week, Andy Zeigler announced the introduction of Enhanced Protected Mode (EPM) over on the IEBlog. In today’s post, I’d like to provide further technical details about EPM to help security researchers, IT professionals, enthusiasts, and developers better understand how this feature works and what impact it may have on scenarios they care about.

Internet Explorer’s Process Model and Bitness

For the past several releases, Internet Explorer has sported a multi-process architecture, where the “Frame” or “Manager” process runs at Medium Integrity and the “Tab” or “Content” processes run at either Low Integrity (Protected Mode) or Medium Integrity (for Zones where Protected Mode is disabled, like Intranet sites). All HTML content and ActiveX controls run in the Content Process. Even toolbars, which visually appear as if they’re in the Manager Process, really run down in a Content Process.

For IE10, we’ve changed IE such that Manager Processes always run as 64bit processes when running on a 64bit processor running a 64bit version of Windows. This improves security among other things. We do not expect that this change will meaningfully impact compatibility, because the Manager Process is designed not to run 3rd party content, and thus there’s little opportunity for anyone to take a dependency upon the Frame Process’ bitness. In support of this change, the various registry points that point to Internet Explorer have been updated to point to C:\Program Files\Internet Explorer\iexplore.exe. If you manually invoke C:\Program Files (x86) \Internet Explorer\iexplore.exe, that 32bit process will simply launch the 64bit version of iexplore.exe (with the appropriate command line parameters) before exiting.

For the Content Processes, the story is a little more complicated. In the Metro-style experience of Internet Explorer, all Content Processes will run at 64bit (on Win64), which means that they benefit from the improved security provided in 64bit. The compatibility impact is minimal because Metro-style IE does not load any browser add-ons (Toolbars, BHOs, and non-browser-platform COM objects like MIME Handlers, URLMon Protocol Handlers, MIME Filters, ActiveX controls, etc). Back in IE9, running in 64bit mode meant that JavaScript was not JIT-compiled, but for IE10, the JIT compiler was enhanced to work for both 32bit and 64bit tabs, providing great performance in both. Additionally, many major browser add-ons like Flash, Silverlight, and Java are now available in 64bit versions.

In Internet Explorer on the Desktop, by default, Content Processes remain at 32bit by default for compatibility with 32bit ActiveX controls, Toolbars, BHOs, etc. Even when you directly launch the 64bit iexplore.exe executable, you will still have a 64bit Manager Process that hosts only 32bit Content Processes. If you want to enable 64bit Content Processes for the Desktop, you must tick the Enable Enhanced Protected Mode option in the Security section of Internet Explorer’s Tools > Internet Options > Advanced tab. When this option is enabled, all Content Processes that are running in Protected Mode (e.g. Internet Zone and Restricted Zone, by default) will begin to use 64bit Content Processes.

Note: In the Windows 8 Release Preview, if you enable Protected Mode for the Local Intranet and Trusted Zones, even if you enable EPM, the Intranet and Trusted Zones will run in 32bit LowIL rather than a 64bit AppContainer.

In the upcoming Internet Explorer 10 on Windows 7 and Windows Server 2008R2, the only thing that enabling Enhanced Protected Mode does is turn on 64bit Content Processes. But, when running on Windows 8, the EPM option provides even more security by also causing the sandboxed Content Process to run in a new process isolation feature called “AppContainer.”

Intro to AppContainer

Windows Vista introduced the concept of Integrity Levels. The default integrity levels used by applications (Low / Medium / High) constrained what parts of the system could be written (e.g. registry keys, files, etc) and how applications could communicate or share data. Notably, in most circumstances, Integrity Levels were “Allow Read-Up; Block Write-Up” meaning that even a Low Integrity process like an IE tab would have full read-access to the rest of the disk and registry even those locations which were marked as Medium or High integrity.

Windows 8 introduces a new process isolation mechanism, called AppContainer, that offers more fine-grained security permissions and which blocks Write and Read Access to most of the system. There’s not a lot of documentation specifically about AppContainer because all Metro-style applications run in AppContainers, so most of the documentation is written from that point of view. For instance, here’s a page that describes the capabilities that a Metro-style application can declare that it needs: https://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx. Under the covers, it’s the AppContainer that helps ensure that an App does not have access to capabilities that it hasn’t declared and been granted by the user.

IE Tabs and AppContainer

Tabs running in Enhanced Protected Mode on Windows 8 run inside an AppContainer. On Windows 7 and Windows Server 2008 R2, AppContainer does not exist, so EPM only enables 64bit tabs on a 64bit OS. (That also means that enabling EPM on a 32bit Windows 7 system doesn’t do anything, because a 32bit Windows 7 system supports neither 64bit nor AppContainer).

On Windows 8, Metro-style IE’s tabs in the Internet and Restricted Zone run in Enhanced Protected mode, while tabs in other zones run in 64bit only. You cannot disable EPM for Metro-style IE except by turning off Protected Mode entirely.

By default, Desktop IE’s tabs run in the Low Integrity Protected Mode at 32bit. Only if you enable Enhanced Protected Mode using the Internet Options control panel will Desktop IE’s tabs run in AppContainer (and 64bit, if available).

IE’s AppContainer

Internet Explorer’s EPM-mode tabs run in an AppContainer named windows_ie_ac_001. In the Windows 8 Consumer Preview release, this container declares the capabilities internetClient, location, and sharedUserCertificates.

Notably, the container does not specify internetClientServer, privateNetworkClientServer, enterpriseAuthentication, or any of the *Library capabilities, which means that Internet content runs in a tightly-limited process.

AppContainer - Network Restrictions

AppContainer introduces three key restrictions related to Network Connectivity that impact EPM. I’ll describe each.

Acting as a Network Server is Blocked

Because EPM’s AppContainer does not have the internetClientServer capability, there’s no way for an EPM process to accept inbound connection attempts from the network. Typically, such connections weren’t possible in the Web Platform anyway (e.g. there's no JavaScript method to listen() on a new TCP/IP socket), but some browser add-ons had the capability of allowing inbound connections (even though this became pretty uncommon with the broadscale deployment of firewalls). When EPM is enabled, such add-ons will not be able to accept remote connections.

Loopback-blocked

Apps running in AppContainer are not allowed to make connections to locally-running processes outside of their own package. This means, for instance, if you run a local developer instance of Apache or IIS on your own computer, you will find that Metro-style applications are unable to connect to that server. This also means that by-default, you cannot use Fiddler to debug Metro-style applications, because Fiddler acts as a proxy server on your local computer. To unblock Fiddler users, I’ve published a simple utility that allows users to remove the Loopback Restriction on the AppContainers of their choice; you can also use this utility to allow your App or MetroIE to contact a locally-running web server for development purposes.

Please note that Windows Store-delivered applications will not be permitted to set a loopback exemption for themselves, so this is only useful for test/development purposes.

Now, one key thing to understand about Loopback connections in Metro-style Internet Explorer is that the Hostname you use in your URL matters a lot! If you try to navigate to https://127.0.0.1/, your page will be treated as an Internet Zone and thus will run in an EPM tab, and the loading of the page will be blocked by the AppContainer’s Loopback-block-- you’ll see a Page Could Not Be Displayed error page.

However, if you instead try the URL https://localhost/ (assuming your Intranet Zone is enabled), you will find that Internet Explorer considers your content to be Local Intranet Zone, and thus it is loaded in a Medium Integrity (non-Protected Mode) tab. The page will successfully load since it is not running in EPM, and thus isn't blocked by the network restrictions provided by AppContainer.

Private Network resources

Because EPM does not declare the privateNetworkClientServer capability, your Intranet resources are protected from many types of cross-zone attacks (usually called “Cross-Site-Request-Forgery (CSRF)” and “Intranet Port Scanning.”) Internet pages are not able to frame Intranet pages, load images or resources from them, send them CORS XHR requests, etc.

However, it’s important to understand how this restriction functions, because it can have some very surprising outcomes depending on how your Internet Explorer Security Zones are configured.

For instance, many of us have a home router with a configuration UI accessible at https://192.168.1.1 or a similar address that is not globally-routable. On one hand, it’s desirable to prevent Internet content from sending requests to such addresses to help block CSRF-attacks that might maliciously reconfigure poorly-secured routers. However, for historical and other reasons, Security Zones consider this dotted hostname to be an Internet-Zone address by default, which means that if you attempt to navigate to the Router configuration page in Metro-style IE, you may encounter a Page Cannot Be Displayed error page. If you enable EPM in the Desktop mode of the browser, you can use the F12 Developer tools to see why the request was blocked:

Note: The next update to IE10 will use a more specific error message here; this string was designed for developers of Metro-style applications, not for folks debugging in EPM in IE.

To resolve this issue, you can either use a non-dotted hostname for your router (e.g. my DNS points https://router to 192.168.1.1) or you can manually add the router’s address to your Trusted Sites zone using the Tools > Internet Options > Security | Trusted | Sites... list. When navigating to Trusted Sites, the navigation occurs outside of Protected Mode, so AppContainer restrictions are not a problem.

There’s a non-obvious subtlety here which bears mentioning. When I personally tried to reproduce this restriction at home, I had no problem in navigating straight to the router’s IP Address in both Metro and Desktop IE with EPM enabled:

What’s up with that?

The explanation is that the AppContainer network restrictions are sensitive to your network configuration. When I had originally connected to my router, I had selected the following configuration:

As a result, the Windows Firewall considered my router part of a public network:

…and thus AppContainers are freely able to contact the 192.168.1.1 address as I had indicated that I was on a “Public Network” and thus the privateNetworkClientServer capability is not required to contact local / non-routable addresses like 192.168.1.1.

I can enable the network restriction by reconfiguring my network settings. First, I use the sidebar's context menu to tell Windows to “forget” my Linksys connection. Then, I re-established it as a “home” network:

This causes the Windows Firewall consider this a “Private network”:

 

...and subsequently block connections to "local" addresses from AppContainers that lack the privateNetworkClientServer capability.

AppContainer – Isolation of Cookies and Cache

AppContainers do not have read or write access to files outside of their container, which means that the cache, cookies, and other web-platform state information is not shared between different AppContainers and the rest of the system. This means, for instance, that if you have a Windows Web App (a Metro-style app written in HTML+JavaScript), that application will not share cookies or cache files with Internet Explorer. Similarly, Metro-style apps will not share cookies and cache with one another.

This “partitioning” can be great for security and privacy, because it means that your use of one application isn’t visible to another. For instance, if you log into your Banking App, the banking app’s cache, cookies, and credentials aren’t available to be stolen from pages you browse in Metro-style Internet Explorer, even if a vulnerability was discovered that allowed an attacker to run arbitrary native code in the AppContainer.

However, partitioning can lead to unexpected behaviors. I describe some of these in a previous post called Beware Cookie Sharing in Cross-Zone Scenarios. In that post, I observed that even in IE7 to IE9, there exists a partition between sites that run in Medium Integrity vs. those that run in Protected Mode, such that cookies are not shared between those modes. That can lead to problems when a site in one zone frames another, since the sandbox in which all frames in a page run is determined by the top-level page’s Zone.

In Windows 8, the existing Medium IL / Low IL partition remains, and a new EPM AppContainer partition is added as well. It’s now possible for a user to have three independent copies of a cookie for a single site in IE (not even counting other non-IE Metro Apps). For instance, if www.example.com tries to set a cookie when it’s the subframe of an Intranet top-level page, that cookie will go in the MediumIL cookie jar. If the user then visits www.example.com in Metro-style IE, the cookie will be set in the EPM’s AppContainer cookie jar. Then, if the user visits www.example.com in Desktop IE, the cookie will be set in the LowIL cookie jar. These three cookies are independent, and changes or deletions of the cookie in one partition will not be seen in the other partitions. If the user "logs out" in one mode of the browser (which deletes the cookie) the other modes of the browser will remain "logged in" (since their cookies are isolated). Sites that need to securely log a user out across all browser modes should continue to expire the session on the server, rather than only relying on the client to stop sending a given cookie.

To be explicit, the following data stores are partitioned between Internet Zone content running in Metro-style IE (in EPM) and Desktop IE (in LowIL):

• Cookies
• Cache files
• Web Storage
• IndexedDB
• userData

In contrast, Local Intranet Zone and Trusted Zone pages run in Medium IL in both Metro-style IE and Desktop IE, and thus these Zones' data stores are shared between both browser modes.

Cookie Pushing

One exception exists to the partitioning behavior described above. When you use the View on the Desktop command in Metro-style IE, it will "push" the current tab’s session cookies into the new Desktop IE instance that opens. However, this only applies to session cookies and not persistent cookies.

You can see how this works by following these steps:

1. Clear all cookies using Delete Browser History
2. Visit www.facebook.com in Metro-style IE
3. Log in with the Keep me logged in box unchecked on the Facebook site
4. Facebook will send you a session cookie containing your credentials.
5. Invoke the View on the Desktop command

At this point, you should find that Desktop IE shows your default post-logon Facebook page (e.g. your Wall)-- you're still logged in.

Now close your browsers and repeat these steps, except at step #3, check the Keep me logged in option. At Step #4, Facebook will send you a persistent cookie with your credentials. When you switch to Desktop IE at step #5, you will find that you are not logged in to Facebook, because the persistent cookie set by Facebook isn’t pushed to Desktop IE.

You will further notice that if you enable Enhanced Protected Mode for Desktop IE, when switching from Metro IE to Desktop IE you will remain logged into Facebook in Desktop, because MetroIE in EPM shares cookies with DesktopIE in EPM since they are both running in the same AppContainer.

Add-ons in Enhanced Protected Mode

Metro-style Internet Explorer does not load add-ons, so there are no AppContainer considerations to worry about in MetroIE.

In contrast, most users expect add-ons to work in Desktop IE, but very few add-ons are AppContainer-compatible today. If you enable EPM in the desktop and have a BHO or Toolbar that isn’t EPM compatible, the add-on will be disabled:

If you visit a page that requires an ActiveX control which is not EPM-compatible, you’ll be provided the opportunity to load the page in a special “Low IL Compat” tab that runs the page at 32bits in LowIL instead of in an 64-bit AppContainer:

In order to be EPM-compatible, Toolbars and BHOs must be available in 32bit and 64bit flavors, to avoid toolbars or other UI appearing and disappearing as you navigate between zones that run at different bitnesses. To load in EPM on Windows 8, the add-on must also indicate that it is compatible with the AppContainer isolation feature by registering with a COM Component Category that indicates that the component was designed and tested to ensure it runs correctly in the no-read-up process.

The category is named CATID_AppContainerCompatible and its GUID is {59fb2056-d625-48d0-a944-1a85b5ab2640}. C++ programmers may use:

  DEFINE_GUID(CATID_AppContainerCompatible, 0x59fb2056,0xd625,0x48d0,0xa9,0x44,0x1a,0x85,0xb5,0xab,0x26,0x40);

Any non-trivial add-on is likely to find that it needs access to resources that are not available from within an AppContainer. The way to security provide such access is to build a broker object that runs at Medium IL. In Vista and later, brokers were needed to write protected resources, and in EPM, they are required to read protected resources.  The general pattern is:

1. Untrusted code (the add-on running in the Protected Mode tab) calls a method in the broker, passing zero or more arguments.
2. The broker evaluates the request's arguments and its own security policy.
3. The broker confirms with the user that the requested operation is acceptable (e.g. by showing a Save prompt or whatever).
4. The broker undertakes the operation if allowed, or blocks it if denied.

Writing a broker is a significant undertaking, and requires a thorough security audit to ensure that the broker doesn’t allow malicious code to escape from the tab running in Protected Mode.

12/20/2013 UPDATE: The IE team has published documentation on writing EPM-Compatible extensions on MSDN.

-Eric

PS: Please see this post for discussion of the impact of EPM on loading of local files that contain a Mark-of-the-Web.

Comments

• Anonymous
  March 23, 2012
  Why not add non-routable addresses, especially 192.168.0.0/23 for most used c-nets, to Trusted Sites by default?

• Anonymous
  March 23, 2012
  @KS: That presumes that you actually Trust all such sites, which isn't always a safe assumption to make and represents an interesting attack surface.

• Anonymous
  March 24, 2012
  thx... well written, easy on the brain with praticle tips for web app devs.

• Anonymous
  March 24, 2012
  The comment has been removed

• Anonymous
  March 25, 2012
  @Eric: Is CATID_AppContainerCompatible supposed to work with IE10.0.8250 from the Consumer Preview? I tried CATID catids[] = { CATID_AppContainerCompatible }; hr = pICatRegister->RegisterClassImplCategories(CLSID_BrowserHelperObject, COUNTOF(catids), catids); but the BHO is still not loaded. The "not compatible" warning disappeared though... Is there anything else one has to do to get loaded into an AppContainer?

• Anonymous
  March 26, 2012
  The comment has been removed

• Anonymous
  March 26, 2012
  @Robert: If you have a simple repro, feel free to email it to me using the "Email blog author" link at the top-right.

• Anonymous
  March 26, 2012
  Why aren't 64-bit content processes available to users without Enhanced Protected Mode? Didn't Microsoft think such an option would be desirable to IE users on Windows 8? I use IE COM addons and ActiveX controls which are 64-bit but which are never likely to be updated for EPM, so the compromise I have to make is to forego 64-bit content processes. I thought Windows 8 and IE was supposed to be "no compromises experience". Hope this changes for RC or RTM.

• Anonymous
  March 27, 2012
  The comment has been removed

• Anonymous
  March 28, 2012
  @ChrisTX: There's no direct management UI for EPM exceptions. When you delete your browser history (Ctrl+Shift+Del, History option) then the EPM-exception list is cleared.

• Anonymous
  March 28, 2012
  Where can I find more information about AppContainers? How can an AppContainer communicate with a broker if its objects are isolated in the session?

• Anonymous
  March 28, 2012
  @Ralf: There's one link in the section on Brokers at the end of this post. That link takes you to the whitepaper on how brokers are written, and how Protected Mode extensions communicate with those brokers. Thx!

• Anonymous
  March 28, 2012
  @Eric: Thanks for the reply (and the great article!). I already have a broker written for IE9, and now in IE10 EPM my objects (mutex, etc.) are created in the namespace "Sessions1AppContainerNamedObjectsS-1-15-2-14304..." and the broker does not see them. How can I create object in the Local session, i.e. Sessions1BaseNamedObjects...?

• Anonymous
  July 10, 2012
  FOLDERID_LocalAppDataLow returns different path than LocalLow, something like C:Users<user>AppDataLocalPackageswindows_ie_ac_001AC It looks that even LocalLow is now "protected" and funny is that you can got different folder for different tabs. Microsoft know how to make developer happy :-( Did somebody found list of "protected resources" in EPM ?

• Anonymous
  August 13, 2012
  The comment has been removed

• Anonymous
  August 23, 2012
  Q: If I use the notification bar to exempt a site from Enhanced Protected Mode, how can I later clear that exemption? A: Use the Delete Browser History item and check the "History" checkbox.

• Anonymous
  December 05, 2012
  The comment has been removed

• Anonymous
  December 05, 2012
  The comment has been removed

• Anonymous
  December 06, 2012
  @Eric. I solved it. For some reason, IE10 was NOT reading from files saved in 'Briefcases' (which I had moved from my previous laptop which ran on W7HP). I deleted all Briefcases and made them into 'normal' folders. And I can now access and upload. Thanks guys.

• Anonymous
  December 12, 2012
  Hello, How to find whether the add-on is running in EPM? For an ordinary PM there is IEIsProtectedModeProcess, but I cannot find anything like that for EPM. EricLaw: Great question. As far as I know, there's no public API that permits detecting that you're running in EPM, although it's probably possible to use one of the AppContainer APIs or Windows Security Token APIs to detect this case.

• Anonymous
  December 17, 2012
  Another question, see the codes below, isExited == True immediately after browserProcess.Start(), after checking process in Task Manager, the 32bit IE seems still run. I am not sure why the 32Bit IE process exited. Could you give me help on this answer ? Thank you so much. Running on OS: 64bit Win2012 Process browserProcess = new Process();
  browserProcess.StartInfo.FileName = @"C:Program Files (x86)Internet Exploreriexplore.exe";
  browserProcess.Start();
  bool isExited = browserProcess.HasExited; EricLaw: If you launch the 32bit IExplore.exe directly, it immediately launches a 64bit frame process and then shuts the 32bit instance of itself down. That 64bit frame process may itself then launch a 32bit content process, but that content process has no relationship to the original 32bit instance that kicked off the 64bit frame process.

• Anonymous
  January 01, 2013
  The comment has been removed

• Anonymous
  January 04, 2013
  Brilliant! The trusted route is all I need at this stage. As you say, the key is to trust the page host rather than the websocket host. Everything works now, so thank you very much Eric.

• Anonymous
  February 06, 2013
  Hi can any one tell me  Switch Between 32-bit and 64-bit Internet Explorer 10 in Windows 7  is also possible like windows 8 or not ?? i.e in order to enable 64bit Content Processes for the Desktop we will enable "Enhanced Protect Mode" in IE10 windows 8. . is it the same case in Windows 7 ?? EricLaw: In IE10 on Windows7, the "Enhanced Protect Mode" checkbox controls only whether IE runs in 64bit. In IE9, 64bit IE is a separate program in the Start Menu.

• Anonymous
  February 28, 2013
  We blocked the x64 IE9 with AppLocker (Program Files path). Users should run only x86 version of IE. But with IE10: blocking the x64 path with prevents startup of x86 IE! How to handle this? EricLaw: That rule definitely shouldn't be used with IE10, as IE10 requires processes of both bitnesses for its normal function. You can use Zones to control what bitness processes are used for sites.

• Anonymous
  March 01, 2013
  On Win7-64 with IE10 I want to enable EPM and use 64-bit browser processes for everything, EXCEPT for a few sites that require a 32-bit IE for a 32-bit-only add-on.  With IE9 I could create a shortcut to ProgFilesX86IEiexplore.exe with a URL to get a 32-bit browser instance.  But with IE10 and EPM, that shortcut now produces a 64-bit browser process so the 32-bit add-on fails. How can I leave EPM enabled by default for 99% of browsing and create a shortcut or link to launch a 32-bit browser instance or somehow tag a site to use a 32-bit browser instance? Thx.

• Anonymous
  March 01, 2013
  This part seems especially important for those enterprise customers that have transparent proxy server through which outbound traffic flows: Notably, the container does not specify internetClientServer, privateNetworkClientServer, enterpriseAuthentication, or any of the *Library capabilities, which means that Internet content runs in a tightly-limited process. I'm seeing authentication requests fail when the site is running in an AppContainer tab. If I add the site to IE Trusted Sites zone, the site runs at Medium level, and the transparent authentication works.  It seems that AppContainer is preventing the passing of network credentials to the proxy server.  For corporate customers, what is the way around this?  Is it possible to enable the enterpriseAuthentication capability for IE10 when running in the AppContainer?  

• Anonymous
  March 01, 2013
  Thilo, it looks like you will need to ensure that Enhanced Protected Mode is always OFF for the desktop version of IE10.  This will ensure that tabs run at 32-bit.  Tommcg1, if it's only a few sites, you can add them to IE Trusted Sites through Group Policy, and they will run at 32-bit, while all other sites continue to use EPM and run at 64-bit.  Adding to Trusted Sites will turn Protected Mode OFF, so be aware of that.  

• Anonymous
  March 01, 2013
  Thilo, you can use Group Policy to disable Enhanced Protected Mode -- forgot to add that.  

• Anonymous
  March 01, 2013
  Thanks, breca89, for the suggestion.  However, with EPM globally enabled and tagging the site "trusted" (medium security and protection disabled) still does not result in a 32-bit IE process running when navigate to that site. If launch IE on about:blank with EPM enabled, it is a 64-bit process. Just typing the address of the trusted site in address bar or choosing link from favorites does not result in a new 32-bit iexplore.exe process -- it just loads the site in the 64-bit content process that the browser window runs within.   And launching iexplore.exe from ProgFilesX86 still results in a 64-bit IE. With EPM enabled, a desktop URL shortcut to trusted site still results in 64-bit IE. Open link in new window still results in 64-bit IE. Even setting trusted sites to lowest security level still results in 64-bit IE. Still can't figure out how to get a 32-bit IE to load for only a specific site or link or shortcut while leaving EPM enabled globally.   This is Win7-64 IE10 with tabs disabled. Thx.

• Anonymous
  March 05, 2013
  Tommcg1, I think the issue is that tabs are disabled.  If you run Process Explorer, and add the Integrity and Image Type columns, you can see the bitness of the IE processes and which integrity level they are running at.  My guess is that because tabs are disabled, IE now will only run at 64-bit -- I will run a test myself to see if it jives with what you are seeing.  In my testing so far, I have EPM enabled and tabs enabled, and I can list a specific site in IE Trusted Sites and it will run in 32-bit mode.  

• Anonymous
  March 05, 2013
  Tommcg1, actually, I turned off tabs, and I'm still able to run 32-bit IE process with EPM enabled -- if I view a Trusted Site in IE.  I am running Win8 64-bit, so slightly different than you.  Another difference is that you may have EPM enabled through group policy, and I am just using IE options to enable it.  I will test enabling it thru group policy.

• Anonymous
  March 05, 2013
  I set EPM with local group policy, and disabled tabs.  I still see a 32-bit IE process when browsing to a Trusted Site.  All other zones run in 64-bit mode (and since this is Win8, they run at the AppContainer integrity level).

• Anonymous
  March 07, 2013
  The comment has been removed

• Anonymous
  April 08, 2013
  The comment has been removed

• Anonymous
  July 02, 2013
  Nice sharing. Is there any similar API (IEGetProtectedModeCookie) can access to EPM cookie? Thanks. [EricLaw] Unfortunately, no, this API didn't make it for IE10 and I haven't heard any indication that it exists for IE11 either. You may want to file a bug on the IE CONNECT site.

• Anonymous
  July 10, 2013
  I'm trying to build a plugin for IE. I've completed it for both 32-bit and 64-bit and it's working on IE9 (both 32 and 64 bit). But when I use it on IE10 with EPM on, it's not loading. I've used "DEFINE_GUID(CATID_AppContainerCompatible, 0x59fb2056,0xd625,0x48d0,0xa9,0x44,0x1a,0x85,0xb5,0xab,0x26,0x40);" in my plugin to register it to CATID_AppContainerCompatible, but it's still not loading.. Am I doing something wrong? EricLaw: You need to store the .DLLs in an AppContainer-readable folder like the Program Files folder.

• Anonymous
  July 17, 2013
  On 64 bit Win8.1 with IE11. I have tool-bars at C:Program Files (x86) for 32 bit version and C:Program Files for 64 bit version. pICatRegister->RegisterClassImplCategories(CLSID_StockBar, 1, catids) succeeded but no "Implemented Categories" created. I manually create Implemented Categories/{59fb2056-d625-48d0-a944-1a85b5ab2640} and the incompatible warning does not show up. However the toolbar still now showing. What else I could miss. Thanks. EricLaw: You need to register your toolbar in the COM registry before attempting to register its categories using the category manager.

• Anonymous
  August 07, 2013
  The comment has been removed

• Anonymous
  August 30, 2013
  Is it possible in EMP to open a shared mutex (between a BHO and a broker process) by lowering the mutex rights via (ConvertStringSecurityDescriptorToSecurityDescriptorW, ..., SetSecurityInfo)?  This is currently working fine for Protected Mode a scenario. EricLaw: While I'm not an expert on the specifics, yes, I expect you can communicate in this way if the privileged process ACLs the shared resource properly.

• Anonymous
  September 12, 2013
  BHO in EPM is located in Program FilesBHO, and it can read files from any folder under Program Files, but why it cannot read from files under AppDataLocalLow?

• Anonymous
  September 12, 2013
  @Alex: If you see the comment on this post from "Radek" made on Wed, Jul 11 2012 2:56 AM, you'll find that the ACL for the LocalLow folder is indeed "Low Integrity"; AppContainers have an even lower level of privilege than the Vista-era "Low Integrity". If you want to read out of an AppContainer, you need a broker.

• Anonymous
  September 17, 2013
  @Eric: In IE10 with EPM on Windows 8, BHO is loaded, but it is not loaded in IE10 with EPM on Windows 7. What could be a difference?

• Anonymous
  October 28, 2013
  Let me get this right - you cannot manipulate cookies within the current window using an add-on i.e. by using Wininet? [EricLaw] If your code is running in the same process as the HTML content (e.g. a typical BHO or ActiveX control) then your WinINET API calls will be operating against the correct AppContainer data stores. If your code was running in a different process (e.g. a standalone executable, or an out-of-process broker) then your WinINET calls would typically be running against the non-AppContainer data stores that are not used by the EPM-tab process.

• Anonymous
  November 03, 2013
  You say: Writing a broker is a significant undertaking, and requires a thorough security audit to ensure that the broker doesn't allow malicious code to escape from the tab running in Protected Mode. Does this mean that every broker must be audited and certified by Microsoft or is this general guidance to broker developers to take heed to the security issues? [EricLaw]: Microsoft doesn't offer or require auditing/certification of brokers. That's especially unfortunate because they are so often a source of sandbox-escape exploits. Microsoft merely reserves the right to disable 3rd-party brokers if they're found to be vulnerable; it does not (currently) proactively pen-test brokers.

• Anonymous
  November 07, 2013
  Eric, Thank for you the Article. I have been creating a new BHO from scratch. I am trying to log some simple things (think debug logging) to disk. When I was running IE10, IE Tab Process Visualization was putting my log file (text file)in someplace like C:UsersusernameAppDataLocalMicrosoftWindowsTemporary Internet FilesVirtualized.  Ever Since I installed IE11 and made my BHO Protection Mode all Write Requests from BHO are Failing. Simple Question: Where can I place my BHO log file?

• Anonymous
  November 07, 2013
  @Ehsan: Your BHO needs to write to a folder which is ACL'd to allow access to processes running within an AppContainer. Unlike virtualization done for PM, I don't know that there's any default-writable folder for EPM processes.

• Anonymous
  November 08, 2013
  Thanks Eric, so essentially an application installer must modify the ACL for the BHO to have write access to a certain folder. I am gone try logging to EvenLog and see if that still works.

• Anonymous
  November 13, 2013
  The comment has been removed

• Anonymous
  April 25, 2014
  Superb article Eric, this is the kind of detail developers need. Is there any way to force running IE x32? [EricLaw] I don't think I really understand the premise of the question. The option Tools > Internet Options > Advanced Use 64-bit Processes for Enhanced Protected Mode controls whether IE on the Desktop uses 64bit Tab processes. You can't use a 32bit frame process except on a 32bit machine.

• Anonymous
  April 29, 2014
  The comment has been removed

• Anonymous
  July 25, 2014
  I do not seem to have the option Use 64-bit Processes for Enhanced Protected Mode. Is there a way to load trusted sites in 64-bit mode on the desktop without disabling tab processes altogether?

• Anonymous
  January 08, 2015
  Does EPM have anything to do with why the different Zones' 'custom options' settings do not work (ie; pop-up blocker [mixed content], Smartscreen filter, XSS filter, etc.) with it turned ON?  (or, in some cases, even if it is Off - depending on the page - I still have to manually over-ride/allow 'all contents to be displayed', even if the site/page is in my Trusted list or Intranet list... which each have their own custom settings for popup blocker, smartscreen ActiveX, XSS filter, "Safe" & "UN-Safe" Programs,Apps)...? [EricLaw] No, enabling EPM should not have any real impact on your other security zone settings. Each zone should still respect its own section.