The following are additional considerations for Enterprise Browser version 1.0.
- Enterprise Browser can work with the Netskope Client on the same device.
- Account admins cannot add or modify Chromium specific policies.
- Admins can apply extension installation policies on two different levels, by product (by omitting the tenant name in the browser_config table) and at the tenant configuration level. When both product and tenant level configs are provided, the configuration defined for the tenant overwrites that specified at product level. No considerations for merging are made (restrictiveness or any other kind). For example, if all product level extensions are blocked by default (ExtensionInstallBlocklist = [“*“]) but only one is specified for the tenant (ExtensionInstallBlocklist = [“myext“]) then browsers configured for that tenant will be allowed to install any extension but “myext”.
- Usernames are not searchable when inviting users. Admins must enter the users complete full name.
- Enterprise Browser only steers HTTPS traffic to the Netskope cloud. Other protocols are not supported, e.g. HTTP or HTTP2 traffic with version 1.0.
- Browser_id is not enforced.
- Admins cannot force a specific version of the browser to install on tenants. The most current browser version will be installed.
- Some policy features are not supported with version 1.0, such as Policy Schedule and email notifications. Enterprise Browser policies are not evaluated for connections that are SSL bypassed.
- There are limits to length and the number of items for policy and related objects which includes:
- Name: max 128 chars
- Description: max 240 chars
- Apps: max 100 entries
- App Instances: max 100 entries
- Categories: max 100 entries
- Users: max 100 entries
- User Groups: max 100 entries
- OUs: max 100 entries
- Policies: max 8192 entries
- Enterprise Browser protection policies cannot be applied to all users. However as a workaround, admins can apply policies to groups containing all tenant users and associate policies to the groups of users.
- The relaunch notification policies are applied during browser initialization, based on the last value received. If a new value is received, it is not used until the browser is relaunched.
- Policies are not applied when a new user is added to a group/OU.
- Licenses are not automatically removed from a user when the user is deleted/deactivated from the IdP.
- If an admin deletes a user, data in the user’s machine will be deleted. No corporate remains in the user’s endpoint after the profile is deleted, minimizing the risk of data leakage (it’s a secure browser in an untrusted endpoint). The user will need a new license if they need to be added back, it will be a fresh install. That license won’t be valid anymore. The admin will need to generate a new license and share it with the user.
- MSI doesn’t fail if the profile creation fails. The MSI installer used in the MDM flow installs the browser and creates a user profile based on the provided license. If the profile creation step fails, the MSI ends successfully. The result of the profile creation step is stored in the registry so that it can be checked after running the MSI.