Earlier this year, 9to5 Google caught code changes about something called LaCrOS. Work has progressed on this enough to the point where LaCrOS is available in the Canary Channel of Chrome OS 87, appearing as another Chrome browser icon. That’s because Google is decoupling the Chrome browser from Chrome OS on Chromebooks. And it’s using Linux to do this.
We know this because of a Google document explaining what LaCrOS is and what it stands for: Linux And ChRome OS. That’s right, the Chrome browser will be independent of Chrome OS and appears to be based on a Linux version of Chrome with improved Wayland support.
So why is Google doing this? To be honest, I don’t think it’s to extend the life of older Chromebooks as others covering this news have suggested.
I’d like to be wrong on that, believe me.
However, that doesn’t make much sense since now all now Chromebooks get approximately 8 years of software update support. And it makes even less sense when you think about older Chromebooks currently out of their software support window: How would they get the required update to break out the Chrome browser from Chrome OS?
Instead, I think this is mainly to help Google better manage work on the Chrome browser and get browser updates faster to Chromebooks by making the platform more modular.
Have you ever wondered why Chrome OS updates are typically delivered a week or two after Chrome updates for all other platforms? That’s partially because Chromebooks aren’t just getting browser updates; they’re getting software platform updates for Chrome OS as well.
By decoupling the Chrome browser from Chrome OS, Google can manage a single Chrome code base for all platforms and push browser updates out to those platforms at the same time. And on the flipside, Chrome OS updates that might be ready for deployment don’t have to be held up by Chrome browser updates.
The LaCrOS document suggests that there might be a slight performance hit with a separate Chrome browser. That’s because Chrome OS will use APIs to communicate with the browser instead of native code for such communication:
The basic approach is to rename the existing binary to ash-chrome, with minimal changes. We then take the linux-chrome binary, improve its Wayland support, make it act like the web browser on Chrome OS, and ship that as the lacros-chrome binary. This allows the two binaries to be released independently, with some performance/resource costs. The API boundary initially will be semi-stable: it will tolerate 1-2 milestones of version skew. We may allow larger amounts of skew in the future.
I don’t expect that performance hit to be very noticeable however. And as noted, you may see your Chromebook running on Chrome OS 90, for example, while your browser version is 91. That won’t likely matter to the end user experience either, although you may have some new browser features before you get a Chrome OS update, which is a good thing.
I’m sure people have thoughts and opinions on this approach by Google, so let’s hear them in the comments!
7 Comments
Maybe it’s one of those just because we can kind of things and the actual usage will come later.
Could this have something to do with Fuchsia? Could the underlying Linux be replaced in the future, and if so wouldn’t you need to separate chrome browser first? There might be double the benefits, cleaner development of the Chrome browser and the ability to replace the underlying OS in the future if need be.
Agreed. Unlikely to affect UAE date. When Chrome OS was a simpler platform, it probably made a lot of sense for the browser to be “baked in” with the OS. But now, this level of integration probably stands out as a unique work process next to others that are more uniform with useful synergies. Interestingly, this decision is very reminiscent of when Microsoft may have been forced decouple Internet Explorer from Windows as a result of an antitrust settlement agreement. Google is experiencing similar antitrust litigation, and perhaps Chromebook ubiquity has reached to scale where lawyers can now see it “on the radar.” ?
https://www.morningbrew.com/daily/stories/2020/07/20/revisiting-antitrust-case-microsoft
This is interesting. Could we see alternative browsers on chrome os like the new chromium based edge browser?
Are you sure this isn’t a regulatory compliance issue to come into alignment with Microsoft and their antitrust history with Netscape?
Remember, back in the early days of the internet, Microsoft had to unbundle IE from its OS to comply with legal pressures.
One important aspect that hasn’t been mentioned is maintenance of security.
As I understand the term, the browser presents a huge attack surface. In contrast, the rest of Chrome OS is exceptionally well secured relative to other operating systems (including other Linux releases, because of the very included minimal base Linux), and generally much less exposed than the browser. So I expect that being able to update the browser independently of the OS could dramatically reduce and simplify the Chrome OS release pressures, and that alone seems like sufficient motivation to make this change.
IMHO, the main motivation for LaCrOS is to improve OS security by moving the browser into a VM. The VM isolation layer protects the underlying OS from potentially dangerous web content which is particularly important for the Android Runtime for Chrome (ARC++) and NaCl code.