The actual FSF definition of an abstract-but-nominally-UEFI-based SecureBoot (as opposed to non-UEFI plain old legacy boot which they also define) is this: "sure-fire way" for the enduser to be able to install Linux/etc on the device, themselves, with keys they select and trust, themselves. See the fsf.org link in second paragraph of the original article.
I would argue that the current approach does not qualify as a "sure-fire way" to freedom, no matter how we interpret that phrase: what we have right now is RestrictedBoot-on-by-default, but if you are savvy enough to figure out details of your particular firmware via the internet, in an hour or two you can jailbreak your machine and get it back into PlainBoot and/or actual-UEFI-style SecureBoot.
Unfortunately, the FSF definitions omit the use of adjectives like easy / obvious / userFriendly / simple / straightforward / wellDocumented / completelySupported / noGooglingRequired when they talk about the good kind of SecureBoot, as they were imagining it in the abstract. (The FSF article in question was written before hard details of UEFI-in-practice were known, methinks.)
no subject
I would argue that the current approach does not qualify as a "sure-fire way" to freedom, no matter how we interpret that phrase: what we have right now is RestrictedBoot-on-by-default, but if you are savvy enough to figure out details of your particular firmware via the internet, in an hour or two you can jailbreak your machine and get it back into PlainBoot and/or actual-UEFI-style SecureBoot.
Unfortunately, the FSF definitions omit the use of adjectives like easy / obvious / userFriendly / simple / straightforward / wellDocumented / completelySupported / noGooglingRequired when they talk about the good kind of SecureBoot, as they were imagining it in the abstract. (The FSF article in question was written before hard details of UEFI-in-practice were known, methinks.)