Back

This is a particularly painful and comprehensive example of an industry-wide trend, which is that vendors are expected to deliver things as fully-formed, self-explanatory products. Users, already justifiably wary of the upgrade treadmill, reflexively flinch away from anything that looks like a big learning investment, which means "user education" is treated as a sort of taboo, something that *cannot* be made a prerequisite to using a product, because if you're explaining, you've already lost.

The failure of passkeys to date is a particularly dramatic example of this because it's extremely high-stakes, visible, and black-or-white (you're either switching your auth to passkeys or you aren't, whereas other apps you may use in a casual or incorrect capacity). But the same problem exists in other domains, and it's almost as bad.

Almost every communication technology is like this. Email is bad so we *still* keep getting new email clients that try to "solve" email (or chat apps; remember when slack was going to "solve" email?). Don't worry, don't change your habits, you don't need to learn anything, just click this button. We made a "promotions" tab, and an "important" tab for you, so now you won't be overloaded. Just consume product, don't learn to be a better communicator. Here are some suggested AI replies.

People need to develop sophisticated strategies and think deeply about their values and goals when using social media, but the only response that social media companies have to this is to introduce features or to constantly tweak their recommendation algorithms. Disinformation? Oh, that's okay, we'll block the word "suicide" so now everyone starts saying "unalive yourself in minecraft", great, teen mental health is solved. No need to have a difficult conversation about norms and pedagogy.

I can't blame companies; users really do reflexively avoid learning, and have been conditioned to see their primary feedback mechanism as switching apps. If your app requires learning, you'll see massive churn and be harshly punished for that. I definitely can't blame users, who avoid learning because developing deep expertise with modern apps is rewarded by having your brains scrambled with constant A/B tests of everything being reshuffled to suit the users who *don't* put in effort.

In a way, you can see the passkeys community pushing *against* this trend, trying to acknowledge this need, developing resources like https://webauthn.io to allow users and developers to cultivate a structured understanding of the technology as a whole, decoupled from vendor-specific solutions. But the ingrained product development habits from every vendor undermine this.

@glyph I'm going to add something, it's not as big as the other problems you raised but I think it's a problem: Someone, somewhere, set it up so the non-vendor-locked version of passkeys so it *requires*, per the spec, for you to use Bluetooth, which simply means I will never use it. This is probably childish. But I am probably not the only person who hears "bluetooth" and immediately tunes out.

@mcc @glyph i am using non-vendor-locked passkeys with zero bluetooth

(keepassx supports it)

@whitequark @glyph are the passkeys stored on the same physical device that they are utilized on

@mcc @glyph yes

@whitequark @mcc I'm not really clear on what "non-vendor-locked" means here, but it sounds like people aren't paying attention to an extremely stupid corner of the spec, so: great

@glyph @mcc i am using a password manager with a browser extension that lets me do passkey logins in most places i've tried to do them

keepassx stores them in the password database, like everything else it stores

it's a normal file

@whitequark @glyph @mcc AFAICT passkeys are a half-baked solution to a non-problem that was already solved by "use a password manager and let it generate strong passwords".

@dalias @glyph @mcc PKI-based authentication is strictly better than what you're suggesting since you can no longer steal a credential (other than from the password manager), no matter what happens with the browser or the website

@whitequark @glyph @mcc That's assuming you want to store the keys on a separate device, which is a really bad idea for most normal users.

@dalias @whitequark @mcc that is one possible benefit, but a minor one. the absolute vast majority of password theft is via normal user interactions via copy/paste or data breach dataset downloads, not via targeted implants and RCE of victim endpoints.

@dalias @whitequark @mcc please, please trust me when I tell you that you cannot tell people not to copy and paste a password into a web page when their job is copying and pasting passwords into web pages all day long. people _routinely_ circumvent domain restrictions on password pasting. smart people. security-aware people. it is easy for social engineers to create synthetically exigent situations where this seems like a reasonable and obvious thing to do.

@glyph @dalias @whitequark @mcc it is actually the NIST recommendation to *allow* password pasting, because the alternative, typing it, is completely worse. Passkeys are nice because it changes that mess into an actual defined protocol.

@falcon @glyph @dalias @whitequark @mcc it also removes a whole lot of phishing risk because you aren't pasting it into a text field and i guess they can maybe mitm it but it's raising the bar (not just clipboard stealing)

@NireBryce @falcon @dalias @whitequark @mcc right; I do think that within the realm of *just* password managers, I am far less vulnerable to phishing than I once was, because "I have to _manually_ paste a password” is a sufficiently uncommon occurrence now that it's weird, a workflow i need to deliberately choose to activate, and one which causes me to slow down and start being really skeptical. I hope everyone can have this experience

@dalias @glyph @whitequark @mcc I remain on the side of usability here, primarily because password pasting is necessary when the password manager plugin fails, and in any event if you are going to have the password manager and website talking to each other properly as a requirement you would be better served with passkeys which do not require communicating the persistent secret at all.