3 ms·
I don't think you've addressed my point. My point is that an alternative client (and hence UX) for the Signal protocol could still have all the flaws that you
by jackpirate 7y ago
I don't think you've addressed my point. My point is that an alternative client (and hence UX) for the Signal protocol could still have all the flaws that you point out about email. Therefore, the security of Signal is fundamentally dependent on the client/UX. A bad client (that is 100% interoperable with existing the existing Signal client) would break Signal in the same way that email is broken.
Of course such a client for Signal doesn't exist and is unlikely to become widespread even if it were created. Therefore Signal is more secure. I agree with your conclusion and everything in the article; I disagree only with the claim that it is not a UX problem, and the disagreement is likely that we are drawing the boundaries around what constitutes UX in different places.
- tptacek 7y agoNo, it could not have all the flaws that I've pointed out. It seems pretty obvious to me why an alternate Signal client wouldn't have those flaws. Be specific about which one you're thinking of.
- jackpirate 7y agoAn alternative signal client could forward all messages to a gmail account (pt 1 from my original post) and store the messages in plain text on the local computer (point 2). Of course these would be very poor design choices for the alternative client, but none-the-less technically possible.
- tptacek 7y agoThese are not interesting points. Respectfully: do you have interesting points about what an alternate Signal client might actually do?
- asveikau 7y agoThis is not the point of the commenter you're going back and forth with on the thread, but as I read this it occurs to me that some version of the plaintext reply problem exists in real life regardless of protocol. That is, once the recipient has plaintext, we don't know what they're going to do with it. They could read it aloud in a crowded place. They could blab about it to all their friends. They could pass it verbatim to somebody else. Or more innocuously, they could store it in an insecure database as in this commenter's scenario. Now, if you're using something better than email, the protocol itself won't be the problem and it's less likely (or impossible through the protocol itself) to be an unintentional plaintext transmission, so this fact is pretty moot and not at all a justification of how email clients might behave. Nobody building these systems has to necessarily be concerned about protecting against "social" types of plaintext leaks.
- tptacek 7y agoThis is what people are talking about when they talk about the "Print Screen" button or screenshots or securing the clipboard. But I'm not kidding about the "inevitable plaintext reply" problem. Everyone I know who has used PGP at scale has seen it. These aren't people deliberately doing dumb things; they're doing things a bad tool begs them to do, because the underlying system is designed for, expects, begs for plaintext. Nobody can do anything about people deliberately subverting the security of their privacy tools. There's nothing deliberate about plaintext replies. The people who do that don't want their messages sent in plaintext.
- asveikau 7y agoI know. I am not claiming otherwise.
- jackpirate 7y agoI agree they are not interesting points. But they are exactly the problem you are complaining about for email. Also respectfully: If the point of your writeup is to suggest that the signal protocol is better than the SMTP protocol, then I suggest you delete those points from your writeup. If the point of the writeup is that the signal experience is better than the email experience, then I suggest you stop claiming that the signal protocol is better than the SMTP protocol.
- tptacek 7y agoI don't follow this at all. Obviously, the Signal Protocol is better than the SMTP Protocol.