Ie Edge Chromium

Browsers As Decision Makers

As a part of every page load, browsers have to make dozens, hundreds, or even thousands of decisions — should a particular API be available? Should a resource load be permitted? Should script be allowed to run? Should video be allowed to start playing automatically? Should cookies or credentials be sent on network requests? The list is long.

It was at the Build 2019 developer conference where Microsoft first announced IE Mode for their Chromium-based Edge browser. After enabling a flag, you could then use Internet Explorer within a tab in Edge. Only a few weeks later, the “Show this page using Internet Explorer” option in the menu isn’t there anymore, even if. IE mode on Microsoft Edge makes it easy to use all of the sites your organization needs in a single browser. It uses the integrated Chromium engine for modern sites, and it uses the Trident MSHTML engine from Internet Explorer 11 (IE11) for legacy sites. Display web pages using IE within Edge. Use Java, Silverlight, ActiveX, Sharepoint, and more. IE Tab exactly emulates IE by using the IE rendering engine directly within Edge. This will enable you to use ActiveX controls and test your web pages with different versions of IE (IE 7-11).

In many cases, decisions are governed by two inputs: a user setting, and the URL of the page for which the decision is being made.

Display web pages using IE within Edge. Use Java, Silverlight, ActiveX, Sharepoint, and more. IE Tab exactly emulates IE by using the IE rendering engine directly within Edge. This will enable you to use ActiveX controls and test your web pages with different versions of IE (IE 7-11). Microsoft Edge Chromium comes up with several good features, including internet explorer mode, This enterprise feature lets users to load any internal websites inside any enterprise network. This article will guide you to enable Internet Explorer Mode in Microsoft Edge Chromium. Enable Internet Explorer mode in Microsoft Edge Chromium.

In the old Internet Explorer web platform, each of these decisions was called an URLAction, and the ProcessUrlAction(url, action,…) API allowed the browser or another web client to query its security manager for guidance on how to behave.

To simplify the configuration for the user or their administrator, the legacy platform classified sites into five¹ different Security Zones:

• Local Machine
• Local Intranet
• Trusted
• Internet
• Restricted

Users could use the Internet Control Panel to assign specific sites to Zones and to configure the permission results for each zone. When making a decision, the browser would first map the execution context (site) to a Zone, then consult the setting for that URLAction for that Zone to decide what to do.

Reasonable defaults like “Automatically satisfy authentication challenges from my Intranet” meant that most users never needed to change any settings away from their defaults.

In corporate or other managed environments, administrators can use Group Policy to assign specific sites to Zones (via “Site to Zone Assignment List” policy) and specify the settings for URLActions on a per-zone basis. This allowed Microsoft IT, for instance, to configure the browser with rules like “Treat https://mail.microsoft.com as a part of my Intranet and allow popups and file downloads without warning messages.“

Beyond manual administrative or user assignment of sites to Zones, the platform used additional heuristics that could assign sites to the Local Intranet Zone. In particular, the browser would assign dotless hostnames (e.g. https://payroll) to the Intranet Zone, and if a Proxy Configuration script was used, any sites configured to bypass the proxy would be mapped to the Intranet Zone.

Applications hosting Web Browser Controls, by default, inherit the Windows Zone configuration settings, meaning that changes made for Internet Explorer are inherited by other applications. In relatively rare cases, the host application might supply its own Security Manager and override URL Policy decisions for embedded Web Browser Control instances.

The Trouble with Zones

While powerful and convenient, Zones are simultaneously problematic bug farms:

• Users might find that their mission critical corporate sites stopped working if their computer’s Group Policy configuration was outdated.
• Users might manually set configuration options to unsafe values without realizing it.
• Attempts to automatically provide isolation of cookies and other data by Zone led to unexpected behavior, especially for federated authentication scenarios.

Zone-mapping heuristics are extra problematic

• A Web Developer working on a site locally might find that it worked fine (Intranet Zone), but failed spectacularly for their users when deployed to production (Internet Zone).
• Users were often completely flummoxed to find that the same page on a single server behaved very differently depending on how they referred to it — e.g. http://localhost/ (Intranet Zone) vs. http://127.0.0.1/ (Internet Zone).

The fact that proxy configuration scripts can push sites into the Intranet zone proves especially challenging, because:

• A synchronous API call might need to know what Zone a caller is in, but determining that could, in the worst case, take tens of seconds — the time needed to discover the location of the proxy configuration script, download it, and run the FindProxyForUrl() function within it. This could lead to a hang and unresponsive UI.
• A site’s Zone can change at runtime without restarting the browser (say, when moving a laptop between home and work networks, or when connecting or disconnecting from a VPN).
• An IT Department might not realize the implications of returning DIRECT from a proxy configuration script and accidentally map the entire untrusted web into the highly-privileged Intranet Zone. (Microsoft IT accidentally did this circa 2011).
• Some features like AppContainer Network Isolation are based on firewall configuration and have no inherent relationship to the browser’s Zone settings.

Legacy Edge

The legacy Edge browser (aka Spartan, Edge 18 and below) inherited the Zone architecture from its Internet Explorer predecessor with a few simplifying changes:

• Windows’ five built-in Zones were collapsed to three: Internet (Internet), the Trusted Zone (Intranet+Trusted), and the Local Computer Zone. The Restricted Zone was removed.
• Zone to URLAction mappings were hardcoded into the browser, ignoring group policies and settings in the Internet Control Panel.

Use of Zones in Chromium

Chromium goes further and favors making decisions based on explicitly-configured site lists and/or command-line arguments.

Nevertheless, in the interest of expediency, Chromium today uses Windows’ Security Zones by default in two places:

1. When deciding how to handle File Downloads, and
2. When deciding whether or not to release Windows Integrated Authentication (Kerberos/NTLM) credentials automatically.

For the first one, if you’ve configured the setting Launching applications and unsafe files to Disable in your Internet Control Panel’s Security tab, Chromium will block file downloads with a note: “Couldn’t download – Blocked.”

For the second, Chromium will process URLACTION_CREDENTIALS_USE to decide whether Windows Integrated Authentication is used automatically, or the user should instead see a manual authentication prompt. (Aside: the manual authentication prompt is really a bit of a mistake– the browser should instead just show a prompt: “Would you like to [Send Credentials] or [Stay Anonymous]” dialog box, rather than forcing the user to reenter the credentials that Windows already has.

Even Limited Use is Controversial

Respect for Zones² in Chromium remains controversial—the Chrome team has launched and abandoned plans to remove them a few times, but ultimately given up under the weight of enterprise compat concerns. Their arguments for complete removal include:

1. Zones are poorly documented, and Windows Zone behavior is poorly understood.
2. The performance/deadlock risks mentioned earlier (Intranet Zone mappings can come from a system-discovered proxy script).
3. Zones are Windows-only (meaning they prevent drop-in replacement of ChromeOS).

Note: By configuring an explicit site list policy for Windows Authentication, an administrator disables the browser’s URLACTION_CREDENTIALS_USE check, so Zones Policy is not consulted. A similar option is not presently available for Downloads.

Zones in the New Edge

Beyond the two usages of Zones inherited from upstream, the new Chromium-based Edge browser (v79+) adds one more:

1. Administrators can configure Internet Explorer Mode to open all Intranet sites in IEMode. Those IEMode tabs are really running Internet Explorer, and they use Zones for everything that IE did.

Update: This is very much a corner case, but I’ll mention it anyway. On downlevel operating systems (Windows 7/8/8.1), logging into the browser for sync makes use of a Windows dialog box that contains a Web Browser Control (based on MSHTML) that loads the login page. If you adjust your Windows Security Zones settings to block JavaScript from running in the Internet Zone, you will find that you’re unable to log into the new browser. Oops.

Downsides/Limitations

While it’s somewhat liberating that we’ve moved away from the bug farm of Security Zones, it also gives us one less tool to make things convenient or compatible for our users and IT admins.

We’ve already heard from some customers that they’d like to have a different security and privacy posture for sites on their Intranet, with behavior like:

• Disable the Tracking Prevention, “Block 3rd party cookie”, and other privacy-related controls for the Intranet (like IE/Edge did).
• Allow navigation to file:// URIs from the Intranet (like IE/Edge did)
• Disable “HTTP and mixed content are unsafe” and “TLS/1.0 and TLS/1.1 are deprecated” nags.
• Skip SmartScreen checks for the Intranet.
• Allow ClickOnce/DirectInvoke/Auto-opening Downloads from the Intranet without a prompt. Previously, Edge (Spartan)/IE respected the FTA_OpenIsSafe bit in the EditFlags for the application.manifest progid if-and-only-if the download source was in the Intranet/Trusted Sites Zone.
• Allow launching application protocols from the Intranet without a prompt.
• Drop all Referers when navigating from the Intranet to the Internet; leave Referers alone when browsing the Intranet.
• Internet Explorer and legacy Edge will automatically send your client certificate to Intranet sites that ask for it. The AutoSelectCertificateForUrls policy permits Edge to send a client certificate to specified sites without a prompt, but this policy requires the administrator to manually list the sites.
• Block all (or most) extensions from touching Intranet pages to reduce the threat of data leaks.
• Guide all Intranet navigations into an appropriate profile or container (a la Detangle).
• Upstream, there’s alongstanding desire to help protect intranets/local machine from cross-site-request-forgery attacks; blocking loads and navigations of private resources from the Internet Zone is somewhat simpler than blocking them from Intranet Sites.

At present, only AutoSelectCertificateForUrls, manual cookie controls, and mixed content nags support policy-pushed site lists, but their list syntax doesn’t have any concept of “Intranet” (dotless hosts, hosts that bypass proxy).

You’ll notice that each of these has potential security impact (e.g. an XSS on a privileged “Intranet” page becomes more dangerous; unqualified hostnames can result in name collisions), but having the ability to scope some features to only “Intranet” sites might also improve security by reducing attack surface.

As browser designers, we must weigh the enterprise impact of every change we make, and being able to say “This won’t apply to your intranet if you don’t want it to” would be very liberating. Unfortunately, building such an escape hatch is also the recipe for accumulating technical debt and permitting the corporate intranets to “rust” to the point that they barely resemble the modern public web.

Best Practices

Throughout Chromium, many features are designed respect an individual policy-pushed list of sites to control their behavior. If you were forward-thinking enough to structure your intranet such that your hostnames are of the form:

Congratulations, you’ve lucked into a best practice. You can configure each desired policy with a *.contoso-intranet.com entry and your entire Intranet will be opted in.

Unfortunately, while wildcards are supported, there’s presently no way (as far as I can tell) to express the concept of “any dotless hostname.”

Why is that unfortunate? For over twenty years, Internet Explorer and legacy Edge mapped domain names like https://payroll, https://timecard, and https://sharepoint/ to the Intranet Zone by default. As a result, many smaller companies have benefitted from this simple heuristic that requires no configuration changes by the user or the IT department.

Opportunity: Maybe such a DOTLESS_HOSTS token should exist in the Chromium policy syntax. TODO: figure out if this is worth doing.

Summary

• Internet Explorer and Legacy Edge use a system of five Zones and 88+ URLActions to make security decisions for web content, based on the host of a target site.
• Chromium (New Edge, Chrome) uses a system of Site Lists and permission checks to make security decisions for web content, based on the host of a target site.

There does not exist an exact mapping between these two systems, which exist for similar reasons but implemented using very different mechanisms.

In general, users should expect to be able to use the new Edge without configuring anything; many of the URLActions that were exposed by IE/Spartan have no logical equivalent in modern browsers.

If the new Edge browser does not behave in the desired way for some customer scenario, then we must examine the details of what isn’t working as desired to determine whether there exists a setting (e.g. a Group Policy-pushed SiteList) that provides the desired experience.

-Eric

¹ Technically, it was possible for an administrator to create “Custom Security Zones” (with increasing ZoneIds starting at #5), but such a configuration has not been officially supported for at least fifteen years, and it’s been a periodic source of never-to-be-fixed bugs.

² Beyond those explicit uses of Windows’ Zone Manager, various components in Chromium have special handling for localhost/loopback addresses, and some have special recognition of RFC1918 private IP Address ranges (e.g. SafeBrowsing handling) and Network Quality Estimation.
Within Edge, the EMIE List is another mechanism by which sites’ hostnames may result in different handling.

We created Internet Explorer (IE) mode in Microsoft Edge for organizations that still need Internet Explorer 11 for backward compatibility with existing websites but also need a modern browser. This feature makes it easier for organizations to use one browser, for legacy web/apps or for a modern web/app. This article provides an introduction to using Microsoft Edge with IE mode.

New Ie Edge Chromium

Note

This article applies to Microsoft Edge version 77 or later.

What is IE mode?

IE mode on Microsoft Edge makes it easy to use all of the sites your organization needs in a single browser. It uses the integrated Chromium engine for modern sites, and it uses the Trident MSHTML engine from Internet Explorer 11 (IE11) for legacy sites.

When a site loads in IE mode, the IE logo indicator displays on the left side of navigation bar. You can click the IE logo indicator to display additional information, as shown:

Only those sites that you specifically configure (via policy) will use IE mode, all other sites will be rendered as modern web sites. For a site to use IE mode, you need to:

• List the site in the Enterprise Mode Site List XML defined in one of these policies:
  • Microsoft Edge 78 or later, 'Configure the Enterprise Mode Site List'
  • Internet Explorer, 'Use the Enterprise Mode IE website list'

  Note

  We only process one Enterprise Mode Site List. The Microsoft Edge site list policy takes precedence over the Internet Explorer site list policy.

• All Intranet sites when the Send all intranet sites to Internet Explorer group policy is enabled (Microsoft Edge 77 or later.)

Ie Edge Chromium

IE mode supports the following Internet Explorer functionality

• All document modes and enterprise modes
• ActiveX controls (such as Java or Silverlight)
• Browser Helper Objects
• Internet Explorer settings and Group Policies that affect the security zone settings and Protected Mode
• The F12 developer tools for IE, when launch with IEChooser
• Microsoft Edge extensions (Extensions that interact with the IE page content directly are not supported.)

IE mode doesn't support the following Internet Explorer functionality

• Internet Explorer toolbars
• Internet Explorer settings and Group Policies that affect the navigation menu (for example - search engines, and home pages.)
• IE11 or Microsoft Edge F12 developer tools

Prerequisites

The following prerequisites apply to using Microsoft Edge with IE mode.

Important

Ie Edge Chromium Pro

To ensure success, install the latest updates for Windows and Microsoft Edge. Failure to do so will likely cause IE mode to fail.

1. The minimum system updates for the operating systems listed in the next table.

Ie Edge Chromium

Important

** Windows 7 and Windows Server 2008 R2 will be supported by Microsoft Edge even after those operating systems go out of support. In order for IE mode to be supported on these operating systems the devices will need to have the Extended Security Updates for Windows 7. We recommend that you upgrade to a supported operating system as soon as possible in order to remain secure. Support for Microsoft Edge with the Extended Security Updates should be considered a temporary bridge to getting to a supported OS state.

Ie Edge Chromium Beta

2. The Microsoft Edge administrative template. For more information, see Configure Microsoft Edge.
3. Internet Explorer 11 enabled in Windows Features.

Ie Edge Chromium Based Download

See also