2.3 Configure Edge S/MIME Extension Follow these steps to correctly configure the S/MIME extension in Microsoft Edge: 1. Click on the Start button and open Microsoft Edge. It may be already pinned to the Start Menu on the right-side (as depicted below) or you may have to navigate to it in the programs list on the left-side. Even if you do add a site to the trusted sites in Microsoft Edge you still have a few different security levels you can choose from ranging from Low to High. To add a trusted website to Microsoft Edge Web Browser: 1. Open Windows 10 Start Menu Type Internet Options Open Internet Options. Site permissions Personal Choice Some sites will ask permission to use your microphone or video camera, and the Edge browser remembers this. If you clear this option, the browser will prompt you again for access the next time you visit; it's safe to clear this option.

In some cases, such as enterprise, have to add trusted site to group policy manually before visiting the website. Today, we'll show you how to solve this issue. Although you are new to use group policy, worry not, this tutorial is easy for you to understand.

Note: Windows 10 Home edition doesn't support group policy.

How to Add Trusted Site to Group Policy Windows 10

Step 1: Press Windows + R key combination to invoke Run dialog. Input gpedit.msc to the box and click on OK.

Step 2: In the left pane, navigate to Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security page. Double-click on Site to Zone Assignment List in the right pane.

Step 3: In the Site to Zone Assignment List window, select Enabled then tap on Show button under Options.

Step 4: In the column under Value name, input the website. Then Type 2 in the box next to it.

Tips: Internet Explorer includes four safe zones, respectively, one to four. To add trusted site to group policy, we have to select number 2.

1: Intranet zone

2: Trusted Sites zone

3: Internet zone

4: Restricted Sites zone

Step 5: Go back to Site to Zone Assignment List window, tap on Apply then OK.

Step 6: When you finished the steps above, go to the desktop and check whether added successfully or not. Click on Search box then input Internet Explorer. Hit Enter, it will be opened at once.

Step 7: Click the gear icon in the top-right corner then select Internet options.

Step 8: Click on Security tab, tap on Trusted sites and click on Sites button.

Step 9: In the Trusted sites dialog, you will see the trusted site that added to group policy.

Related Articles:

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).
• 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

Trusted Sites Google Chrome

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.

What Are Trusted Sites

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.

Add Trusted Site To Microsoft Edge Browser

-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.