Why I won't recommend Signal anymore • Hacker News Board

Re: Why I won't recommend Signal anymore

#111

Post by SamWhited » Sat, Nov 05, 2016, 8:06 PM UTC

giancarlostoro wrote: post #110

SamWhited wrote: post #5

I highly recommend Conversations (disclaimer: I've worked on it in the past, although I'm not a project "member" per say): https://conversations.im/ It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty…

Curious for next time I evaluate XMPP is there a list of servers recommended by the Conversations team that people could install themselves? My issue with XMPP is that on the same system I have at DigitalOcean where I could run: an IRC server, a Web Server, and a Mumble Server and extra goodies all together in one box, I couldn't effectively run a XMPP server that would stay up (it would crash). I would of kept at XM…

I'm a big fan of Prosody (prosody.im); even the nightlies (what I run) are remarkably stable, and the memory footprint is tiny (they have some metrics somewhere if you ask in the chat; I can't find them right away).

Re: Why I won't recommend Signal anymore

#112

Post by darklajid » Sat, Nov 05, 2016, 8:06 PM UTC

giancarlostoro wrote: post #110

SamWhited wrote: post #5

I highly recommend Conversations (disclaimer: I've worked on it in the past, although I'm not a project "member" per say): https://conversations.im/ It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty…

Curious for next time I evaluate XMPP is there a list of servers recommended by the Conversations team that people could install themselves? My issue with XMPP is that on the same system I have at DigitalOcean where I could run: an IRC server, a Web Server, and a Mumble Server and extra goodies all together in one box, I couldn't effectively run a XMPP server that would stay up (it would crash). I would of kept at XM…

THE xmpp server I'd recommend is prosody[1]. Lua based, quite active, very friendly community and easy to set up/configure.

1: http://prosody.im

Re: Why I won't recommend Signal anymore

#113

Post by SamWhited » Sat, Nov 05, 2016, 8:07 PM UTC

Veratyr wrote: post #57

SamWhited wrote: post #5

I highly recommend Conversations (disclaimer: I've worked on it in the past, although I'm not a project "member" per say): https://conversations.im/ It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty…

I tried Conversations but I couldn't for the life of me get message history to work. There's just so much stuff you have to do when it comes to XMPP to get things working. Perhaps if I used someone else's server it wouldn't be a problem but I'd prefer not to do that.

I agree that it's a bit hard to get setup if you're dead set on running your own server, but that will be the case with anything (although Prosody and Ejabberd et al could have better defaults for the majority of people who probably just want to throw up a server and be done). The nice thing about XMPP is that if you don't want to run your own server, you're spoiled for choice. The network is significantly bigger than any of the other protocols I know of [citation needed].

Re: Why I won't recommend Signal anymore

#114

Post by darklajid » Sat, Nov 05, 2016, 8:10 PM UTC

heavenlyhash wrote: post #90

qwertyuiop924 wrote: post #82

Earlier quoted context omitted.

I heard from another thread that Matrix is bad a realtime messaging, and quite slow at it. Is this true?

Not even remotely. It's quite good at realtime, and especially reliable realtime. Compared with protocols like XMPP, Matrix scores way higher on reliability because it has message IDs and message ordering baked into the protocol, so it can actually converge on a correct state after network flakes. (I consider this a pretty big deal because silent message drops were a pretty regular issue for me in XMPP, and we all kn…

I'm not trying to compare xmpp (which I know a bit) and matrix (which I don't know about, really), but losing messages with xmpp is probably a thing of the past. There were a good number of issues (the protocol originally didn't expect mobile devices that change addresses/connectivity all the time), but with a somewhat recent set of client and server you should be good.

Re: Why I won't recommend Signal anymore

#115

Post by mst » Sat, Nov 05, 2016, 8:10 PM UTC

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…

Plus the complaint about giphy seems to completely miss the point that the more 'random messaging users' Signal attracts the better from a POV of deniability/etc.

Re: Why I won't recommend Signal anymore

#116

Post by SamWhited » Sat, Nov 05, 2016, 8:10 PM UTC

qwertyuiop924 wrote: post #73

SamWhited wrote: post #45

Earlier quoted context omitted.

I haven't looked into Tox, but I'd be curious to find out the highlights. Really I've just never understood why people complain about XMPP; yes, it's XML which is ugly, but it's also the right tool for the job (easy to stream, very fast SAX-style parsers, event based, etc.), it certainly has its warts, I won't pretend it's perfect, but for the most part it's been around for 20+ years getting the kinks worked out. If…

Tox is a fully distributed ( not federated) p2p system. It supports 2-way messaging, multi-way chatrooms, voice and video calling (using Opus and VP8, respectively), file sharing, and desktop streaming, although not all features are supported by all clients. Although any client can implement any feature they like, so long as they can do it atop the actual network system, sticking to the Tox Client Standard is reccome…

> Tox is a fully distributed (not federated) p2p system

Ah, see, you lost me there already. I'm sure it's clever and well made and all the rest of it, but fully distributed systems either almost never work, are very difficult to get setup and use properly, or end up just not being fully distributed systems (eg. early Skype and it's "supernodes" or whatever it called them, aka "servers", or Tor [which I love] and it's directory authorities which admittedly are elected, but even so are effectively just "servers", or Bittorrent which has either trackers, aka "servers", or hard-coded DHT bootstrap nodes, aka also "servers").

Distributed systems sound great in theory, but in the real world I just never think they're worth the effort, or you have to compromise them and add some centralized element anyways, at which point you might as well just use a federated system so that people who don't want to deal with all that can use a third party server and people who do want their own specially contained distributed node can just run their own server and client.

Re: Why I won't recommend Signal anymore

#117

Post by SamWhited » Sat, Nov 05, 2016, 8:12 PM UTC

Veratyr wrote: post #105

joecool1029 wrote: post #65

Earlier quoted context omitted.

See my comment below. You need a server with the XEP support for it. (XEP-313 I believe)

Yep, I have it. Somehow it was turned off for my account in particular at some point and there's no way I can find to get it back.

If you're using conversations go into the drop down menu, choose Accounts, click on the account you're using and then in its drop down / context menu (what do you call the hamburger menu on Android?) choose "Archiving preferences". Although it's deliberately buried so that you don't mess with it, so I'm not sure how it would have been accidentally turned off, so maybe whatever's happening with your server is unrelated.

Re: Why I won't recommend Signal anymore

#118

Post by SamWhited » Sat, Nov 05, 2016, 8:19 PM UTC

heavenlyhash wrote: post #95

qwertyuiop924 wrote: post #91

Earlier quoted context omitted.

Ah. It was claimed by https://news.ycombinator.com/item?id=12880856 , but that was an XMPP developer, so there's a bias.

It's true that it's a big hunk of JSON. And I'll readily concede that when efficiency matters, I'm more partial to binary formats like CBOR. But XMPP is XML, which... isn't exactly lighter. There's another HN thread where I've talked more about XMPP vs Matrix here: https://news.ycombinator.com/item?id=9772968 -- long story short, I tried to write an XMPP client, and I got grey hairs, fast. The story for consistent de…

XMPP only has to turn the radio on full power mode when it gets a new message or creates a new connection (the tower sends the LTE radio a paging message telling it to wake up, then the long-lived TCP connection can receive data). Matrix has to turn the radio on every single time it wants to check for data, regardless of whether there is data to receive or not. This is the problem with HTTP based protocols; you might have a persistent TCP connection, but it doesn't help you when you have to send a request just to check if there are new messages.

It's not a case of radio off vs on, it's a case of the radio being able to stay in RRC_IDLE mode (which I've probably called "off" more than once, which is where the confusion came from I'm sure, apologies for that) for more of the time, where as with Matrix it almost always has to remain RRC_CONNECTED mode.

Re: Why I won't recommend Signal anymore

#119

Post by SamWhited » Sat, Nov 05, 2016, 8:24 PM UTC

heavenlyhash wrote: post #90

qwertyuiop924 wrote: post #82

Earlier quoted context omitted.

I heard from another thread that Matrix is bad a realtime messaging, and quite slow at it. Is this true?

Not even remotely. It's quite good at realtime, and especially reliable realtime. Compared with protocols like XMPP, Matrix scores way higher on reliability because it has message IDs and message ordering baked into the protocol, so it can actually converge on a correct state after network flakes. (I consider this a pretty big deal because silent message drops were a pretty regular issue for me in XMPP, and we all kn…

It has to make an HTTP request every single time it wants to check if there are new messages… I wouldn't call that a good realtime protocol (though in fairness, I'm sure it's good for many other things).

Re: Why I won't recommend Signal anymore

#120

Post by SomeStupidPoint » Sat, Nov 05, 2016, 8:25 PM UTC

zigzigzag wrote: post #74

tptacek wrote: post #50

Earlier quoted context omitted.

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…

Good points. Perhaps crypto-hipsterism, then: crypterism.

As an aside, I like "crypsterism" as a portmanteau for people who advocate hipster cryptography/security policy.