What is Chromium Project?
The Chromium projects include Chromium and Chromium OS, the open-source projects behind the Google Chrome browser and Google Chrome OS, respectively. This site houses the documentation and code related to the Chromium projects and is intended for developers interested in learning about and contributing to the open-source projects
Chromium Project
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web. This site contains design documents, architecture overviews, testing information, and more to help you learn to build and work with the Chromium source code.
Chromium OS Project
Chromium OS is an open-source project that aims to provide a fast, simple, and more secure computing experience for people who spend most of their time on the web. Learn more about the project goals, obtain the latest build, and learn how you can get involved, submit code, and file bugs.
What is Google Chrome OS?
Some Purpose of GChrome OS:
- a Chrome browser running on an optimized Linux kernel
- the built-in operating system is automatically kept up to date and/or repaired from the cloud (can even be entirely re-imaged from the cloud)
- initial bootup takes mere seconds
- supports only solid-state storage
- will read data from USB storage devices (memory sticks, cameras, etc)
- all user data will be stored in the cloud
- will cache user data locally and encrypt it
- built to be fast, simple, and secure
- it will only run web applications
- the root partition of the device’s drive is read-only, preventing any application from changing the core code
Although you’ll hear people saying things such as “this is going to kill Microsoft”, I don’t feel this is going to happen any time soon.
Google Chrome OS will be a great to have on your netbook, and that’s exactly what Google will be focusing on at this point in time. Google are not looking to replace your home/business desktop computer operating system….at least not yet.
The web browser application experience is getting more and more interactive and powerful. The advent of HTML5 is only going to speed things up even more. We already have powerful applications we can run in the browser, which historically required a full blown computer, such as Google Docs or Zoho. Even Microsoft themselves will be releasing a web based version of Office 2010.
It won’t be long before we can do almost anything using cloud-based applications.
More resource intensive applications, such as high-end gaming, CAD, and video editing will likely take a few years before we see viable cloud-based options start to appear.
So the Google Chrome operating systems isn’t going to become the new default operating system which will rule the world, but it just might become the operating system to rule all netbooks in a very short amount of time.
Update: here are some step-by-step instructions on how to install Chrome OS into a virtual machine.
Google is working with Canonical, the lead sponsor behind the Ubuntu Linux project on part of the underlying OS. Chris Kenyon VP of OEM services at Canonical blogged today Canonical is contributing engineering to Google under contract. So, that means that there IS a link between Ubuntu and Chrome OS! That's a surprise. But hey it's still all open source.
By making the project fully open source,Google is opening the project up to participation and comment from interested developers. It also means that they'll be contributing code back to the open source community, which ultimately means that other vendors could benefit as well.
Aside from the Chromium OS announcement today, Google has provided a whole lot of interesting information about Chrome OS.
During a live event (that was also webcast) today Google detailed what we should all look for in their new ChromeOS.
Basically it's all about the web. Apps are in the cloud as well as users' data. Sundar Pichai, VP of Product Management at Google explained that the local hard drive in Chrome OS should just be thought of as a local cache for syncing with the cloud. That's cool.
Going a step further, by design Chrome OS will specify a reference hardware architecture which will require Solid State Drives (SSDs) instead of regular hard drives. The idea is to provide for a faster overall user experience.
"Every application is a web application so users don't have to install program," Pichai said.Pichai also showed off how Chrome OS would have a new apps tab to make it easier to load and access apps.
The screenshot (left) gives us a glimpse of how that new apps tab may look. Those apps are basically just url shortcuts, organized in a window.
There is also an Mac OS 'fish-eye' type of interface for scrolling between open windows which looked pretty interesting as well.
Security is a big focus with the Security Verified Boot process. Basically ChromeOS checks to ensure the OS hasn't been corrupted on boot. If it has, it automatically re-images the users hardware. Another interesting idea, though how that will work in practical utility is another question. I can see it adding time to the overall boot process as time progress and what happens if the wireless driver (for Internet connectivity) gets corrupted?
Google didn't specifically say which version of Linux they were using inside of their ChromeOS build, but Pichai did specifically thank the Ubuntu community for their efforts. No ChromeOS is not an Ubuntu knock-off but it likely borrows some of the same Debian-based plumbing and as I noted earlier, there is a contractual relationship in place.
Overall, few surprises in ChromeOS from what they had originally led us to believe when they announced the effort a few months back. It's all about the web and the browser is the OS.
Chrome - the browser- will continue on its own development path and for current Linux, Mac and Windows users they'll get some of the benefits that ChromeOS will ultimately deliver as well.
Mitigating remote system compromise
There are several vectors through which an adversary might try to compromise a Chromium OS device remotely: an exploit that gives him control of one of the Chromium-based browser processes, an exploit in a plugin, tricking the user into giving a malicious web app unwarranted access to HTML5/Extension APIs, or trying to subvert our autoupdate process in order to get some malicious code onto the device.
As in any good security strategy, we wish to provide defense in depth: mechanisms that try to prevent these attacks and then several more layers of protection that try to limit how much damage the adversary can do provided that he's managed to execute one of these attacks. The architecture of Chromium browsers provides us with some very nice process isolation already, but there is likely more that we can do.
OS hardening
- Process sandboxing
- Mandatory access control implementation that limits resource, process, and kernel interactions
- Control group device filtering and resource abuse constraint
- Chrooting and process namespacing for reducing resource and cross-process attack surfaces
- Media device interposition to reduce direct kernel interface access from Chromium browser and plugin processes
- Toolchain hardening to limit exploit reliability and success
- NX, ASLR, stack cookies, etc
- Kernel hardening and configuration paring
- Additional file system restrictions
- Read-only root partition
- tmpfs-based /tmp
- User home directories that can't have executables, privileged executables, or device nodes
- Longer term, additional system enhancements will be pursued, like driver sandboxing
The more modular the browser is, the easier it is for the Chromium OS to separate functionality and to sandbox different processes. Such increased modularity would also drive more efficient IPC within Chromium. We welcome input from the community here, both in terms of ideas and in code. Potential areas for future work include:
- Plugins
- All plugins should run as independent processes. We can then apply OS-level sandboxing techniques to limit their abilities. Approved plugins could even have Mandatory Access Control (MAC) policies generated and ready for use.
- Standalone network stack
- Chromium browsers already sandbox media and HTML parsers.
- If the HTTP and SSL stacks were isolated in independent processes, robustness issues with HTTP parsing or other behavior could be isolated. In particular, if all SSL traffic used one process while all plaintext traffic used another, we would have some protection from unauthenticated attacks leading to full information compromise. This can even be beneficial for cookie isolation, as the HTTP-only stack should never get access to cookies marked "secure." It would even be possible to run two SSL/HTTP network stacks—one for known domains based on a large whitelist and one for unknown domains. Alternately, it could be separated based on whether a certificate exception is required to finalize the connection.
- Per-domain local storage
- If it were possible to isolate renderer access per domain, then access to local storage services could similarly by isolated—at a process level. This would mean that a compromise of a renderer that escapes the sandbox would still not be guaranteed access to the other stored data unless the escape vector were a kernel-level exploit.
Web app security
- User experience
- The user experience should be orthogonal to the policy enforcement mechanism inside the Chromium browser and, ideally, work the same for HTML5 APIs and Google Chrome Extensions.
- HTML5/Open Web Platform APIs and Google Chrome Extensions
- We're hopeful that we can unify the policy enforcement mechanisms/user preference storage mechanisms across all of the above.
- Plugins
- We are developing a multi-tiered sandboxing strategy, leveraging existing Chromium browser sandboxing technology and some of the work we discuss in our System Hardening design document.
- Long term, we will work with other browser vendors to make plugins more easily sandboxed.
- Full-screen mode in some plugins could allow an attacker to mock out the entire user experience of a Chromium OS device. We are investigating a variety of mitigation strategies in this space.
Phishing, XSS, and other web vulnerabilities
Secure autoupdate
- Signed updates are downloaded over SSL.
- Version numbers of updates can't go backwards.
- The integrity of each update is verified on subsequent boot, using our Verified Boot process, described below.
Verified boot
- Firmware-based verification
(for details, see the Firmware Boot and Recovery design document) - Read-only firmware checks writable firmware with a permanently stored key.
- Writable firmware then checks any other non-volatile memory as well as the bootloader and kernel.
- If verification fails, the user can either bypass checking or boot to a safe recovery mode.
- Kernel-based verification
(for details, see the Verified Boot design document) - This approach extends authenticity and integrity guarantees to files and metadata on the root file system.
- All access to the root file system device traverses a transparent layer which ensure data block integrity.
- Block integrity is determined using cryptographic hashes stored after the root file system on the system partition.
- All verification is done on-the-fly to avoid delaying system startup.
- The implementation is not tied to the firmware-based verification and may be compatible with any trusted kernel.
- Detects changes at boot-time
- Files, or read-write firmware, changed by an opportunistic attacker with a bootable USB drive will be caught on reboot.
- Changes performed by a successful runtime attack will also be detected on next reboot.
- Provides a secure recovery path so that new installs are safe from past attacks.
- Doesn't protect against
- Dedicated attackers replacing the firmware.
- Run-time attacks: Only code loaded from the file system is verified. Running code is not.
- Persistent attacks run by a compromised Chromium browser: It's not possible to verify the browser's configuration as safe using this technique.
Rendering pawned devices useless
Mitigating device theft
A stolen device is likely to have a higher value to a dedicated adversary than to an opportunistic adversary. An opportunistic adversary is more likely to reset the device for resale, or try to log in to use the device for himself.
The challenges here are myriad:
- We want to protect user data while also enabling users to opt-in to auto-login.
- We want to protect user data while also allowing users to share the device.
- We especially want to protect user credentials without giving up offline login, auto-login, and device sharing.
- Disk encryption can have real impact on battery life and performance speed.
- The attacker can remove the hard drive to circumvent OS-level protections.
- The attacker can boot the device from a USB device.
Data protection
The Protecting Cached User Data design document provides details on data protection. Key requirements for protecting cached user data (at rest) are as follows:
- Each user has his own encrypted store.
- All user data stored by the operating system, browser, and any plugins are encrypted.
- Users cannot access each other's data on a shared device.
- The system does not protect against attacks while a user is logged in.
- The system will attempt to protect against memory extraction (cold boot) attacks when additional hardware support arrives.
- The system does not protect against root file system tampering by a dedicated attacker (verified boot helps there).
Account management
- What are the practical concerns?
- Whose wifi settings do you use? Jane's settings on Bob's device in Bob's house don't work.
- But using Bob's settings no matter where the device is doesn't work either.
- And if Bob's device is set up to use his enterprise's wifi, then it's dangerous if someone steals it!
- "The owner"
- Each device has one and only one owner.
- User preferences are distinct from system settings.
- System settings, like wifi, follow the owner of a device.
- Whitelisting
- The owner can whitelist other users, who can then log in.
- The user experience for this feature should require only a few clicks or keystrokes.
- Promiscuous mode
- The owner can opt in to a mode where anyone with a Google account can log in.
- Incognito mode
- Users can initiate a completely stateless session, which does not sync or cache data.
- All system settings would be kept out of this session, including networking config.
Biometrics, smart cards, and Bluetooth
Login
At a high level, here is how Chromium OS devices authenticate users:
- Try to reach Google Accounts online.
- If the service can't be reached, check an offline cache of user->password hash mappings.
- For every successful online login, cache a mapping between the user and a salted hash of his password.
CAPTCHAs
Rather than strictly rate limiting failed authentication attempts, Google Accounts APIs respond with CAPTCHAs if our servers believe an attack is underway. We do not want users to face CAPTCHAs to log in to their device; if the user has correctly provided his credentials, he should be successfully logged in.
Furthermore, including HTML rendering code in our screen locker would introduce more potential for crashing bugs, which would give an attacker an opportunity to access the machine. That said, we cannot introduce a vector by which attackers can brute force Google Accounts.
To work around this right now, we do offline credential checking when unlocking the screen and ignore problems at login time, though we realize this is not acceptable long-term and are considering a variety of ways to address this issue in time for V1.
Auto-login
When a user turns on auto-login, he is asserting that he wishes this device to be trusted as though it has his credentials at all times; however, we don't want to store actual Google Account credentials on the device—doing so would expose them to offline attack unnecessarily. We also don't want to rely on an expiring cookie; auto-login would "only work sometimes," which is a poor user experience. We would like to store a revokable credential on the device, one that can be exchanged on-demand for cookies that will log the user in to all of his Google services. We're considering using an OAuth token for this purpose.
Single sign-on
As we discuss in the Login design document, we want to provide an SSO experience on the web for our users. There's one relatively minor piece of fallout from this: our login manager needs to pass Google authentication cookies to the browser. We currently pass these over a named pipe, though we are working on a more general solution for passing sensitive information between processes.
For third-party sites, we would like to provide credential generation and synced, cloud-based storage.
Chromium OS Fast Boot
The operating system itself is a lightweight Debian GNU/Linux based operating system which contrary to earlier rumours, includes, an X Window based windowing system with support for OpenGL and the Clutter UI animation library. The latter components play a part in providing the quite rich animation which appears on screen. An important change at the lower levels of Chrome OS, and one which cannot be tried out just yet, is Google's development of custom firmware for Chrome OS devices which is focussed on booting as quickly as possible by only looking for hardware expected by Chrome OS; this doesn't stop Chrome OS being booted on a device with a traditional BIOS, but it does mean that the boot time on these devices isn't as fast as Google is aiming for with custom firmware in place.
Google released their ChromeOS operating system yesterday. So naturally, as a VoIP fan I was curious if ChromeOS could run VoIP. Since Google's ChromeOS has a Flash Player built-in, in theory it can run a Flash-based VoIP client. The first VoIP solution that came to mind was Flaphone (formerly Flashphone), a Flash-based VoIP app which runs in a browser. I first discovered Flaphone back in 2007 and did a review of it.
Well, it appears that Flaphone works in ChromeOS. It's worth noting that Flaphone can make VoIP calls to PSTN numbers using any SIP provider you want. Just enter the SIP credentials and away you go! You can also make calls to Skype and Flaphone's callme button widgets also work in ChromeOS.
VoIP in Google ChromeOS
Well, it appears that Flaphone works in ChromeOS. It's worth noting that Flaphone can make VoIP calls to PSTN numbers using any SIP provider you want. Just enter the SIP credentials and away you go! You can also make calls to Skype and Flaphone's callme button widgets also work in ChromeOS.
Update: Looks like TringMe is jumping on the Goolge ChromeOS news as well. Just got an email from their CEO claiming they are "first" to have VoIP in ChromeOS. Well, not to burst your bubble, but Flaphone supports it as well. Let's just call it a tie for "first" and call it a day.
Software Architecture
Abstract
Chromium OS consists of three major components:
- The Chromium-based browser and the window manager
- System-level software and user-land services: the kernel, drivers, connection manager, and so on
- Firmware
High-level design
Firmware
The firmware plays a key part to make booting the OS faster and more secure. To achieve this goal we are removing unnecessary components and adding support for verifying each step in the boot process. We are also adding support for system recovery into the firmware itself. We can avoid the complexity that's in most PC firmware because we don't have to be backwards compatible with a large amount of legacy hardware. For example, we don't have to probe for floppy drives.- System recovery: The recovery firmware can re-install Chromium OS in the event that the system has become corrupt or compromised.
- Verified boot: Each time the system boots, Chromium OS verifies that the firmware, kernel, and system image have not been tampered with or become corrupt. This process starts in the firmware.
- Fast boot: We have improved boot performance by removing a lot of complexity that is normally found in PC firmware.
System-level and user-land software
From here we bring in the Linux kernel, drivers, and user-land daemons. Our kernel is mostly stock except for a handful of patches that we pull in to improve boot performance. On the user-land side of things we have streamlined the init process so that we're only running services that are critical. All of the user-land services are managed by Upstart. By using Upstart we are able to start services in parallel, re-spawn jobs that crash, and defer services to make boot faster.
- D-Bus: The browser uses D-Bus to interact with the rest of the system. Examples of this include the battery meter and network picker.
- Connection Manager: Provides a common API for interacting with the network devices, provides a DNS proxy, and manages network services for 3G, wireless, and ethernet.
- WPA Supplicant: Used to connect to wireless networks.
- Autoupdate: Our autoupdate daemon silently installs new system images.
- Power Management: (ACPI on Intel) Handles power management events like closing the lid or pushing the power button.
- xscreensaver: Handles screen locking when the machine is idle.
- Standard Linux services: NTP, syslog, and cron.
Chromium and the window manager
The window manager is responsible for handling the user's interaction with multiple client windows. It does this in a manner similar to that of other X window managers, by controlling window placement, assigning the input focus, and exposing hotkeys that exist outside the scope of a single browser window. Parts of the ICCCM (Inter-Client Communication Conventions Manual) and EWHM (Extended Window Manager Hints) specifications are used for communication between clients and the window manager where possible.
The window manager also uses the XComposite extension to redirect client windows to offscreen pixmaps so that it can draw a final, composited image incorporating their contents itself. This lets windows be transformed and blended together. The Clutter library is currently used to animate these windows and to render them via OpenGL or OpenGL|ES.