Chrome exposes a different set of configurations to administrators. These configurations are called policies and they give administrators more advanced controls than the standard users. With different device management tools, an administrator can deliver these policies to many users. Here is the help center article that talks about Chrome policy and its deployment.
This doc focus on how to design a new policy. More details about policy development can be found in the Chromium doc.
Not every single Chrome update needs to be guarded with a policy. In some cases, enterprise users can accept new features just like consumer users. However, consider adding new policy if
And if you are not sure, don’t hesitate to contact the Chrome enterprise team).
Similar to the switches on the chrome://settings page, enterprise policies are designed to provide options to our users to customize Chrome’s behaviors.
In some cases, a simple kill switch is a good starting point. It allows admins to force a feature they really need or block one that they can’t have due to privacy or security concerns. However, a boolean won’t always provide enough flexibility and may turn enterprise users away. In other words, providing granular control would be a better approach here. It allows enterprise users access to a feature while administrators can still meet all compatibility requirements. Sometimes, a policy can even be used to provide an enhanced version of the feature to enterprise users.
For example, ExtensionSettings allows admins to block extensions based on their permissions or update URLs while still giving users the ability to install extensions that they like and admins are comfortable with.
Another example is BrowserSignin policy which provides an additional force-sign-in feature which is not available for consumer users.
Think about CUJ(Critical User Journey), collect information to understand how administrators and enterprise users will use this feature. They can help you to design a policy.
Each Chrome policy must be defined in the Chromium code base which contains all metadata of a policy.
Policy name is a short phrase that briefly describes what the policy does.
Searching for a similar pattern from existing policies list is always a good strategy to find a good name. However, be careful about some ancient policies that were added a long time ago. We may already abandon those naming patterns, but keep the policies only because of backward compatibility. For example, SyncDisabled was added in Chrome 8, but we keep its name even though Disabled is banned.
There are 6 major types of policies, listed below.
This is the simplest policy type that defines 3 states: enabled, disabled and not set. Not-set should have the same behavior as consumer users.
Example: CloudReportingEnabled
A policy type provides more than 3 states for the admin to choose from.
Example: BrowserSignin
If multiple options can be chosen at the same time, use string-enum-list type.
Example: ExtensionAllowedTypes
A policy that accepts any integer as input. It can be used to define a period of time or size of a folder. The integer can't be negative and must be less than 2^32.
In most cases, there are two things to consider.
Unit:
The enterprise team used to use the minimum unit for policy to give enterprise more flexibility. However, that may require admin to put an unnecessary large number for certain policies which is error-prone.
Now we ask people to choose more proper units. For example, instead of milliseconds, hours may be a better choice, if most people won’t care about the differences between 1 hour and 59 minutes.
Example: CloudReportingUploadFrequency and DiskCacheSize
A policy that accepts any string as input.
Starting from this type, admin can put anything as policy input and error handling become more important.
Note that setting an empty string must be treated as not setting the policy due to the limitation of policy delivery mechanisms on some platforms.
Example HomepageLocation
A policy that accepts a list of strings as input.
Similar to string policy
In addition to that, depending on the policy implementation, setting a limitation is necessary when having too many list entries could cause performance issues. As an example, URLBlocklist policy only accepts 1000 URLs because we need to scan the list for every navigation request.
However, sometimes admins may want to set values more than what we can afford. In those cases, we will need to redesign the input format. For example, supporting wildcard characters is a common solution.
Example: URLBlocklist, ExtensionInstallAllowlist
URL list is a common format of list policy. It allows admins to apply policy only to certain websites or URLs.
Other than normal list policy, a few more considerations:
Another common format of list policies. It allows the admin to set exceptions for certain situations. Usually, we can create them as:
If more than one policy is defined for the same feature, please find a proper solution to resolve the conflict cases.
A policy that accepts a complex structure as input. Depending on the platforms, it could be a JSON string or XML files.
This is the most powerful and complicated policy format. A complicated dictionary policy may be hard for admins to understand and maintain. In many cases, splitting a dictionary configuration into multiple simple policies is a better approach.
Same as String and List policy, an empty dictionary must be treated as not setting the policy.
Also, a complicated dictionary policy may also contain conflict configurations. Make sure those cases are handled properly.
Example: ExtensionSettings
The default value defines Chrome’s behavior when policy is not set.
Always support as many platforms as possible. And unless there are good reasons, please launch a policy on all platforms at the same time.
If a setting is controlled by policy and UI at the same time, please make sure the UI is disabled when the policy is set with a proper message or UI element which tells end users that the option is controlled by their administrator.
Alert: There might be multiple UI entries, make sure all of them are covered.
Most of the time, there is no need to worry about the admin console UI. However, cover this section if your policy is complicated. Talk with the server team for more details. (Internal link, Googlers only)
If multiple policies are added at the same time or there are existing policies for the same feature, make sure all those policies won’t break each other.
Also, if multiple policies are created for the same topic, creating a new policy group can help admins find all related policies.
In some cases, we would like to replace one policy with a more powerful one. The old policy will be deprecated in this case. However, for the sake of backward compatibility, we still need to support the old one.
On the other hand, it’s always nice to think about future expansion when designing a policy. For example, if there is a chance we want to add more options to a policy, then enum type will be better than boolean.
Policy is a very powerful configuration tool that may bring additional security and privacy concerns. Talk with the Chrome privacy and Chrome security ahead of time if there is any concern.
Will bad actors be interested in your policy? The Enterprise team can provide additional management checks for the policy by marking it sensitive. But it may block admins from small companies which didn’t pay for expensive management systems. In other cases, limiting the ability of policy may also help.
We would like to protect end users’ privacy as much as we can while fulfilling admins’ requests. Another area that may need careful balance.
One major difference between policy launching and other features is that rollout control via experimental is not always an option. Majority of admins want their policies settings to apply to all devices they control.
Usually, policy must be ready and launched before the feature it controls rolls out.
In other cases, we can use trusted testers to test the policies for a small number of enterprise customers first. Talk with the Enterprise team for more details.
