[bri3d]

The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).

BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.

[veeti]

Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.

[Groxx]

Yah, it seems blatantly hostile how much they hide it.

I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.

But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.

[bri3d]

For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.

It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.