Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I won't recommend Signal anymore

sandervenema.ch

Post reply on HN
Print view View original

331–340 of 350 posts

Re: Why I won't recommend Signal anymore

#331

Post by wtbob »

bascule wrote: post #324
wtbob wrote: post #317

Earlier quoted context omitted.

> 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…

> 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 so…

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

Re: Why I won't recommend Signal anymore

#332

Post by giancarlostoro »

majewsky wrote: post #322
giancarlostoro wrote: post #226

Earlier quoted context omitted.

I had not even 3 users... I was running a Java one, looks like Prosody is worth it's salt. Does it support E2E and other features that Conversations supports? :) Edit: I was running it on a DigitalOcean box with only 512MB of ram at the time, which I found a bit silly that I would come back and the server was down, but it was a different XMPP server than Prosody.

E2E does not need support from the server. Regarding Conversations, I'm using it with my server and it seems to be working fine, although I have not tested every single XEP supported by Conversations.

This is true, it's kind of easy to forget how E2E works sometimes, thanks!

Re: Why I won't recommend Signal anymore

#333

Post by giancarlostoro »

catdog wrote: post #280
giancarlostoro wrote: post #226

Earlier quoted context omitted.

I had not even 3 users... I was running a Java one, looks like Prosody is worth it's salt. Does it support E2E and other features that Conversations supports? :) Edit: I was running it on a DigitalOcean box with only 512MB of ram at the time, which I found a bit silly that I would come back and the server was down, but it was a different XMPP server than Prosody.

You probably used Openfire, known to be a memory hog and a bit unstable. Simply go for prosody and you should be fine (ejabberd should also be OK). Some newer XEPs which you may want to have with Conversations are not supported OOTB in prosody (yet) but there are plugins distributed separately [1][2]. [1] https://modules.prosody.im/ [2] https://prosody.im/doc/installing_modules

Yes that was the culprit! OpenFire sounds like it... I wanted something simple to setup, without too many terminal incantations. Thanks for the information, it's invaluable.

Re: Why I won't recommend Signal anymore

#334

Post by matt_kantor »

tptacek wrote: post #50
zigzigzag wrote: post #43

Like a lot of crypto-puritanism it is rather mixed up. He says he recommended Signal because it was easy to use (more consumer friendly I guess) and secure, then says he wouldn't have gone in the direction of making it easier to use and criticises the things that make it user friendly, like using phone numbers instead of usernames. He says he thinks the protocol is secure, then says he doesn't want it to use GCM beca…

I agree overwhelmingly with what you wrote, except that I want to point out that this isn't "crypto-puritanism". It's just hipsterism. The author isn't a cryptographer, and if you asked a panel of 10 cryptographic engineers what messaging system they'd recommend, 9 of them would say "Signal". The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper…

> I don't think Signal has sockpuppets (it's just not their style), but I know several other "secure" messaging applications do.

Could you provide details/sources? This seems like a good opportunity for some public shaming.

Re: Why I won't recommend Signal anymore

#335

Post by tortasaur »

Kliment wrote: post #158
tptacek wrote: post #151

Earlier quoted context omitted.

GCM has practically nothing to do with the security/privacy of Signal, but it is the #1 "concern" that people who don't understand cryptographic messaging security feel they must relate about Signal.

My main concern with GCM is that it's unavailable on fully open OS builds, so requiring it compromises the security of the device as a whole, rather than Signal in particular.

GCM is available on fully open OS builds. The microG project implements a fully open stand-in for GCM.

Re: Why I won't recommend Signal anymore

#336

Post by fnordfnordfnord »

exo762 wrote: post #282
jhasse wrote: post #278

Earlier quoted context omitted.

Does Google know you are using Signal? Does it know whom of your contacts use Signal? Does Google know you've sent a message? Does Google know that you are receiving a message? Does Google knows who from your contact list send this message? Can Google infer from pings who is communicating with whom? Yes to all of those, because they have root on your phone.

You are assuming that Android reports on every step you take. Do you have sources backing this claim?

It did formerly via Carrier IQ, which was widely reported in the press. So that's not unprecedented.

Re: Why I won't recommend Signal anymore

#337

Post by bascule »

wtbob wrote: post #331
bascule wrote: post #324

Earlier quoted context omitted.

> 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 so…

> 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…

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.

Re: Why I won't recommend Signal anymore

#338

Post by Siimteller »

petre wrote: post #261
darklajid wrote: post #96

Earlier quoted context omitted.

I'm not a cryptographer. I .. am reasonably sure that no one would take me for a hipster. But two issues - or call it 'differences in opinion' - in that article are relevant for me: The inability to use the service without a mobile number and federation. I understand the rationale behind the former ("It's easier"), but I don't understand why it is mandatory. I could've been 1283783127356128531312 on Signal and option…

Wire can use e-mails or phone nunbers for IDs, so you can use the same ID on multiple devices. But the mobile UI is worse than Signal's and it's also it's not federated. The source for the clients is on Github. It does have desktop apps for Windiws and Mac and a web app that works in most modern browsers. It's in many ways better than Skype. You don't have to link it to your phone in order to send messages - just use…

Servers ARE outside of the US. All in EU.

Re: Why I won't recommend Signal anymore

#339

Post by strcat »

md_ wrote: post #303
strcat wrote: post #293

Earlier quoted context omitted.

The point of CopperheadOS is not that it lacks Play Services... and Play does not provide more secure updates than an app store like F-Droid. In fact, Play abuses system privileges to bypass the signature system used by Android. It will happily clobber an app with another with a different signature. It moves all the security checks for that into the cloud... completely bypassing the standard trust-on-first-use signat…

My point was that there's no real merit to the complaint that Signal requires Play Services if you're going to use an OS with Play Services installed anyway. One can reasonably argue that Signal should work on non-Play Androids, but since his target audience is non-technical users, it seems likely that they are all using (and are more secure using!) off-the-shelf iOS or Android phones, which implies a significant rel…

> it seems likely that they are all using (and are more secure using!) off-the-shelf iOS or Android phones

In what sense are they more secure using stock Android than CopperheadOS? They wouldn't be installing it themselves either way. It's a product available for purchase too... have you done any research into what it is before making claims about it?

> Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.

Play contains a bunch of privileged / platform signature apps. They don't follow the regular permission rules. An unprivileged app not signed with the platform key cannot do automatic upgrades and counts as an unknown source. The Play Store chooses to bypass the trust-on-first-use signature checks of the package manager too. Upgrading apps via F-Droid or manually will perform the signature checks, but the Play Store does not. Try installing an app from F-Droid on a phone with Play, and note how Play will happily clobber it with an update signed with a different key. On the other hand, F-Droid won't do that even if you sign it with the platform key as CopperheadOS does to mark it as a unknown party source.

Re: Why I won't recommend Signal anymore

#340

Post by wtbob »

bascule wrote: post #337
wtbob wrote: post #331

Earlier quoted context omitted.

> 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…

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…

> 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?

Post reply on HN