[lk] The Cr-48 and Chrome OS: Google's vision of the net [LWN.net]

[Peter Teoh]

This is a good read..... http://lwn.net/Articles/423002/ The Cr-48 and Chrome OS: Google's vision of the net By Jonathan Corbet January 18, 2011 The Cr-48 is, according to Google, the "first of its kind - a notebook built and optimized for the web." It is the next step in the promotion of Chrome OS, Google's other Linux-based distribution. As a way of showing off what it has accomplished and building interest in the system, Google has distributed Cr-48 machines widely. Your editor was a lucky, if late, recipient of one of these devices; what follows are his impressions after some time playing with it. The Cr-48 and Chrome OS are an interesting vision of where computing should go, even if that vision is not for everybody. The hardware itself is quite nice at a first glance. This machine is not a netbook; it is a small notebook device which clearly has taken some inspiration from Apple's hardware. Except, of course, that Apple's machines are not jet black, with no logos or markings of any type. It exudes a sort of Clarke-ian "2001 monolith" feel. There's an Intel Atom dual-core processor, 2GB of memory, and a 16GB solid-state drive. The silence of the device is quite pleasing; also pleasing is the built-in 3G modem with 100MB/month of free traffic by way of Verizon (which, unsurprisingly, is more than prepared to sell you more bandwidth once that runs out). Other connectivity includes WiFi and Bluetooth (though there appears to be no way to use the latter); there is no wired Ethernet port. There's a single USB port, an audio port, a monitor port, and what appears to be an SD card reader. Battery life is said to be about eight hours. Despite the small disk, it's a slick piece of hardware. Using Chrome OS The operating system and the hardware work nicely together. A cold boot takes a little over ten seconds; suspend and resume are almost instantaneous. In normal use, one simply lifts the lid and the system is ready to go; by default, the system does not even request a password at resume time if somebody is logged in - a setting that security-conscious users may want to change. There is a large trackpad with some simple multitouch capability. Interestingly, there is no "caps lock" key; Google, in its wisdom, replaced it with a "search" key. Happily, Google was also wise enough to allow the key to be remapped by the user; it can be restored to caps lock or, instead, as $DEITY intended, set to be a control key. Where one would expect to find the function keys are more web-centric buttons: Google has dedicated keys to operations like "back," "forward," and "reload." Of course, they're really just function keys underneath as far as the X server is concerned. The system software is Linux-based, of course, but there's no way for a casual user to notice that. The core idea behind Chrome OS is that anything of interest can be had by way of a web browser, so that's all you get. Like an Android phone, the system starts by asking for the user's Google account; everything after that is tied to that account. Email is to be done via GMail (there appears to be no way to read mail directly from an IMAP server), document editing with Google Docs, conferencing with Google Talk, and so on. Like an Android phone, a Chrome OS device is meant to be a portable front-end to Google-based services. That is why the Cr-48 comes with such a small SSD; very little is stored there beyond the operating system image itself, and that image is small. Most of the space, in fact, is set aside for a local cache, but it's entirely disposable; everything of interest lives in the Google "cloud." So if, as the startup tutorial says, the device succumbs to an "unexpected steamroller attack," nothing is lost except the hardware. The user can sign onto a new device and everything will be there. The appeal of this arrangement is clear: no backups, no lost data, no hassles upgrading to a new machine. Just browse the web and let Google worry about all the details. Of course, there are some costs; the Cr-48 can do almost nothing which cannot be done via the web. There is no way to get a shell (though see below) and no way to install Linux applications. Even updates are out of the user's hands: they happen when the Chrome OS Gods determine that the time is right. There is a "web store" where browser-based applications can be had. At this time there is a surprising variety of them, almost all of which are free of charge. The application selection still falls far short of what is available with a standard Linux distribution or on Android, though. It's also not at all clear how many (if any) of these applications are actually free software. The "no local installations" philosophy means that Chrome browser plugins (which hook into the browser at a lower level than "applications" do) cannot be installed; that, in turn, means that any application which requires a plugin, while usable on regular Linux or Windows, is not installable on Chrome OS. It turns out that quite a few web store applications need plugins; annoyingly, the only way to find out if any given application can be installed is to try. Your editor wanted to take a screenshot or two of the system in operation. The store offers a few screenshot applications, one provided by Google itself. The Google tool, though, needs a plugin and thus refused to install. An alternative application did install, but the "save" button, needing a plugin, was not able to save the result anywhere. The application could, though, "share" the screenshot through any of a number of web services - though the image itself (to your editor's surprise) is stored on the web site of the company providing the screenshot application. Something as simple as taking a screenshot should not be so hard - and it should not broadcast screenshots to the world by default. Under the hood The Cr-48 is a locked-down system. Its firmware will only load Google-signed images, so it's not possible for the user to make any changes. The root filesystem is mounted read-only. The whole verified boot mechanism is designed to ensure that the device's software has not been compromised and that the user can trust it. That said, the design goals are also expressed this way: It is important to note that restraining the boot path to only Chromium-project-supplied code is not a goal. The focus is to ensure that when code is run that is not provided for or maintained by upstream, that the user will have the option to immediately reset the device to a known-good state. Along these lines, there is no dependence on remote attestation or other external authorization. Users will always own their computers. The way this works on the Cr-48 is through a "developer switch," which is cleverly hidden behind a piece of tape inside the battery compartment. The instructions describe a lengthy series of events that will happen when that switch is flipped, including a special warning screen and a five-minute delay while the system cleans up any personal data which may be cached locally. What actually happened was a warning that the system is corrupted; hitting control-D at that screen did manage to boot the system into the developer mode, though. Developer mode looks much like the regular operating mode with one exception: the other virtual consoles are now enabled, allowing the user to get to a shell and explore the system a bit. The system, it turns out, is based on a 2.6.32.23 kernel; it's said to be based on Ubuntu Gentoo, but any such parentage is hard to find. It uses the trusted platform module for integrity measurement, but it does not appear to be using the IMA or EVM modules shipped with the mainline kernel. The devtmpfs filesystem is used to populate /dev. The system uses the ext3 filesystem for local data storage. There are two sets of root filesystem partitions; one is in use while updates are loaded into the other. It also uses eCryptfs to store user-specific data; in theory that means that such data is safe from prying eyes when the user is not actually logged into the system. Given access to developer mode, one can go as far as installing an entirely new operating system on the device. The instructions for doing so are intimidating at best, though; Google has not gone out of its way to make displacing Chrome OS easy. Your editor will probably give it a try at some point, but the job did not look like something which could be done within any sort of deadline. It sure would have been nice if the system could just boot from an external device. What it's good for The appeal of a system like this is easy enough to understand. Here is a computer which can access all kinds of web-based services, never needs to be backed up, is highly malware-resistant, and which can be easily replaced. It could be handed to one's children with minimal fear of the consequences, and it is easily operated by people who are intimidated by any sort of system management task. A Chrome OS device is the contemporary equivalent of an X terminal; it is little more than a window into services which are managed elsewhere. Your editor, who is not afraid to break manage his systems, and who prefers more control over his data, does not find this approach to computing to be hugely attractive. It is not useful for software development at all, and the things it can do are contingent on having network access. Google Docs might be able to handle a presentation, but the idea of depending on a conference network to be able to give a talk is frightening. There are those of us who will always want our systems to be more self-contained and locally controlled. That said, such machines are not without their applications. Thousands of people, it seems, have had their laptops searched at the US border; your editor, who crosses that border frequently, has not, yet, had that experience. Should it ever come to pass, it might be nice to have a laptop which contains no local data at all. A throwaway Google account could be used for plausible deniability, and, in the unlikely case of a border agent who knows about the developer switch, any user-specific data on the system (which is encrypted anyway) should be gone by the time it becomes accessible. "Data in the cloud" systems have security concerns of their own (it would be nice if a Chrome OS system could be backed up by providers other than Google, for example), but there are times when having all of one's data be elsewhere can be comforting. The locked-down nature of Chrome OS is thus not without its value, but locked-down is only good as long as the owner wants things that way. The Chrome OS documentation suggests that Google wants all devices to include a developer switch. In the real world, it would be unsurprising if some vendors somehow never quite got around to adding that switch. Without full access, one of these laptops becomes something more like a television: useful for displaying content, but something short of a real computer. Chrome OS is clearly not meant to be a "real computer" of the sort that LWN readers are likely to want. The target user base is different, to say the least. As such, it is an interesting exercise in what can be done to package Linux for other classes of users. At the beginning of the year, your editor predicted that Chrome OS would struggle; who wants such a limited system when a real computer can be so easily had? Based on this experience, your editor is not quite ready to change his mind, but he is willing to admit that Chrome OS may be the experience some people are looking for.