What is a “Chrome Enterprise Browser”?
A Chrome enterprise browser is just a regular Chrome Browser connected to a Google G Suite account.
It lets you deploy and manage Chrome Browser for your organization. It consists of a Chrome Browser and a set of admin tools, resources, and installer packages which allow an IT administrator to deploy and manage Chrome Browser in an enterprise environment. The admin tools allow administrators to configure, package, and deploy Chrome Browser at the system level, and manage policies on an ongoing basis.
What are Chrome Enterprise Policies and Preferences?
Having a Google G Suite account allows the admin to control a variety of features that will apply to each Google Account that is a part of the organization. Chrome Browser offers the user many configuration options and settings to personalize and enhance their web browsing experience. When deploying Chrome Browser, the administrator can control Chrome Browser default settings and policies using the following methods:
Policy:
A policy is a configuration for Chrome for security or productivity. It can be used to enforce and maintain settings on client computers. For example, you can enable auto-updates, and set the update interval, the default search engine, and the default browser.
Preferences:
Can be used to set the default value for particular setting, while still allowing the user flexibility to change the setting. For example, you can set the user’s default homepage to the company intranet, set the home button to display in their toolbar, or allow the bookmarks bar to display in the toolbar.
There are two ways to set up policies and preferences:
Manage on Premise:
It requires to set some Group Policy Objects (GPOs) on the actual machine Chrome is installed. It involves using a Windows Server to control and manage Windows computers.
A Windows Server with Active Directory Domain Services and Active Directory Users and Computers set up allows to use Group Policy to remotely manage users and computers.
Cloud-managed Chrome Browser:
This method consists on managing the Browsers only from a cloud admin console and does not require to set-up a Windows Server. There are two ways to set this up:
Policies set for users: Policies will only apply to browser signed in with a managed Google Account. It is therefore needed for the user to explicitly sign in. There is an option to forces users to sign in to Chrome Browser before they can use it.
A properly signed browser should have this message in the setting menu.
Policies set for enrolled browsers: Policies will apply to all the browsers regardless of the account being used. User do not even need to sign in. This is done so by generating an enrollment token using the Google Admin Console which is used to enforce policies for any users who open Chrome Browser on an enrolled device.
Chrome Enterprise Policies and WebRTC for Enterprise Mesh Networks.
In order to successfully match people within the same subnet to generate peer-peer connection, it is necessary to have a list of their IP addresses over which communication is possible.
However, your organization might have an internal set of IPs which are anonymized with mDNS as per the newer versions of Google Chrome require that WebRTC servers use anonymized addresses (i.e., mDNS hostnames) only.
For example, instead of allowing to send a media content to address 192.168.103.221, Google Chrome would instead give the address as 1bbabc05-80d2-4386-8e39-9666b53900d0.local. This ".local" address will resolve to 192.168.103.221, but only for systems on the same local subnet, and only on operating systems which support the mDNS protocol. Because the mDNS protocol registers addresses only on local networks, these random ".local" addresses reveal no information over the internet unless both the server and the client are on the same local network.
With this, it is not possible to know whether or not the two IP addresses are in the same subnet without getting the actual IP address instead of the mDNS hostnames. This causes a problem with Subnet Matching for eCDN since it relies on actual IP addresses to match the peers within a Subnet.
Solution
For Chrome versions 79 onwards, it is required to set up a policy (either on cloud or on premise) in order to reveal the local IP addresses that are otherwise concealed with mDNS hostnames to the WebRTC ICE candidates. This can be done by setting up WebRtcLocalIpsAllowedUrls.
This policy de-obfuscates the local IP for a certain list of origin and applies to all managed browsers.
If a match is found, the local IP addresses are shown in WebRTC ICE candidates. Otherwise, local IP addresses are concealed with mDNS hostnames.