[ChrisMarshallNY]

A public key can be associated with an individual user. Same with the pseudo-UDIDs, that are required for push notifications.

[mpalmer]

I guess I don't see a practical way of exploiting that association. UDID, that's unique identifying info for sure. But a public key that's never reused?

[ChrisMarshallNY]

It can still be associated with a user, the same goes for push notification IDs.

It would be difficult, but AI has suddenly made difficult things a lot easier.

[Aaargh20318]

But so can the email address.

[ChrisMarshallNY]

To an extent. They can still use a throwaway or redirect address.

With PassKeys and push notifications, there’s no way to do that.

[6yyyyyy]

You can use KeePassXC for passkeys. It will generate completely unidentifiable public keys, and save the the private keys to a portable KDBX file.

It's unfortunate that passkeys have been such a disaster. Attestation should never have been part of the spec, it should never have been presented as a replacement for hardware U2F keys, and a private key file format should have been defined on day 1. But there is useful functionality buried under all the noise and confusion.

[Aaargh20318]

You can throw away a passkey just as well as you can throw away an email address.

[ChrisMarshallNY]

This is a good point. I'm not sure that it is as obvious to nontechnical users, though.

I suspect that many people's Passwords apps are littered with dead passkeys.

[vhcr]

If they're so privacy-focused, can't they generate a key specific to the app?

[ChrisMarshallNY]

That’s pretty much what Apple does with both the PassKey and push notifications.

The PassKey is a bit better, because there’s no need to go through a broker server, like you do with push notifications, but the key is still connected with an individual user and device, so an association can still be established, with some difficulty.

If you don’t have the key or the ID stored on a server, then even that is not an issue.