Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @shaoyu@mastodon.social
ori@ori@hj.9fs.net (2026-07-22 12:01:24)
It's public key cryptography, not a simple password. The private data is not sent over the wire, so it can't be stolem. I would like to have public key cryptography in use for authentication, though I have one major and one minor reservation with passkeys.

The major reservation is remote attestation: the party that I'm authenticating with should have no idea what device I'm using, as long as it follows protocol. I don't feel comfortable using a protocol with provisions for this; large tech companies have shown that they're not to be trusted, especially where there's an opportunity for lock-in.

The minor reservation is the difficulty of backup and recovery. (If the major reservation is resolved, I can run a non-standard passkey agent that backs up the way I want, so this is only an issue if someone has protocol support for constraining the devices I can use)

CC: @filippo@abyssdomain.expert @shaoyu@mastodon.social
---Reply---
Filippo Valsorda@filippo@abyssdomain.expert (2026-07-22 18:34:43)
@ori @shaoyu There are no popular software authenticator that support attestation and no major websites that constrain AAGUID (because they wouldn't work with major software authenticators). The attestation concern is purely hypothetical and has so far proven unfounded. The human cost od phishing, on the other hand, is very real.

---Replies---

ori@ori@hj.9fs.net (2026-07-24 05:40:36)
I would still be much more comfortable if the spec was updated to remove support. Hypothetical bad behavior by companies has an unpleasant tendency to become actual, especially if there's a way to use it for additional lock-in.

I don't think it's worth prioritizing holding on to a dead feature over removing things that make adopters uncomfortable.

CC: @shaoyu@mastodon.social @filippo@abyssdomain.expert