We should have the ability to run any code we want on hardware we own

> In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware

It doesn't work. Everything from banks to Netflix and others are slowly edging out anything where they can't fully verify the chain of control to an entity they can have a legal or contractual relationship with. To be clear, this is fundamental, not incidental. You can't run your own operating system because it's not in Netflix's financial interest for you to do so. Or your banks, or your government. They all benefit from you not having control, so you can't.

This is why it's so important to defend the real principles here not just the technical artefacts of them. Netflix shouldn't be able to insist on a particular type of DRM for me to receive their service. Governments shouldn't be able to prevent me from end to end encrypting things. I should be able to opt into all this if I want more security, but it can't be mandatory. However all of these things are not technical, they are principles and rights that we have to argue for.

This is the crux of the matter.

Maybe conceptually you will be able to run some kind of open operating system with your own code, but it will be unable to access software or services provided by corporate or governmental entities.

This has been obvious for some time, and as soon as passkeys started popping up the endgame became clear.

Pleading to the government definitely can't save us now though, because they want the control just as much as the corporations do.

> as soon as passkeys started popping up the endgame became clear

That's why I'm 100% against passkeys. I'll never use them and I'll make sure nobody I know does.

They're just a lock-in mechanism.

"Passkeys" is a new brand name slapped on an older open, interoperable technology, so it's difficult for me to be "against passkeys" as they haven't fundamentally changed anything.

Before the branding they were known as FIDO2 "discoverable credentials" or "resident keys".

Two things have changed with the rebrand:

1. A lot of platforms are adopting support for FIDO2 resident keys. This is good actually.

2. A lot of large companies have set themselves up as providers of FIDO2 resident keys without export or migration mechanisms. This is the vendor lock-in part (no export feature), but it's not a feature of the underlying tech itself.

Fwiw FIDO are actively working on some standard for exporting/importing keys so that's something.

If you want to use passkeys without lockin, just use Bitwarden or KeepPassXC - they all have full support. Or you can also store a limited number of passkeys on your FIDO2-compatible hardware key like Yubikey or the open-source Nitrokeys.

Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407

> trying to pressure KeepassXC to remove exporting passkeys in an open format

I'm not sure that's an entirely accurate representation of the request? At least from a quick skim the claimed issue is being able to export keys in plaintext. For example, from the issue author:

> I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption.

And later:

> > Besides, determined advanced users could just write code to decrypt the kdbx file and extract the passkeys anyway.

> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.

> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.

To me that doesn't sound like they're requiring a proprietary format. Something like AES encrypted JSON sounds like it'd work as well, and that sounds pretty "open" to me?