Live data from Hacker News

Why I won't recommend Signal anymore

sandervenema.ch

321–330 of 350 posts

Re: Why I won't recommend Signal anymore

#321

- Lack of federation Use a federated secure protocol. Oh wait, there are none. Because if a problem appears you just can't fix it without breaking all federated clients. And then they will whine. - Dependency on Google Cloud Messaging Fair enough - Your contact list is not private Fair enough - The RedPhone server is not open-source While it would be nice that it was Open sourced I can understand them not releasing i…

Umm... Tox?

Tox on mobile? Have you actually tried to use it? It drains your battery like crazy.

Re: Why I won't recommend Signal anymore

#322

Earlier quoted context omitted.

I have a virtual server (1 CPU + 1 GiB RAM) running nginx, murmur and Prosody. free(1) reports 80 MiB used memory, thereof 10 MiB for Prosody. (I just have one active account, though: myself.) So unless you're planning on hosting hundreds or thousands of users, you should be fine IMO.

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.

Re: Why I won't recommend Signal anymore

#323
post #242

Earlier quoted context omitted.

This is a common problem with nearly all software, especially on phones.

A common problem that is mostly solved by other services (like the black phone).

At some point you have to trust someone unless you refine you own silicon, make your own chips, audit every line of code they run, etc.

Re: Why I won't recommend Signal anymore

#324
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). 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 disc…

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

Re: Why I won't recommend Signal anymore

#325
post #262

Earlier quoted context omitted.

Agree. I'm not a cryptographer and never claimed to be either. -- and I think it would be difficult to mistake me for a hipster. For one, I don't have that snazzy majestic beard.. Anyway, on to the point. :) Yes, the phone number thing is a policy decision by the Signal people. As I write in my article, it's maybe marginally easier to get connected using phone numbers, but I may want to communicate via Signal with so…

Use Wire then. You can either use you e-mail or phone number. Uses Signal OTR protocol and a single sign in for all your devices. The clients are open source. IMHO Signal is only usable on smartphones. I don't want to link my desktop client with the phone, so I use Wire on the desktop. Oh and Wire is a Swiss company. I see you run your blog off the .ch TLD.

That has other issues though. Last I checked you're unable to remove contacts from your contact list. I'm not kidding.

You can 'block' people, but simply removing them? Nope.

Why do I care? Because at one point the 'upload all contacts to Wire to help you find them on Wire' wasn't optional (I understand it is now) and now I'm stuck with entries on my contact list that I just don't care about. Very weird..

Re: Why I won't recommend Signal anymore

#326

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.

There are no fully open OS builds that are Android.

Osomocombb is the closest we've ever gotten.

Re: Why I won't recommend Signal anymore

#327
post #267

I haven't actually worked with GCM so please forgive me if this doesn't make any sense. I suggest that, instead of routing all messages through GCM, what if Signal could send a "wake up" message via GCM, and then let the app pull the encrypted messages directly out of Signal's servers? A wake up message would only be sent by the server if the message could not be received by the client via normal means (implying that…

> I suggest that, instead of routing all messages through GCM, what if Signal could send a "wake up" message via GCM, and then let the app pull the encrypted messages directly out of Signal's servers? Yep, that's exactly how Signal has been doing it for >1.5 years now.

ahh. I just thought otherwise from some of the other comments here. Makes sense. Thank you.

Re: Why I won't recommend Signal anymore

#328
post #321

Earlier quoted context omitted.

Umm... Tox?

Tox on mobile? Have you actually tried to use it? It drains your battery like crazy.

He didn't ask about that. He asked about a federated/distributed protocol that actually worked. Tox is one.

Re: Why I won't recommend Signal anymore

#329
The author offers no better alternative so I think that means the article speaks for itself: there's not much to do but whine. These are problems, sure, but they're minor when you consider that Signal is the most secure and user-friendly messenger we have on the market right now. If something takes its place, then great. Otherwise, we just will continue to use what is secure and actually works.

Re: Why I won't recommend Signal anymore

#330
post #294
post #291

Earlier quoted context omitted.

Signal is not positioned as a tool for possible TAO targets. Never was, and never will be. Don't use it and please stop spreading the FUD.

What exactly is a TAO target?

https://en.m.wikipedia.org/wiki/Tailored_Access_Operations

Aka NSA's "we really need to get access to this device and will fund diverting backbone traffic / writing firmware malware / whatever else we need to in order to get it" team(s).

Post reply on HN