> Hackenburg found that models trained to become more persuasive also ended up being less truthful.
> Even in Hackenburg’s recent preprint, Claude spouted numerous inaccuracies and falsehoods
> when Hackenburg ran his competition of coached elite debaters and AI, there was one way he could bring AI down to human levels of persuasiveness: by forcing it to write human-length messages at human writing speed.
> they found that an AI could talk people into conspiracy theories, and that the magnitude of their increase in belief was roughly the same as that of the decrease in belief after talking to a debunking bot.
> Some password managers will only fill if a domain matches, but IRL the response I've seen from most users when it doesn't match is to assume the integration broke and manually copy/paste it in. I've also seen lots of them do stuff like happily autofill on any prefix of the domain, so your credential for `something.example.com` will autofill into `fake-something.example.com`.
Why would you trust the very same password managers that don't handle passwords properly to handle passkeys properly?
You don't. The browser handles the passkey matching to the domain which is obviously a better place to do it. There could obviously still be bugs as with all things, but it's much more intentionally integrated into the flow which makes it much harder to bypass.
Right, I haven't seen that particular flaw in baked-into-the-browser ones (probably because they already having secure domain matching code ready to use), but the distinction is that doing the domain check is a part of the spec and standard, so e.g: sites aren't going to break it by changing the log-in subdomain routinely, as has been common historically.
Password managers have had to be permissive enough to work with most websites, and there is no standard for it. There have been sites that blocked the autofilling of passwords and so on as well.
My point wasn't this one particular flaw in some password managers is the reason to use passkeys (the copy/paste point is the much bigger issue anyway), just that it's an example of how relatively brittle the password manager process is. Having it a core part of the spec gives stronger guarantees.
“There have been sites that blocked the autofilling of passwords and so on as well.”
Sites that do this irritate me so much. Ones that try to block pasting and stuff… like somebody intentionally baked that into the site. Who? And what was their rationale? Are they really so arrogant to think people are going to carefully type in some elaborate password not once but twice?
That and blocking paste in fields like bank account numbers and stuff.
Surely somebody here has been asked to implement these mis-features. Please explain what went through the heads of the people responsible for it?
Blocking bank account numbers from being pasted is considered an error prevention measure. By forcing people to enter it manually at least once, you stop them from blindly pasting the wrong number twice.
There's no real regulation requiring blocking paste but it has become an annoying informal standard of sorts.
The users are the ones manually copy/pasting the password. There's no way the password manager could prevent this short of disallowing copying/viewing passwords.
Two crucial things you can do with a password that you can't do with a passkey:
1. Write it down on a piece of paper and put it in a safe deposit box.
2. Read it on one device (or from a piece of paper!) and enter it manually on another device.
Plain text is the ultimate form of cross-platform portability. Passkeys are the ultimate form of vendor lockdown. The passkey vendors won't even allow you to view the private key, unlike with ssh keys, which you can also write down on a piece of paper. It's vendor cabal to destroy computing freedom in the name of "security", always the excuse. Tech company paternalism at its worst.
If passkeys were meant to be user friendly then there'd be a secure optical transfer mode to QR code them from device to device with the screen and camera.
Easy to implement (receiver flashes a public key, sender encrypts to that key and flashes the QR code back).
That it doesn't exist for a protocol meant to work with phones tells you exactly where the thinking was headed.
That they have purposely put effort into preventing you from doing that shows you everything you should need to know.
The entire point of passkeys is yanking the control over authentication out of the hands of people. These companies don't want you to be able to let someone else log in as you.
That's the entire point.
The problem they are solving has absolutely nothing to do with security.
I have no idea which keychain is in which, but the last time I migrated from one Apple laptop to another, I couldn't get the automated tool to work at all, so I restored a physical backup, went through the sign-in process, and passwords and passkeys migrated correctly.
Passwords and passkeys are in the iCloud keychain. You can technically save passwords in the login keychain (not sure about passkeys), but if you’re using the Passwords app it will be in the iCloud one.
What information from your login keychain do you expect to need on your new computer?
There's not really a plausible answer to that question, because the login keychain data is almost entirely specific to that host.
To iron-man your argument: Apps that store account credentials to third party services will need to be signed in again.
If you were using http basic auth for a website and saving that, then it was probably in there.
Private keys and certificates you manually imported, or that were created by an application for your host. This is the closest to a plausible answer, imo.
It sounds like the arguments were basically AI slop hallucinations.
reply