If you have a Google account, passkeys (FIDO2) will be enabled by default starting today. I believe this will require a compatible device like an iPhone, Android, or a web browser/OS/PC combination like Windows 11 with Windows Hello and Chrome.
While I support passwordless authentication, using a dark pattern is bad and excluding free software users is bad.
The article gives this URL as a way to disable passkeys–for now.
https://myaccount.google.com/signinoptions/passwordoptional
My primary objection to Passkeys is that they are confusing even to technical users. It’s good to have the option, and it’s good to push the option, but it should not be the only option.
There was a lot of discussion about this on the GrapheneOS forums a few months ago: what is your opinion on the "new" passkey release of google? - GrapheneOS Discussion Forum
One point to touch on is that Apple implements passkeys through iCloud Keychain. If you aren’t aware, you can’t transfer the keychain to an Android or non-Apple device. If you later move to an Android device like I did and don’t use a computer with macOS, you need to completely re-create your passkeys because Apple doesn’t trust you with the secrets. It’s not like you can extract them.
So this point is actually false in the case of Apple:
Since phone based passkeys sync across all of a user’s devices, the process of upgrading to a new mobile phone is a seamless transition.
But that’s just Apple. Google probably won’t implement it in a stupid vendor lock-in way. Hopefully. Other vendors might implement passkeys in this way too.
On the subject of the safety of passkeys, a friend told me about a phishing scenario and I posted this:
This seems more and more possible to me because most people don’t understand how passkeys work. But I don’t know how hard it would be to convince somebody to hand over their Google logins. Right now, the only thing compromised is Google (so handing over logins is already equal to account compromise), but in the future, lots of services might require or encourage passkeys. Android users would be using their Google accounts for those passkeys, so the attack surface could be very large.
Edit: God, I must be half-asleep. Because Google might make it mandatory to login with passkeys in the future, that would take care of this scenario. So it seems like something they’ve considered. The problem with this is that there are actually scenarios where you’d like to share accounts, but also not share your entire passkey collection. For instance, sometimes businesses use your Google account to perform a service. If you have separate personal and business Google accounts, that might be okay, but you need a separate phone number for each of them.
…and uh, forgive me if I posted all this stuff before. My memory is awful.
I’m not a Google user (aside from updating my banking app from Google Play), but I agree this would be bad. I think this is the part you’re referring to:
This would be annoying. The wording is a bit strange, though (“built-in platform authenticator”), which suggests it might be possible? I don’t even know if GrapheneOS would support this…
Your last link suggests that passkeys actually work, but only on non-Firefox (KHTML descendants) browsers. This would also be annoying, as I use Firefox, but at least it would be usable.
If Apple, Google, and Microsoft implement passkeys like this, it serves to tether people to these companies. Some people have made the argument that passkeys are interoperable between all Apple, Microsoft and Google devices, so it won’t lead to tethers, but not all people use those devices and operating systems. GNU/Linux is a major exception. It’s a shame that security is often used as an excuse to tether people to proprietary platforms…
It looks like there is some acknowledgement of the need to share passkeys.
You can use AirDrop to securely share passkeys … for website and app accounts with someone using an iPhone, iPad, or Mac.
I believe the argument against stealing passkeys is that you’d have to authorize the remote attack:
When you turn on iCloud Keychain on an additional device, your other devices using iCloud Keychain receive a notification requesting your approval of the additional device.
Also, passkeys are not a substitute for hardware FIDO2 keys, like YubiKey, which don’t sync and which can be protected by a self-destructing PIN depending on the model of the key. That’s what is still recommended for corporate security.
To put this into context, Apple, Google, and Microsoft hardware will have access to their version of a secure coprocessor, encrypted storage, and a method to unlock these like fingerprint, face unlock, or PIN. The combination of these three technologies (processor, storage, and authentication) is referred to as a built-in platform authenticator in the FIDO documentation. Together, these protect and authenticate access to passkeys stored locally. Most of the convenience of passkeys (passkeys are the big tech version of FIDO2) depend on built-in platform authenticators.
Keep in mind, that the presence or absence of a TPM chip is a different issue from the steps and hardware you use to authenticate. I just want to emphasize there are two distinct issues related to built-in platform authenticators: Is it there? vs. Do you use it?
For example, if you choose the scenario where you use passkeys with only a desktop and no phone then it looks like a built-in platform authenticator is required.
As you know, Linux is a volunteer project focused on transparency and freedom. Technologies like TPM and face unlock infringe on these core goals. So, no one ever contributed a built-in platform authenticator to Linux. Therefore, the underlying support for passkeys is not present on Linux. And, this explains the big “no” signs in the Google documentation linked in my original post.
Another link in my original post refers to the combination of Ubuntu, Chrome, and QR codes (using a phone as a “roaming authenticator”). That’s one option if you want to access a Google account with a passkey from Linux. By using your phone, the Linux desktop doesn’t need a built-in platform authenticator.
Yes, this is correct and where things appear to be going. While FIDO2 is platform agnostic, passkeys were created with vendor lock-in and look set to stay that way. This is a shame.
In time, I hope that support for FIDO2 will improve within open source software. As far as FIDO2 and the FIDO Alliance is concerned, the door is open. But, I don’t expect passkeys to be supported on Linux. And, without a big tech daddy, synchronizing and other conveniences will be fewer on open source platforms (back up your FIDO2 secrets).
It looks like there is some acknowledgement of the need to share passkeys.
Oh, that’s good to hear from a business perspective of needing to manage client’s accounts. AirDrop is a very inconvenient way of doing it, though, as they require your physical presence. It’s also not good to hear that Apple requires you to to use an Apple device to make use of it, but at this point, not surprising.
I believe the argument against stealing passkeys is that you’d have to authorize the remote attack
I just thought of this today. Yes, that would be the simplest approach and most phishing attempts would be thwarted by a properly-worded approval request. So in this respect, phishing is much harder 
Also, passkeys are not a substitute for hardware FIDO2 keys, like YubiKey
That’s what I use and prefer. This page explains that Yubikeys also support passkeys.
The combination of these three technologies (processor, storage, and authentication) is referred to as a built-in platform authenticator in the FIDO documentation.
You seem to have a better grasp on it than me, because my head is spinning when I try to wrap my head around it all 
The TPM serves as the secure coprocessor, right?
As you know, Linux is a volunteer project focused on transparency and freedom. Technologies like TPM and face unlock infringe on these core goals. So, no one ever contributed a built-in platform authenticator to Linux. Therefore, the underlying support for passkeys is not present on Linux.
(I assume the technologies required to support built-in platform authenticators needs to be implemented mainly in the kernel)
The Linux kernel is actually one of the largest corporate collaboration projects in existence. Probably the biggest, actually. Just look at this insane list of corporate members for the Linux Foundation: Members of the Linux Foundation
The amount of volunteers working on the Linux kernel is tiny compared to the amount of paid programmers. In reality, I don’t think the Linux Foundation (and Linux stewards by extension) have any compunction about implementing support for passkeys. The reality is they just don’t have any reason to do it because they view Linux as only being incorporated in server OSes (and AOSP, but that’s not mainlined yet). Red Hat is the most likely candidate to implement it, but they’ve been winding down their desktop projects over the past year.
That’s as it relates to the kernel. Of course, I would be interested to see the LF’s perspective, but all I could find was this post about a completely different passwordless protocol. You’re likely right about the issues with TPM and transparency for other developers/maintainers for core software that interacts with Linux. It’s not a discussion I’m equipped to have because I just don’t understand it! Even after spilling so much ink about passkeys, TPMs, and whatnot, I’m not ashamed to admit that haha.
By using your phone, the Linux desktop doesn’t need a built-in platform authenticator.
Ah, right. I wonder if GrapheneOS supports passkeys in the way websites require. It would have the required hardware and secure unlock method. This thread suggests it will not:
In time, I hope that support for FIDO2 will improve within open source software. As far as FIDO2 and the FIDO Alliance is concerned, the door is open. But, I don’t expect passkeys to be supported on Linux. And, without a big tech daddy, synchronizing and other conveniences will be fewer on open source platforms (back up your FIDO2 secrets).
Sigh. I noticed Bitwarden has routinely missed any chance to mention what the support will be like on Linux-based operating systems, but they’re planning to launch this month, so we’ll see. I am not looking forward to the passwordless future, approved by Google™, Apple™ and Microsoft™.
I was able to find several password managers that support passkeys across platforms. On Linux, they work via a browser extension. Third-party passkey managers work on iOS 17 and Android 14. Synchronizing is a paid feature.
If you decide to go the security key (hardware USB authenticator) route, keep in mind two things.
Security keys can only store a small number of passkeys. This will be listed as a limited number of FIDO2 or resident keys. A resident key (discoverable credential) is required to log on without providing a user name or password. I’ve seen numbers like twenty-five total FIDO2 credentials per security key.
Make sure your security key is compatible with CTAP 2.1 and not CTAP2. CTAP2 requires you to erase your entire security key to remove any FIDO2 credential. That would lock you out of all your accounts. CTAP 2.1 added the option to remove credentials individually.
Yes.
From PC building, a trusted platform module (TPM) is the root of trust on a personal computer (PC) and can be used to store and manage secrets like passkeys. In practice, TPMs would be how Microsoft Windows secures passkeys on a desktop computer. I believe Apple’s branding is “Secure Enclave” (built into current Apple A and M chips) which replaces the older “Apple T2 SoC” (a coprocessor for Intel macs). I am not familiar with Google or Qualcomm’s branding. But they must have hardware which serves the same purpose.
Coming from a PC background, I use TPM as my generic catchall term for FIDO’s built-in platform authenticators.
My limited knowledge leads me to believe that this is the Titan M chip:
Secure Enclave / Secure Element (SE)
An optional hardware component designed to be protected from all other components on the device and from physical attack, as defined in Introduction to Secure Elements.This includes the Titan-M chip present in some Android devices.
Thank you for the explanations!