As Microsoft Edge for iOS and Android adoption continues to grow, we have received a few questions on the experiences Edge offers with handling blocked websites.
By default, Edge allows users to access any website. However, many organizations need data protection mechanisms to control what websites their users visit and how the data is handled. With Microsoft Endpoint Manager Intune App Protection Policies (APP), organizations can enforce how web data is handled. With an app configuration policy (delivered through the APP channel), organizations can restrict what websites an Azure AD account visits.
Figure 1: Edge mobile App Configuration Policy
When websites are defined in the Allowed URLs (com.microsoft.intune.mam.managedbrowser.AllowListURLs) list, Edge ensures that the Azure AD account can only access the allowed websites, thereby blocking all other websites.
Conversely, organizations can define a set of Blocked URLs (com.microsoft.intune.mam.managedbrowser.BlockListURLs). In this configuration, Edge ensures that the Azure AD account cannot access the restricted websites.
Note: If both allowed and blocked URLs are defined, only those URLs defined in the allow list are enforced.
Preventing your users from accessing certain sites can lead to a broken and frustrating experience from the end user’s perspective. To address that concern, Edge supports transition experiences, based on additional app configuration settings. There are additional app configuration settings that define how Edge should act when an Azure AD account attempts to access a restricted website:
- The setting Redirect restricted sites to personal context (com.microsoft.intune.mam.managedbrowser.AllowTransitionOnBlock), which is set to true by default, ensures that if the user has added his or her personal account into the app, then Edge can open the restricted site in the user’s personal account context or possibly in the Azure AD account’s InPrivate context.
- The setting com.microsoft.intune.mam.managedbrowser.openInPrivateIfBlocked, which is set to false by default, defines whether the Azure AD account has the option to open the restricted website in the Azure AD account’s InPrivate context when transitions are enabled. This key is not exposed in Edge’s app configuration UX, so this key/value pair must be defined manually. This key is only enforced when AllowTransitionOnBlock is enabled.
- The setting com.microsoft.intune.mam.managedbrowser.disabledFeatures with a value of InPrivate enables further customization by allowing organizations to disable the InPrivate experience for Azure AD accounts. By default, the Azure AD account can use InPrivate to browse sites. This key is not exposed in Edge’s app configuration UX, so this key/value pair must be defined manually.
It’s the combination of AllowTransitionOnBlock and openInPrivateIfBlocked that define whether a user can transition a restricted site to the personal context, Azure AD account’s InPrivate context, or whether the site is blocked entirely.
With this in mind, let’s look at a few scenarios to understand the expected outcomes when an organization has defined a set of restricted sites.
Transitions with only work or school accounts
First, let’s assume that the user only has an Azure AD account configured in Edge. There are effectively four scenarios:
|
Scenario |
AllowTransitionOnBlock |
OpenInPrivateifBlocked |
|
1 |
False |
False |
|
2 |
False |
True |
|
3 |
True |
False |
|
4 |
True |
True |
With Scenario 1 and Scenario 2, the organization has disabled the ability to transition when the Azure AD account accesses a restricted site (the value of OpenInPrivateifBlocked is irrelevant when AllowTransitionOnBlock is disabled). As a result, the user is notified that the site is blocked and prevented from accessing the site.
Figure 2: Restricted website is blocked
Scenario 3 is the default configuration when the app is configured to restrict access to certain websites. The transition experience depends on whether the organization allows personal accounts in Edge. If personal accounts are allowed (which is the default behavior of the app), the user is prompted to login with a personal account to access the restricted site. If on the other hand, personal accounts are disabled, then the user is blocked from accessing the website.
Figure 3: Login with a personal account to access restricted website
As InPrivate transitions are allowed in Scenario 4, restricted websites are opened seamlessly in the Azure AD account’s InPrivate context, assuming that InPrivate is not disabled for the user. The user is notified of the transition with a notification that states “Link opened with InPrivate mode. Your organization requires the use of InPrivate mode for this content.” which is visible for 7 seconds. If the InPrivate experience is disabled for the user, then access to the website is blocked.
Figure 4: Restricted website is opened in InPrivate
Transitions with personal accounts
Now let’s look at how these experiences change when a personal account exists within Edge.
|
Scenario |
AllowTransitionOnBlock |
OpenInPrivateifBlocked |
|
5 |
False |
False |
|
6 |
False |
True |
|
7 |
True |
False |
|
8 |
True |
True |
With Scenario 5 and Scenario 6, the organization has disabled the ability to transition when the Azure AD account accesses a restricted site. As a result, the user is notified that the site is blocked and prevented from accessing the site within the context of the Azure AD account.
Scenario 7 is the default configuration when the app is configured to restrict access to certain websites. As a personal account exists in the app, the user is prompted to switch to the personal account to access the restricted site.
Figure 5: Transition restricted website to the personal account
And finally, with Scenario 8, the Azure AD account is given a choice to either open the restricted website in the personal account context or to open the website in the Azure AD account’s InPrivate context (assuming the organization has not disabled InPrivate).
Figure 6: Transition restricted website to either InPrivate or personal account
Hopefully, this information clears up how restricted websites are handled in Edge for iOS and Android. For more information on the settings discussed above or other app configuration settings available with Edge, see http://aka.ms/edgeappconfig.
As always, if you have any questions, please let us know.
Ross Smith IV
Principal Program Manager
Customer Experience Engineering