carlodaffara.conecta.it

Finally, after much delays, Google has presented its second operating system after Android: ChromeOS. Actually, it is not that new- developers already had full access of the development source code, and I had already the opportunity to write about it in the past; Hexxeh made quite a name for himself by offering a USB image that is bootable on more systems, and providing a daily build service to help others try it at home. Google launched a parallel pilot program, delivering to many lucky US citizens an unbranded laptop (called Cr-48) preloaded with the latest build of ChromeOS; initial reports are not overall enthusiastic, due to problems with the Flash plugin and trackpad responsiveness to gestures; in general, many of the initial adopter are perplexed about the real value of such a proposition. And the explanation is simple: it’s not for them.

The reality is that ChromeOS is a quite imaginative play designed to enter the enterprise market – and has nothing to do with consumers, or at least it does have only limited impact there. Let’s forget for a moment the fact that the system does have many, many shortcomings and little problems (like the fact that sometimes you are exposed to the internal file system, for example, or that the system is still not fully optimized, or that the hardware support is abysmal). Many observers already commented on the device itself, like Joe Wilcox, Mary Jo Foley or Chris Dawson; what I would like to add is that Google is using the seed devices to collect end user experiences to focus the remaining development effort to create what in the end will be a different approach to enterprise computing – not for consumers. It is not about thin clients: the economics of such devices has always been difficult to justify, with the substantial expenditure in servers and infrastructure; just look at the new refreshment of the concept, in the form of VDI, and despite the hotness of the field, actual deployments are still limited.

Web-based applications change this economics: the only thing that needs to be delivered to the client is the payload (the page, js files, images, and so on), data persistence and identity (authentication, authorization and accounting). All three can be done in an extremely efficient way; the cost per user is one or two orders of magnitude smaller than traditional thin client backends or VDI. It is true that not all apps are web applications, but I believe that Google is making a bet, based on the great uptake of modern web toolkits, javascript and metacompilers like GWT. For those apps that cannot be replaced, Citrix is providing a very nice implementation of their Receiver app – giving a full, uncompromised user experience directly in the browser.

Let’s consider what advantages does this approach bring to the enterprise:

• Activation: you don’t need an engineer to deploy a ChromeOS machine. Actually, anyone can do it, and without the need for any complex deployment server, initial authentication or activation keys. It works everywhere there is a form of connectivity, and as soon as you have completed it, your desktop environment is ready with all the links and apps already in place. It means: no need for large helpdesks (a limited support line is sufficient); no need to fiddle with apps or virtualization desktop layers, you can do it from an hotel room… everywhere you are. Your machine stop working? You activate another.
• Management: There is no machine management – all activities are based on the login identity, and machines are basically shells that provide the execution capabilities. It means that things like hardware and software inventories will not be necessary anymore, along with patch deployment, app supervision, and all those nice enterprise platform management things that add quite a lot of money to the IT licensing budgeted costs.
• Security: Since there are no additional apps installable, it is much easier to check for compliance and security. You basically have to log every web transaction on your web app-which is fairly easy. There is still one area that is uncovered (actually, not covered in any current commercial operating system…) that is information labelling, and I will mention it later in the “still to do” area.

So, basically ChromeOS tries to push a model of computation that is based on something like 90% of apps as web-based applications, that use local resources for computation and the browser as the main interface; and the remaining 10% through bitmap remotization like Citrix (I bet that it will not take much time to see VMware View as well). To fulfil this scenario Google still needs quite some work:

• They need to find a way to bring ChromeOS to more machines. If the enterprise already has its own PCs, they will not throw them out of the window. The ideal thing would be to make it a bootable USB image, like we did for our own EveryDesk, or make an embeddable image like SplashTop. The amount of reinvention of the wheel that is coming with ChromeOS is actually appalling – come on, we did most of those things year ago.
• Google has to substantially improve management of the individual ChromeOS data and app instances. There must be a way for an enterprise to allow for remote control of what apps can and cannot be installed, for example – to preload a user with the internal links and data shared to all. At the moment there is nothing in this area, and I suspect that it is better for them to develop something *before* initial enterprise enrolments. Come on, Google, you cannot count only on external developers for filling this gap.
• The browser must implement multilevel security labels. That means that each app and web domain must have a label, cryptographically signed, to claim what “level” of security is implemented, and how information can flow in and out. For example, it must prevent secure information from the ERP application to be copied into FaceBook, or securely partition different domains. A very good example of this was the Sun JDS trusted extensions, unfortunately defunct like JDS itself. This is actually fairly easy to implement in the browser, as the only application that can access external resources and copy and paste between them – and Chrome already uses sandboxing, that can be used as basis for such a label-based containment. This would give a substantial advantage to ChromeOS, and would open up many additional markets in areas like financials, banking, law enforcement and government.

So, after all, I think that Google is onto something, that this “something” needs work to mature before it can be brought to the market, and that the model it proposes is totally different from what we have up to now. Noone knows if it will be successful (remember the iPad? Its failure was nearly assured by pundits worldwide…) but at least it’s not a boring new PC.