Yes, and that was the solution to an incentive design problem.
If you make it easy to persistently use a rooted device, then regular users would use rooted devices for regular tasks. (Because there are advantages of doing so, like side-loading native apps.)
If regular users use rooted devices, some people’s only experience of a device would be of a rooted device.
If some people’s only experience of a device is of a rooted device, then they’ll have no idea what an actually tampered device looks like, because every device they’ve seen is “tampered.”
This is exactly the state of Android, as it happens. Tons of people use Android in its developer mode; and so people don’t take a security mindset toward using a rooted phone.
The solution to this is to use technical mechanisms to achieve social effects (a.k.a. “incentive design” — the type of thing that tax credits are.) By making it irritating and risky to use developer mode in a persistent way, people won’t do it for anything other than tasks that truly require using developer mode for what it’s for (that’s “using the device as a debug build target”, by the way, not “writing code on the device.”)
Thus, nobody uses Chromebooks in developer mode.
Thus, the average person’s experience of seeing a Chromebook in use is, 99.9% of the time, of a non-rooted Chromebook.
Thus, the boot beep is surprising, and will scare the average user off of using the device.
Adding a switch in the OS that disables this, would be akin to having a switch in your OS (on a device MDM-managed by someone else, including the certificate store) that disables web browsers from doing any certificate checking. You could flip it; but so could viruses, and so could the NSA half-way through the laptop’s delivery process. Why would you want that switch to exist?
——
What people with complaints like yours really want, I think, is not to disable the TCB. You want to be able to be in control of the TCB. You want something that’s like a Chromebook, but where the MDM controller is an enterprise (e.g. you individually, if you’re clever enough) rather than Google.
Well, I mean, first: that’s what a regular PC with Secure Boot is.
But if the particulars of Chromebooks appeal to you (and I suppose they could appeal to somebody): the cheap hardware, the keyboard layout, the sandboxing, etc. Then what you might want is a variant Chromebook.
Such a device would have to look different than a regular Chromebook, somehow, to show regular users that it’s not for them. Sort of like how developer units of game console hardware are clearly not the same as production units. But if that were done, I think it’d be okay for those units to have a user-controllable TCB.
> If some people’s only experience of a device is of a rooted device, then they’ll have no idea what an actually tampered device looks like, because every device they’ve seen is “tampered.”
This is false. All but the most technically inept user will understand "WARNING! YOUR COMPUTER IS NOT RUNNING GOOGLE CHROME OS/HAS BEEN ALTERED FROM FACTORY DEFAULTS!" shown at boot time. Which is what Chromebooks do. All that's needed to make it into a usable device is to get rid of "Press space to wipe your device."
> Tons of people use Android in its developer mode; and so people don’t take a security mindset toward using a rooted phone.
Android security is catastrophic on factory settings already, so how you managed to blame the tiny proportion of users that root their phones to get rid of vendor bloatware for it is beyond me.
> All but the most technically inept user will understand "WARNING! YOUR COMPUTER IS NOT RUNNING GOOGLE CHROME OS/HAS BEEN ALTERED FROM FACTORY DEFAULTS!" shown at boot time.
No. Not if half† the Chromebooks people own emit that message.
Users do not read. I know, it's hard to believe, but a large portion of average (not "most technically inept", average) users have never read a warning message on a screen in their lives. They see a warning message—and then they ask an authority figure what it means. They then classify whatever technobabble response they get into two executive-summary categories: either the warning means they should stop and wait for assistance; or the warning means nothing, and they should confirm whatever it's asking them to confirm and go on as per usual. After that, every time they see a prompt that looks like the one they asked about, they'll remember which of the two categories they surmised it to fall into, and that's what they'll do. Even if it's a prompt with different text. It looks the same—it gets the same treatment.
The next time you see a non-IT person using Windows and they get a UAC prompt, observe what they do. Ask them why it came up, and why they reacted the way they did. They won't know. All they'll know is that someone once told them it's fine to ignore those and click Accept.
If the ChromeOS boot screen is as common as Windows UAC, then it fails at its mission. That is why it makes it easy to un-root the device: because, if you have a boot screen that can "trick" average users into un-rooting a Chromebook, then you can't trust the average user around your rooted Chromebook to not accidentally wipe it, so you can't ever give the average user a rooted Chromebook as some kind of cheap kiosk (i.e. exactly what the author of the article was trying to do.)
And so rooted Chromebooks "in the wild" are rare—rare enough that if any user ever sees that boot screen, it'll be a new error that no authority figure ever told them "the trick" to bypassing and getting on with their day. New enough that they'll either "fall for" the prompt and un-root the device; or they'll call someone over to ask what the prompt "means."
----
† Sure, far less than half of Android devices are rooted. But consider the demographic difference. Every human being has a potential reason to own an Android device. Right now, very few average human beings have a reason to own their own Chromebook. (Be assigned a Chromebook by an enterprise MDM system, sure. But own their own? Quite rare.)
Ignoring the enterprise users, and taking the small slice of people who own their own Chromebook as the base population, any random niche use that requires rooting the Chromebook, if it got popular enough, could blow that population out of the water. If rooted Chromebooks turned out to be, say, good for running TAILS, or game emulators, or any other stupid thing you can think of, suddenly half the Chromebooks "in the wild" that a non-enterprise user ever sees would be doing that, and so would be rooted. They'd all beep and show the warning. And, like UAC, it'd be just another one of those things you ignore.
If you make it easy to persistently use a rooted device, then regular users would use rooted devices for regular tasks. (Because there are advantages of doing so, like side-loading native apps.)
If regular users use rooted devices, some people’s only experience of a device would be of a rooted device.
If some people’s only experience of a device is of a rooted device, then they’ll have no idea what an actually tampered device looks like, because every device they’ve seen is “tampered.”
This is exactly the state of Android, as it happens. Tons of people use Android in its developer mode; and so people don’t take a security mindset toward using a rooted phone.
The solution to this is to use technical mechanisms to achieve social effects (a.k.a. “incentive design” — the type of thing that tax credits are.) By making it irritating and risky to use developer mode in a persistent way, people won’t do it for anything other than tasks that truly require using developer mode for what it’s for (that’s “using the device as a debug build target”, by the way, not “writing code on the device.”)
Thus, nobody uses Chromebooks in developer mode.
Thus, the average person’s experience of seeing a Chromebook in use is, 99.9% of the time, of a non-rooted Chromebook.
Thus, the boot beep is surprising, and will scare the average user off of using the device.
Adding a switch in the OS that disables this, would be akin to having a switch in your OS (on a device MDM-managed by someone else, including the certificate store) that disables web browsers from doing any certificate checking. You could flip it; but so could viruses, and so could the NSA half-way through the laptop’s delivery process. Why would you want that switch to exist?
——
What people with complaints like yours really want, I think, is not to disable the TCB. You want to be able to be in control of the TCB. You want something that’s like a Chromebook, but where the MDM controller is an enterprise (e.g. you individually, if you’re clever enough) rather than Google.
Well, I mean, first: that’s what a regular PC with Secure Boot is.
But if the particulars of Chromebooks appeal to you (and I suppose they could appeal to somebody): the cheap hardware, the keyboard layout, the sandboxing, etc. Then what you might want is a variant Chromebook.
Such a device would have to look different than a regular Chromebook, somehow, to show regular users that it’s not for them. Sort of like how developer units of game console hardware are clearly not the same as production units. But if that were done, I think it’d be okay for those units to have a user-controllable TCB.