Ehcho.com

Disable Welcome to Google Chrome

By Morgan Rowe | 05 Oct 2015

When Google Chrome is opened for the first time your users will be prompted by a dialog window named Welcome to Google Chrome. The dialog window asks the user to confirm Chrome as their default browser and whether or not to send their diagnostic information to Google. Although your users can simply click "Start Google Chrome" and use Chrome normally, it's still a bit of a nuisance especially the same user is likely to see the pop-up each time they swap machine like in a 1:X or lab environment.

Disable Welcome to Google Chrome - Dialog window

You'd think there would be some sort of a option to negate this functionality. To the best of my knowledge, there's no way to do so using Chrome's system-wide or user property list files, or even using one of the extremely powerful Google Chrome Master Preferences options. There's even an open chromium-project ticket regarding the issue, but it doesn't look like the problem has been resolved yet.

However, you can get Chrome to never show the Welcome to Google Chrome dialog window by ensuring the folders ~/Library/Application Support/Google/Chrome/Default, and files ~/Library/Application Support/Google/Chrome/First Run and ~/Library/Application Support/Google/Chrome/Default/Preferences are present when Chrome opens. We don't even need to add anything to the First Run or Preferences file, just ensure they're present. It's worth noting that using this technique may have detrimental effects on the performance or stability of Google Chrome, but this solution has been deployed across a fleet of around 200 Macs for a number of months with no reports of any issues.

These files need to be present before Chrome launches and you might have noticed that the files need to be in the user's home folder. We have several options for making this happen, but the three I'm most comfortable using are LoginHooks, LaunchAgents and editing the User Template. LoginHooks are depreciated but still work really well. LaunchAgents are cool, but unreliable at doing tasks before the user is able to interact with the OS. The final option is putting the files into the User Template, which is the method we'll be going for today.

Using the User Template for this sort of task has two main concerns. The first is the fact we're editing the User Template itself. It is located within /System/Library/. We're not encouraged to modify any of the files within /System/ as they can be changed or deleted at any time without warning, sometimes during an OS update. You could write LaunchDaemons or use something like Puppet to ensure the files are always present in the User Template. The second concern is that the User Template is only used once—when the user account is generated during login. This means if you're trying to use this technique to modify existing user accounts, this isn't the option for you, but to be fair if the user has already logged in, they've probably dismissed Chrome's first run dialog box already.

I'm going to assume you want to deploy this 'hack' across a fleet of Macs, rather than just one, so we'll be writing a bash script to add the required files to the User Template that can be deployed using Remote Desktop, Munki or any of the other deployment tools out there. The most up to date script can be found within my blog's public repo on GitHub with comments and human readable white spacing, but if you want a quick copy of it, here is it:

#!/bin/bash

if [ "$(/usr/bin/id -u)" != 0 ]; then
	exit 0
fi

for userTemplatePath in "/System/Library/User Template"/*; do
	/bin/mkdir -p "${userTemplatePath}"/Library/Application\ Support/Google/Chrome/Default
	/usr/bin/touch "${userTemplatePath}"/Library/Application\ Support/Google/Chrome/First\ Run
	/usr/bin/touch "${userTemplatePath}"/Library/Application\ Support/Google/Chrome/Default/Preferences
	/usr/sbin/chown -R root:wheel "${userTemplatePath}"/Library/Application\ Support/Google
	/bin/chmod -R 700 "${userTemplatePath}"/Library/Application\ Support/Google
done

exit 0

In essence, the script loops through the localization files within User Template and creates the required folder structure for this 'hack' to work. It finishes up by ensuring the permissions are correct.

That's it! Use something like Payload-Free Package Creator to embed this bash script into a package and deploy it to your fleet of Macs.

Tested on Chrome 43-45 and OS X 10.10 - 10.10.5.