After years of quiet development, Google’s Fuchsia OS has arrived. Google expects to use Fuchsia on various future devices, ranging from small gadgets all the way up to phones and tablets. But the key driver for the built-from-the-ground-up OS appears to be the IoT.
I say that in light of a comment made by Hiroshi Lockheimer, the SVP in charge of Android, Chrome, and Google Play at Google I/O back in 2019:
In the world of IoT, there are an increasing number of devices that require operating systems and new runtimes and so on. I think there’s a lot of room for multiple operating systems with different strengths and specializations. Fuchsia is one of those things and so, stay tuned.
Fuchsia emulator. Image courtesy Greg Willard
So what is Fuchsia OS?
Fuchsia is brand new. Instead of using existing open source technologies such as Linux, Android, and Chromium, Google built a new OS from scratch. It’s still open source, though. You can view the code at this repository, for example.
And when I say brand new, I mean really brand new.
Fuchsia runs on top of a unique Google-built microkernel called Zircon. That microkernel handles only a few, but important, device functions, such as the boot-up process, hardware communication, and management of application processes.
Fuchsia is also where apps and any user interface runs. Think of Zircon as the base upon which this new operating system is built; as such, it needs to be fast, secure, and stable. And since Google designed it from scratch, the company doesn’t have to worry about issues or baggage brought by a legacy system.
Speaking of interfaces, developers can use Google’s Flutter language to build interfaces for smart screens; it’s currently used for some apps on Android, the web, and of course, some original Google Home Hubs are now running a Flutter interface Fuchsia OS. You could certainly use Flutter to create a thermostat interface or any other connected device with a display.
Flutter components
I’ve dabbled with Flutter a little and would roughly equate it to React, a component-based JavaScript library, which I have used quite a bit lately. Indeed, Fuchsia and React are both built with application components, which you can think of like widgets. So developers have a framework to design and build modular components for their devices.
Components are a key aspect of Fuchsia, and not just for the user interface. At Google’s Fuchsia.dev site, components are described as “the basic unit of executable software” and as the site notes, just about everything in Fuchsia is an isolated component. Moreover, Fuchsia components are individually sandboxed.
Components have specific access to other components only as needed, which is how secure modern systems are designed today. Compared to older, “monolithic” platforms, this boosts the potential for improved security. The best illustration I can offer comes from this deep-dive on Fuchsia, which notes that this organization “brings good segmentation properties: a vulnerability that affects a component compromises only its process.”
Image of Fuchsia architecture courtesy Quarklabs
The security model needed for IoT?
From an IoT perspective, this organization brings improved security because each modular component is very limited or controlled as to what it can (or cannot) do and what data it has access to.
Here’s a great example to illustrate this point, again from the Fuchsia.dev site:
Each component typically has a small number of responsibilities and exposes services that other components use to perform more complex tasks. For example, the ethernet driver component exposes a service for sending ethernet frames. The network stack component connects to the ethernet driver component and uses its services to communicate with the hardware. These two components can be authored by different parties and be distributed separately because they agree on a common set of protocols that let them work together.
Of course, this approach doesn’t guarantee device security. But by implementing controlled components, security risks can be minimized. The network stack, for example, is well defined, isolated from other processes or components, and limited to only the functionality for which it’s intended. According to Google, “Capabilities used and exposed must be explicitly declared” in components, which makes it difficult to exploit the stack in this case. And even if it is exploited, the exploit would be limited because of the compartmentalized nature of the component model.
Why start with the Google Home Hub, er…Google Nest Hub?
It’s clear that Google — and Amazon, for that matter — believe strongly in smart displays for the IoT at home. But given that Fuchsia is so new, it doesn’t make sense for Google to simply create a new smart display running on the young platform. Instead, the company wisely decided to update its oldest smart display with Fuchsia.
There’s less risk of introducing issues to a large userbase with this approach because there are likely more newer Google Nest Hub devices in the wild than the original model. They may not even be the primary smart display for many homes. Of course, being a data-driven company, Google knows how many of each model is out there.
If you’re curious, the original hub display has actually run on Google’s Cast OS, which is essentially an offshoot of its Chromecast protocol. Which made sense in 2018, when “casting” music or video around the smart home was a front-and-center feature. In 2021, however, it makes less sense because the smart display has evolved from a media-centric device to one that can control our homes. And Chromecast technology isn’t well suited for that.
With Fuchsia OS on the original Google smart display, developers and device makers can build new experiences for a limited number of devices in the field. By upgrading the base software of its oldest smart display, Google is lowering the barrier of entry for IoT app makers. Otherwise, developers would have to use the Fuchsia emulator, which isn’t ideal, or install Fuchsia on supported hardware, which is more effort.
The future of Fuchsia isn’t written yet
Keep in mind that building an entirely new operating system from the ground up takes a long time and much effort. Google began the Fuchsia journey back in 2016, and it’s only now that we have a commercially available device running on the platform.
My point is that we’re just getting started with Fuchsia. It remains to be seen what other IoT devices will run on the system and what changes device makers will have to make to their light bulbs, webcams, and sensors, for example.
However, given that Fuchsia is modularized and currently works with the IEEE 802.11 standard for Internet Protocol network data, I can’t see why it wouldn’t eventually work with Matter for device-to-device communication. Surprisingly, Google didn’t mention Fuchsia at its I/O developer keynote event last week, so hopefully the company will share more information in the near future.