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.
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.
Exactly, and it doesn’t take any effort to come up with software that will make it impossible for most people to even consider doing things a different way than big tech wants them to. Download the wrong app, use the wrong OS, attempt in any way to reclaim your privacy, and all of a sudden you can’t be authorized to open your own banking app because of some bullshit “security” message. What option does that leave you? Either become a hermit and reject all technology with whatever cost that has for you, especially in a decade or two as technology transitions to something completely mandatory for everyone, or fall in line and use everything the way they intend you to.
This is already the reality without passkeys. The correct response is to bank with a bank that isn’t enabling Google’s monopoly. Pretend passkeys don’t exist–nothing’s changed. You still can’t use your bank’s app without a Google Account if your bank is an enabler of Google’s monopoly. So… again, myopic dimwits are getting angry at something, but don’t know what. They’ve latched onto passkeys though. Amusing.
No, I’m not assuming people are using a Google wallet.
Most businesses only release an android package via Google’s PlayStore. (“Download our app via PlayStore.”)There’s no reason a bank couldn’t host their .apks on their website (if you’re unfamiliar with the .apk extension imagine it’s a .exe: you click on it and a program runs; an .apk is to Android what an .exe is to Windows). To download packages from Google’s PlayStore requires a Google account. Google demands a few things from these two parties: publishers need to pay Google a fee to have their .apk hosted by Google and users need to run Google’s spyware in order to access those .apks hosted by Google.
It’s often stated that if you want digital-freedom/privacy use GrapheneOS (if you have a compatible Android-device) or use a linux mobile-phone. To which most users respond: but my bank app doesn’t work on those platforms, therefore I won’t use either GrapheneOS or a linux-phone.
The bank app won’t work, because Google’s spyware is not included in GrapheneOS (a point of GrapheneOS is to avoid such spyware). Because GrapheneOS (or linux) doesn’t include Google’s spyware Google will do its best to block such devices from accessing Google’s PlayStore. Such computers are violating Google’s demands: if you want access to the PlayStore you have to run Google’s spyware.
Even if you were to get the appropriate .apk by avoiding Google directly (perhaps a friend who got it from Google then passed it to you) the bank’s .apk would fail to run on a device free of Google’s spyware, because you’re not capitulating to Google’s demand: you didn’t get it from Google’s PlayStore and the ‘app’ knows that by the lack of Google spyware. (Google’s spyware and the bank ‘app’ talk to each other. If the app can’t talk to Google’s spyware it will halt.)
Therefore if a bank only has an ‘app’ to interact with that bank is saying: you have to download it via Google’s PlayStore–which necessitates a Google account and running Google’s spyware. Therefore if you want to use banking ‘apps’ you need to enable Google’s monopolistic, spyware practices (you have to enable the corporations to practice surveillance-capitalism). Google defends this practice often with security-theater (“Google says it must be done this way for security.”) when in reality it’s about entrenching a market monopoly.
This is absolutely removed and I do deride users who say they want computing-liberty and -privacy, because there are banks who still have usable websites. You don’t have to bank via an app. If you do bank via an app you do so with full acknowledgment that:
a) you’re rewarding anti-competitive behavior;
b) you’re entrenching Google’s monopoly over Android;
c) you don’t actually want computing-liberty or -privacy.
It’s piss easy to change banks. It’s impossible to stop Google. If you want privacy you have to ditch Google, which means banking with a bank that allows you to bank via a desktop-computer (via a website) or in-person through bank-branches. If the only way to bank with your chosen bank is via an app that then means the only way to bank with your chosen bank is by enshrining Google’s monopoly into your life.
Passkeys are a completely separate thing. They’re an increase in security for all users. Users are frustrated by ‘big tech’s’ increasingly monopolistic practices and instead of doing anything practical (like not running those particular pieces of software) they’ve latched on to decrying passkeys, which the majority of the commentators are actually clueless about. They’re just seeing those ‘big tech’ companies forcing yet another change onto them. They’re lashing out against their lack of power. They’re lashing out against their subjugation by ‘big tech’. That they’re being forced to use “passkeys” when they don’t even know what a passkey is.
Passkeys are an open standard. They’re not entrenching anyone’s monopoly. Increased security is desirable by all parties (corporations, governments and individuals). Passkeys enable that. You’re not locked into Google’s Android, or Microsoft or Apple. People are under the assumption they are however.
I could host my own website using passkeys as the method for authentication. No big-corp involved. Offline. Spooky. Big-passkey is coming for you.
That probably left you with more questions than answers…
it’s that none of them are consumer advocacy groups.
I would put that more as a curiosity than a red flag. I doubt they were excluding groups, but happy to hear about if they were (e.g. donation minimums or something to that effect). The author actually says that whole paragraph is “notable” – great, noted. I hope that doesn’t mean they were using it as an argument for “Do not use [passkeys]” (the title of the article). FWIW, W3C recommends use of passkeys. EFF has had blog articles for 3+ years suggesting advantages of Passkeys. I also don’t know what a consumer advocacy group would suggest differently here – DONT implement an attestation spec? Attestation is a massive improvement for specific types of security.
The GraphenOS example is a good one.
I went and looked for what you were referring to and didn’t find anything. What do you mean by this? I use GrapheneOS. I use passkeys. Google being hostile to third party OS doesn’t seem related but maybe I am missing something.
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.
Well this seems like a reasonable point I should expand on. Maybe I can plant a seed of doubt about this hypothesis. A few comments:
People being locked out of their email is actually one of the biggest logistical nightmares for email providers. Proving someone is who they say they are is actually fairly difficult as well as doing it at scale. People lock themselves out of their own email. People get locked out of their email because of phishing attacks. In practice, Passkeys reduce phishing rates significantly. That’s a massive win for email providers in reducing their burden. Intentionally locking out a massive number of their customers is an unthinkably bad move, comically bad. It wouldn’t happen.
Email is the most important mechanism of communication for people’s security. Bank and financial accounts, paid services, government notices… they are almost all through email. The idea that they will vendor-lock email to specific hardware… it’s not realistic. They would face such massive PR And public blowback. Email is also accessed from more than just your phone. “Requiring” an attested phone would kill a massive use case.
People already feel locked to their email provider – it’s extremely difficult to change all contacts you have to a new email address. Passkeys don’t change that. Phone hardware doesn’t change that. So I’d say it’s just a continued problem, and not a reason to not use passkeys.
The FIDO Alliance had like three phone manufacturers out of 250 members.
Overall, I don’t see how passkeys, or attestation, could lead to a world where any public service would want to require attestation, and even if they did, there’s no reason it would be “requires my X branded phone”. These companies supported the development of this protocol for the specific reason of NOT wanting to cater to specific vendors. This is a vendor-neutral specification. There are many hardware and software providers. They all have their own motivations, and they hope implementing the spec brings in more customers, improves consumer security, and reduces their operational costs. Do you still have zero doubts about a future world with vendor-locked attested passkeys for public services?
passkeys are giving away too much control to the second party.
There are already dozens of hardware and software passkey vendors. It’s honestly amazing how little lock-in there is. There’s a half dozen FOSS authn services providing passkey services. You can buy dedicated hardware for passkeys from multiple independent companies. What “control” are you referring to? Companies could always force rotate your password, make it invalid, etc. Any control you thought you had was an illusion.
There are already dozens of hardware and software passkey vendors. It’s honestly amazing how little lock-in there is.
If my passkeys are spread across dozens of vendors I wouldn’t call that good, first of all, it’s just a headache.
Secondly, just because there’s many of them doesn’t mean there’s no lock-in. Can I get my passkeys out? Can I migrate them freely between any vendors? Can I take backups for myself from all the vendors? Can I restore the backups into each vendor? Can I replace those vendors with a self-hosted solution?
If my passkeys are spread across dozens of vendors
You’re picking what vendor you want, not picking unique vendors for every unique passkey.
Can I get my passkeys out? Can I migrate them freely between any vendors? Can I take backups for myself from all the vendors? Can I restore the backups into each vendor? Can I replace those vendors with a self-hosted solution?
It depends. It sounds like you just don’t like or want hardware-locked/TPM passkeys. If you generate that type of passkey, then no you can’t do much of that. Maybe your major complaint is that some major OS’s default to hardware-bound passkeys?
My reference to “vendor” meant to include self-hosted/FOSS solutions.
You’re picking what vendor you want, not picking unique vendors for every unique passkey.
I don’t get to pick anything, in fact. Most often you’re told “that’s how it is, that’s where the passkey goes” and there’s nothing you can do about it.
It sounds like you just don’t like or want hardware-locked/TPM passkeys. If you generate that type of passkey, then no you can’t do much of that.
Again, _I_ typically don’t get to make that choice, it’s being made for me. And that’s a problem.
I replied to someone else asking the same thing, but we can avoid this infinite-universe syndrome. Which service is forcing a specific passkey provider, and doesn’t offer alternatives? I just need an example to understand because I don’t know of any and I have been using passkeys for awhile, so I’d appreciate being informed.
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.
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.
Exactly, and it doesn’t take any effort to come up with software that will make it impossible for most people to even consider doing things a different way than big tech wants them to. Download the wrong app, use the wrong OS, attempt in any way to reclaim your privacy, and all of a sudden you can’t be authorized to open your own banking app because of some bullshit “security” message. What option does that leave you? Either become a hermit and reject all technology with whatever cost that has for you, especially in a decade or two as technology transitions to something completely mandatory for everyone, or fall in line and use everything the way they intend you to.
This is already the reality without passkeys. The correct response is to bank with a bank that isn’t enabling Google’s monopoly. Pretend passkeys don’t exist–nothing’s changed. You still can’t use your bank’s app without a Google Account if your bank is an enabler of Google’s monopoly. So… again, myopic dimwits are getting angry at something, but don’t know what. They’ve latched onto passkeys though. Amusing.
sorry, not OP but I’m not following your logic.
Are you assuming everyone’s using a Google wallet or something (what’s tying one’s bank to Google?).
Fuck that - that’s why we have credit cards…
No, I’m not assuming people are using a Google wallet.
Most businesses only release an android package via Google’s PlayStore. (“Download our app via PlayStore.”)There’s no reason a bank couldn’t host their .apks on their website (if you’re unfamiliar with the .apk extension imagine it’s a .exe: you click on it and a program runs; an .apk is to Android what an .exe is to Windows). To download packages from Google’s PlayStore requires a Google account. Google demands a few things from these two parties: publishers need to pay Google a fee to have their .apk hosted by Google and users need to run Google’s spyware in order to access those .apks hosted by Google.
It’s often stated that if you want digital-freedom/privacy use GrapheneOS (if you have a compatible Android-device) or use a linux mobile-phone. To which most users respond: but my bank app doesn’t work on those platforms, therefore I won’t use either GrapheneOS or a linux-phone.
The bank app won’t work, because Google’s spyware is not included in GrapheneOS (a point of GrapheneOS is to avoid such spyware). Because GrapheneOS (or linux) doesn’t include Google’s spyware Google will do its best to block such devices from accessing Google’s PlayStore. Such computers are violating Google’s demands: if you want access to the PlayStore you have to run Google’s spyware.
Even if you were to get the appropriate .apk by avoiding Google directly (perhaps a friend who got it from Google then passed it to you) the bank’s .apk would fail to run on a device free of Google’s spyware, because you’re not capitulating to Google’s demand: you didn’t get it from Google’s PlayStore and the ‘app’ knows that by the lack of Google spyware. (Google’s spyware and the bank ‘app’ talk to each other. If the app can’t talk to Google’s spyware it will halt.)
Therefore if a bank only has an ‘app’ to interact with that bank is saying: you have to download it via Google’s PlayStore–which necessitates a Google account and running Google’s spyware. Therefore if you want to use banking ‘apps’ you need to enable Google’s monopolistic, spyware practices (you have to enable the corporations to practice surveillance-capitalism). Google defends this practice often with security-theater (“Google says it must be done this way for security.”) when in reality it’s about entrenching a market monopoly.
This is absolutely removed and I do deride users who say they want computing-liberty and -privacy, because there are banks who still have usable websites. You don’t have to bank via an app. If you do bank via an app you do so with full acknowledgment that: a) you’re rewarding anti-competitive behavior; b) you’re entrenching Google’s monopoly over Android; c) you don’t actually want computing-liberty or -privacy.
It’s piss easy to change banks. It’s impossible to stop Google. If you want privacy you have to ditch Google, which means banking with a bank that allows you to bank via a desktop-computer (via a website) or in-person through bank-branches. If the only way to bank with your chosen bank is via an app that then means the only way to bank with your chosen bank is by enshrining Google’s monopoly into your life.
Passkeys are a completely separate thing. They’re an increase in security for all users. Users are frustrated by ‘big tech’s’ increasingly monopolistic practices and instead of doing anything practical (like not running those particular pieces of software) they’ve latched on to decrying passkeys, which the majority of the commentators are actually clueless about. They’re just seeing those ‘big tech’ companies forcing yet another change onto them. They’re lashing out against their lack of power. They’re lashing out against their subjugation by ‘big tech’. That they’re being forced to use “passkeys” when they don’t even know what a passkey is.
Passkeys are an open standard. They’re not entrenching anyone’s monopoly. Increased security is desirable by all parties (corporations, governments and individuals). Passkeys enable that. You’re not locked into Google’s Android, or Microsoft or Apple. People are under the assumption they are however.
I could host my own website using passkeys as the method for authentication. No big-corp involved. Offline. Spooky. Big-passkey is coming for you.
That probably left you with more questions than answers…
Happy to discuss a few points you’ve brought up.
I would put that more as a curiosity than a red flag. I doubt they were excluding groups, but happy to hear about if they were (e.g. donation minimums or something to that effect). The author actually says that whole paragraph is “notable” – great, noted. I hope that doesn’t mean they were using it as an argument for “Do not use [passkeys]” (the title of the article). FWIW, W3C recommends use of passkeys. EFF has had blog articles for 3+ years suggesting advantages of Passkeys. I also don’t know what a consumer advocacy group would suggest differently here – DONT implement an attestation spec? Attestation is a massive improvement for specific types of security.
I went and looked for what you were referring to and didn’t find anything. What do you mean by this? I use GrapheneOS. I use passkeys. Google being hostile to third party OS doesn’t seem related but maybe I am missing something.
Well this seems like a reasonable point I should expand on. Maybe I can plant a seed of doubt about this hypothesis. A few comments:
People being locked out of their email is actually one of the biggest logistical nightmares for email providers. Proving someone is who they say they are is actually fairly difficult as well as doing it at scale. People lock themselves out of their own email. People get locked out of their email because of phishing attacks. In practice, Passkeys reduce phishing rates significantly. That’s a massive win for email providers in reducing their burden. Intentionally locking out a massive number of their customers is an unthinkably bad move, comically bad. It wouldn’t happen.
Email is the most important mechanism of communication for people’s security. Bank and financial accounts, paid services, government notices… they are almost all through email. The idea that they will vendor-lock email to specific hardware… it’s not realistic. They would face such massive PR And public blowback. Email is also accessed from more than just your phone. “Requiring” an attested phone would kill a massive use case.
People already feel locked to their email provider – it’s extremely difficult to change all contacts you have to a new email address. Passkeys don’t change that. Phone hardware doesn’t change that. So I’d say it’s just a continued problem, and not a reason to not use passkeys.
The FIDO Alliance had like three phone manufacturers out of 250 members.
Overall, I don’t see how passkeys, or attestation, could lead to a world where any public service would want to require attestation, and even if they did, there’s no reason it would be “requires my X branded phone”. These companies supported the development of this protocol for the specific reason of NOT wanting to cater to specific vendors. This is a vendor-neutral specification. There are many hardware and software providers. They all have their own motivations, and they hope implementing the spec brings in more customers, improves consumer security, and reduces their operational costs. Do you still have zero doubts about a future world with vendor-locked attested passkeys for public services?
There are already dozens of hardware and software passkey vendors. It’s honestly amazing how little lock-in there is. There’s a half dozen FOSS authn services providing passkey services. You can buy dedicated hardware for passkeys from multiple independent companies. What “control” are you referring to? Companies could always force rotate your password, make it invalid, etc. Any control you thought you had was an illusion.
Cheers
If my passkeys are spread across dozens of vendors I wouldn’t call that good, first of all, it’s just a headache.
Secondly, just because there’s many of them doesn’t mean there’s no lock-in. Can I get my passkeys out? Can I migrate them freely between any vendors? Can I take backups for myself from all the vendors? Can I restore the backups into each vendor? Can I replace those vendors with a self-hosted solution?
You’re picking what vendor you want, not picking unique vendors for every unique passkey.
It depends. It sounds like you just don’t like or want hardware-locked/TPM passkeys. If you generate that type of passkey, then no you can’t do much of that. Maybe your major complaint is that some major OS’s default to hardware-bound passkeys?
My reference to “vendor” meant to include self-hosted/FOSS solutions.
I don’t get to pick anything, in fact. Most often you’re told “that’s how it is, that’s where the passkey goes” and there’s nothing you can do about it.
Again, _I_ typically don’t get to make that choice, it’s being made for me. And that’s a problem.
I replied to someone else asking the same thing, but we can avoid this infinite-universe syndrome. Which service is forcing a specific passkey provider, and doesn’t offer alternatives? I just need an example to understand because I don’t know of any and I have been using passkeys for awhile, so I’d appreciate being informed.
Thanks.