zlacker

“They” in this case included me and this was a deliberate fix for poor UX many years ago. We definitely thought about it and we used to blink only the key that had a credential from the allow list, because like you we thought that made the most sense. But people got routinely stuck because they just tapped a different key out of habit and nothing happened. There was no way for the browser to tell them “not that key”. Best case the reports would say the key was dead because it didn’t blink.

We changed it to blink all keys, so that if you tap the wrong one, the browser can at least tell you something sensible and get you unstuck. This wasn’t a hypothetical shot in the dark, but something we tested and actually worked well for real users.

I don’t disagree that WebAuthn has grown well beyond anything we could call good spec design. But it’s worth remembering that there’s /a lot/ of context behind it, and that the average user doesn’t behave anything like an average HN reader.

> hoping the other keys with timeout before the use actually have to use them

Both Chrome and Android will cancel requests to all other keys. If your keys are locking up until a timeout it’s more likely the key itself is buggy.

>>arnarb+(OP)
that's the kind of compromise you don't want to see on authentication code though.

that's just the one i hit yesterday. Making software do crazy things "for the uneducated user" is a sure way to alienate both.

but anyway. what bothers me most about passkey is that tomorrow someone will realize requiring passkeys trhu google and apple only, cuts spam more than captcha. it will happen and everyone knows it.