> And again this presupposes that you can disable Secure Boot, boot a malicious OS from another drive, fool the user into entering their password, automatically reboot, enable Secure Boot, boot into the legit OS, then come back later and have the ability to boot the OS yourself and log in as the user (because again, you don't have the decryption key, you have the user's login credentials).

But that's the same thing that happens with full disk encryption. They come get physical access to the machine but don't have the decryption key yet so they compromise the unencrypted part of the machine which is what prompts you for it, have that capture the key when you enter it, and now they have the key when they come back to use it.

If anything allowing the short password is even worse, because if you leave your machine in suspend you expect it to prompt for your unlock password but not the full disk encryption key when you come back, so the latter would be suspicious but the former doesn't let them unlock the disk, and now you're using the short password for both.

> You are also presupposing what the TPM is bound to. I don't use Windows, but using systemd-cryptsetup I could configure a TPM to bind to the drives in the system; in this way, it will refuse to boot my legit OS while your malicious disk is installed (well, it will demand a recovery key). Again, setting off alarm bells, and if I discover the disk with my recorded credentials before you can physically access it, I can just destroy it.

Except that it doesn't need to be installed once you're at that point. By then it has already captured your credentials and stored them or sent them to the attacker over the network, so it can disable that device right before it goes to boot into the original operating system.

Also notice that the original premise was to make it easy for ordinary users and now the workaround is to install Linux and change a setting that will confuse people as soon as they leave their own USB stick plugged into their computer.