This title is highly editorialized so as to be very misleading. The video doesn't mention Safari at all, it describes new APIs in iOS and in the web standards that allow developers to transition users to passkeys. Notably, these APIs work on iOS for whichever password manager the user has configured, not just the built in one. To the extent Safari is implicated in this at all it's that Safari implements CredentialsContainer.create [0], but that's a web standard that every major browser is implementing.<p>I'm all for scrutinizing the rollout of passkeys to make sure it doesn't turn into a lock in situation, but editorializing a video title is particularly egregious because, as we see in this comment thread, people are even more likely than usual to read only the title.<p>[0] <a href="https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/create" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Credentials...</a>
I'm hesitant about embracing passkeys. I think passkeys are poorly implemented at this point because of the inability to move them around like passwords - I don't want to be locked in. But I don't think what he is explaining is forcing an automatic upgrade for passwords, he is explaining that it can happen at the request of the user or application prompt. Notice that the diagram - The user in the app requests to upgrade (sure, let's call it an upgrade) from a password to a passkey.
There is a <i>lot</i> of FUD around passkeys.<p>Think about all the regular (read: non-Hacker News) users out there who fall for a phishing email/SMS, or who re-use passwords and get popped by a credential stuffing attack. Passkeys provide not only <i>massively-improved</i> security (they can’t be keylogged; they are linked to a specific domain so can’t be spoofed by look-alike fake login pages; they’re protected from replay attacks even if the transport mechanism is compromised), but a <i>much</i> nicer login flow as a bonus.<p>Many people also don’t understand how easy it is to login from a <i>different</i> device: say an Android user created a passkey for a site with Chrome. Now that user needs to sign in to the same site on a Mac running Safari (where there is no passkey for the user). They can still use their Android device to login from the Mac by selecting “use a passkey from another device”. Safari will show a QR code that they scan using the Android phone, and verify with their screen lock. A one-time passkey signature is transferred to the Mac, which the website uses to authenticate the user. The two devices verify that they are in proximity with each other using Bluetooth. This cross-device, cross-operating-system mechanism of passkey authentication is standardized under FIDO; no additional work is needed by the website to enable this login flow.<p>If you are “anti-Apple” or “anti-Google” and have strong aversions to them securely backing up things like passkeys (again, think of all the non-Hacker News readers where this is <i>not</i> the case), then go ahead and continue to use passwords. But we should be encouraging our parents, grandparents, siblings, friends, etc. to embrace passkeys to make all of their accounts more secure and phishing-resistant. The more passkey FUD they see, the longer people will have to deal with annoying (and still insecure) SMS codes, the longer passwords will be stolen/re-used, etc.
Passkeys are great. Me and my colleague are sharing a GitHub account that we use for managing a GitHub app on our autograder server. Previously we had to share the password. Six months ago we set up one passkey each on the GitHub account and no longer need to think about the password.<p>(We are only using this GitHub account for this one thing, and we don’t use it for commits etc.)
All your passkeys are belong to us.<p>The trouble is, Apple devices, which Apple can update remotely and for which no one external can see the source code, are trusted. There's this one huge single point of failure.<p>Can you use this without iCloud? Can you avoid any iCloud involvement?
EDIT: I know many people love their Apple devices and take criticism of that company as a personal attack, but <i>please</i> consider that I speak from experience of a US person whose laptop <i>and</i> cellphone were stolen in Poland in 2022.<p>Instead of downvoting, please help me understand: <i>how would one re-gain access to services used with passkeys</i> in this scenario?<p>Note that T-Mobile won't ship a SIM card overseas.<p>-----<p>Great reason to not use Apple ecosystem.<p>Having a cellphone / laptop broken and/or stolen is enough hassle <i>without</i> all the authentication being tied to the device that you aren't likely to use for more than a couple of years anyway.<p>And yes, things like that actually happen to people who are not CEO of Apple. Especially while traveling, when your <i>other</i> devices are far away.<p>It sounds like someone decided to reinvent 2FA hardware in the worse way, combining the inconvenience of needing a physical key with all the hassles of password <i>and</i> adding a million ways for the key to self-destruct.<p>Oh, the passkeys can be transferred through the cloud? Explain like I'm five how that's more secure than email/SMS OTP for authentication then (which are an awful thing too, but at least I can have my own email). So we have <i>one more</i> link in the security theater that I absolutely trust is more secure than having <i>passwords.txt</i> in Dropbox (how is it different, again?).<p>From a user's perspective, passkeys sound like a solution in search of a problem. The only thing I can see passkeys doing for me is locking me out of my accounts when I need them most.<p>Or facilitating <i>other</i> parties in that.
This is straightforward illegal monopoly nightmare fuel right here. Apple passkeys are going to be locked-in into their infrastructure, with no possibility to easily switch devices.<p>This doesn't have to be true, there are third-party password managers with Passkeys support (e.g. BitWarden), but they are not going to be able to access Passwords. It's specifically locked to only browser applications, Apple will not provide entitlement to access the keychain for any other app.