Hacker News new | ask | show | jobs
by digiown 129 days ago
> Approximately nobody thinks users shouldn't be able to access their keys in the general case

Citation needed. To me it seems to be the quiet part that they aren't saying out loud. If it's just a consequence of the spec being unfinished, then they shouldn't threaten to ban KeepassXC for this. The purpose of a system is what it does, and commercial passkey implementations lock users out of their credentials and uses it to strengthen vendor lock-in.

> Is it a super useful feature? No

It's security theater and a way for websites to annoy users unnecessarily.

> KeePassXC is not "being threatened with being banned via attestation".

https://github.com/keepassxreboot/keepassxc/issues/10406#iss...

It's a thinly veiled threat. Making a certification process and refusing to certify KeepassXC is exactly the same as banning it.

1 comments

Let's be specific. Who is "they"? Who do you think is threatening to ban KeePassXC? A mid-level Okta employee? The whole FIDO Alliance?

Brother, there's no conspiracy here. Attestation requires a trusted third party, same as TLS. You know how you can generate self-signed certificates, but your browser and other tools don't trust them? Attestation is like that. What you keep calling a "ban" is a trivial operational consequence of this. Individual services still get to decide whether attestation is even required, and in the consumer space you aren't going to see it much.

The "they" is any corporation that has an interest in the user not controlling their system, and whom this technology caters to. This sea has plenty of fish already. Streaming services serving Hollywood content, banks, dating apps...

Lastly I even faced another one. Something as simple as a gym token wants GMS, attestation and GPS positioning because it treats its users as liars prima facie. That's the new norm this attestation enables. No conspiracy needed, simple business interest and greed to juice "customers" to the last penny drives you there.

You're on a tangent from the discussion you're replying to. Individual services get to decide requirements for their users, but that's not at all the same as "banning" KeePassXC from the entire ecosystem.

Like, there are lots of services that require SMS or email link MFA. I guess KeePassXC is just banned from everything, then?

To repeat, the GitHub issue digiown linked is not a threat to ban KeePassXC. A random guy from Okta doesn't have that power. Okta itself doesn't have that power or want to have that power. The GitHub issue is simply a description of what attestation is.

OPs point is that we shouldn't allow "individual services get to decide requirements for their users". If the spec requires being implemented in a way that allows that, it's a user-hostile spec.
That wasn't their point and is orthogonal to their misunderstanding of the GitHub issue where, again, no threat is being made.

But in any case services do get to decide, because the service runs on someone else's computer, not yours. You get to decide what happens on your computer, they get to decide what happens on theirs.