How Lacros Attempted to Separate Chrome from ChromeOS

This article examines the technical architecture of Google's Lacros project, an initiative designed to decouple the Chromium web browser from the underlying ChromeOS system shell. By breaking down the traditional monolithic structure of ChromeOS, the article details how the project split the operating system into two distinct binaries, utilized the Wayland protocol for window management, and implemented a specialized inter-process communication layer to allow the browser and system user interface to operate and update independently.

Historically, ChromeOS was engineered as a single, monolithic binary. The system user interface, the window manager (known as the Aura Shell, or "Ash"), and the Chrome web browser were all compiled together into one executable. Because these components were tightly coupled within the same runtime, updating the web browser required a full operating system update. Consequently, when a Chromebook hardware model reached its end-of-life support date, the web browser could no longer receive security patches or new features.

The Lacros project—an acronym for "Linux And ChRome OS"—attempted to solve this limitation by splitting the single executable into two separate binaries: ash-chrome and lacros-chrome.

Under this architecture, ash-chrome remained the core system shell. It handled the login screen, system tray, app launcher, settings, and window management, but its web-browsing capabilities were deactivated. Conversely, lacros-chrome was essentially the standard Linux version of the Chrome browser, compiled as a standalone binary with added optimizations for ChromeOS hardware. It handled only web rendering, extensions, and browser tabs, completely stripped of any operating system management duties.

Decoupling the browser meant it could no longer draw windows directly to the screen using internal system code paths. To solve this, Lacros relied on the Wayland display protocol. ChromeOS already featured a built-in Wayland compositor called "Exo," which it used to render Android apps and Linux development containers. The Lacros project configured lacros-chrome to act as a Wayland client. The browser sent its graphical output to Exo, allowing ash-chrome to render and manage browser windows alongside system UI elements with native performance and support for ChromeOS-specific windowing features.

While graphical separation was handled by Wayland, the browser still required deep integration with the operating system to function properly. The standalone browser needed access to the user's single sign-on profile, system notifications, Bluetooth, networking, and hardware certificates. Furthermore, because the goal of Lacros was to update the browser independently of the OS, a newer lacros-chrome binary had to be able to communicate reliably with an older ash-chrome binary.

To bridge this gap, engineers created "Crosapi" (ChromeOS API), a communication layer built on top of Chromium’s existing Mojo inter-process communication (IPC) system. Crosapi acted as a stable, versioned boundary between the two binaries. Whenever the browser needed the operating system to perform a task—such as opening a file manager dialog or accessing the webcam—it sent a message across Crosapi. Because the API was designed for backward compatibility, the browser and the system shell could be updated on entirely different schedules without breaking system functionality.

By combining binary separation, Wayland-based rendering via Exo, and the versioned Crosapi IPC layer, the Lacros project successfully separated the Chromium browser from the ChromeOS shell. Although Google ultimately ended the Lacros project in 2024 after finding alternative ways to modularize their codebase and extend device support, the project proved that a monolithic OS could be re-architected into independent, Asynchronous components.