I think GPGTools for OSX does a great job of a client.
Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
91–100 of 165 posts
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#92Earlier quoted context omitted.
There is a lot wrong with that scorecard, and it's dispiriting to hear that it is actually influencing research.
Interesting; I'd really like to hear what issues you have with that scorecard.
That bet was a reaction to the release of the EFF scorecard, which at the time gave Cryptocat(†) a perfect score but dinged ChatSecure, which is a libotr client, for not having an audit done.
I told Matthew Green I'd write up something about the bet, and what did get reported to me about libotr; I'll probably spend a few thousand words critiquing the scorecard there. A brief outline, though:
* There are places where the scorecard is factually misleading. For instance: there seems to be no coherence to what "source code available for inspection" means; it still lists Telegram as being open source!
* It's oversimplified in misleading ways as well. Systems which technically have the capability of verifying peers are given big green checkmarks even when that feature is so broken as to be useless. And, of course, there's the "been audited recently" checkmark, which, as anyone familiar with software security auditing will tell you, means absolutely fuck-all (again: ponder the fact that libotr, which has been a high-profile target for something like a decade and is more or less frozen stable, was counted as "not audited", while projects that got a 1-week drive-by from a firm specializing in web security got a big green checkmark).
* What does "security design properly documented" even mean? Where's the methodology behind the chart? A few paragraphs of text aimed at laypeople isn't a documented methodology! The one place they eventually did add documentation --- "what's a good security audit" --- tries to explain a bunch of stuff that has almost nothing to do with the quality of software security inspection, and then throws up its hands and says "we didn't try to judge whether projects got good audits". Why? Why didn't they consult any named outside experts? They could have gotten the help if they needed it; instead, they developed this program in secret and launched it all at once.
* The project gives equal time to systems that nobody uses (at one point, Cryptocat was near the top of the list, and ChatSecure was actually hidden behind a link!), and is ranked alphabetically, so that TextSecure, perhaps the only trustworthy cryptosystem on this list (with the possible exception of the OTR clients) is buried at the bottom.
* If the point of this chart is to educate laypeople on which cryptosystem to use, how is anyone supposed to actually evaluate it? They don't really say. Is it ok to use Jitsi's ZRTP, despite missing the "recent audit" checkbox? What about Mailvelope, which is missing the forward-secrecy checkbox? Can anyone seriously believe it's a better idea to use Telegram or Cryptocat, both flawed ad-hoc designs, than TextSecure or ChatSecure?
I guess I can't be brief about this after all. Grrr. This scorecard drives me nuts.
I am not saying that these flaws in any way impacted your particular research project.
PS: an old thread on this: https://news.ycombinator.com/item?id=8557654*
† 31580544b27c10736ebe1bdd05a56d96c486823d563d4493c317548976c3d8db
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#93I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…
See "Why King George III Can Encrypt" (2014) for an alternative metaphor to 'private key' and 'public key': http://randomwalker.info/teaching/spring-2014-privacy-techno... >We present the user with four items, a key, lock, seal and imprint. The key and lock serve the purposes of encryption: Alice distributes her locks as widely as possible so that others can send her messages that only she can open with her key. Simi…
I already explain encrypted email to colleagues with the key and lock metaphor: I give you a box full of open padlocks to which only I hold the key, and you do the same for me. Anyone can have the padlocks as long as you keep the key secure. Seems to work.
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#94Earlier quoted context omitted.
I've been using GPG since a while now, to sign my outgoing mail. I don't encrypt it as I don't know anyone who uses GPG. I'm still happy to use it, to get used to it, and to see alternative uses. Signing is in my view a big improvement, to make sure nobody has messed with the messages. I always use HTML, so the receiver gets an attachment with the signing hash in it, and no strange text in the mail. I use a signature…
Getting a strange attachment is better then getting a few strange lines of text at the end of the email?
With PGP/Mime email clients that don't understand OpenPGP simply show a small attachment. Without PGP/Mime (the old way) you get funky delimiters in your mail body that look scary to non-technical users. I started with the old way (because it appears to be more compatible with legacy email clients) until a colleague worriedly asked me about the weirdness in my mails, so I switched to PGP/Mime. As far as I can tell only really old Outlook versions can't handle PGP/Mime, and you can use plain text mails as well as HTML.
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#95Earlier quoted context omitted.
> In practice, I heard someone say that the biggest improvement in people’s privacy has been use of Gmail. In practice, until Snowden happened, NSA was able to access all the Google's internal data as Google replicated in plaintext its whole datacenters through the links snooped by the NSA or the GCHQ. http://www.slate.com/blogs/future_tense/2013/10/30/nsa_smile...
Correct. And now they encrypt all the inter-data center traffic. Question: Is that done on an end-to-end basis? Or do they encrypt the links between data centers? I want to encrypt a 10g ethernet and all the solutions look quite expensive. Has anyone done high speed encryption (i.e. 10gbps/1500 byte packets) with strongswan or similar?
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#96Backwards compatibility is the killer. The whole design of PGP is to be the envelope to make email private, versus the plaintext postcard that everybody can read. It works with existing servers and existing mail clients. The biggest Snowden revelation is the importance of metadata. Just knowing whom you talk to, when, is frequently enough to compromise the parties involved. You might be doing something legal now, but…
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#97Backwards compatibility is the killer. The whole design of PGP is to be the envelope to make email private, versus the plaintext postcard that everybody can read. It works with existing servers and existing mail clients. The biggest Snowden revelation is the importance of metadata. Just knowing whom you talk to, when, is frequently enough to compromise the parties involved. You might be doing something legal now, but…
Anyone reasonably competent conducting the most cursory of investigations could figure out who I do business with in hours. The NSA boogeyman with omniscient network surveillance capability will come up with ways to find the source/destination of obfuscates messages anyway.
Sensitive data that I routinely handle is content. Employees improperly reading mail (on either sender or recipient side), or some data breach affecting mail servers, desktops, or relays are much higher risks.
PGP is a great way to encrypt ad hoc data at rest. I think the reason it isn't pervasive is that once you figure out what is really secret, you develop specific tools to transmit that data more seamlessly.
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#98http://davidjarvis.ca/dave/tech/privacy.shtml
Once signing is in place, you can send an encrypted e-mail:
https://support.mozilla.org/en-US/kb/digitally-signing-and-e...
Here's the response from Robert Hansen on why Enigmail has such a complicated process:
> Here's the heart of the problem: "Modifying the wizard to account for average users" works only if you can define an 'average user'. And you can't, the same way that I can't. Please don't misunderstand me, it's not my intent to slight you or your willingness to do a lot of hard work. (Quite the opposite: I really hope you're willing to do it!) But we have to start by looking at the realities, and the reality is the the GnuPG-using community is incredibly fractious and prone to declaring holy wars over the most trivial and irrelevant of details.
> If you set key generation to default to 4096-bit keys, a lot of people will roll their eyes and accuse you of subscribing to key length fetishism. If you leave the default at GnuPG's default of 2048-bit keys, a lot of people will scream that you're not providing enough security.
> If you default to inline PGP, international users and people who love HTML mail will complain the default doesn't work for them. If you default to PGP/MIME, people who post to mailing lists will scream that your change just broke their communications. (Not a joke, incidentally: there are a lot of mailing lists that strip all attachments as a security measure... which has the side effect of completely breaking PGP/MIME.)
> The reason why we ask so many questions in the wizard is not because we're afraid of losing existing users, although that would definitely be a consequence if we were to go with your more simplified way. The reason why we ask so many questions is because we cannot know which option a user will demand to use and will think should be enabled by default.
> If we can't come up with a default that will work just fine out-of-the-box for 95% of our userbase, then we're not going to make it a default. We'll ask the user for their preference. And that's the reason why our wizard asks so many questions: we ask questions when there is no clearly correct default.
I think he's wrong. Flexible software would have a default wizard for basic users and an advanced wizard for users who care about the difference between 2048- and 4096-bit keys. It's one question at the start of the install process, "Would you like to tweak encryption settings?" -- Yes, No, and "What does tweak mean?" are possible answers. Or install with default settings and guide power users to tweak the parameters post-install. Encrypted e-mail should not require over 90 steps.
Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#99Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
#100Backwards compatibility is the killer. The whole design of PGP is to be the envelope to make email private, versus the plaintext postcard that everybody can read. It works with existing servers and existing mail clients. The biggest Snowden revelation is the importance of metadata. Just knowing whom you talk to, when, is frequently enough to compromise the parties involved. You might be doing something legal now, but…