This right here. KeepassXC (PC) already had passkey support for a while, KeepassDX (Android) recently implemented support. If you use FOSS implementations, vendor lock-in and potential future corporate enshittification are non-issues.
The argument from the “it’s a trap” article is that the service you are registering to can use attestation to ensure that you are only using passkey managers that they approve.
I have to admit that I haven’t investigated this thoroughly myself but if the protocol can be abused in that way then your only choice really would be not to use the service. If it is related to banking or government services then you may not have much of a choice.
The web api for fido2/passkeys exposes attestation information.
Warning: Attestation provides a way for a relying party to determine the provenance of an authenticator. Relying parties should not attempt to maintain allowlists of authenticators.
This right here. KeepassXC (PC) already had passkey support for a while, KeepassDX (Android) recently implemented support. If you use FOSS implementations, vendor lock-in and potential future corporate enshittification are non-issues.
For now.
In some countries, banks require users use their app on IOS or Google’d Android. You can’t use their services via browser, LineageOS, GrapheneOS
Then you’re screwed anyway
The argument from the “it’s a trap” article is that the service you are registering to can use attestation to ensure that you are only using passkey managers that they approve.
I have to admit that I haven’t investigated this thoroughly myself but if the protocol can be abused in that way then your only choice really would be not to use the service. If it is related to banking or government services then you may not have much of a choice.
The web api for fido2/passkeys exposes attestation information.
from https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
I did read that part, but like you, I haven’t been able to independently verify it yet.