It’s an interesting time. Microsoft now maintains three different web browsers:
Internet Explorer 11
Microsoft Edge Legacy (Spartan, v18 and below)
Chromium-based Microsoft Edge (v79+)
If you’re using Internet Explorer 11, you should stop; sometimes, this is easier said than done.
If you’re using Legacy Microsoft Edge, you should upgrade to the new Microsoft Edge which is better in almost every way. When you install the Stable version of the new Microsoft Edge (either by downloading it or eventually by using WindowsUpdate), it will replace your existing Legacy Edge with the new version.
What if I still need to test in Legacy Edge?
If you’re a web developer and need to keep testing your sites and services in the legacy Microsoft Edge, you’ll need to set a registry key to prevent the Edge installer from removing the entry points to the old Edge.
Simply import this registry script before the new Edge is installed. When the AllowSxS key is set to 1, the new Edge installer will keep the old entry point, renaming it to “Microsoft Edge Legacy”:
Thereafter, you can use both versions of Edge on the same PC.
If you didn’t have this registry key set and your legacy Edge entry points have disappeared when you installed the new Edge, you can use the Add or Remove Programs applet in the system control panel to uninstall the new Edge, then set the registry key, then reinstall the new Edge.
Note: If you’re a Web Developer, you should also be testing in the Edge Beta or Edge Dev builds because these will allow you to see the changes coming to Edge before your users do. These builds install side-by-side (replacing no browser) and can be installed from https://MicrosoftEdgeInsider.com.
What if my company has sites that only work in Internet Explorer?
In order to help speed migration to the new Microsoft Edge, it offers an Internet Explorer Mode feature when running on Windows. IE Mode allows IT administrators to configure PCs running Windows 7, 8.1, and 10 such that specified sites will load inside a browser tab that uses the Internet Explorer 11 rendering engine.
IE Mode is not designed for or available to consumers.
Because IE Mode relies upon the IE11 binaries on the current machine, it is not available in Edge for MacOS, iOS, or Android.
IE Mode tabs run inside the legacy security sandbox (weaker than the regular Edge sandbox) and ActiveX controls like Silverlight are available to web pages.
IE Mode does not share a cache, cookies, or web storage with Microsoft Edge, so scenarios that depend upon using these storage mechanisms in a cross-site+cross-engine context will not work correctly. IT administrators should carefully set their policies such that user flows occur within a single engine.
Most Edge browser extensions will not work on IE Mode tabs–extensions which only look at the tab’s URL should work, but extensions which try to view or modify the page content will not function correctly.
In an ideal world, users will migrate to the latest version of Microsoft Edge as quickly as possible, and enjoy a faster, more compatible, more reliable browser. Nevertheless, Microsoft will continue to patch both Legacy Edge and Internet Explorer 11 according to their existing support lifecycle.
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.
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.
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 five1 different Security Zones:
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.“
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.
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).
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.
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.
Avoiding Zones in Chromium
Chromium goes further and favors making decisions based on explicitly-configured site lists and/or command-line arguments.
When deciding whether or not to release Windows Integrated Authentication (Kerberos/NTLM) credentials automatically.
Respect for Zones2 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:
Zones are poorly documented, and Windows Zone behavior is poorly understood.
The performance/deadlock risks mentioned earlier (Intranet Zone mappings can come from a system-discovered proxy script).
Zones are Windows-only (meaning they prevent drop-in replacement of ChromeOS).
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.
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.
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.
1 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.
2 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.