Security Zones in Edge

Last updated: 4 January 2024

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.

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 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, and Google IT accidentally did it circa 2016).
• 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.

Similarly, because Chrome uses the Windows Attachment Execute Services API to write a Mark-of-the-Web on downloaded files, the Launching applications and unsafe files setting (aka URLACTION_SHELL_EXECUTE_HIGHRISK) for the download’s originating Zone controls whether the MoTW is written. If this setting is set to Enable (as it is for LMZ and Intranet), no MoTW is written to the file’s Zone.Identifier alternate data stream. If the Zone’s URLAction value is set to Prompt (as it is for Trusted Sites and Internet zones), the Security Zone identifier is written to the ZoneId property in the Zone.Identifier file.

By setting a policy, Administrators can optionally configure Edge or configure Chrome to skip SmartScreen/SafeBrowsing reputation checks for File Downloads that original from the Intranet/Trusted Zone.

For the second use of Zones, 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 retype credentials that Windows already has.

Even Limited Use is Controversial

Any respect for Zones (or network addresses²) in Chromium remains controversial— the Chrome team has launched and abandoned plans to remove all support a few times, but ultimately given up under the weight of enterprise compat concerns. The 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 WPAD-discovered proxy script).
3. Zones are Windows-only (meaning they prevent drop-in replacement of Windows by ChromeOS).

A sort of compromise was reached: 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 (Downloads and Auth), the new Chromium-based Edge browser adds three 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.
2. Administrators can configure Intranet Zone sites to navigate to file:// URIs which is otherwise forbidden.
3. Administrators can configure Intranet Zone sites to not be put into Enhanced Security Mode.

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.

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 behaviors 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 (policy was added to Edge 95).
• Disable “HTTP and mixed content are unsafe” and “TLS/1.0 and TLS/1.1 are deprecated” nags. (Update: Now pretty obsolete as these no longer exist)
• Skip SmartScreen website checks for the Trusted/Intranet zones (available for Download checks only).
• 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. As of Edge 94, other policies can be used.
• Allow launching application protocols from the Intranet without a prompt.
• Drop all Referrers when navigating from the Intranet to the Internet; leave Referrers alone when browsing the Intranet. (Update: less relevant now).
• Internet Explorer and legacy Edge 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 specify the site list.
• Block all (or most) extensions from touching Intranet pages to reduce the threat of data leaks (runtime_blocked_hosts policy).
• Guide all Intranet navigations into an appropriate profile or container (a la Detangle).
• Upstream, there’s a longstanding 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. The current plan is to protect RFC1918-reserved address space.

At present, only AutoSelectCertificateForUrls, AutoOpenFileTypes, AutoLaunchProtocolsFromOrigins. manual cookie controls, and mixed content nags support policy-pushed site lists, but their list syntax doesn’t have any concept of “the entire Intranet” (all 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 powerful 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:

• https://payroll.contoso-intranet.com
• https://timecard.contoso-intranet.com
• https://sharepoint.contoso-intranet.com

…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 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. This seems unlikely to happen. Edge has been on Chromium for over two years now, and there’s no active plan to introduce such a feature.

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 hostname 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-will-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, navigation restrictions, and Network Quality Estimation. As of 2022, Chrome did a big refactor to allow determination of whether or not the target site’s IP address is in the public IP Address space or the private IP address space (e.g. inherently Intranet) as a part of the Private Network Access spec. This check should now be basically free (it’s getting used on every resource load) and it may make sense to start using it in a lot of places to approximate the “This target is not on the public Internet” check.

Within Edge, the EMIE List is another mechanism by which sites’ hostnames may result in different handling.

Ancient History

Security Zones were introduced with Internet Explorer 4, released back in 1997:

The UI has only changed a little bit since that time, with most of the changes happening in IE5. There were only tiny tweaks in IE6, 7, and 8.