Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

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

View on HN

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?

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.

But so can the email address.

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

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

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.

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

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.

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.

This is all stuff that we'll need to consider. We have to have a valid email address, because the app won't work, otherwise. That's really the only requirement for server-stored information. There's a bit of stuff that stays on the phone. We try to use the Secure Enclave, as much as possible.

The issue is that the demographic we Serve (recovering drug addicts) is a very privacy-sensitive one. Another demographic (that we don't serve) is non-hetero/cisgen folks. Both of these demographics can mean persecution, and even death, in some places, so we are not casual at all about the privacy of our end-users.

At the same time, too much security can render the app useless, so we need to find a balance. The issue with information, is that once it's out; it's not so easy to put back in the bottle, so we tread carefully.

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

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.

Reply on news.ycombinator.com