> go out of your way to use Signal

With that mindset we will never get secure communications to the masses but will repeat the PGP dilemma again and again. UX is of utmost importance.

We would still be on 99.99% HTTP websites if HTTPS required going out of one's way.

Signal is an order of magnitude easier to use than PGP. It's not even close.

The GP was comparing two apps that are actually both very easy to use, one maybe slightly moreso.

(That said, PGP isn't THAT hard either.)

I've been actively using PGP for about 2 years with a few friends that all use keybase, but I still don't feel like I really know what I'm doing, or if I'm really doing the right thing. A lot of the terminology and best practices I learned while first setting it up are lost on me now. It still works though! Well, somewhat... since I switched to KDE thunderbird no longer remembers my pgp password. I miss the gnome keyring.

70% of the UX complaints people have about PGP stem from the huge number of options it has and the lack of guidance it gives you for which options matter.

Which is a shame, because none of the options actually matter.

If you're encrypting messages to a public key, and not with a passphrase, and you're signing the messages you encrypt, you're getting 98% of the value PGP has to offer.

If you want to do things more advanced than that, you probably shouldn't use PGP. PGP has lots of advanced options, but it lacks a lot of fundamental features you'd want from a secure messaging system.

But for the basic use case it supports without options, PGP is just fine.

That's what the Cryptocat people said.

Is it? It is also what Edward Snowden said.

In fact, he may have even said it on Cryptocat; Poitras and Greenwald used it to collaborate with him. Snowden also used Lavabit to send email. Why? Because Lavabit had superior UX to his other options --- because Lavabit handled all the crypto serverside. NSA has presumably read everything he sent on both of those systems. Despite the extreme ease of use both systems boasted, they were both so badly designed that they enabled retroactive decryption.

So I think, if that was an attempt at a rebuttal, it was not a very effective one.

So they used bad products because their UX was good. That seems to be grandparent's point?

Secure messaging products with good UX and bad security should wait to launch until they can have good security; the alternative puts people at risk, as it did to Snowden.

They should but they don't. That's why have competitive UX is important for the good tools or people won't even consider using them. We have seen that happen countless times.

Tbh, Signal's UX on Android is pretty good.

Is Telegram just better on iOS or am I missing something when you say it has better UX?

Enh. Signal's UX is still not effortless.

For example:

* Does not make it clear it's a point to point mapping (on iOS) right now. I discovered this the hard way.

* Unclear failure modes (see above). It's entirely possible to have messages be silently dropped.

* Texting vs. call methods unclear. I.e. there's a phone icon but no text icon (select name instead).

* Contacts list has some text only, some phone only, some both.

* The whole contacts list arguably needs to be rethought. It only shows others that have installed Signal/RedPhone/Textsecure. There is no easy way to see if someone does NOT have Signal installed and have the functionality to send a link to invite other person to add the app. I think this would help tremendously in the virality of the app.

* There used to be easy ways to invite people to the app within the app, seems to have gone away with only a tweet an invite to app store function remaining.

* There have been several instances when I can't see someone after they install Signal. They have to initiate a message to me in order for the contact to show up in the list.

* Signal has poor handling for contacts with multiple numbers. It's not clear which number is being used and you can't switch selection of numbers.

So what I'm saying is don't necessarily ape what Telegram/WhatsApp etc. is doing but I think Signal would do well to study hard the onboarding workflows of those apps.

What do you mean it's a point-to-point mapping? Genuinely curious.

You mean that there is no server to buffer failed delivery attempts if one of the devices is off or disconnected?

(Side note, I've hit that the same bug where the other person has to contact me first because they don't show up in my contacts, even though they should.)

It's one device to one device (as stated elsewhere in this thread. Apparently, only Android+Chrome combo is supported for multi-device).

Put differently, I can't register the same number to an iPad and iPhone simultaneously at this time and hope to communicate with someone. It apparently gets things all confused.

I was doing some more testing and it also appears that I'm unable to call someone with a greyed out name but with available phone icon. Once again, no clear indication if this is a bug (not supposed to happen) or a feature (can call but not text).

Oh I see. That is indeed annoying. So I guess this bit from the desktop announcement is a stretch: "....all incoming and outgoing messages are displayed consistently on all your devices." I mean I guess if you ONLY have one phone and a desktop that would be true? And I guess if Signal only allows you to register those two things, it is TECHNICALLY true, in the sense that "all" <= 2

And all = Android + Chrome (at least for now).

Since I'm not an Android user, I'm unable to confirm all > 2 scenarios. Someone should try and report back.

I have Signal on Chrome on multiple computers. It works just as expected with messages shared across Chrome and to the phone.

It's all very fast and working quite well.

I do have an "invite" prompt on my SMS contacts that don't yet have Signal: "Invite to Signal: Take your conversation with %s to the next level.". Perhaps it's a function in the beta version that isn't in the live version yet?

I haven't seen a message with a double-tick that's been dropped yet, at least not on a recent version. It can sometimes behave poorly with Android battery-saving mode - however, so does plain SMS. Turning off sync is part of the actual point of battery-saving, but conversely, I never want to not get messages. That's arguably Android's problem, not Signal's. Still, it uses GCM, so at least there's hope for the deep sleep (which I haven't tried yet).

Surely battery saving modes should not drop messages? It could delay them but should never (well, almost never) drop them.

With no knowledge of how signal's servers actually implement this, I would like to ask you... how long should the central server hold on to the (encrypted) message that Alice sends to Bob if Bob never becomes available again?

I haven't thought about what's reasonable (an hour? a week?) but it still shouldn't be dropped but bounced back to the sender with an undelivered message. At last that's how email solved it some thirty years ago.

(But perhaps a new protocol could take the opportunity to improve things further and offer on-line delivery status notifications throughout the process.)

No matter what, messages should never be silently dropped.

Best effort, deliver at least once?

At least that how it seems iMessage seems to work. I have no idea how long iMessage holds on the queue but it seems no more than a few days.

Not sure what kind of attack vector a public TTL would constitute.

This reply is mainly intended for Moxie and the team developing Signal as feedback (which they probably have received from others). I'm not going to focus on security, because Signal is likely the best on that front from whatever I have read.

I really want Signal to be my only app for chats and I do try Signal once in a while, but I always go back to Telegram for a few reasons. Telegram is very fast in delivering messages, just like it claims. Signal, on the other hand, has been and continues to be slow. Messages could sometimes take anywhere from 10 seconds to even a minute or several minutes to get delivered. That's not really a good UX for chats when you can't say whether your message would get delivered or not. If I wanted to send a slightly urgent message (urgent enough to be a message but not urgent enough to be a call), I wouldn't rely on the current implementation of Signal. Back and forth communication also becomes very odd and frustrating if the messages don't get delivered within a few seconds. Even SMS seems better when compared to Signal's speed of message delivery.

Next is the multi-device availability and syncing of conversations in Telegram. Once you get used to having Telegram on the desktop/laptop and phone (and perhaps a tablet), it fits in so well with the physical location someone is in, what the person is doing and which device the person feels comfortable with. There are many people who have deep and heavy conversations on these chat apps, and doing that on a small screen's touch keyboard is a big hindrance. Being able to do that with a laptop or a desktop makes it so superior an experience that it's difficult to give that up.

People that I chat with either don't know much about encryption and privacy or don't care much about those. Getting some of them to use Telegram instead of WhatsApp was difficult, but they're now big fans of Telegram because of how it works and what it provides. But getting them to move to Signal? I can't imagine doing that with the current state of affairs with Signal.

While Signal may be a very secure chat app, not focusing on the things that help increase UX (and in turn, market share) will not help in the long run.

My hope and wish is that Signal development would accelerate faster and provide quicker releases that solve what I see as fundamental issues. This would benefit everyone and make our world a much better place.

What if you care about control over the system and not being tied to a single vendor?

Then you definitely don't want to be using Telegram.

I'm curious about this response. Could you please explain or point to something that explains, for a common person who doesn't code or cannot build code or cannot maintain servers, how Signal would provide more control and avoid being locked to a single vendor when compared to Telegram?

It does not. In practice both are equivalent in that regard. I guess tptacek meant that Signal might have less control over you than Telegram, but that's a different issue from what I was thinking of.

Both Telegram, Signal¹ rely on a central server to which all users connect. If that server goes up in flames then nothing will work for anyone. Or if those who run it turn out to be evil or otherwise doing bad things then there is nowhere you can go without losing all your contacts.

But in a system that has multiple servers that talk to each other, like email and Jabber/XMPP, you have a choice in who provides the server while still being able to talk to everyone on the network. So then it is at least possible to switch to another server or provider and still be able to reach your contacts. It is also possible to run your own server, or convince your more technical friend to run one for you. This model is called a federated client-server model.

A true serverless peer-to-peer system would in theory be even better, but in practice it is much harder to build and maintain, especially on mobile where devices may lose coverage at any time. So for example Skype (before Microsoft bought them) would promote some clients to "super nodes" which other clients would use to communicate ... kinda like having servers but with less control over who they are.

(Note, I work on XMPP software so I'm kinda biased)

¹ There appears to exist server software but it is unsupported and might not be useful for more than talking to yourself.

There was talk some time ago now about Signal server federation. I was under the impression that it was planned and either dropped or de-prioritised for now.

Certainly, it seems that while running your own server might not be actively discouraged, it isn't supported by the Open Whisper Systems team at the moment.