Wednesday 2 December 2009

Chrome OS - What is Google doing?

Well... Chromium OS is out!
As usual, it has been released by Google in the classic "Beta" style.
As they did with Google Android, but having a different target: trying to get experience in a field  in which the company has never landed.
They're also trying to obtain some percentage of market, to annoy main competitors, getting published in a lot of newspapers and so on (read it as free advertising).
I had no time to test it, but all I can see is an increasingly interest of developers on checking it out, rebuilding and trying it in a virtualized machine.




It surely lacks in hardware support and configuration.
BUT a lot of people are remarking one thing: if the operating system is a safe and secured environment, nowadays all the activities can be performed via browser, in the cloud.
Better if Google switches users in the
Google made ChromiumOS (the correct way to say it should be: "placed together different open source projects and glued them by using their IP and ideas") announcing a secure operating system.
Schneier in this article said it was an "idiotic claim". Well... Maybe they wanted to say that the newborn OS, being Linux derived, will have less problems than Microsoft counterpart.
There's a page in the ChromiumOS Project website, in which Google tries to explain how security is implemented.
I'm quoting a part of it:

The perfect is the enemy of the good.  No security solution is ever perfect.  Mistakes will be made, there will be unforeseen interactions between multiple complex systems that create security holes, and there will be vulnerabilities that aren't caught by pre-release testing.  Thus, we must not allow our search for some mythical perfect system to stop us from shipping something that is still very good.
Deploy defenses in depth.  In light of our first principle, we will deploy a variety of defenses to act as a series of stumbling blocks for the attacker.  We will make it hard to get into the system, but assume that the attacker will.  We'll put another layer of defenses in place to make it difficult to turn a user account compromise into root or a kernel exploit.  Then, we'll also make it difficult for an attacker to persist his presence on the system by preventing him from adding an account, installing services, or re-compromising the system after reboot.
Make it secure by default.  Being safe is not an advanced or optional feature.  Until now, the security community has had to deploy solutions that cope with arbitrary software running on users' machines; as a result, these solutions have often cost the user in terms of system performance or ease-of-use.  Since we have the advantage of knowing which software should be running on the device at all times, we should be better able to deploy solutions that leave the user's machine humming along nicely.
Don't scapegoat our users.  In real life, people assess their risk all the time.  The Web is really a huge set of intertwined, semi-compatible implementations of overlapping standards.  Unsurprisingly, it is difficult to make accurate judgments about one's level of risk in the face of such complexity, and that is not our users' fault.  We're working to figure out the right signals to send our users, so that we can keep them informed, ask fewer questions, require them to make decisions only about things they comprehend, and be sure that we fail-safe if they don't understand a choice and just want to click and make it go away.

They are using sandboxing techniques and they will try to apply it even at lower operating system layers (such as drivers).

No comments: