131–140 of 152 posts
Earlier quoted context omitted.
Doesn't doing so necessarily lock out all the users using that client?
It would, yes. Thus it’s an action I would only recommend if doing so would help prevent serious injury to their customers. If it comes down to a choice between locking a customer out and having, say, their money stolen, then the scale tips towards safety.
The passkey spec authors think websites should be able to ban clients which allow users to manage their own data[1,2]. It makes me really hesitant to adopt passkeys if my client could get banned because it's open source and lets me control my client how I want to. It appears to be more useful for vendor lock-in than anything else[3]. A shame, since it could've been a cool tech if they had built it to be resilient to…
So if a client ever goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a malicious third party, you think relying parties shouldn’t have the option not to trust that client anymore?
As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM module. That means one of three big, US-based tech companies will control all of the world's login data. Those 3 companies are all currently involved in the largest fascist-taint-tongue-polishing in US history, and we want to hand them control over the world's logins. That's a much, much bigger risk than some users doing something stupid.
The spec needs to be written with the assumption that the user's private keystore may be hostile to the user's own interests, because in the real world, it is. It needs to be written to mitigate damage to the user from a hostile keystore. Instead, the spec places total trust in the keystore. This is a fatal error.
Earlier quoted context omitted.
Apple is already shipping remote attestation in Safari in the form of Private Access Tokens ( https://developer.apple.com/news/?id=huqjyh7k ), though Cloudflare's trial for that has ended. Safari authenticates and attests itself against Apple, who hands out tokens to your browser, which in turn get used to bypass CAPTCHAs and other anti spam filters. There's no direct remote attestation implementation for passkeys ye…
> remote attestation for web browsers has been around for a few years now. May it always remain niche. A world in which open source browsers are unusable for most people and new entries to the browser market are all but impossible sounds terrible .
linux is open-source and a very common attestation target
Earlier quoted context omitted.
It's likely that the websites need your actual government issued credentials are not your twitters and your hacker news, but government websites that actually need to link the web user to the citizen. As an example my country has a portal that you use as a citizen to book appointments to government institutions, keeps you updated about the status of your requests, allows you to securely upload scans for additional do…
until your gov decides that websites need to age-check everyone with the equivalent of showing some ID...
Earlier quoted context omitted.
until your gov decides that websites need to age-check everyone with the equivalent of showing some ID...
Or corpos decide the time is ripe to force users to do it, so they can better optimize their surveillance targeting. Google has been nagging me with a periodic Android popup for like a decade to "add my birthday to help them comply with the law". Eventually that tack of borderline misleading will turn into an outright demand.
Earlier quoted context omitted.
> remote attestation for web browsers has been around for a few years now. May it always remain niche. A world in which open source browsers are unusable for most people and new entries to the browser market are all but impossible sounds terrible .
there is no contradiction between open-source and attestation linux is open-source and a very common attestation target
GrapheneOS supports attestation. GrapheneOS even provides the sort of security guarantees that would make risk management types at banks happy, but it isn't popular enough for them to be motivated to support it as an attestation target.
Now imagine it was practical for websites to require attestation from browsers. How likely do you think it that all the major services would accept anything other than Chrome, Safari, and Edge?
If I'm being honest, I regret every passkey I ever made. With my old flow, I knew when to use my Yubikey, when to use my OTP, and when to use SMS 2FA. With the new flow, these things say "use your passkey" and I don't know where in god's name I did this. If I did this on my iPhone in a WebUI that popped up when I followed a link to buy something, then it's never going to be on Chrome or Bitwarden. I've decided to sto…
I can't blame you. I know the passkey UX on Windows was absolutely horrible (and probably still is). However I can't say that I relate. I use 1Password and I don't think I've literally ever been asked to use the native UI. It always goes straight to 1Password. I'm not sure why we have different experiences. (I use a mac, an iphone, and a google pixel)
Earlier quoted context omitted.
So if a client ever goes rogue someday (either intentionally or has been compromised) and starts shipping off private material to a malicious third party, you think relying parties shouldn’t have the option not to trust that client anymore?
Sure that's bad, but the trouble is you're not thinking about what the alternative is. If users don't have control over their own data, then someone else does . As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM…
Earlier quoted context omitted.
Or corpos decide the time is ripe to force users to do it, so they can better optimize their surveillance targeting. Google has been nagging me with a periodic Android popup for like a decade to "add my birthday to help them comply with the law". Eventually that tack of borderline misleading will turn into an outright demand.
In the end we all are allowed to just not use a product... aren't we? Vote with your wallet is still possible.
Earlier quoted context omitted.
Sure that's bad, but the trouble is you're not thinking about what the alternative is. If users don't have control over their own data, then someone else does . As stated by the spec authors on KeePassXC's bug tracker, open source software may be modified by the user, so cannot be trusted. The passkey proposal is for all of your keys to be managed by proprietary software validated by your phone or your computer's TPM…
By all means, make a proposal to the FIDO Alliance that solves all these problems without introducing new ones. You're going to have to anticipate all the objections and be prepared to answer them, though.