5 ms·
It's not the core email UX that's the problem; it's SMTP email that's the problem. You're article seems to argue the opposite to me. For example, the followin
by jackpirate 7y ago
It's not the core email UX that's the problem; it's SMTP email that's the problem.
You're article seems to argue the opposite to me. For example, the following quotes are all related to the email UX:
1. In any group of people exchanging encrypted emails, someone will eventually manage to reply in plaintext, usually with a quoted copy of the entire chain of email attached.
2. Every archived message will eventually leak.
My understanding is that it would be possible to create an alternative app that is compatible with the Signal protocol that would provide a different UX. This alternative UX could, for example, offer the ability to save all messages onto google docs, eliminating the benefits of secure messaging.
- tptacek 7y agoThere is nothing about the core UX of email that requires plaintext as an option; you can straightforwardly imagine, and probably even readily implement, a secure messenger with the same UX as Outlook in which it's not possible to plaintext-reply a message, or send plaintext at all. Archival is a problem. But you can also imagine something with the UX of Outlook that implements the same advisory-level disappearing messenger feature that modern secure messengers have; in fact, I wouldn't be surprised if you told me Outlook already has that feature (but that it only works for Outlook users). The problem is the legacy of SMTP. It's not what the UI looks like.
- TylerE 7y agoPretty hard to block PrintScreen though.
- schoen 7y agoThat feature isn't trying to prevent people from deliberately archiving or forwarding messages in a way that the sender didn't intend, expect, or prefer.
- lvh 7y agoSure! But a screenshot is trivial to forge anyway, and even if you block PrScrn, people can always taddle. The goal is to get the message safely to the recipient, not prevent the recipient from disclosing anything afterwards. (Non-repudiation is a common goal, but screenshots being easy to forge solves that.)
- jackpirate 7y agoI 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.