When last I dealt with this, the new "multiple user" support in Chrome did not exist, so the only available solution was to invoke Chrome with --enable-udd-profiles on the command-line. Things have since theoretically improved. Alas, in practice they've actually gotten worse. This post notes some steps taken locally to get working multiple Chrome instances on MacOS, with separate Dock icons, etc.
The solution chosen is not right for everyone. Chrome's defaults are probably right for casual computer users who keep all their windows on one desktop.
The basic problem is that with the multiple users, Chrome remembers which one was opened last; while probably useful for many, it creates problems when you use multiple desktops and place different conceptual topic areas in different desktops. For instance, on MacOS the old 2d "Spaces" concept is alive and well in Lion if you purchase TotalSpaces from BinaryAge. Having been using a 2d grid of desktops for 18 years now, the few days of trying to live without this was too painful and I leapt to spend money to get this back. So, one can maintain my work browser in the top left, work terminals to the right of that, messaging and communications in another area, ssh to a personal box with email on it in yet another area, and let longer-lived windows survive clustered in an area of the 2d grid, yet each foregrounded. This troll can mentally map the layout, navigate it and find his way around without consciously thinking about it, instead of having to look at the Alt-Tab list of apps and figure out how many times to tab to find an app and so get kicked out of the flow zone.
So, laying out a setup of browsers "fights" against a model where which UI you get depends upon which you had open last. Instead, for this workflow model, it's better to have multiple dock icons for starting the browser, in the different modes.
The very first pass was to create a new user profile, give it an icon and a visual theme. The only reason themes are useful to this troll is to be able to immediately identify the setup of the current browser window and know at a glance that this is a "Personal" browser, with an @gmail.com Google Id, because the browser borders are brown and the theme is "nature". No custom theme for "work" here, but later a dark blue with planets is the work theme.
The next pass, to have separate identities which can be placed, is thus to start Chrome with --profile-directory="Profile 1", dig out some notes and figure out how to create a new MacOS "application" which can be in the dock (details below, in the final believed-working version), simply to invoke a small shell wrapper. Find the alternative icon I'd chosen before for "personal", open the .ico with Preview, select-all, copy; then open the directory parent of the custom .app, select the app, Command-i to Get Info, select the icon in the top left, and paste the replacement in. (If you already have the app in the dock, “killall -v Dock” to get it to restart and use the new icon).
Everything is using the new custom profiles, everything is started from the command-line, everything appears to be working smoothly in simple tests and Google Chrome's new user profile support is an apparent win.
Alas, it soon becomes clear that when you click on a link in another application that clicking on the link has no effect.
Fortunately, the Unix influence on MacOS saves us, as there is a file “/var/log/system.log” with some diagnostic information:
<timestamp, machine> [0x0-0xd70d7].com.google.Chrome:
Unable to obtain profile lock.
It transpires that if Chrome was started with --profile-directory, then no other Chrome can successfully start, so opening links from other applications will fail. Sadness ensues.
After a couple of intermediate setups, which we'll skip, there are now three UDD profiles. Both personal and work usage get their own non-default profile with themes identifying them. Thus anything from clicking links in IM opens in an unthemed Chrome with no access to social network tracking cookies, no conflicts, and no ability to tie into work identity either (which would be the case it were only personal stuff using a non-default profile).
So we return to “--enable-udd-profiles --user-data-dir=...” to get completely different instances of Chrome. In a terminal, change directory to ~/Library/Application Support/Google/ and copy “Google” to “Google-Personal” and “Google-Employer”. Move the profile sub-directory to an appropriate name, for completeness, and edit “Local State” to reference the correct profile name.
$ mkdir -p ~/Applications/chrome-personal.app/Contents/MacOS
$ cd ~/Applications/chrome-personal.app/Contents/MacOS
$ cat > chrome-personal <<EOF
GOOGLE_CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
exec "$GOOGLE_CHROME" \
--enable-udd-profiles --user-data-dir="$USER_DIR" \
$ chmod 755 chrome-personal
Note that the problematic startup lock is managed in the $PROFILE_PARENT directory, with each --profile-directory being a child of that. The lock being unavailable if any instance of Chrome is running with a --profile-directory inside that profile parent seems like a bug (Chrome 19).
Beware that for Chrome, you must use “--long-opt=foo” and not “--long-opt foo”.
With the above example, open “~/Applications” in Finder, right-click the “chrome-personal.app”, choose Get Info, and use the version of the icon in the top left, the small one, as the target for copy/paste for icon replacement. This will create the file “~/Applications/chrome-personal.app/Icon\r” (with a literal Carriage Return character as part of the filename). Drag this to the Dock.
Repeat for the work variant.
Use no theming, no customisation for the normal Chrome instance and don't let that one get any cookies you care about. Treat it as “not incognito, but happy enough to blow the cookies away on a whim without being in for pain”. This is easier if you use a password manager such as 1Password or LastPass, with a browser plugin but with the passwords being external to the browser. Don't use Chrome's own sync, since that's tied to one account you're trying to avoid sharing between browser instances.
Themes here are really not about looking pretty, merely about being visually distinctive and just choosing the theme which is least annoying to look at.
-The Grumpy Troll