For a customer project, I recently needed to take a closer look at best strategies of deploying Chromium settings to thrillions of client machines in a corporate network.
Unfortunately, the information on how to deploy site-wide Chromium
browser policies are a little scattered over the internet and the
intertwining of Chromium preferences and Chromium policies required
deeper introspection.
Here, I'd like to provide the result of that research, namely a list of references
that has been studied before setting up Chromium policies for the customer's proof-of-concept.
Difference between Preferences and Policies
Chromium can be controlled via preferences (mainly user preferences) and
administratively rolled-out policy files.
The difference between preferences and policies are explained here:
https://www.chromium.org/administrators/configuring-other-preferences
The site-admin (or distro package maintainer) can pre-configure the
user's Chromium experience via a master preferences file
(
/etc/chromium/master_preferences). This master preferences file is
the template for the user's preferences file and gets copied over into
the Chromium user profile folder on first browser start.
Note: By studying the recent Chromium code it was found out that
/etc/chromium/master_preferences is the legacy filename of the initial
preferences file. The new filename is
/etc/chromium/initial_preferences. We will continue with
master_preferences here as most Linux distributions still provide the
initial preferences via this file. Whereas the new filename is already
supported by Chromium in openSUSE/SLES, it is not yet support by Chromium
in Debian/Ubuntu. (See Debian bug
#992178).
Difference of 'managed' and 'recommended' Policies
The difference between 'managed' and 'recommended' Chromium policies is
explained here:
https://www.chromium.org/administrators/configuring-other-preferences
Quoting from above URL (last visited 2021/08):
Policies that should be
editable by the user are called "recommended policies" and offer a better
alternative than the master_preferences file. Their contents can be
changed and are respected as long as the user has not modified the value
of that preference themselves.
So, policies of type 'managed' override user preferences (and also lock
them in the Chromium settings UI). Those 'managed' policies are good for
enforcing browser settings. They can be blended in also for existing
browser user profiles. Policies ('managed'
and 'recommended') even get
blended it at browser run-time when modified.
Use case: e.g. for rolling out browser security settings that are
required for enforcing a site-policy-compliant browser user
configuration.
Policies of type 'recommended' have an impact on setting defaults of the
Chromium browser. They apply to already existing browser profiles, if the
user hasn't tweaked with the to-be-recommended settings, yet. Also, they
get applied at browser run-time.
However, if the user has already fiddled with such a to-be-recommended
setting via the Chromium settings UI, the user choice takes precedence
over the recommended policy.
Use case: Policies of type 'recommended' are good for long-term
adjustments to browser configuration options. Esp. if users don't touch
their browser settings much, 'recommended' policies are a good approach
for fine-tuning site-wide browser settings on user machines.
CAVEAT: While researching on this topic, two problematic observations were
made:
- All setting parameters put into the master preferences file
(
/etc/chromium/master_preferences) can't be superceded by
'recommended' Chromium policies. Pre-configured preferences are
handled as if the user has already tinkered with those preferences
in Chromium's settings UI. It also was discovered, that distributors
tend to overload /etc/chromium/master_preferences with their
best practice browser settings. Everything that is not required on
first browser start should be provided as 'recommended' policies,
already in the distribution packages for Chromium .
- There does not seem to be an elegant way to override the package
maintainer's choice of options in
/etc/chromium/master_preferences file via some file drop-in
replacement. (See Debian bug
#992179). So, deploying Chromium
involves post-install config file tinkering by hand, by script or by
config management tools. There is space for improvement here.
Managing Chromium Policy with Files
Chromium supports 'managed' policies and 'recommended' policies. Policies
get deployed as JSON files.
For Linux, this is explained here:
https://www.chromium.org/administrators/linux-quick-start
Note, that for Chromium, the policy files have to be placed into
/etc/chromium. The example on the above web page shows where to place them
for Google Chrome.
Good 'How to Get Started' Documentation for Chromium Policy Setups
This overview page provides a good get-started-documentation on how to
provision Chromium via policies:
https://www.chromium.org/administrators/configuring-policy-for-extensions
First-Run Preferences
It seems, not every setting can be tweaked via a Chromium policy. Esp.
the first-run preferences are affected by this:
https://www.chromium.org/developers/design-documents/first-run-customiza...
So, for tweaking the first-run settings, one needs to adjust
/etc/chromium/master_prefences (which is suboptimal, again see Debian
bug
#992179 for a detailed explanation
on why this is suboptimal).
The required adjustments to
master_preferences can be achieved with the
jq command line tool, here is one example:
# Tweak chromium's /etc/chromium/master_preferences file.
# First change: drop everything that can be provisioned via Chromium Policies.
# Rest of the changes: Adjust preferences for new users to our needs for all
# parameters that cannot be provisioned via Chromium Policies.
cat /etc/chromium/master_preferences \
jq 'del(.browser.show_home_button, .browser.check_default_browser, .homepage)'
jq '.first_run_tabs=[ "https://first-run.example.com/", "https://your-admin-faq.example.com" ]'
jq '.default_apps="noinstall"'
jq '.credentials_enable_service=false .credentials_enable_autosignin=false'
jq '.search.suggest_enabled=false'
jq '.distribution.import_bookmarks=false .distribution.verbose_logging=false .distribution.skip_first_run_ui=true'
jq '.distribution.create_all_shortcuts=true .distribution.suppress_first_run_default_browser_prompt=true'
cat > /etc/chromium/master_preferences.adapted
if [ -n "/etc/chromium/master_preferences.adapted" ]; then
mv /etc/chromium/master_preferences.adapted /etc/chromium/master_preferences
else
echo "WARNING (chromium tweaks): The file /etc/chromium/master_preferences.adapted was empty after tweaking."
echo " Leaving /etc/chromium/master_preferences untouched."
fi
The list of available (first-run and other) initial preferences can be found in Chromium's
pref_names.cc code file:
https://github.com/chromium/chromium/blob/main/chrome/common/pref_names.cc
List of Available Chromium Policies
The list of available Chromium policies used to be maintained in the Chromium wiki:
https://www.chromium.org/administrators/policy-list-3
However, that page these days redirects to the Google Chrome Enterprise
documentation:
https://chromeenterprise.google/policies/
Each policy variable has its own documentation page there. Please note
the "Supported Features" section for each policy item. There, you can
see, if the policy supports being placed into "recommended" and/or
"managed".
This is an example
/etc/chromium/policies/managed/50_browser-security.json file (note that all kinds of filenames are allowed, even files without .json suffix):
"HideWebStoreIcon": true,
"DefaultBrowserSettingEnabled": false,
"AlternateErrorPagesEnabled": false,
"AutofillAddressEnabled": false,
"AutofillCreditCardEnabled": false,
"NetworkPredictionOptions": 2,
"SafeBrowsingProtectionLevel": 0,
"PaymentMethodQueryEnabled": false,
"BrowserSignin": false,
And this is an example
/etc/chromium/policies/recommended/50_homepage.json file:
"ShowHomeButton": true,
"WelcomePageOnOSUpgradeEnabled": false,
"HomepageLocation": "https://www.example.com"
And for defining a custom search provider, I use
/etc/chromium/policies/recommended/60_searchprovider.json (here, I recommend not using DuckDuckGo as DefaultSearchProviderName, but some custom name; unfortunately, I did not find a policy parameter that simply selects an already existing search provider name as the default :-( ):
"DefaultSearchProviderEnabled": true,
"DefaultSearchProviderName": "DuckDuckGo used by Example.com",
"DefaultSearchProviderIconURL": "https://duckduckgo.com/favicon.ico",
"DefaultSearchProviderEncodings": ["UTF-8"],
"DefaultSearchProviderSearchURL": "https://duckduckgo.com/?q= searchTerms ",
"DefaultSearchProviderSuggestURL": "https://duckduckgo.com/ac/?q= searchTerms &type=list",
"DefaultSearchProviderNewTabURL": "https://duckduckgo.com/chrome_newtab"
The Essence and Recommendations
On first startup, Chromium copies
/etc/chromium/master_preferences to
$HOME/.config/chromium/Default/Preferences. It does this only if the
Chromium user profile has'nt been created, yet.
So, settings put into
master_preferences by the distro and the site
or device admin are one-time-shot preferences (new user logs into a
device, preferences get applied on first start of Chromium). Chromium
policy files, however, get continuously applied at browser runtime.
Chromium watches its policy files and you can observe Chromium settings
change when policy files get modified.
So, for continuously provisioning site-wide settings that mostly always
trickle into the user's browser configuration, Chromium policies should
definitely be preferred over
master_preferences and this should be
the approach to take.
When using Chromium policies, one needs to take into account that
settings in
/etc/chromium/master_preferences seem to have
precedence over 'recommended' policies. So, settings that you want to
deploy as recommended policies
must be removed from
/etc/chromium/master_preferences.
Essentially, these are the recommendations extracted from all the above
research and information for deploying Chromium on enterprise scale:
- Everything that's required at first-run should go into
/etc/chromium/master_preferences.
- Everything that's not required at first-run should be removed from
/etc/chromium/master_preferences.
- Everything that's deployable as a Chromium policy should be deployed as a policy (as
you can influence existing browser sessions with that, also long-term)
- Chromium policy files should be split up into several files.
Chromium parses those files in alpha-numerical order. If policies occur
more than once, the last policy being parsed takes precedence.
Feedback
If you have any feedback or input on this post, I'd be happy to hear it. Please get in touch via the various channels where I am known as sunweaver (OFTC and libera.chat IRC, [matrix], Mastodon, E-Mail at debian.org, etc.). Looking forward to hearing from you. Thanks!
light+love
Mike Gabriel (aka sunweaver)
On Saturday 28 August 2021, the annual Debian Developers
and Contributors Conference came to a close.
DebConf21 has been held online for the second time, due to the coronavirus
(COVID-19) disease pandemic.
All of the sessions have been streamed, with a variety of ways of participating:
via IRC messaging, online collaborative text documents,
and video conferencing meeting rooms.
With 740 registered attendees from more than 15 different countries and a
total of over 70 event talks, discussion sessions,
Birds of a Feather (BoF) gatherings and other activities,
DebConf21 was a large success.
The setup made for former online events involving Jitsi, OBS,
Voctomix, SReview, nginx, Etherpad, a web-based
frontend for voctomix has been improved and used for DebConf21 successfully.
All components of the video infrastructure are free software, and configured through the
Video Team's public ansible repository.
The DebConf21 schedule included
a wide variety of events, grouped in several tracks:
Debian 11 (codename Bullseye) was recently released. This was the smoothest upgrade I've experienced in some 20 years as a Debian user. In my haste, I completely forgot to first upgrade dpkg and apt, doing a straight dist-upgrade. Nonetheless, everything worked out of the box. No unresolved dependency cycles. Via my last-mile Gigabit connection, it took about 5 minutes to upgrade and reboot. Congratulations to everyone who made this possible!
Since the upgrade, only a handful of bugs were found. I filed bug reports. Over these past few days, maintainers have started responding. In once particular case, my report exposed a CVE caused by copy-pasted code between two similar packages. The source package fixed their code to something more secure a few years ago, while the destination package missed it. The situation has been brought to Debian's security team's attention and should be fixed over the next few days.
Afterthoughts
Having recently experienced hard-disk problems on my main desktop, upgrading to Bullseye made me revisit a few issues. One of these was the possibility of transiting to BTRFS. Last time I investigated the possibility was back when Ubuntu briefly switched their default filesystem to BRTFS. Back then, my feeling was that BRTFS wasn't ready for mainstream. For instance, the utility to convert an EXT2/3/4 partition to BTRFS corrupted the end of the partition. No thanks. However, in recent years, many large-scale online services have migrated to BRTFS and seem to be extremely happy with the result. Additionally, Linux kernel 5 added useful features such as background defragmentation. This got me pondering whether now would be a good time to migrate to BRTFS. Sadly it seems that the stock kernel shipping with Bullseye doesn't have any of these advanced features enabled in its configuration. Oh well.
Geode
The only point that has become problematic is my Geode hosts. For one things, upstream Rust maintainers have decided to ignore the fact that i686 is a specification and arbitrarily added compiler flags for more recent x86-32 CPUs to their i686 target. While Debian Rust maintainers have purposely downgraded the target, RustC still produces binaries that the Geode LX (essentially an i686 without PAE) cannot process. This affects fairly basic packages such as librsvg, which breaks SVG image support for a number of dependencies. Additionally, there's been persistent problems with systemd crashing on my Geode hosts whenever daemon-reload is issued. Then, a few days ago, problems started occurring with C++ binaries, because GCC-11 upstream enabled flags for more recent CPUs in their default i686 target. While I realize that SSE and similar recent CPU features produce better binaries, I cannot help but feel that treating CPU targets as anything else than a specification is a mistake. i686 is a specification. It is not a generic equivalent to x86-32.
A new release 0.4.13 of 
DebConf21 is taking place online, from 24 August to 28 August 2021.
It is the 22nd Debian conference, and organizers and participants are working hard
together at creating interesting and fruitful events.
We would like to warmly welcome the 19 sponsors of DebConf21, and introduce them to you.
We have five Platinum sponsors.
Our first Platinum sponsor is 
Two months ago was my last day of working as an employee for DFINITY, and as I mentioned in 
The Interface Specification as a book
So today is the day when a new Debian release comes out!
Congratulations to everybody, and thanks a lot mainly to the Release
Team. Lots of very hard work was put into making Debian 11 Bullseye
a reality!
My very personal way to celebrate this was to do a somewhat different
Debian install at home. Why different? Well, I have quite a bit of
old, older and frankly elderly laptops at home. And as many of you
know, I have done more than 
Several issues were brought before the Debian Community team regarding responsiveness, tone, and needed software updates to 
If I have seen further, it is by standing on the shoulders of Giants Issac Newton, 1675. Although it should be credited to 12th century Bernard of Chartres. You will know why I have shared this, probably at the beginning of Civil Aviation history itself.
But yes, it needs it own space, maybe after some more time.
When you re accessing services over the WEB let s pick GMail as an example couple of things have to happen upfront:
The server you re connecting to (GMail in our example) has to get to know who you are. Only after getting to know who you are it s able to decide what resources you are allowed to access (e.g. your own email inbox, your Calendar, Drive etc.). Step 1 above is called authentication.