> very obviously once Passkeys are everywhere it'll become "we're requiring attestation from approved device bootloaders/enclaves"
This is far from very obvious, especially given that Apple have gone out of their way to not provide attestation data for keychain passkeys. Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.
If there's no intention of doing this, it should be removed from the protocol. "I promise we'll never use this feature, so long as you implement it" isn't very convincing.
Great, they can use standards that aren't targeted at running services for the general public. It seems like the requirements already diverged.
Drop attestation from passkeys, and I become a promoter. Keep it, and I suggest people stay away.
If it's not something anyone intends to use on public services, this should be uncontroversial. Dropping attestation simplifies implementation, and makes adoption easier as a result.
The fact that sites targeted at the general public are prompting me to use them. Should websites avoid using passkeys and webauthn? Would you like to tell them that they're doing it wrong?
Yeah, so if you want me to trust them, the harmful parts need to get removed from specs used in public contexts.
I would love to use public key cryptography to authenticate with websites, but enabling remote attestation is unacceptable. And pinky swears that attestation won't be used aren't good enough. I've seen enough promises broken. It needs to be systematic, by spec.
Passwords suck. It's depressing that otherwise good alternatives carry poisonous baggage.
Because passkeys are designed to replace passwords across multiple different service contexts, that have different requirements. Just because there's no reason to use it for one use case doesn't mean it's not actually useful in a different one. See things like FIPS140 (which everyone ignores unless they're legally required not to).
Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process? Why would they decide to wake up and say "I know, I'm going to require that all of my users authenticate just with a Yubikeys and nothing else"?
Is there a difference? It's a field in the response payload that nobody is filling out except the corps that need it. Would it make you feel better if they moved it to an appendix and called it an optional extension?
There's a tension here between "user freedom" and a service wanting to make sure that credentials that it trusts to grant access to stuff aren't just being yolo'd around into textfiles on people's dropboxes.
People forget that one of the purposes of authentication is to protect both the end user and the service operator.
Sure, but as long as the fallback for account recovery is sending a reset email or sms (both of which are similar or worse than yoloing textfiles on dropboxes), that's a very tough argument to make in good faith.
This attitude has got to stop. Is it not enough that there's no customer service and it's almost impossible to sue these companies thanks to arbitration clauses? Now they need to have control over our computing to keep themselves safe? And how many recorded incidents of losing an account because someone had their "password in a text file" are even out there? The most common scenarios one hears about are either phishing or social engineering.
Do you think someone running a service that's under constant denial-of-service attacks would be sympathetic to the argument that "What people do on their own computer is none of the service's business".
Pretty much every service out there has "don't share credentials" in their ToU. You don't have to like it, but you also don't have to accept the ToU.
Note the scare quotes around user freedom. Perhaps user freedom is a notorious fake issue, a bizarre misconception, or an exotic concept that nobody understands.
I'm good enough at my job to see that when it's happening. That's one reason why I didn't say 'I think.' Another is because I know the way to bet is that, with this weapon forbidden, others will be found to replace it. Why go into any of that without even the promise of hazard pay? I'd rather just do honest work.
One of the biggest fallacies I see in this space is people looking at an observability standard like otel and thinking "I must enable all of that".
You really don't have to.
Throw away traces. Throw away logs. Sample those metrics. The standard gives you capabilities, it doesn't force you to use them. Tune based on your risk appetite, constraints, and needs.
My other favourite retort to "look how expensive the observability is" is "have you quantified how expensive not having it is". But I reserve that one for obtuse bean counters :)
The onus is on the one asking to spend the money to demonstrate and quantify the business value and compare it to alternatives. Our field could do with a bit more justifying our purchases with dollar values.
> Worse, they’re using it for massive commercial gain, without paying a dime upstream to the supply chain that made it possible. If there is any purpose of copyright at all, it’s to prevent making money from someone’s else’s intellectual work.
This makes no sense. If I buy and read a book on software engineering, and then use that knowledge to start a career, do I owe the author a percentage of my lifetime earnings?
Of course not. And yet I've made money with the help of someone else's intellectual work.
Copyright is actually pretty narrowly defined for _very good reason_.
> If I buy and read a book on software engineering
You're comparing that you as an individual purchase one copy of a book to a multi-billion dollar company systematically ingesting them for profit without any compensation, let alone proportional?
> do I owe the author a percentage of my lifetime earnings?
No, but you are a human being. You have a completely different set of rights from a corporation, or a machine. For very good reason.
If you pirate a book on software engineering and then use that knowledge to start a career, do you owe the author the royalties they would be paid had you bought the book?
If the career you start isn't software engineering directly but instead re-teaching the information you learned from that book to millions of paying students, is the regular royalty payment for the book still fair?
