secure boot
@freakazoid Right, and that is a legitimate issue, but - and this is the crucial point - that is first and foremost an *operating system* problem.
There's so much more that operating systems could be doing to be much more resilient against this type of issue, like capability security, but aren't. Instead, the problem got shifted to firmware, even though that's a much worse place to address it in in many ways.
(Also: something that fucks with the boot chain can still be removed. There's nothing that makes that *fundamentally* harder than any other kind of software repair, and with sufficient-yet-imperfect security on the OS level, it would be a rare enough occurrence that it can be trivially handled through all the usual repair venues.)
secure boot
@freakazoid I guess my more fundamental point here is that the situation with secure boot is similar to that with a lot of snakeoil.
If you start by assuming secure boot, you can certainly retroactively find reasons and justifications why it might be useful. But if you started with a *problem statement of end-user security*, and asked what the most effective and efficient solution would be, you would never end up at "secure boot" as the answer.
That sort of situation is a very reliable red flag for a bad technology choice, often one that has been argued for for undisclosed other reasons rather than the stated one (and I suspect that the 'DRM' and 'corporate hardware' cases are those reasons, here).