Adam, thank you for your (surprising) answer. You seem to agree with me, I'm summarizing what you wrote (quoted at the end of this toot), I joke you not:

——{
If you don't want to risk losing them, don't use ANDROID passkeys!

Instead, use a third party solution (requiring Android 14+)...
}——
 
 
*GOOGLE AUTHENTICATOR MISTAKE*
Please have a look at the weird distribution of ratings of Google Authenticator (https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2); score : aproximate percentage of voters:

5 : 55%
sum of 2,3,4 : 20%
1 : 25% <——— note!

MOST people who voted "1", appear to have done that because, after losing (access to) their smartphone, they ALSO lost access to their (2FA TOTP-protected) accounts.

According to their reactions, most of them are PISSED; nobody warned them beforehand of this risk that TOTP secrets were not being backed up (this was changed last year; however, insecurily according to, in German, https://www.heise.de/news/Google-Authenticator-Geraeteverschluesselung-versprochen-aber-nicht-geliefert-9065547.html ).

Unfortunately, Google is making the same mistake with passkeys.
 
 
*RELIABLE LOGIN CREDS BACKUP*
Note that some security-aware people (such as I try to be) make backups of their TOTP secrets, which is POSSIBLE (I save QR-code screenshots in a password manager).

However, users CANNOT make backups of their Android passkey secrets. Therefore, if there is even the slightest chance of losing passkeys, users should ensure that a -usually PHISHABLE- alternative exists for logging in to each of their passkey-protected accounts.

Unfortunately, way too many people forget or lose "rescue codes" etc. because they hardly ever use them.
 
 
*PROMISING PASSKEY SECURITY*
The PROMISE of passkey security is relatively good, in particular for users who don't know how to choose, install (and properly configure autofill in order to prevent phishing) and use a third party password manager, and know how to backup its database (and actually make sure that this happens).

Therefore I fail to understand why it would be more important to provide an "optimal experience" to SECONDARY users of Android devices, rather than that PRIMARY users risk losing their passkeys.

Also, passwords are NOT deleted on my device when I tap "clear data"; why not?
 
 
*ARNAR WROTE*
Arnar Birgisson wrote in https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html :
——{
Passkeys in the Google Password Manager are always end-to-end encrypted: When a passkey is BACKED UP, its private key is uploaded only in its encrypted form using an encryption key that is only accessible on the user's own devices. This protects passkeys against Google itself, or e.g. a malicious attacker inside Google. Without access to the private key, such an attacker cannot use the passkey to sign in to its corresponding online account.

Additionally, passkey private keys are ENCRYPTED AT REST ON THE USER'S DEVICES, with a hardware-protected encryption key.
}——
 
 
*MISLEADING DOCS/INFO*
Google's passkey documentation and your statements are incomplete, confusing and extremely inconsistent.

If passkeys are "encrypted at rest on the user's devices, with a hardware-protected encryption key", why would I care if they are synced to somebody else's account, if the other person DOES NOT POSSESS the hardware-protected encryption key?

Also, you wrote: "when they sign in on a device", "someone else signs in on their device": What Do You Mean?

Maybe someone else using the owner's screen unlock code, or signing in to an alternative Android account, or "sign in to Chrome" (whatever that means - I can imagine "signing in to" (unlocking) a /password manager) and/or switch the Google cloud account associated with the device?

As if granting another user access to your Android account on your Android device is not an extremely stupid thing to do (from a security perspective) anyway?
 
 
*JUST DON'T*
That is, unless you can trust the other user for 100% (which you never can): DON'T DO IT!

For example, your kid or grandchild may obtain access to content that your phone claims the owner is old enough for; spoofed "age verification" is just one of the increasing risks of storing "electronic passports" in smartphone "wallets". They may also steal your identity in many more ways, such as sending emails or messsges in your name, or add their credentials to your accounts (including banking apps).
 
 
*IN FACT, ARNAR AND DIANA WROTE*
Arnar Birgisson and Diana K Smetters wrote in https://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html :
——{
In fact, if you sign in on a device shared with others, YOU SHOULD NOT CREATE A PASSKEY THERE. When you create a passkey on a device, anyone with access to that device and the ability to unlock it, can sign in to your Google Account. While that might sound a bit alarming, most people will find it easier to control access to their devices rather than maintaining good security posture with passwords and having to be on constant lookout for phishing attempts.
}——
 
 
*CONCLUSION*
When/where did Google forget about KISS?

Why did (when Android 14 was not even available), and does Google promote passkeys - if there are even multiple ways of -unexpectedly- losing them (in my FD article I provided 3 examples) without being able to backup them by yourself?

Suppose a user, now knowing this, wants to switch from Android passkeys to, for example, Bitwarden: how do they transfer them?

Why are you not even interested in the rest of my findings?

Unbelievable.
 
 
On Feb 28, 2024, 23:30, Adam Langley (@agl) wrote:
——{
The other side of having data live on devices and using the account as a sync channel is widespread user confusion when they sign in on a device and are upset to find that their data remains on the device even after they've signed out. Or when someone else signs in on their device and their data syncs up to the other person's account.

I understand that one model isn't going to work for everybody, and Android 14 supports pluggable passkey providers so that nobody is locked into using Google Password Manager. But GPM passkeys are conceptually part of the account and clearing the account does clear them. I'll continue to try and push that our wording is consistent on this point. We'll be replacing the reset flow for passkeys in the coming months to be more specific and narrower in scope. Given that, we can be very clear about the consequences of resetting things. But while we might disagree about how Google Password Manager passkey should work, I know we do have a bug for accounts with custom passphrases. It is at least not causing data loss, but it does make the credentials inoperable. And we just need to damn well fix that and any other issues. We knew about it prior to your report but thank you for the report anyway: clear bug reports are rare.
}——