3 ms·

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

• wtbob 10y ago
  > 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.
  • bascule 10y ago
    > 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.
    • wtbob 10y ago
      > 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.