I'd rather just have memory safety built in to the language I'm using—I'm not sure exactly what the equivalent is for passwords, but I don't think I would oppose it.
It's a hard problem. I don't think passkeys really are the solution long term, they just sweep the problem under a corporate rug and ignore that people will still use them inappropriately.
But somehow the same people arguing for ultimate freedom and OSS are also arguing for centralization of passwords into corporate controlled infrastructure.
I'm somewhat at a loss on how to argue on these issues. You want to hand over control over your key infrastructure to big tech and you want the average population to do that as well? Go ahead. Most people on iPhones already use sign in with Apple with apples 2FA system anyway it won't matter to them.
But why encroach on me and force me to use it to protect me from myself?
We will also have at least one open software implementation when this gets merged:
https://github.com/keepassxreboot/keepassxc/pull/8825
There are braindead implementations like PayPal's:
https://www.paypal.com/us/cshelp/article/what-are-paypal-pas...
that force you to use Android or iOS, but it's nothing new, they manage to fuck up everything they touch (for example, U2F 2FA only supports registering one hardware key and it has been that way for years).
"Big Tech" does not control Passkeys beyond the work on the underlying WebAuthn spec https://www.w3.org/TR/webauthn-2/, and that they develop implementations of that spec.
Can you expand on these 2 points? I'm still trying to wrap my head around passkeys and these are some of the arguments I see around but never quite explained.
Because if this passkey stuff takes off with normal people, 98% of passkeys will be stored in cloud accounts with those providers.
The weakest link in the security chain is the procedure for when the user forgets their password / loses their phone / gets a rootkit / gets phished / has their e-mail compromised. You can transfer that problem from your site to a cloud provider and hope they do a good job - but the problem doesn't go away.
They will also (and primarily) be stored in the individual devices, and don't need cloud access to the providers in order to be used.
In this sense, it solves one of the main issues with third-party sign-in, i.e. that if the provider decides to lock your account, you get locked out of any linked services.
> You can transfer that problem from your site to a cloud provider
With passkeys? How so? Are passkeys not just cryptographic key pairs? If your service associates a certain account to a certain public key, there's nothing an external cloud provider can do to solve the issue you describe.
It's possible I've missed something, like I said before I'm still wrapping my head around the whole thing.
Without passkeys, if one of my users lost their "second factor" (e.g. lost phone) I had to provide a flow for them to get into their account despite that, while remaining secure.
With passkeys, users can restore their "second factor" from a cloud backup, so long as they can get access to that cloud backup. Hence, my lost-second-factor flow is outsourced to the user's cloud provider.