zlacker

[parent] [thread] 7 comments
1. arnarb+(OP)[view] [source] 2024-12-27 01:16:34
Chrome on desktop did: https://developer.chrome.com/docs/identity/webauthn-signal-a...
replies(3): >>jessee+Ei >>1oooqo+P11 >>compoo+Le1
2. jessee+Ei[view] [source] 2024-12-27 06:37:56
>>arnarb+(OP)
Nice seeing you here! :)
3. 1oooqo+P11[view] [source] 2024-12-27 15:52:13
>>arnarb+(OP)
now just 27 absurdly insane implementation hacks to solve.

webauthn is the only spec born like a 60 yr old legacy technology with global adoption. everything about it is insane.

they didn't even think about having more than one key plugged in (mostly because the use case was just so that the device own your identity so they never thought the use would have control over the hardware), and the solution is to just blink all the keys and use the first one the use touches while hoping the other keys with timeout before the use actually have to use them. so much insanity.

replies(1): >>arnarb+LQ1
4. compoo+Le1[view] [source] 2024-12-27 17:14:23
>>arnarb+(OP)
chrome is a child's toy with MV3. lmk when it's in a real browser!
replies(1): >>surajr+WD1
◧◩
5. surajr+WD1[view] [source] [discussion] 2024-12-27 20:00:15
>>compoo+Le1
What extensions do you use which are not supported under mv3? I'm sure there are some chromium forks like brave which will also get this support for free.
replies(1): >>aspenm+Oa3
◧◩
6. arnarb+LQ1[view] [source] [discussion] 2024-12-27 21:41:29
>>1oooqo+P11
“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.

replies(1): >>1oooqo+Jm2
◧◩◪
7. 1oooqo+Jm2[view] [source] [discussion] 2024-12-28 03:18:30
>>arnarb+LQ1
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.

◧◩◪
8. aspenm+Oa3[view] [source] [discussion] 2024-12-28 14:50:40
>>surajr+WD1
If I had to guess, uBlock Origin.
[go to top]