> how exactly would you be sure the user saw this message and is what replies yes to it?
> do you even know what video cards are installed in the system? let alone what mode they are in or which of the displays are hooked up to a monitor?
Because it would be displayed by the firmware at boot time. And yes, you can create a situation where a user with e.g. a serial console can't install a /new/ OS without special stunts, just as things _already are_.
And yes, "the industry" (how polite we are to not name names, I suppose) made an affirmative decision to unnecessarily deny the end users reasonable control over their devices. It's a fact, but it's not a justification. And
> this is (unintentionally) starting to sound a lot like Secure Boot as actually defined. In fact, I think approximately the only difference is that Microsoft
Not unintentionally at all. A previously installed bootloader from a vendor using signing to support remote updates from the author of the bootloader sounds fine for software created under a model where that makes sense. This is orthogonal to the question of authorizing that bootloader in the first place, however. The "only difference" that matters is that under secureboot a new operating system can not be installed at all or only via an opaque, undocumented, and user hostile procedure (depending on the platform and implementation details). It may be the only difference, but its the one that matters because its what determines if the owner of the hardware can choose to take control of it by authorizing a free operating system, and its what determines if all downstream distributors of free software have equal access to the deployed equipment.