04 September 2008

Not ready for (corporate) prime time

Since Google launched the Beta version of their Chrome browser - it's about 72 hours ago but it feels like a lot longer - we've been getting people asking why we've blocked its download to our corporate network.

The short answer is "because it's not suitable". Sure, it looks great, has better security, Javascript runs fast, etc etc. But it seems like no thought has gone into how one might go about deploying it in a business setting.

First, the only way to get it is by interacting with Google's download site. You get a small installer executable, which then goes back to Google and downloads the rest. During this time, you sit and watch. Is it installing the same code as yesterday? How can you tell? Until we can see a single .MSI file, with the usual command-line parameters allowing for totally silent installation, we can't use this.

Secondly, have you taken a look at where the installer leaves all the files which make up the browser? Well, most of them are in the profile of the user who downloaded it. On an out-of-the-box version of XP this means that your Web browser is in C:\Documents and Settings\username\Local Settings\etc etc etc. This is a disaster in many corporate environments which use roaming profiles, because they typically have fairly strict retention policies about how long old profile copies are allowed to remain on PCs. Although it could have been worse (Chrome could have installed into some other directory at the top of the profile rather than "Local Settings", thus entering the roaming part of the profile and being copied to the server when you log off), this means that in practice you're going to have multiple copies of the browser per PC, but with each individual user losing access to it every time the local profile copy is cleaned.

I wish that this was the first time we'd seen this sort of problem, but it isn't. Although "consumer" products (such as the iPhone and iPod, or any Google application you can name) tend to be the worst offenders in terms of treating your entire PC as if they own it, some business software publishers are not far behind. I hope the person who decided to place Adobe Bridge's file cache in the roaming part of the user profile is reading this.

In mitigation, perhaps I should mention that it took Microsoft about 6 years from the release of Windows NT 4.0 to get their programmers to understand the consequences of roaming profiles. Most MS products now do the right thing, although some are still quick to impose their own view of the world on "User Shell Folders" registry entries if the network is a little slow, with potentially "hilarious" consequences for unsuspecting users who didn't realise that all their new documents are being chucked into an unbacked-up directory on the local hard disk instead of their network drive.

No comments:

Post a Comment