i would also like to have a third security model, something in between "anyone who downloads fastboot.exe can do anything with your phone" and "if you forget the passphrase you have to desolder the eMMC and reimage it with a sector level backup of OEM partitions"
(yes i know that avb_custom_key lets me do this, provided i build my OS from source, add every system app i need to the manifest, and maintain signing keys long-term. contrary to what you might expect i do not enjoy any of that)
avb_custom_key is also weird because the warning screen, despite having plenty of room, only displays 8 hex digits of the sha256 of the custom key
so...why display it at all? i think nation-state level attackers might be able to build a supercomputer that can brute force 32 bits
Displaying the fingerprint isn't a security feature right now. The device enforces that the flashed custom key (stored on the Titan M) is the only valid key for the yellow boot state. Checking the fingerprint wouldn't improve security against persistent compromise/tampering.
Only use case for the displayed fingerprint would be verifying that you didn't just install a different OS than what you intended to download and flash, i.e. it was replaced by an attacker at some point. Even if they displayed twice as many bits though, 64 bits is still useless.
On the initial generation of Pixels, I convinced them to display more bits of the signature. That was before custom keys had proper enforcement as part of the verified boot process. It was only indirectly enforced via integration into encryption key derivation before the Pixel 2.
So, back then, the displayed fingerprint actually mattered. I'm not sure why they're still including it particularly if they aren't going to include enough bits for it to serve any useful security purpose. Perhaps they just don't want to bother removing it from the specification?