Passkeys do have a (partial) solution to this problem: multi-device credentials. See the videos at the bottom of [1].
Say you install an app/visit a website on your phone and register an account with a passkey. My current understanding is that on iOS 16, the passkey lives in your iCloud keychain. If you want to sign in on a Mac on Safari, you can just visit the website and the discoverable credential from your phone will appear when you try to log into the site with webauthn. The website will be able to tell that you're logging in from a new device and optionally require additional authentication.
If you want to sign in on a device that doesn't have access to your keychain, you can use your phone as an authenticator over a combination of Bluetooth and a tunnel server by scanning a QR code on that device with your phone. The site is then supposed to prompt you to register the new device with whatever its local passkey solution is.
The best source I could find for how this protocol works at a technical level is an episode of "Security. Cryptography. Whatever" on passkeys. I guess the specs aren't exactly public yet (at least since I last checked) and are only available to fido alliance members.
I've been trying to work on figuring out ways to build a "passkey manager" of sorts to live up to the potential webauthn offers with hardware-backed credentials that are also synced and backed up (to an offsite key). As far as I can tell, as mentioned in another comment, this just doesn't seem to be a priority for the fido alliance, which is a real shame.
I'm cautiously waiting to see how 1Password deals with passkeys, given that they're one of the few FIDO members with a vested interest in being cross platform, but I'm betting they'll just implement a software keystore built into their current vaults without any hardware backing.
That's essentially what passkeys are: a consumer-friendly name for on-device FIDO keys you can use over webauthn, along with (in the apple/google/Microsoft case) a mechanism for syncing/backup/recovery provided by your platform account provider. The keys are still backed by hardware, but instead of an external key it uses the internal platform security module (TPM, Secure Enclave, etc.)
You can use your phone without the syncing part to authenticate other device through a mix of a QR code, a tunnel server, and Bluetooth.
Nebula has also recently started selling skillshare/masterclass-esque classes in addition to the main video platform product. Many (maybe all???) are taught by existing Nebula creators.
The classes are advertised on the Nebula homepage to subscribers, but require additional payment.
Isn't it better to leave them exposed and make it easier for security researchers who genuinely want to test the chip? Someone interested in and capable of developing and using/selling an exploit won't be deterred by needing a special cable to get a UART console, whereas a security researcher might appreciate the simpler access.
So long as it doesn't weaken the actual security model, companies should make their products as easy to analyze as possible imo.
Google Pixels generally have the best support for alternate OSes, especially from a security POV. See CalyxOS and GrapheneOS, which primarily/only support Pixels thanks to their ability to re-lock the bootloader.
I doubt third party Android distributions pose any real threat to Google given that 99% of people will stick to the default.
Say you install an app/visit a website on your phone and register an account with a passkey. My current understanding is that on iOS 16, the passkey lives in your iCloud keychain. If you want to sign in on a Mac on Safari, you can just visit the website and the discoverable credential from your phone will appear when you try to log into the site with webauthn. The website will be able to tell that you're logging in from a new device and optionally require additional authentication.
If you want to sign in on a device that doesn't have access to your keychain, you can use your phone as an authenticator over a combination of Bluetooth and a tunnel server by scanning a QR code on that device with your phone. The site is then supposed to prompt you to register the new device with whatever its local passkey solution is.
The best source I could find for how this protocol works at a technical level is an episode of "Security. Cryptography. Whatever" on passkeys. I guess the specs aren't exactly public yet (at least since I last checked) and are only available to fido alliance members.
I've been trying to work on figuring out ways to build a "passkey manager" of sorts to live up to the potential webauthn offers with hardware-backed credentials that are also synced and backed up (to an offsite key). As far as I can tell, as mentioned in another comment, this just doesn't seem to be a priority for the fido alliance, which is a real shame.
I'm cautiously waiting to see how 1Password deals with passkeys, given that they're one of the few FIDO members with a vested interest in being cross platform, but I'm betting they'll just implement a software keystore built into their current vaults without any hardware backing.
[1] https://fidoalliance.org/multi-device-fido-credentials/