
Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client - lisper
http://arxiv.org/abs/1510.08555
======
Decade
Backwards 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 you can’t tell when some
despot takes over and makes your activity illegal. When data can potentially
last your lifetime, you need to consider this sort of thing. Illustration:
Using Metadata to find Paul Revere. [1]

So, we need a new mail transmission protocol that limits the amount of
metadata that can be seen. Something like Dark Mail [2]. I don’t think Open
Whisper Signal hides the metadata.

The problem is that Dark Mail needs to be developed and its security reviewed,
and people need to adopt it. It needs new servers and clients, and the
prevalence of Windows shows just how difficult that problem is. Also, any new
messaging program these days needs a story about web and mobile.

In practice, I heard someone say that the biggest improvement in people’s
privacy has been use of Gmail. The clients connect to it with SSL certificates
controlled by Google; Google promotes 2-factor authentication and access
tokens; and Google’s legal team challenges subpoenas. As long as you are not
leaking national security secrets, I think this is adequate until a better
system is deployed.

[1] [http://kieranhealy.org/blog/archives/2013/06/09/using-
metada...](http://kieranhealy.org/blog/archives/2013/06/09/using-metadata-to-
find-paul-revere/)

[2] [https://darkmail.info](https://darkmail.info)

~~~
baudehlo
SMTP with TLS doesn't leak any metadata except the connecting IP address. And
with DMARC you can mandate it.

Calls for whole new protocols for email are usually made by people who don't
understand the email ecosystem as it currently stands.

~~~
function_seven
Can the TLS be enforced by the sender all the way through the chain to the
destination mailbox?

~~~
Arnt
The sender (the sender's service provider or organization) decides when to use
TLS while the message bounces around internally, then (this is the typical
long hop) the recipient's server and the sender's SMTP client negotiate, and
then the recipient gets to decide.

The sender may have opinions, but as soon as the message is handed over to the
recipient's server, that's it. That's the end of the sender's influence, and
that's how it has to be on a global internet. People can connect without
having their infrastructure approved by anyone else.

------
squidlogic
I think of it like this: usability can be a security feature.

If you build a "perfectly secure" piece of software, but it takes a very high
level of skill to use it, your users will use something else that is easier to
use, but less secure. And then how has your ideologically perfect piece of
software helped improve their security?

If you make tradeoffs for usability, you will raise the bar because people
will actually use what you make.

~~~
x5n1
Fork Thunderbird or some such client, also make a web client available. Make a
new service which offers only encrypted e-mail by default (with a new e-mail
address that includes e-mail hosting for your own domain) and provides the key
server and everything else. Advertise it as something different from e-mail
like encrypted e-mail. Set a new precedent, create a new industry.

~~~
mike-cardwell
Unless they can check their email on their phones, it wont take off. Mobile
email clients are much more important than desktop nowadays IMO.

~~~
gozo
Most "users" don't care about end-to-end encryption and instant messaging has
already become the "better e-mail" on phones. The only way I see of breaking
into this space is to make something for companies, because they still have
reasons for a "better e-mail" and value encryption.

------
jordanpg
I 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" continues to appear to be an enormous password, people
will continue to treat it that way, along with all the crazy worst-practices
in the world. Not to mention the huge host of problems that accompanies key
security for the layman.

I don't know what the answer is, but I do think that a physical token of some
sort is the right start.

2\. At the end of the day, the vast majority of people are not interested in
the trade off between better security and convenience.

There is a learning curve, however shallow it can be made, and those that
genuinely want or need better security are motivated enough to do the
learning. For everyone else, it's like optional homework.

I would add to this that most everyone I know who cares about security is
_quite comfortable_ with a large array of APIs and software to do all sorts of
cryptographic gymnastics. The bar is quite low already -- it has been for some
time, IMO.

~~~
rogeryu
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 with a link to my public key and a
link to the PGP page on Wikipedia. Everybody can read my mail, and if they
want they can validate it.

~~~
kobayashi
The idea of including a link to your public key and a link the wiki on PGP is
great! I'm going to do this as well. Would you mind showing me how you link to
the above mentioned?

~~~
rogeryu
Here's the code that I used in Thunderbird. I make it small and light in
color.

<div style="font-size: 10px; color: #666;">This message is signed using <a
href="[https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</a>](https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</a>).
Public key: <a
href="[https://pgp.mit.edu/pks/lookup?op=get&search=0xBE5D1E31ABCD1...](https://pgp.mit.edu/pks/lookup?op=get&search=0xBE5D1E31ABCD1234">)
ABCD1234</a> </div>

I see the link in the code is not closed properly, so you need to fix this.

------
patrickaljord
Real secure encryption is and always will be not user friendly because it
means only you can know the private key. This means no "Forgot my password"
functionalities, no fancy powerful cloud AI analyzing your data and suggesting
cool stuff, no free hosted full text search of your data, no open directory of
friends to search on etc. So basically, no gmail, icloud, facebook, dropbox
etc. It would require a complete new paradigm, sure there are interesting
techs such as ethereum and bitcoin but they are not user friendly, and don't
scale much to the regular user (downloading the whole blockchain is a no-no to
most people for example) but most importantly, current solutions are too
convenient and work really well (bar privacy and security issues most don't
care about). So you'd need a tech that not only is way better, more efficient
and smarter than current ones (gmail, google, facebook, icloud etc) but also
secure and decentralized. Not happening any time soon but hopefully not
impossible either.

~~~
iak8god
Because I have no interest in memorizing keys, I store them on disk protected
by a passphrase. I don't know if this counts as "Real secure encryption" but
it's sure a lot more secure than more typical use of email.

~~~
patrickaljord
You can store it on disk protected by a passphrase but that's still not user
friendly as way too few people would be willing to or capable of doing so
which was my main point. My point is that secure encryption is by definition
impractical, inconvenient and not user friendly which makes its adoption by
mainstream users very unlikely at least in the foreseeable future.

------
makmanalp
I think it's easy to pick on a weak example, but much progress has been made
since the original "Why Johnny Can't Encrypt".

A recent example: Textsecure / Signal has been very, very smooth for me and I
doubt it'd be much more difficult for laypeople either:
[https://whispersystems.org/](https://whispersystems.org/)

~~~
Perceptes
Although, like mentioned in above comments, Signal does not hide metadata,
which can be as valuable to attackers as the contents of the messages
themselves.

Also, in terms of adoption, it's still hard when everyone has phones that use
iMessage or SMS by default. iMessage is end-to-end encrypted, but not
compatible with Signal, and Android has no equivalent baked in. Using Signal
requires two extra steps for the user 1) downloading/installing Signal 2)
knowing about it and caring enough to use it in the first place.

------
lordofmoria
PGP does have a legitimate use case, namely Edward Snowden: he's technical,
the NSA is his main threat vector, and it makes sense for him to spend lots of
time reasoning about the web of trust, signing keys, double-checking
fingerprints, and creating 12-minute explainer-videos for people he needs to
communicate with (for reference:
[https://vimeo.com/56881481](https://vimeo.com/56881481)).

Here's the problem: not everyone needs the stringent encryption guarantees
that Snowden needed. There is value in crypto systems that are less demanding
than PGP, especially if they come with vast increases in usability.

iMessage, I think, is what most people need in their everyday life. It's end-
to-end encrypted, and although it has a central key-server, it is backed by
Apple, which has publicly announced their commitment to user privacy. Yes, a
central key-server means that you can't verify the fingerprints Apple gives
you, but again, that's not what iMessage's encryption was designed for. If you
need that level of certainty, use Signal.

~~~
anon1mous
What a non-sense.

We live in the information era, information nowadays is the ultimate power.
Democracy depends on the balance of power between the people and the
government. If the government has all the data, it has all the power.

------
bluegate010
Hey HN, I'm one of the authors on this paper. I'd be happy to answer any
questions.

~~~
bhickey
Given the usability and technical problems with PGP, do you think it's worth
saving?

~~~
bluegate010
For those who value security enough to take the pains to learn the system,
yes, it's useful. For your average netizen, we feel a progressive approach
would be more effective. Start out with a key escrow service and if the user
wants more security, they can ratchet up to PGP.

------
pen2l
Should be considered with moxie's piece:
[http://www.thoughtcrime.org/blog/gpg-and-
me/](http://www.thoughtcrime.org/blog/gpg-and-me/)

------
snassar
This paper should be titled: Why Johnny Still, Still Can't Use Mailvelope:
Evaluating the Usability of Mailvelope.

~~~
bluegate010
Yes, we probably would have gotten better usability scores if we developed our
own PGP client with a better UX and tutorials. We selected Mailvelope because
it was rated highly on the EFF's secure messaging scorecard [1] and we were
exploring how the state-of-the-art in PGP software actually performed with end
users.

[1] [https://www.eff.org/secure-messaging-
scorecard](https://www.eff.org/secure-messaging-scorecard)

~~~
tptacek
There is a _lot_ wrong with that scorecard, and it's dispiriting to hear that
it is actually influencing research.

~~~
bluegate010
Interesting; I'd really like to hear what issues you have with that scorecard.

~~~
tptacek
Matthew Green and I had a bet for the last year, which just ended, over
libotr's security; I bet him that nobody would find a sev:hi flaw in it all
year, and, of course, won, because at this point all the low-hanging fruit in
libotr has been shaken out.

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*](https://news.ycombinator.com/item?id=8557654*)

† _31580544b27c10736ebe1bdd05a56d96c486823d563d4493c317548976c3d8db _

~~~
UserRights
What would be a better way to produce such a scorecard?

Is there already any collection of common criteria established by computer
scientists and accepted by experts and / or any kind of standardization of
requirements for secure software that was produced by leading security
capacities that allows to extract data for a compact visual comparison like
the eff scoreboard?

Would you like to provide or show me a link or any material that compares "the
security" of products and offers an understandable and "industry-accepted"
categorization?

Isn't it a bit strange that a small organization of non computer scientists
produce something that was painfully missing for at least 50 years? Isn't it
clear that a first approach to such a thing must fail and that this can only
be a prototype for a process that should be adopted and worked out by people
who understand what they are doing?

Isn't it a bit strange, that there is no such thing as that scoreboard
produced by an international group of universities and industry experts, with
a transparent documentation of the review process and plenty of room for
discussion of different paradigms?

The eff scoreboard demonstrates painfully the obvious omissions of multiple
generations of security experts who failed to establish a clear definition of
what security exactly means, how to discuss it and how to find an acceptable
approach to establish a thing that would allow to be named "review" in the
scientific meaning of the word.

It is totally clear that Apple and Microsoft have very different ideas about
security than OpenBSD developers, but it would still be of great value to have
a space where people could follow that discussions and compare the results of
different approaches and solutions to security related problems.

The eff scoreboard carries the embryo idea of a global crypto discussion,
review, comparison and knowledge site that could also serve as a great
resource for non-crypto people and students to learn a lot about that field.
The highly valued information you and other experts are dropping here and
there in HN threads and/or on various mailing lists should be visible in a
place that collects all that stuff and allows for open discussion of these
things in the public, so people can learn to decide what security means for
them.

If such a thing exists, please show me.

If not, please build it.

~~~
tptacek
There is not. Software security is a new field, cryptographic software
security is an even newer field, and mainstream cryptographic messaging
software is newer still.

The problem with this flawed list is that it in effect makes endorsements.
It's better to have no criteria at all than a set that makes dangerously
broken endorsements.

------
jnpatel
It's worth mentioning, the original paper [0] recently won the USENIX Security
2015 Test of Time Award [1], which highlights papers at least 10 years old,
that have made a lasting impact on their field.

[0]:
[http://www.gaudior.net/alma/johnny.pdf](http://www.gaudior.net/alma/johnny.pdf)

[1]: [https://www.usenix.org/conferences/test-of-time-
awards](https://www.usenix.org/conferences/test-of-time-awards)

------
iza
What ever happened to Google's "End-To-End" Chrome extension?
[https://googleonlinesecurity.blogspot.com/2014/06/making-
end...](https://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-
encryption-easier-to.html)

~~~
dguido
It's still being worked on. Turns out, getting these things right from a
crypto and a UX perspective is hard.

------
jheriko
i'm not entirely sure this is worthy of a paper... its pretty much a common
sense conclusion to reach if you've ever tried to use these things that the UX
is usually terrible - even by the standards of a technical user.

too many manual efforts need to be made, even after setting up software that
is purely designed to make this sort of thing easier.

mailvelope is a good example though - i've tried using it, but its not very
clear what to do with it, and even once you get to the point of having the
button appear in your gmail or whatever you have to then go and do even more
things before you can actually send something that is encrypted. optimising
this workflow should be trivial... a lot of this stuff can be done for you,
e.g. by automatically enabling for common webmail sites, automatically
generating some keys for you etc.

------
mbrock
I think we should start with an EXTREMELY simple app that does not attempt to
do any fancy e-mail client integration, but is aimed at making it possible for
non-nerds to send one-off secure mails and files in a way that is at least
SLIGHTLY fun.

Keybase, GPGTools, and all of these things have different features and menus
and all kinds of stuff which makes them EXTREMELY intimidating.

My mom is a teacher of computers, she is an expert at Excel and basic Windows
things and Twitter and mail and she's even somewhat into Bitcoin, but crypto
makes her instantly freeze into "oh my god what is happening I am terrified
and confused" mode.

Today she needed to send some encrypted JPGs to verify her identity for some
Bitcoin wallet thing. The support asked her to please encrypt her stuff with
our public key.

When she opened that public key it came up in Notepad++ as a huge intimidating
block of random characters. That was probably enough to put her in a bad mood.
After that she wasn't very receptive and I guarantee that every single guide
or tutorial or program would be WAY too nerdy, boring, and complicated for her
to follow step one.

Anyway I just did it for her on my Mac and I explained my thoughts as I did it
and she said "see I understand the concepts but it's just too much stuff to
know about to actually do it myself."

I said "yeah, that's what Snowden keeps saying, these things are just too
difficult for normal people. Even Glenn Greenwald, that journalist you know,
apparently he sucks at computers and it took him months to even install the
crypto app."

So I wish I could have said "just go to crypto.express" (random made up
available memorable domain) and follow the easy steps and you can encrypt your
zip file pretty easily with just drag and drop and it's totally made for
newbies but still Snowden-level secure.

I don't really think people in general relate to the paranoid wish to encrypt
all your mail. They probably think more in terms of specific secrets that they
care about protecting. So you could get them started on use cases like sending
passport photos, passwords, codes, credit card numbers, or dick pics or
whatever it may be.

Once they have some tiny bit of successful experience with using
private/public keys that one time, and it wasn't super impossible like they
thought, they might be more open to learning more sophisticated ways of using
crypto, such as automatically encrypting and signing mail.

~~~
lisper
What do you think of this?

[https://github.com/Spark-Innovations/SC4](https://github.com/Spark-
Innovations/SC4)

~~~
mbrock
I just tried it and it seems like a pretty good start!

It doesn't seem to have launched publically yet but I hope they will have a
landing page with utterly clear copy in a large font written with the mindset
that for example this sentence

"Once you have entered your email address, SC4 will automatically provision
you with a set of random keys."

is terrifyingly incomprehensible gobbledygook.

...actually I might be confused right now but even I (a total smartypants guy)
can't seem to figure out how to paste in somebody else's public key in there.
The default option is to encrypt for myself, and I see no way to input another
key, only a text box for the message...

Edit: oh, maybe the text box is for the keys, and the thing I want to encrypt
should be drag and dropped? Either way, the UI as it is right now is difficult
to understand, but I suppose it is a prototype.

~~~
luvz2code
Keys are stored in local browser storage. How does this work when browser
cache is cleared?

~~~
lisper
Cache is separate from localStorage. Clearing your cache should have no effect
on your SC4 keys. (Also, if you're running one of the two standalone versions,
your key is stored in a file.)

~~~
gbuk2013
At least in Firefox, clearing cookies (not an unreasonable thing for users to
do once in a while) will also clear localStorage.

~~~
lisper
That's true. There are limits to what one can do when running in a browser. If
you have a better idea for where to store keys, I'm all ears.

------
longlivegnu
I mean using (Keybase) [https://keybase.io/](https://keybase.io/) is pretty
easy

~~~
patrickaljord
I created an account there and never used it ever again, same for most people
I know. Even the rock stars featured there don't seem to be using it. Also, in
what world is a cli tool with a git-like interface "pretty easy" outside of
the tiny world of computer programmers?

~~~
mike-cardwell
Same here. I set up a Keybase account and never used it. And I'm somebody who
actually uses PGP every day.

------
dorfsmay
I personally have started to use enigmail in Thunderbird a lot more since it
has its newer, much more intuitive interface.

------
mikeytown2
If someone could use your public SSH from say Github and send you a private
message that would be great. From my understanding that is not possible. You
need to generate and exchange PGP keys before, a major UX issue. Allow SSH
public keys to be used and we'll be a lot closer to fixing the secure email
issue.

~~~
nailer
Also Facebook (which has an official onion site to help if your internet
connection is suspect) has GPG as a standard part of all user profiles. This
would be a much more normal person directory than GitHub or MIT ( yes someone
on HN suggested MIT as a mainstream PGP directory)

------
mirimir
It's unrealistic to expect naive subjects to learn how to use GnuPG in an
hour. It takes longer than that to learn a new game! People need at least to
know what public-key cryptography is before trying to use it. But
unfortunately, the Wikipedia entry is rather intimidating.[0] The GnuPG FAQ
(at 7.1) is clearer, but not so easy to find.[1]

[0]
[https://en.wikipedia.org/wiki/Pretty_Good_Privacy](https://en.wikipedia.org/wiki/Pretty_Good_Privacy)

[1] [https://www.gnupg.org/faq/gnupg-
faq.html](https://www.gnupg.org/faq/gnupg-faq.html)

~~~
joshbuddy
You said "People need at least to know what public-key cryptography is before
trying to use it." I think this is untrue. People really just need to know how
to work with the technology, not understand what it's actually doing. Trying
to explain the underlying principles makes it more confusing and thus, less
safe.

~~~
mirimir
I mean basic stuff. Users need to know that they have both public keys and
private keys. That public keys allow other users to encrypt stuff to them. So
they need to share them. That private keys allow them to decrypt stuff
encrypted to their public keys, and also to sign stuff. So they need to
protect them, keep them private. Failure to get those basic facts accounted
for much of the craziness and confusion in the cited study.

------
stuaxo
This is something that the UX people of gnome could actually be useful for..

~~~
lmm
But they've made gnome worse, not better.

~~~
bruo
Worse for some people and better for other. My mother (58) and my grand mother
(82) love how easily is to do what they usually do contrasted to the windows 8
experience.

I don't know if that is a common case or not, but at least it's not a
definitive "worse" or "good". And for me, it's great as I never got a call to
ask me where is something anymore.

~~~
kuschku
Well, my little sister (12) and my dad (56) love KDE Plasma, as it’s "simpler
than windows".

------
gavkearney
Hi guys,

Maybe you should try Jumble (www.jumble.io) for email encryption - works with
Gmail, iOS and MS Outlook.

Jumble manage key pairs for users and encrypt the private key with the users
password so they don't have access, this ultimately simplifies the whole
process for the end user and frees them from the key management aspect which
is the major pain-point with PGP-based solutions. Also, it integrates on top
of existing emails clients so no need to change your email address or how you
interact with emails.

Full disclaimer: I'm a co-founder of Jumble

------
vxNsr
At this point the only way for PGP or really any user-based encryption to get
widespread use, gmail, yahoo and microsoft need to adopt it and integrate it
into their webmail client, possibly as a semi-mandatory feature that's opt-out
instead of opt-in.

Anything less will fail as no one is interested in getting a new email
address.

Anecdotally, I've tried three of four times to learn how to use PGP and
integrate it into my workflow and failed each time, so it definitely needs
work (at least if they want me on board :))

------
bburshteyn
Our approach here is to make security usable to developers via a programmatic
interface/API, so users' data is better protected without them having to do
anything at all.

[https://www.trycryptomove.com](https://www.trycryptomove.com)

Eventually if/when we think about making consumer-facing wrappers to
CryptoMove, the key is going to be usability. Security will need to be as
easy/fun as consumer applications. Easier said than done though.

------
jabo
I think GPGTools for OSX does a great job of a client.

~~~
Perceptes
I've been pretty happy with it, but I'm also a programmer with interest in and
knowledge of why it's important and how it's useful. I can see non-
technically-inclined family and friends being very confused by it.

------
enginnr
A lot of baseline configs can be implemented to setup opportunistic crypto,
for what Ben Brookes calls 'starbucks hacker bob'
[https://brooksreview.net/2013/06/encrypting-stuff-against-
st...](https://brooksreview.net/2013/06/encrypting-stuff-against-starbucks-
hacker-bob/)

------
omginternets
I have a budding idea that involved using a blockchain to manage cryptographic
credentials, but I'm having trouble finding proper blockchain libraries. Any
recommendations?

I'd prefer Python or Go, since that's what I'm mostly using these days, but at
this point I'll take brainfuck if that's my only choice...

------
fonosip
For occasional pgp use, a webapp is as easy as it goes.
[https://ssl.ba.net/util/pgp/](https://ssl.ba.net/util/pgp/)

No need to store or remember keys, just create a new key for your
conversation.

All encyption / decryption is done client-side with open source code.

------
moonbug
PGP's UX is so dismal I could almost believe the whole project operates under
an NSA false flag.

~~~
mschuster91
The problem is a lack of funds. It was concieved for nerds by nerds and never
got enough funding for UX.

A common state in the FOSS universe.

~~~
Asbostos
That's not funding. That's boredom or perhaps ideology. Most FOSS developers
don't bother thinking about UX or even implementing a UI because it's boring.
They're interested in the high-tech stuff that their software can do and hope
somebody else will put a front end on it. But usually nobody does - at least
not an open source front end - because all other FOSS developers are also more
interested in the specific technical thing their software does.

I make money developing a front end for a popular but absolutely unusable
piece of FOSS software. Other companies do too. It sometimes feels a bit wrong
that the open source guys have done the biggest and hardest job for free,
while I profit just slapping some windows and dialog boxes over the top of it.
But they really don't want to do that part of it and have openly said they
think their UI is fine and that people would benefit from learning to use a
command driven interface.

------
jokoon
Isn't there a firefox extension that can just do some PGP stuff with some
right click in gmail ?

~~~
diafygi
Yep! [https://www.mailvelope.com/](https://www.mailvelope.com/)

~~~
sirclueless
Did you guys read the paper, or even the abstract? This whole paper is about
Mailvelope and the difficulty people had using it.

~~~
slipstream-
Maybe that's the joke.

------
calebm
This doesn't solve the problem of email encryption, but I made a (web-based)
file encryption app with the goal of usability:
[https://hypervault.github.io/](https://hypervault.github.io/)

------
jenscow
Johnny can't even select, download, use, or configure an email client.

~~~
serpentor
...not to mention that in most cases, Johnny doesn't even really know what
encryption is, let alone believe he's capable of it.

Try asking someone to encrypt something, anything before sending it. The looks
you'll get range from sideways or merely confused to fearful and panicked, to
are you fucking kidding me?

------
rogeryu
Given the fact that [https://protonmail.com](https://protonmail.com) is still
offline after several days of attacks, will secure mail ever get a chance?

------
thangalin
Here is a list of steps to send a signed e-mail:

[http://davidjarvis.ca/dave/tech/privacy.shtml](http://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...](https://support.mozilla.org/en-US/kb/digitally-signing-and-
encrypting-messages)

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.

~~~
Asbostos
When I use my phone to pay for things in a shop, there's surely a lot of
complicated security going on, and a bit of ugly technology is even exposed
when it displays a QR code for the cashier to scan. But nowhere ever did it
ask me any questions that required me to learn any weird technical concepts. I
never had to choose a number of bits or know anything about what a "key" is.
As soon as a user sees these things, they have to either make a random guess
or go off for hours teaching themselves what it means. It's a complete fail.

The words "PGP/MIME" should never appear on a PGP email plugin! When you send
a regular file attachment, you don't have to specify the MIME type. It's all
silent and hidden.

