I think saying SecureBoot==buyerControl && RestrictedBoot==sellerControl is too simplistic. The born with handcuffs example another poster mentioned a couple comments up from here is relevant.
When the baby is born, some Evil Adversary(tm) has to jump in and put on the handcuffs. From that point forwards, the formerly PlainBaby is now just a RestrictedBaby. When the parents get it home from the hospital, they can go on the internet, and learn about how to pick the lock on the particular model of handcuffs their baby was imprisoned with, and after a couple hours or so of wasted effort (assuming they don't need a BIOS mod to the handcuff firmware to overcome some 'accidental' bug or 'security' misfeature). At that point, and only at that point, do the parents have SecureBaby... assuming they put handcuffs of their own choice in place, with handcuff keys only they have, and not the adversary. (The parents might also opt for PlainBaby, with no handcuffs at all.)
I hope the metaphor is clear: PlainBaby is non-UEFI boot, SecureBaby is UEFI-boot with parent-aka-enduser-supplied keys, and RestrictedBaby is what you get from the hospital-aka-factory. But it seems a pretense to say that the enduser is in 'control' of their *plain* hardware device, when it ships by *default* with RestrictedBoot, just like it seems obviously wrong to say that the parent is in 'control' of their baby when the Evil Adversary with dibs on the hospital grounds swoops in to apply the handcuffs and turn a *plain* old baby into a RestrictedBaby.
The application of RestrictedBoot to a product, without the enduser's getting to say whether they want it or not, and if so what *sort* of security they want, is like the application of handcuffs to newborns, without the parents getting the handcuff keys immediately (or the option of no handcuffs whatsoever!). The reason some folks -- not me personally since actually I would love to have RestrictedBoot applied straight from the hardware-factory which only permits software to install if it has been signed with my personal pubkey i.e. no win9 and no bloatware and no trialware and so on -- but the reason some folks complain about SecureBoot just as loudly as they complain about RestrictedBoot is that, invariably from what I have seen, it works just like the handcuff model.
The enduser has to *work* to get the wrong keys out, and the right keys in. The evil adversary gets what they want for free ... by default ... and the public at large, not savvy in the ways of lockpicking, eventually gets used to the idea that all iPhones, then all tablets, then all PCs just *ought* to be locked-down vendor-software-only disposable-every-six-months special-purpose kiosk-devices for content-consumption and spyware and nothing more.
So, while I agree with your technical stance on SecureBoot as a conceivable advantage, I think you're missing the bigger picture. Namely, that whether you call it SecureBoot that the savvy consumer can bypass, or RestrictedBoot that the savvy firmware-modder can bypass, they are in the same basic category: bad things the evil adversary did, before you had a chance to stop them, and now must be undone, or lived with.
Hint -- if 98% of the population lives with it, then the marketshare of Linux on the PC will be 2%... just like now. When you buy a PC that comes pre-installed with Win/iOS/bloatware, you have 'freedom' to undo that stuff, and install what you really wanted in the first place. But there is a difference between freedom without intentional freedom-blocking-hinderances installed at the factory by default, and the *true* situation we live in.
I'm not saying you're wrong, mjg. SecureBoot *is* distinct from RestrictedBoot, for those of us paying close attention. But when what you get from the factory is invariably RestrictedBoot by default, and converting that state into *actual* SecureBoot requires hours or days or forever, depending on the difficulty of the out-of-support-contract firmware reconfig / not-well-documented firmware upgrade / unauthorized-and-warranty-voiding firmware mod, then you are not talking about freedom by default. You are talking about the possibility of jailbreaking... but the default should not be jail.
The default should be PlainBaby, or SecureBaby with keys supplied by the parents (and not copied at the hospital), because RestrictedBaby-by-default will someday soon lead to a world of RestrictedBaby-take-it-or-leave-it. We already live in that world with many phones, tablets, digicams, televisions, auto-puters, and whatnot. I want *that* world to get smaller and smaller, not grow and grow until it encompasses laptops and desktops and servers and everything.
Re: Let the user choose
When the baby is born, some Evil Adversary(tm) has to jump in and put on the handcuffs. From that point forwards, the formerly PlainBaby is now just a RestrictedBaby. When the parents get it home from the hospital, they can go on the internet, and learn about how to pick the lock on the particular model of handcuffs their baby was imprisoned with, and after a couple hours or so of wasted effort (assuming they don't need a BIOS mod to the handcuff firmware to overcome some 'accidental' bug or 'security' misfeature). At that point, and only at that point, do the parents have SecureBaby... assuming they put handcuffs of their own choice in place, with handcuff keys only they have, and not the adversary. (The parents might also opt for PlainBaby, with no handcuffs at all.)
I hope the metaphor is clear: PlainBaby is non-UEFI boot, SecureBaby is UEFI-boot with parent-aka-enduser-supplied keys, and RestrictedBaby is what you get from the hospital-aka-factory. But it seems a pretense to say that the enduser is in 'control' of their *plain* hardware device, when it ships by *default* with RestrictedBoot, just like it seems obviously wrong to say that the parent is in 'control' of their baby when the Evil Adversary with dibs on the hospital grounds swoops in to apply the handcuffs and turn a *plain* old baby into a RestrictedBaby.
The application of RestrictedBoot to a product, without the enduser's getting to say whether they want it or not, and if so what *sort* of security they want, is like the application of handcuffs to newborns, without the parents getting the handcuff keys immediately (or the option of no handcuffs whatsoever!). The reason some folks -- not me personally since actually I would love to have RestrictedBoot applied straight from the hardware-factory which only permits software to install if it has been signed with my personal pubkey i.e. no win9 and no bloatware and no trialware and so on -- but the reason some folks complain about SecureBoot just as loudly as they complain about RestrictedBoot is that, invariably from what I have seen, it works just like the handcuff model.
The enduser has to *work* to get the wrong keys out, and the right keys in. The evil adversary gets what they want for free ... by default ... and the public at large, not savvy in the ways of lockpicking, eventually gets used to the idea that all iPhones, then all tablets, then all PCs just *ought* to be locked-down vendor-software-only disposable-every-six-months special-purpose kiosk-devices for content-consumption and spyware and nothing more.
So, while I agree with your technical stance on SecureBoot as a conceivable advantage, I think you're missing the bigger picture. Namely, that whether you call it SecureBoot that the savvy consumer can bypass, or RestrictedBoot that the savvy firmware-modder can bypass, they are in the same basic category: bad things the evil adversary did, before you had a chance to stop them, and now must be undone, or lived with.
Hint -- if 98% of the population lives with it, then the marketshare of Linux on the PC will be 2%... just like now. When you buy a PC that comes pre-installed with Win/iOS/bloatware, you have 'freedom' to undo that stuff, and install what you really wanted in the first place. But there is a difference between freedom without intentional freedom-blocking-hinderances installed at the factory by default, and the *true* situation we live in.
I'm not saying you're wrong, mjg. SecureBoot *is* distinct from RestrictedBoot, for those of us paying close attention. But when what you get from the factory is invariably RestrictedBoot by default, and converting that state into *actual* SecureBoot requires hours or days or forever, depending on the difficulty of the out-of-support-contract firmware reconfig / not-well-documented firmware upgrade / unauthorized-and-warranty-voiding firmware mod, then you are not talking about freedom by default. You are talking about the possibility of jailbreaking... but the default should not be jail.
The default should be PlainBaby, or SecureBaby with keys supplied by the parents (and not copied at the hospital), because RestrictedBaby-by-default will someday soon lead to a world of RestrictedBaby-take-it-or-leave-it. We already live in that world with many phones, tablets, digicams, televisions, auto-puters, and whatnot. I want *that* world to get smaller and smaller, not grow and grow until it encompasses laptops and desktops and servers and everything.