[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.

[Aaargh20318]

I'd say it's way more obvious than using a 3rd party email service.

And that's another thing: if you use a 3rd party e-mail service then you have to trust a 3rd party not to abuse that. If they have control of that email address they can take over your account. If it's a temporary address, who's to say when that address gets reused?

If you don't use a 3rd party service then you have to have your own domain for that e-mail address, that domain name can then also be traced back to you.

If you want it to be anonymous, you shouldn't use e-mail at all and only allow passkeys.