--------------------------------------------------------------------------------- |INFO: | | | ---------------------------------------------------------------------------------
In the past 2 years, there have been 7 major unenrollment exploits for Chromebooks, permitting students to essentially remove school ownership of their device and do with it whatever they please. All of these exploits were developed by highschoolers. Google is incompetent at securing their own devices, let's look at why.
Legacy code
If you look through ChromiumOS' codebase you see quite a lot of legacy code that isn't fully understood, is poorly documented, and generally needs a rehaul. This can be seen most easily with the firmware info screens on most Chromebooks released before 2023: when any kind of special boot event occurrs, the device displays a screen that looks like it should've shipped on an early 2010s laptop. Which, coincidentally enough, is what it is. Almost all Chromeboxes sold between the release of the original in 2011 up to 2023 had, for all intents and purposes, the same firmware. Near nothing was changed between devices other than the tree required to get the firmware to boot. This dated-ness extended past the graphics; Google had to implement all sorts of weird workarounds to make this firmware do what it was supposed to, which is why they finally replaced it with NewUI in 2023. This attempt at integrating dated software into the newer system led to quite a large and vulnurable attack surface. Why did it take them so long to develop a second firmware revision? Simple, they didn't ever implement an update mechanism in the original, so they had no way to without going out of their way to ship it on new hardware. Also, yes, you heard that right. Until the introduction of the TI50 and the T1 security chip, Google had no way to proactively or reactively update the firmware on Chromebooks. Surely that won't cause problems.
Poor code quality
I know that this isn't in the description, but it's still important nonetheless. Google's code quality on some of the lower-level parts of ChromeOS is, to put it mildly, horseshit. There was a recent exploit that exploited what essentially amounted to a buffer overflow in ChromeOS' recovery utilities, and the most popular exploit of the last 2 years, SH1mmer, abused the fact that a specific type of recovery image didn't have rootfs verification, even though it was supposed to.