Hacker News new | past | comments | ask | show | jobs | submit login

Here's what Moxie said about this issue: https://whispersystems.org/blog/contact-discovery/



And here's my write-up of how a private set-intersection protocol could be used to enable users to securely swap contacts: https://news.ycombinator.com/item?id=11289223

It's a solved problem, but Signal doesn't implement it.


The protocol you describe is a synchronous online protocol where Alice and Bob have to be online at the same time (and if they're doing this at Charlie's behest, so does Charlie). Signal is designed for asynchronous communication where both participants don't have to be online to discover each other or send each other message.

Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone? Does Charlie initiate the process, only to have it only work if all three of them are online at the same time? Who kicks it off and why, and what would the user experience be?

You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case, and seems like a mere first step of solving a much more complicated problem of actually trying to turn this into a useful feature with good UX.


> The protocol you describe is a synchronous online protocol where Alice and Bob have to be online at the same time (and if they're doing this at Charlie's behest, so does Charlie).

They don't actually have to be online at the same time (and they don't care about whether Charlie is online or not: it's a pairwise protocol): they just to be able to send and receive one another messages, and to store state. Fortunately the former is some Signal's quite good at, and storing state is something that phone hard drives are quite good at.

> Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone?

It's the exact same use case as Signal's existing contact-discovery code, only private: it enables Alice & Bob to share information about a mutual acquaintance, e.g. Charlie. This might be used to share Charlie's key ID, in a trust on first use style. Note that this is no less secure than everyone everywhere trusting Open Whisper Systems on first use.

The idea is that when one starts using Signal, one exchanges keys in some out-of-band mechanism (NFC is a likely candidate) with an acquaintance, and then from that person get keys of mutual acquaintances, and from then others, and so on and so forth. Whenever you add a new acquaintance, one can reiterate the same protocol with all previous acquaintances (it's amenable to batching, too, which is nice) in order to propagate that information.

It may have some interesting uses in a certificate transparency sense, but I don't know about that.

> You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case

It solves the exact same problems the Signal contact-discovery protocol solves, without actually revealing all one's contacts to OWS. That's all. If it did nothing more than that, it would be a good thing.


> It solves the exact same problems the Signal contact-discovery protocol solves, without actually revealing all one's contacts to OWS.

Except it doesn't. If you share your contacts with Signal, it can tell you which ones are on Signal.

If Alice shares her contacts with Bob, she may discover some contacts she has in common with Bob, but not necessarily which ones are Signal users. Perhaps Bob has talked to Charlie some time in the past using Signal, but perhaps not.

So if we run this chatty, online, synchronous protocol with each of your contacts you already know are on Signal who happen to be online at a given time (which will be a subset of all your contacts), you may-or-may-not discover some of your contacts use Signal.

In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.


> If Alice shares her contacts with Bob, she may discover some contacts she has in common with Bob, but not necessarily which ones are Signal users. Perhaps Bob has talked to Charlie some time in the past using Signal, but perhaps not.

The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number (which is the only public identifier Signal currently supports; it could easily be extended to support other identifiers though).

Yes, it won't reveal to Alice that her friend Etta is also using Signal, if Etta and Alice don't have anyone in common. That's part of the privacy-preserving feature which prevents Signal from knowing who's using it, and whom everyone knows.

Given the small-world phenomenon, the odds are that one will very quickly add most folks one knows about, and the others can be added manually.

> So if we run this chatty, online, synchronous protocol

It's not chatty: the exchanges are large, in order to protect privacy, but they are also rare, and are not ongoing. Whenever you add a new contact, you re-initiate the protocol with your pre-existing contacts, that's all.

It's not online: as I indicated before all that's required is for each party to send & receive messages, and have some state.

It's synchronous, I'll grant, but only in the trivial sense that one party acts, then at some point in the future the other party acts. It certainly doesn't require both parties to be online at any point.

> In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.

I think that the user experience would be identical to the current Signal UX: from time to time one's phone would buzz and indicate that one of one's friends uses Signal. If one wanted to, one could add a contact in person, e.g. through NFC or QR codes or whatever.

You seem very invested in hating this idea; you might ask why I'm so invested in it. Very simply, Signal is a tool for secure communication, but it requires that end users reveal every person they've ever communicated with to OWS.


I guess you still don't understand where this falls down yet:

> The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number

If Alice and Bob are just comparing their directories of already-known Signal contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob, and Charlie are already each other's contacts!

So this protocol can only help people discover contacts they are not yet aware are Signal users. That would involve comparing their full set of on-device contacts and sharing mappings of which one of those are within the subset of known Signal contacts.

> You seem very invested in hating this idea

I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.

It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.

The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.

You are starting with a protocol, not thinking about the user experience, and declaring it a "solved problem". I'm not even convinced this protocol is the right tool for the job.


> If Alice and Bob are just comparing their directories of already-known Signal contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob, and Charlie are already each other's contacts!

No, they are sharing (tel:+12025551212 signal:a31d79891919cad24f3264479d76884f581bee32e86778373db3a124de975dd86a40fc7f399b331133b281ab4b11a6ca) pairs. Alice and Bob determine that they both know Charlie; Alice and Bob then — since they both know one another and both know Charlie — feel good about sharing with one another what Charlie's Signal ID is.

> So this protocol can only help people discover contacts they are not yet aware are Signal users.

Which is exactly what Signal's current contact-sharing protocols does, in addition to helping Signal discover all of one's contacts.

> I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.

I will give you the benefit of the doubt and assume that your repeated failures to understand the protocol and its requirements are due to by own poor explanations, and further that you actually intend to be constructive.

> It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.

I'm starting with a principle, not a protocol. That principal is that: online service providers must know the absolute minimum amount of information to do their jobs. Ideally, instant messaging would use some form of private information retrieval protocol so that server couldn't know who is talking to whom. Given Signal's current architecture, it must know to whom one is talking; there's no reason for it to also know everyone to whom one could be talking.

> The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.

Is it better to be usable but insecure than unusable but secure? I think the answer is mu: a product must be both usable and secure. Granted, security is always in the context of some threat, but it should be possible for users to intuitively grasp the security context.

> You are starting with a protocol, not thinking about the user experience

So, what do you think the user experience of contact discovery should be? I've already demonstrated that my proposal has an identical experience to Signal's, with the exception that one must manually register contacts not know to one of one's contacts. How would you implement contact sharing without giving OWS access to everyone's address book everywhere?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: