Sometimes I just want to punch Google in the face
There are things I like about Google, and things I don’t like.
I like Android. I like Gmail (apart from the UI). Even though I use Bing as my default search engine, I still prefer Google’s image search. And there is no question that Google excel at both traditional web and cloud services.
One thing they do not excel at is desktop software. Particularly on Windows.
Mostly this is because they simply don’t know what they’re doing. Last year it was reported that Google were scrapping internal use of Windows entirely, but even before that, it was obvious they really had no idea how a Windows client/server network operates. Their software installers typically ignored even the most basic rules about where files should be stored, especially when it came to user profiles. On products like Google Earth and Sketchup, they’ve improved, but one product’s data storage model remains as badly designed as ever, and that’s Google Chrome.
Ironically, this is the one that they’ve put the most effort into getting ready for use on Windows networks. Just last month, Google made a big show of declaring that “Chrome is Ready for Business“, with a proper Windows .msi installer and even ADMX Group Policy templates. They’re one step ahead of Firefox, who rely on a third party distribution for the same functionality. Apple don’t even bother attempting Group Policy support in Safari, and just like all of Apple’s half-baked .msi installers, Safari won’t even deploy without low-level modifications to the setup database.
Sadly, despite being ahead, Chrome still falls short of being ‘ready for business’ on a Windows system. Just for starters, the .msi installer is actually a wrapper (breaking #2 of my 10 commandments) and therefore impossible to customise. Even changing the location of the shortcuts is impossible, and while we’re on the subject of shortcuts, it unceremoniously poops one onto the desktop the first time a user runs Chrome (commandment #5).
That would be bad enough except for the fact that due to a complete lack of understanding of how roaming profiles work, all the user data for Chrome is stored in the local part of the user’s AppData – not the roaming part. That means the settings are not carried over to a different computer when the user logs on elsewhere, which in a school network, happens all the bloody time. Cue desktop shortcut appearing again because Chrome thinks the user has never used it before. You could move the user data directory to the roaming profile with the -user-data-dir= command line option, but it has to be specified every time, and means that the browsing cache will also be stored in the roaming profile (the only data that should be in the local part). What’s more, when I tried doing this, Chrome wouldn’t even run.
The bug for this has been open for more than 2 years now.
Finally, as the icing on the cake, Google nags the user to make Chrome the default browser when they start the program. While the user can say “Don’t ask again”, such is Google’s conceit at the perfection of their browser that they don’t allow the administrator to suppress this prompt in their fabled Group Policy templates, leaving helpdesk staff having to deal with dozens of end users who just blindly clicked on ‘Yes’ without really knowing what they were doing. Again, you can suppress this with the -no-default-browser-check command line option, but it has to be specified every single time the program is run, so means modifying the shortcut on the Start Menu. Of course, the desktop shortcut Chrome creates for itself doesn’t include this option.