> Passkeys created on Android are backed up and synced with Android devices that are signed in to the same Google Account, in the same way as passwords are backed up to the password manager.
I don't like this. Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration. I certainly don't like the lack of emphasis on interoperability from the get go.
I do not like this future.
Also it seems that Linux is completely out of the picture.
The Android implementation allowing for multiple third part passkey providers (typically, existing password manager that want to support passkeys) is in beta.
Apple does not pre-announce features, so we are all likely in the dark on their timelines, and whether their timelines extend to infinity.
However, I believe a passkey manager can replace the system implementation via the web extension mechanism in mobile Safari today.
It is all user terminology for Web Authentication features, so credentials stored on a current Yubikey are also "passkeys".
There are multiple open source security key hardware implementations that support the published specs.
There are multiple password managers that have started to implement "passkey manager" functionality - 1Password and Dashlane have made announcements here and have published code and Web Extensions for desktop.
Android 14 beta has a system API where software providers such as 1Password and Dashlane can work with this system, not just for Chrome but for installed applications.
I doubt Google's Password Manager will ever be open sourced, but it doesn't need to be for an interoperable ecosystem.
Assuming there is an ecosystem where they can play equally, I suspect they will find all sorts of ways to provide unique value. Their goal shouldn't to be the preferred system across all of Android or iOS, but to offer something a lot of people are willing to pay for.
what you described above doesn't guarantee that the ecosystem is interoperable. With passwords, there is no way for the service provider to hide the cleartext password from you, this is inherent to the way passwords work. With passkey, a service provider could decide to hide the private keys from you, effectively locking you into their ecosystem, and there is nothing you could do to avoid this.
There's no guarantee that they will act in a user-beneficial manner, except they all already exist and already act in a user beneficial manner, and that there is no strategic benefit of acting in a user-hostile manner.
> With passwords, there is no way for the service provider to hide the cleartext password from you
Sure there is. They could refuse to do anything but form fill the passwords on registration and authentication pages, where the field in the browser will not allow you to copy the password back out.
The force that keeps them from doing such user-hostile behavior for lock-in today is that nobody would want to use that system. They would not use that vendor. It would be product suicide.
> effectively locking you into their ecosystem, and there is nothing you could do to avoid this.
Unlike passwords, sites are encouraged to allow you to register multiple passkeys. Some sites may push the user to do this for convenience, such as if they see user utilizing a security key or phone to authenticate into their desktop when the desktop is capable of doing passkeys directly.
This gives a whole new ability to jump ship if you decide you don't like your software vendor.
Now, there is a parallel question of "what if a vendor uses their monopolistic power to prevent an ecosystem from being created, and then acts in a user-malicious manner". I suspect they would quickly get multi-national scrutiny.
You can, but most people won't because they will be locked-in, this is not the case with passwords as it's quite easy to change password manager without having to reset all your passwords.
This is not a remote possibility. It happens to thousands of people every day, for entirely frivolous reasons.
Until there is some authentication system that is genuinely robust to corporate control attacks, I'll keep using the imperfect password manager model.
You can for example use a Yubikey, on a Linux desktop system, to authenticate to services implementing the "passkey" standard. Does Google own my Yubikey in some way that I'm unaware of?
Nothing is owned by Google or Apple or Microsoft, there is no grand conspiracy trying to lock you into a platform.
Try educating yourself before spreading misinformation, and before assuming that everything is an Evil Conspiracy by Big Tech.
I tried to do some research myself, but there's no Wikipedia page for "passkeys" and they aren't mentioned on the Yubikey article.
Edit: this user has a helpful comment: https://news.ycombinator.com/item?id=35810144
> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
I'd love to know more about how / whether these challenges are enforced as part of an open standard, or whether it's up to individual implementers of passkeys to roll their own.
The list of members of the FIDO alliance is public. It includes what most people refer to as “big tech”
Also I am not sure that I would consider not being able to access private key material from a enclave vendor lock in, since that's the entire purpose of the device.
I guess the same people arguing that passkey is a conspiracy are the same ones that think secure boot and TPM is a Microsofts conspiracy to prevent you from installing Linux.
They are an improvement for service providers, sure, but not for users, due to vendor lock-in. This was my initial argument from the start.
You kept countering with arguments such as "you can use a FOSS client", "but Google is a contributor to open source" or "Google can't access your Yubikey" - which are irrelevant to my point, which is that the new standard introduces further vendor lock-in.
In addition you resorted to personal attacks - calling me and other users in this thread conspiracists or uneducated - but could not counter any of the points we were making with valid arguments.
My understanding is that the private key is stored on your own device, unless you decide to use something like iCloud Keychain (which should be encrypted).
The public key, on the other hand, is stored on the service providers' servers. That is used to create a "challenge", which I guess on your phone you will need to "decrypt/sign" with the private key to prove that "it's really you".
That's how I understand it.
How convenient!