> "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps"
That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's.
I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.
Write-once of an enterprise key. If you buy 10k units, you should be able to put your own key in there. Or, have some kind of "we just check keys and add a layer of indirection as a service" for boot and boot signing keys. A batch of devices (identified by range of manufacture-time keys) is registered to a specific enterprise, and then that enterprise's keys are allowed to boot. That involves some kind of network service at boot time, or some kind of signed second-stage loader delivered to the devices telling them they're authorized to boot only from third-stage signed by that registered key.
I don't quite understand the need for that level of security. Surely the cases where being able to elaborately go into the BIOS and change such settings will lead to infections is miniscule. It's certainly worth the tradeoff of not relying on an external entity for verification of what's "good".
It's a big deal if you have fleets of machines which travel outside your control. It lets you treat them as identical (modulo hardware damage).
It's also a big deal because on a conventional machine, malware remotely can download, root, reflash, and persistently doom you, no physical access needed.
> Why wouldn't you be able to treat them as identical?
If a given machine can have arbitrary software installed on it, then that machine can behave differently than other machines in the fleet.
If all machines in your fleet can only install and/or run software signed with the company key, then the company can ensure that the software load for all machines remains the same and -thus- all machines behave identically.
> How would being able to change the sync/verification server make Chromebooks vulnerable...
If the software repo and/or verification server can be changed by a third party, and the trusted keys installed in the machine can be changed, then it's trivial to pwn such a machine. If only the servers can be changed, then it requires loss of control of one's signing keys to pwn such a machine. [0]
[0] Or -obviously- a sufficiently bad privilege escalation bug can pwn such a machine.
Where do they make money on that? The margins on the devices are so slim and go to the OEMs, which Google mostly isn't. I don't think they charge any money for OEMs licensing the OS, and if they do it's likely a pittance. The only way Chromebooks make money for Google is as a gateway to Google services, and allowing people to fork ChromeOS like that puts that revenue source in jeopardy.
That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's.
I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.