this post was submitted on 12 Oct 2026
267 points (84.7% liked)

Privacy

51408 readers
679 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

much thanks to @gary_host_laptop for the logo design :)

founded 7 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Klox@lemmy.world 56 points 3 days ago* (last edited 3 days ago) (38 children)

This is some weird doom and gloom take on a real improvement in public security that we don't see very often. Of course there are a lot of stake holders. Of course every protocol is complicated. I run security for a company, and my auth systems mandate attested (i.e., company-provided) hardware keys. You're not using a passkey on my systems that I'm not providing you. Pretty simple concept, yes?

Do you have any examples of any public service requiring attested keys? No, because it really doesn't make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.

I agree it would be helpful to make the feature set clearer to the end user, but the UX are still a mess across OS and websites. IMO that's not a reason to not use them.

Passkeys are much more phishing resistant. They apply unqiue-credential best practices. I've been managing unique passwords for decades, and passkeys are a great improvement. Very few companies are going to completely remove other forms of auth, and so suggesting passkeys are ruining people's ability to share passwords is really premature. And even so, companies have been pursuing other strategies for identifying shared accounts much more effectively than shared credentials. Thinking that's a reason to not use passkeys just tells me you aren't valuing how passkeys elevate public opsec.

Passkeys are projected to overcome TOTP market share next year. That is honestly amazing. I like the writeup on the features, but this nefarious, conspiratorial narrative doesn't fit what's actually happening.

[–] brackled@lemmy.world 56 points 3 days ago* (last edited 3 days ago) (10 children)

My background is very much not in this world so caveat my questions/response below with that mind set. I do however try to practice decent personal opsec such 2fa (TOTP), password manager with random generation, etc.

I feel like a lot of what you stated was covered in the article. For example the article states that problem isn't the number of stakeholders, it's that none of them are consumer advocacy groups.

I understand that the author maybe leaned on the password sharing example too much but I think that was in an effort to present the material in a friendlier manner to the average reader. The closing statement makes it clear it's not really about Netflix, etc. The main concern is that attested passkey requirement will now be the easiest way to force specific software and hardware upon user. The GraphenOS example is a good one.

You might not use the attested flag in that manner but I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.

Do you have any examples of any public service requiring attested keys? No, because it really doesn't make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.

I think this is a bad take. "Because this potential is not being misused right now it won't be a problem in the future" has not really served us well thus far.

My understanding is that the article is saying that passkeys are giving away too much control to the second party. That can and will be abused.

But again, layman's understanding from my end.

load more comments (36 replies)