Tag Archive

Deploying default Chrome settings to Macs

Posted on July 27, 2022 by alanysiu

You can, of course, manage certain Chrome settings via Google Workspace Admin, but what if you don’t want to manage things like the homepage, but you just want to set defaults for new deployments, and you still want users to be able to change those settings later?

Google has something called an Initial Preferences file (what they used to call Master Preferences).

Exact details are in Use initial preferences for Chrome browser (including the download link for the sample preferences file), with more details in Configuring Other Preferences on the actual preferences.


First, you’ll download the sample preferences file from Use initial preferences for Chrome browser.


It may download with the name master_preferences.


Go ahead and rename that to be Google Chrome Initial Preferences.


Once it’s renamed, you’ll want to edit it to be how you want it. More details are in Configuring Other Preferences on the actual preferences.


You’re going to deploy that modified Google Chrome Initial Preferences file to the /Library/Google folder, using something like munkipkg, Packages, or (if you’re deep into Jamf-land) Composer.


So when it’s landed on the client Mac, the file should appear in the full path of /Library/Google/Google Chrome Initial Preferences.

These initial settings will apply to new accounts or accounts that have never launched Chrome. If you deploy it to a Mac with an account that has launched and set up Chrome already, that account’s Chrome existing settings won’t change.

0

Chrome mid-update versions and Munki

Posted on March 17, 2021 by alanysiu

Most of the time, if you want to patch Chrome using Munki, you just use add Chrome as a managed update or managed install to the relevant manifests in your Munki repo, and then have the AutoPkg Chrome.munki recipe import the new version of Chrome into your Munki repo from time to time (daily, weekly, etc.).

And, most of the time, that isn’t an issue. Munki checks to see if the Chrome installed is the latest version, and then prompts to update if the latest version isn’t installed. That said, if Chrome is the primary browser your user is using, Chrome is likely open all the time, and you probably have it as a blocking application, which is better than just force-updating it while a user is using Chrome, which could result in corruption and/or a bad user experience.

The trick, though, is if you have Chrome’s built-in updater present (some Munki admins remove the built-in updater so Munki is the sole manager of Chrome updates), the built-in updater may update the version in /Applications/Google Chrome.app/Contents/Info.plist, and so Munki may think the new version is installed, even if the new version isn’t running.

So how do you know what version of Chrome is running?

Kudos to Justin Holt for pointing me to a script Graham Gilbert (kudos to Graham, too) wrote for chrome_update_notifier that detects the actual running version.

I’ve adapted that code to a Munki installcheck_script (sample pkginfo here), so Munki will prompt for an update even if the “installed” version is up to date but the running version is still the old version—especially handy if you’re trying to use the force_install_after_date flag in your pkginfo file for particularly urgent Chrome vulnerabilities.

2

Using a Munki nopkg to disable Chrome 80’s ScrollToTextFragment feature

Posted on March 4, 2020 by alanysiu

Update, 14 July 2020

With Chrome 84, Google has now removed the ability to disable the ScrollToTextFragment feature, so this whole write-up is now obsolete

What is ScrollToTextFragment

With Chrome 80, Google has introduced a new ScrollToTextFragment feature that allows you to reference an anchor link by any phrase that’s in a webpage, even if the author of the page hasn’t created an anchor link.

You can see this setting by going to chrome://flags in your Chrome browser (assuming you’re using version 80+).


By default, Chrome 80 has the setting enabled.


And, for example, you can create a direct link to the Recent Posts part of my blog by just appending #:~:text=Recent%20Posts to the end of the website URL.


If you disable this setting, however, the regular old webpage behavior returns.


So visiting the URL with that appended part will do nothing but show you the top of the webpage.

Why might you want to disable ScrollToTextFragment?

David Bokan (from Chromium, the open source project Chrome is based on) wrote up a Google Doc called Scroll-to-text Fragment Navigation – Security Issues (PUBLIC) that explains some potential issues.

How can I automate disabling ScrollToTextFragment?

Well, as of this writing (March, 2020), there doesn’t appear to be a way you can disable this via policy, so the best way I’ve come across to do so is via script. It’s a bit convoluted, but it works—here’s my Munki nopkg for disabling ScrollToTextFragment.

Because changing that setting requires a relaunch of Chrome, the nopkg has GoogleChrome as a blocking application, which means if you want to enforce this, you may have to add a force_install_after_date key to the pkginfo, because the chances that your users will see a pending Managed Software Center update, quit of Chrome, install the update, and then launch up Chrome again are probably fairly low.

0

Forcing updates to Google Chrome using Chrome preferences / a Chrome profile

Posted on November 24, 2019 by alanysiu

Why use Chrome relaunch notification instead of Munki

I’m a huge fan of using Munki to patch software on macOS, but Munki is generally polite—it usually won’t kill an application while the user is using it. There is an option in Munki to force an install after a certain date, but that will log the user out of her computer completely in order to install whatever item you set as a forced install.

The actual preferences for Chrome relaunch notification

If you want to just have Chrome update to the latest version without logging out the user, but you want to force that to happen (say, if there’s a fairly serious zero-day security vulnerability), you can use Chrome preferences to do so:

defaults write com.google.Chrome RelaunchNotification -int 2

defaults write com.google.Chrome RelaunchNotificationPeriod -int 3600000

The first command forces a relaunch instead of just recommending one. The second one gives the period of time (in milliseconds) the user has before the relaunch happens.

Using a profile instead of commands to manage the preferences

Those commands probably aren’t something you want to run at scale. You’d want to use that as a quick test, and then you could deploy those settings as a .mobileconfig profile, which you can use mcxToProfile to do. You can also apparently use ProfileCreator to do so as well (using ProfileManifests), but I haven’t fully explored that yet. And, if you’re a Jamf user, you can use plutil -convert xml1 to use custom settings for a Jamf-created profile.

Deploy (and undeploy) thoughtfully

I’m going to give a major caveat that, unless you want to perpetually annoy your users, you probably don’t want to have this profile installed all the time, because it means every single time there’s a Chrome update (and Google does update Chrome quite frequently), your users will have only an hour (or whatever time period you set for RelaunchNotificationPeriod) to relaunch Chrome. Not all Chrome updates are immediately critical, so use this obnoxious “you must relaunch” Chrome policy judiciously.

What your users will see

This is the type of warning users will see:

Will users lose their open tabs?

I can’t say definitively, because the functionality may change in the future, but as of the writing of this blog post (late November, 2019), even if users have not set Continue where you left off, this forced relaunch will, in fact, re-open the tabs that were open before:

Um, test for yourself, obviously. You don’t want to have a bunch of angry users. You could, alternatively, have your .mobileconfig profile manage the RestoreOnStartup preference.

What’s the actual user experience like for the restart?

In my testing, it seems the 6-minute warning is the last one you can dismiss, and then when it’s ready to relaunch to install the update, Chrome gives absolutely no notification that the relaunch is happening when it happens. Chrome just closes out and then relaunches.

Further reading

More details at Google’s Notify users to restart to apply pending updates.

Even more technical details at Chrome Enterprise policy list.

1