During the Google I/O event last month, the global tech giant showed off new elements of ChromeOS, focused on security, ecosystem and user experience, as well as benefits of the Chrome Enterprise Connectors Framework⁠. The framework lets organizations integrate vendors, including security providers, with Chrome browser and ChromeOS using APIs and “connectors” – with the goal of making it easier for organizations to control who has access to data. The connectors framework is also designed to help endpoint management vendors manage Chrome browsers on Windows, Linux or Mac devices.

The company also unveiled:

Thomas Riedl, product director and head of ChromeOS Enterprise and Education spoke to TechRepublic about ChromeOS, its security posture and growth strategy, including ChromeOS devices’ presence in enterprises (the company reported a 22% growth in sales of enterprise devices in 2022 versus the prior year).

TR: What is the secret sauce of ChromeOS for enterprise?

Riedl: We are actually early in the journey in enterprise spaces. When we started Chromebooks, we started with quite a bold vision of where computing is headed: we saw the world moving to the cloud and we saw that the old way of doing computing wouldn’t be suitable for that. Also, we very much designed ChromeOS for the world Google was building and investing in.

SEE: How to install Docker on ChromeOS

TR: The Chrome Enterprise Connectors Framework —this sounds to me a little like an XDR-based platform approach, where single-point solutions are integrated through a platform.

Riedl: The Connectors Framework is a big name for what is essentially our way of introducing third-party services to our operating system in a secure way.

TR: Security vendors like Splunk or Crowdstrike?

Riedl: We had a big announcement with CrowdStrike recently, and really what it came down to is CrowdStrike usually does the following: when they need to have visibility of, say networked Windows devices, they run their own agent in the background, which may or may not slow the system down, and then will try to collect the data and report suspicious activity back up to the system admin. What we did was a very different approach. We went to CrowdStrike and asked them what data they will need. Meaning we would not have to run their agents. The Connectors Framework gives them the API that provides all of the data they need to do their magic using their services, their dashboards by which they can communicate to their customers.  And so we surface these events to them, and then they can do whatever they need with that data.

TR: Is this a custom API? A vendor-agnostic interface?

Riedl: It’s called Telemetry API, designed based on the needs of the vendor. What we found is that one of the reasons —  when you use a Windows PC, and it immediately gets dramatically slower when an admin is done with their work, is that they have to add antiviruses, XDR, or DLP.

And every vendor is like, ‘my agent is pretty lean,’ but it adds up. And suddenly these vendor agents are eating hundreds of MBs of RAM, which is a difficult proposition to maintain.

TR: How successful is Chromebook for enterprise? Who is the ideal customer?

Riedl: So we go big after the frontline workforce, which constitutes 90% of the computing in the world, but it may not be incredibly obvious to us every day: this could be nurses, doctors, hospitals, shift workers on a manufacturing line, it could be reception workers. It can even include unattended signage kiosks.

TR: Why is ChromeOS and Chrome hardware — Chromebooks — the right solution for this workforce?

Riedl: The reason we think we have a fantastic solution here is because security is paramount. But, these positions on the frontline often have high turnover, with sensitive customer data to protect and they need something that just works, a thin client system.

TR: How is the security model for ChromeOS unique from other operating systems?

Riedl: It is at the heart of ChromeOS, in which the browser is where all activities, tasks and computing takes place. It’s effectively a Linux architecture, but with our own components, starting with what we call Verified Boot. And a framework involving constant checks against the status of the OS — has it been tampered with? Also, no matter which OEM ships our system, we are actually able to update the operating system on our own terms, whenever we think it’s needed. The entire operating system comes as a package that we constantly update and keep secure and check against.

TR: Don’t customizations have to be driven by the OEM?

Riedl: Typically for other operating systems, the device maker would add their own user interface, drivers and systems. Then they package it up and take care of the updates themselves. For example, the way Samsung handles Android updates, they control at what point in time they ship an update to their phones, which would be whenever their engineers are ready. It might be every year, it might be every half year.

TR: How is the software update lifecycle different for ChromeOS?

Riedl: In ChromeOS we’ve taken a very different approach: We ship an update to the operating system every four weeks; that binary block comes from us and we do all the work– it’s done seamlessly in the background so the user can continue to be productive and not look at a spinning wheel for 45 minutes. So the OEM actually is not involved.

TR: So you treat the OS as a unit, like swapping out the entire battery pack in a car when one cell needs an update? Wouldn’t this take a lot of time for each instance?

Riedl: Our updates take five seconds, which is very different to how Windows and Mac do it. We actually download the entire new version of the operating system. It just takes a reboot.

It’s core to the way we have designed the system partitions — our architecture is such that a new version is something that we effectively swap out like a puzzle piece.

TR: How does this monthly ChromeOS replacement differ from typical cadence for software upgrades?

Riedl: Typically, development in software engineering usually runs on a yearly cadence, with a big event to launch the next iteration. But we believe your computer should continually improve; we actually don’t want you to have to wait for the keynote. Thanks to this architecture — how the OS is partitioned and how we put it all together — we have been able to make some very bold claims: we’ve never had a successful ransomware attack on ChromeOS; we have never had our system compromised, even though we have a very generous bug-bounty program in place.

TR: But I’m also wondering about risks inherent in a fast software upgrade cadence because of questions about source code dependencies. Or is this extraneous because of how Google develops software?

Riedl: Well, what I can tell you is, our software cycle is such that we don’t just give you something untested; we have gone through multiple development phases that we’re doing out in the open. So fundamentally, ChromeOS is tested, probed, challenged and pen tested by the community.