The rationale for forcing uses to choose between security and freedom is because you can't provide both together.
One particular use case that is considered important to Chromebooks is: You should, as a user, feel comfortable and secure using one that you do not own. Perhaps it's a loaner Chromebook like Virgin America provided last year for people on their flights, or one provided by a hotel you're staying at (another pilot Google has run), or a public kiosk, etc.
A simple reboot of the device will show whether or not it is a trusted OS installed on it; this is why once the developer switch is toggled, the firmware will always give scary "OS IS UNTRUSTED!" warnings. All bets are off then: since the owner can manipulate the system, including disabling the verified filesystem, install key loggers, send your passwords to others, etc.
The middle-ground would be to semi-trust externally signed OS, for example permit additional signing keys to be added to the firmware so that it can verify that the non-Chrome OS kernel it's booting matches those keys to give the modding community some level of secure boot support.
You'd have to resolve the UI issue, making sure a user unaware of the concept of modding (my dad, for example) would be still aware that he shouldn't trust the device in its modded state. But also have some other level of UI for the modded device firmware not matching the additional keys, while also still supporting modders who flat out don't want to deal with secure boot.
Our firmware team, though I can't actually speak for them, support modding enough that this is probably more a case of getting people to agree on the right approach rather than flat-out denial. Though also you know how security people like to say No and get angry at you ;)
Rationale
One particular use case that is considered important to Chromebooks is: You should, as a user, feel comfortable and secure using one that you do not own. Perhaps it's a loaner Chromebook like Virgin America provided last year for people on their flights, or one provided by a hotel you're staying at (another pilot Google has run), or a public kiosk, etc.
A simple reboot of the device will show whether or not it is a trusted OS installed on it; this is why once the developer switch is toggled, the firmware will always give scary "OS IS UNTRUSTED!" warnings. All bets are off then: since the owner can manipulate the system, including disabling the verified filesystem, install key loggers, send your passwords to others, etc.
The middle-ground would be to semi-trust externally signed OS, for example permit additional signing keys to be added to the firmware so that it can verify that the non-Chrome OS kernel it's booting matches those keys to give the modding community some level of secure boot support.
You'd have to resolve the UI issue, making sure a user unaware of the concept of modding (my dad, for example) would be still aware that he shouldn't trust the device in its modded state. But also have some other level of UI for the modded device firmware not matching the additional keys, while also still supporting modders who flat out don't want to deal with secure boot.
Our firmware team, though I can't actually speak for them, support modding enough that this is probably more a case of getting people to agree on the right approach rather than flat-out denial. Though also you know how security people like to say No and get angry at you ;)