<i>Applause</i>

So, good morning everyone

my name is Arne and today

I'll be hoping to entertain you

a bit with some GPG usability issues.

thanks for being here this early in the morning.

I know, some of you have had a short night

In short for the impatient ones:

Why is GnuPG damn near unusable?

Well, actually, I don’t know

<i>Laughter</i>

So more research is needed … as always.

Because it's not like using a thermometer.

We're doing something between social science and security

But I will present some interesting perspectives

or at least what I hope you'll find interesting perspectives.

This talk is about some possible explanations

that usable security research can offer to the question

Now some context, something about myself,

so you have a bit of an idea where I'm coming from

and what coloured glassed I have on.

So pretty much my background is in Mathematics,

Computer science, and—strangely enough—International relations

My professional background is that I've been doing

embedded system security evaluations and training

and I've also been a PhD student, studying the usability of security.

Currently, I teach the new generation,

hoping to bring some new blood into the security world.

I want to do some expectation setting

I want to say, what this talk is not about.

I will also give some helpful pointers for

those of you that are interested in these other areas.

I will not go into too much detail about the issue of truth

in security science.

Here are some links to some interesting papers that cover this

in a lot of detail.

Neither will I be giving a security primer.

There are some nice links to books on the slide.

I'll also not be giving a cryptography primer or a history lesson.

Neither will I be giving an introduction to PGP

And, interestingly enough, even though the talk is titled

“why is GPG damn near unusable”, I will

not really be doing much PGP bashing

I think it's quite, actually, a wonderful effort and other people

have pretty much done the PGP/GnuPG bashing for me.

And, as I've already mentioned, I will not be giving any definite answers

and a lot of “it depends.”

But then you might ask “well, it depends. What does it depend on?”

Well, for one: What users you’re looking at

which goals they have in mind and

in what context, what environment they’re doing these things.

So, instead I want to kindle your inspiration

I want to offer you a new view on the security environment

and I'll also give you some concrete exercises that you can try out

at home or at the office.

Some “do’s” and “don’t’s” and pointers for further exploration:

This is a short overview of the talk

I'll start with the background story to why I’m giving this talk

then an overview over usable security research area,

some principles and methods for usablity,

some case studies, then some open questions remain

So, the story. Well. It all started with this book.

When I was reading about the Snowden revelations,

I read, how Snowden tried to contact Glenn Greenwald.

On December, 1st, he sent an email, saying, well, writing to Glenn:

“If you don’t use PGP, some people will never be able to contact you.”

“Please install this helpful tool and if you need any help,

please request so.”

Three days later, Glenn Greenwald says: “Sorry, I don’t

know how to do that, but I’ll look into it.”

and Snowden writes back: “Okay, well, sure. And again:

If you need any help, I can facilitate contact.”

Now, a mere seven weeks later,

<i>Laughter</i>

Glenn is like “okay, well, I’ll do it within the next days or so.”

Okay, sure …

Snowden’s like “my sincerest thanks”.

But actually in the meantime, Snowden was growing a bit impatient

’cause, okay, “why are you not encrypting?”

So he sent an email to Micah Lee, saying, “okay, well, hello,

I’m a friend, can you help me getting contact with Laura Poitras?”

In addition to that, he made a ten-minute video for Glenn Greenwald

<i>Laughter</i>

… describing how to use GPG.

And actually I have quite a lot of screenshots of that video

and it's quite entertaining.

’cause, of course, Snowden was getting increasingly

bothered by the whole situation.

Now, this is the video that Snowden made

“GPG for Journalists. For Windows.”

<i>Laughter</i>

I’ll just click through it, because I think,

the slides speak for themselves.

Take notes of all the usability issues you can identify.

So just click through the wizard, generate a new key,

enable “expert settings”, ’cause we want 3000-bit keys

We want a very long password, etc.

And now, of course, we also wanna go and find keys

on the keyserver.

And we need to make sure that we shouldn’t

write our draft messages in GMail

or Thunderbird and enigmail, for that matter.

Although that issue has been solved.

So, I think you can start seeing

why Glenn Greenwald
—even if he did open this video—

was like
“okay, well, I’m not gonna bother.”

And Snowden is so kind to say, after 12 minutes,

“if you have any remaining questions, please contact me.”

At this year’s HOPE conference,

Snowden actually did a call for arms and he said

“Okay, we need people to evaluate our security systems.

we need people to go and do red team. But in addition to that,

we also need to look at the user experience issue.”

So this is a transcript of his kind of manifesto

and he says: “GPG is really damn near unusable”

because, well, of course, you might know command line

and then, okay, you might be okay

but “Gam Gam at the home”, she is never going to be able

to use GnuPG.

And he also notes that, okay, we were part of a technical elite

and he calls on us to work on the technical literacy of people

because what he explicitly warns against is

a high priesthood of technology.

Okay, that’s a nice call to arms

but are we actually up for a new dawn?

Well, I wanna go into the background of usable security

and I wanna show you that we’ve actually been

in a pretty dark time.

So, back in 1999, there was this paper:
“Why Johnny can’t encrypt”

which described mostly the same broken interface

so if you remember, if you go back to the video of which

I showed some screenshots, then, well, if you look at

these screenshots from 1999, well,
is there a lot of difference?

Not really! Nothing much has changed.

There are still the same

conceptual barriers,
and same crappy defaults.

And most astonishingly, in the paper there

is a description of a user study where

users were given 90 minutes to encrypt an email

and most were unable to do so.

I think, that pretty much describes “damn near unusable.”

A timeline from, well, before 1999 to now

of the usable security research.

So, quite a lot has happened

although it is still a growing field.

It started—the idea of usable security,
it was explicitly defined first—

in 1975, but it was only until
… only in … 1989 that

the first usability tests were carried out.

And only in 1996 that

the concept of “user-centered security”
was described.

An interesting paper, also from 1999, shows how

contary to the general description of users as lazy

and basically as the weakest chain in security

this paper describes users as pretty rational beings

who see security as an overhead and …
where they don't

understand the usefulness of what they’re doing.

The study of PGP 5.0, I’ve talked about that already,

and there was also a study of the
Kazaa network in 2002.

And it was found out that a lot of users were

accidentally sharing files from personal pictures,

who knows, maybe credit-card details,
you never know, right?

In 2002, a lot of the knowledge of usable security design

was concretised in ten key principles

and if you’re interested,

I do recommend you to look at the paper.

A solution to the PGP problem was proposed in

2004, well, actually,

it was proposed earlier 
but it was tested in 2005.

And it was found that actually
if we automate encryption

and if we automate key exchange then, well,

things are pretty workable, except that

users still fall for
phishing attacks, of course.

But last year, another research
identified that, well,

making security transparent is all nice and well

but it's also dangerous because users no longer

are less likely to trust the system and

are less likely to really understand
what’s really happening.

So a paper this year also identified another issue:

Users generally have very bad understanding

of the email architecture.

An email goes from point A to point B.

And what happens in-between is unknown.

So, before I go on to general usability principles

from the founding pillar of the usable security field

I wanna give some exaples of usability failures.

You might be familiar with project VENONA.

This was an effort by the US intelligence agencies

to try and decrypt soviet communication.

And they actually were pretty successful.

They encovered a lot of spying and, well,

how did they do this?

The soviets were using one-time pads and,

well, if you reuse a one-time pad,

then you leak a lot of information about plain-text.

Well, what we also see happening a lot is

low password entropy.

We have people choosing password “123456”, etc.

And what I just described, the study looking into

the mental models of users,

of the email architecture and how it works

well, at the top you have

still a pretty simplified description of how things work

and at the bottom we have an actual drawing

of a research participant when asked:

“Can you draw how an email
goes from point A to point B?”

And it’s like:
“Well, it goes from one place to the other.”

Okay …

<i>clicking sounds</i>

Okay, so this died.

So, these are two screenshots of enigmail

Well, if I wouldn’t have marked them

as the plaintext and encrypted email that would be sent

you probably wouldn’t have spotted which was which

this is a pretty big failure in

the visibility of the system.

You don’t see anything? Ah.

Audience: “That’s the point!”
That's the point, yes!

<i>laughter</i>
<i>applause</i>

On the left we have a screenshot of GPG and

as I’ve already described,

command line people, we like command lines

but normal people don’t.

And what we also see is a lot of the jargon that is

currently being used even in GUI applications

so on the right there is PGP 10.0.

Now I wanna close these examples with

well, you might be wondering: “what is this?”

This is actually an example of a security device

from, I think it’s around 4000 years ago.

Like, People could use this.

Why can’t we get it right today?

Something that you should,

this is a little homework exercise,

take a laptop to your grandma, show her PGP,

can she use it—yes or no?

Probably not, but who knows?

Now I wanna go into

the usability cornerstones of usable security.

I wanna start with heuristics

some people call them “rules of thumb,” other people

call them “the ten holy commandments”

For example, the ten commandments of Dieter Rams,

there is ten commandments of Jakob Nielsen,

of Don Norman

and it really depends on who you believe in, etc.

But at the cornerstone of all of these is that

design is made for people.

And, well, actually, Google says it quite well

in their guiding mission:

“Focus on the user and all else will follow.”

Or, as a usability maxim:

“thou shalt test with thy user”

Don’t just give them the thing.

But there is one problem with these heuristics

and with this advice going just with your user.

Because it’s a pretty abstract advice.

What do you do?

You go out into the world to get practice.

You start observing people.

One nice exercise to try is:

go to the vending machine,

for example the ones at the S-Bahn.

Just stand next to it

and observe people buying tickets.

It’s quite entertaining, actually.

<i>Laughter</i>

And something you can also do is

search for usability failures.

This is what you already do when

you’re observing people.

But even just google for “usability failure”,

“GUI fail”, etc., and you will find

lots of entertaining stuff.

Those were some heuristics

but what about the princpiles

that lie behind those?

Usability or interaction design

is a cycle between the user and the system.

The user and the world.

The user acts on the world

and gets feedback.

They interpret that.

One important concept is

for things to be visible.

For the underlying system state

to be visible and

you get appropriate feedback

from the system.

So these are Don Norman’s gulfs
of execution and evaluation

sort of yin and yang.

And there is two concrete problems

to illustrate.

For example, the button problem

that “how do you know what happens
when you push the button?”

and “how do you know how to push it?”

I unforunately don’t have a picture of it

but at Oxford station, the tabs in the bathrooms

they say “push” and you need to turn.

<i>Laughter</i>

Then there is the toilet door problem.

The problem of “how do you know
what state a system is in”.

How do you know whether an email will be encrypted?

This is a picture …

basically there is two locks.

One is actually broken and it’s …
when pushing the button that's on the

door handle, you usually lock the door.

But … well … it broke. So that must have been

an entertaining accident.

Another, as I’ve already described,

another important concept is that of mental models.

It’s a question of what idea does the user have

of the system by interacting with it?

How do they acquire knowledge?

For example, how to achieve discoverability

of the system?

And how to ensure that while
a user is discovering the system

that they are less likely to make mistakes?

So this is the concept of poka-yoke

and it’s … here is an example
you also see with floppy disks,

with USB sticks, etc.

It’s engineered such that users are

less likely to make a mistake.

Then there’s also the idea
of enabling knowledge transfer

So how can we do this?

One thing is metaphors.

And I’m not sure how many of you recognise this,

this is Microsoft BOB.

Traditionally, PC systems have been built

on the desktop metaphor.

<i>Laughter</i>
Microsoft BOB had a little too much.

To enable knowledge transfer,
you can also standardise systems.

And one important tool for this is design languages

so if you’re designing for iOS, go look at

the design language, the Human
Interface Guidelines of iOS.

The same for Windows – go look
at the Metro Design Guidelines.

As for Android, look at Material Design.

Because, another interesting exercise
to try out

relating to design languages

and also to get familiar with how designers try to

communicate with users is to

look at an interface and trying to decode

what the designer is trying to say to the user.

And another interesting exercise is to look at

not usability but UNusability.

So there is this pretty interesting book

called “evil by design” and it goes into

all the various techniques that designers use

to fool users, to get them to buy an extra hotel, car, etc.

and, well, RyanAir is pretty much the worst offender

so a good example to study.

<i>Applause</i>

So, what if you wanna go out into the world

and are gonna apply these princpiles, these heuristics?

The first thing to know is that

design has to be a process

whereby, first part is actually defining your problem.

You first brain-storm

then you try to narrow down to concrete requirements

after which you go and try out
the various approaches

and test these.

What materials do usability experts actually use?

Well, of course there’s expensive tools, Axure, etc.

but I think one of the most used materials

is still the post-it note. Just paper and pens.

And, okay, where do you wanna go and test?

Well, actually, go out into the field.

Go to the ticket machine of the S-Bahn.

But also go and test in the lab, so that you have

a controlled environment.

And then you ask “okay, how do I test?”

Well, first thing is: Go and get some real people.

Of course, it’s … it can be difficult to actually

get people into the lab but it’s not impossible.

So once you have people in the lab,

here are some methods.

There are so many usability evaluation methods

that I’m not gonna list them all and

I encourage you to go and look them up yourself

’cause it’s also very personal what works for you

and what works in your situation.

When using these methods you wanna

evaluate how well a solution works

So you’re gonna look at some matrix

so that at the end of your evaluation

you can say “okay, we’ve done a good job”,

“this can go better”,
“Okay, maybe we can move that”, …

So these are the standardised ones, so

how effective are people, or etc.

You can read …

For a quick start guide on how to

perform usability studies, this is quite a nice one.

And the most important thing to remember

is that preparation is half the work.

First thing to check that everything is working,

make sure that you have everyone
you need in the room, etc.

And maybe most importantly,
usability and usable security,

well, usable security is still a growing field, but

usability is a very large field and most likely

all the problems that you are going to face

or at least a large percentage, other people

have faced before.

So this book is, well, it describes a lot of the stories

of user experience professionals and the things

that they’ve come up against.

A homework exerciese if you feel like it

is looking at basically analysing who is your user

and where they’re going to use the application.

And also something to think about is

how might you involve your user?

Not just during the usability testing,

but also afterwards.

Now I wanna go into some case
studies of encryption systems.

Now there’s quite a lot, and these are not all,

it’s just a small selection but I wanna focus on three.

I wanna focus at the OpenPGP standard,
Cryptocat and TextSecure.

So, OpenPGP, well …

email is now almost 50 years old,

we have an encryption standard—S/MIME,
it is widely used

well, it’s widely usable but it’s not widely used …

and GnuPG is used widely but is not installed by default

and when usability teaches us one thing

it’s that defaults rule.

Because users don’t change defaults.

Now you might ask “Okay,
PGP is not installed by default,

so is there actually still a future for OpenPGP?”

Well, I’d argue: Yes.
We have browser plug-ins

which make it easier for users

JavaScript crypto … I’ll come back to that later …

But when we look at Mailvelope, we see, well,

the EFF scorecard, it has a pretty decent rating

at least compared to that of native PGP implementations.

And also Google has announced and has been working

for quite some time on their own plug-in for

end-to-end encryption.

And Yahoo! is also involved in that.

And after the Snowden revelations there has been

a widespread search in the interest

in encrypted communications

and this is one website where a lot of these are listed.

And one project that I’d especially like to emphasise

is mailpile because I think it looks

like a very interesting approach

whereby the question is:

Can we use OpenPGP as a stepping stone?

OpenPGP is not perfect, meta-data is not protected,

header is not protected, etc.

But maybe when we get people into the ecosystem,

we can try and gradually move
them to more secure options.

Now, what about Cryptocat?

So, Cryptocat’s online chat platform

that … yes … uses JavaScript.

And of course, JavaScript crypto is bad

but it can be made better.

And I think JavaScript crypto is not the worst problem.

Cryptocat had a pretty disastrous problem

whereby all messages that were sent

were pretty easily decryptable.

But actually, this is just history repeating itself

’cause PGP 1.0 used something called BassOmatic,

the BassOmatic cypher which is also pretty weak.

And Cryptocat is improving, which is the important thing.

There is now a browser plug-in and

of course, there’s an app for that and

actually, Cryptocat is doing really, really well

in the EFF benchmarks.

And Cryptocat is asking the one question that a lot

of other applications are not asking, which is:

“How can we actually make crypto fun?”

When you start Cryptocat, there’s noises

and there’s interesting facts about cats

<i>Laughter</i>

… depends on whether you like cats, but still!

Keeps you busy!

Now, the last case: TextSecure
also has pretty good markings

and actually just like CryptoCat,

the App store distribution model is something that

I think is a valuable one for usability.

It makes it easy to install.

And something that TextSecure is also looking at is

synchronisation options for your address book.

And I think the most interesting development is

on the one side, the CyanogenMod integration,

so that people will have encryption enabled by default.

’Cause as I mentioned: People don’t change defaults.

And this one is a bit more contoversial, but

there’s also the WhatsApp partnership.

And of course people will say “it’s not secure”,

we know, we know,

EFF knows!

But at least, it’s more secure than nothing at all.

Because: Doesn’t every little bit help?

Well, I’d say: yes.

And at least, it’s one stepping stone.

And, well, all of these are open-source,

so you can think for yourself:

How can I improve these?

Now, there’s still some open questions remaining

in the usable security field and in the

wider security field as well.

I won’t go into all of these,

I wanna focus on the issues that developers have,

issues of end user understanding

and of identitiy management.

Because the development environment

there’s the crypto-plumbing problem, some people call it.

How do we standardise on a cryptographic algorithm?

How do we make everyone use the same system?

Because, again, it’s history repeating itself.

With PGP, we had RSA, changed for
DSA because of patent issues

IDEA changed for CAST5 because of patent issues

and now we have something similar:

’cause for PGP the question is:

Which curve do we choose?

’cause this is from Bernstein, who has got a whole list

of, well not all the curves,
but a large selection of them

analysing the security

but how do you make, well, pretty much

the whole world agree on a single standard?

And also, can we move toward safer languages?

And I’ve been talking about the
usability of encryption systems

for users, but what about for developers?

So, API usability, and as I’ve mentioned:

Language usability.

And on top of that, it is not just a technical issue,

because, of course, we secure microchips,

but we also wanna secure social systems.

Because, in principal, we live in an open system,

in an open society and a system cannot audit itself.

So, okay, what do we do, right?
I don’t know.

I mean, that’s why it’s an open question!

’Cause how de we ensure the authenticity of,

I don’t know, my Intel processor in my lapotp?

How do I know that the

random number generator isn’t bogus?

Well, I know it is, but …
<i>laughter</i>

Then, there’s the issue of identity management

related to key management, like

who has the keys to the kingdom?

One approach, as I’ve already mentioned, is

key continuity management.

Whereby we automate both key exchange and

whereby we automate encryption.

So one principle is trust on first use,

whereby, well, one approach will be to attach your key

to any email you send out and anyone who receives

this email just assumes it’s the proper key.

Of course, it’s not fully secure,

but at least, it’s something.

And this is really, I think, the major question

in interoperability:

How do you ensure that you can access your email

from multiple devices?

Now, of course, there is meta-data leakage,

PGP doesn’t protect meta-data,

and, you know, your friendly security agency knows

where you went last summer …

So, what do we do?

We do anonymous routing, we send over tor, but

I mean, how do we roll that out?

I think the approach that

mailpile is trying to do is interesting

and, of course still an open question, but

interesting research nonetheless.

Then there’s the introduction problem of

okay, how, I meet someone here, after the talk,

they tell me who they are,

but either I get their card—which is nice—or

they say what their name is.

But they’re not gonna tell me, they’re not gonna spell out

their fingerprint.

So the idea of Zooko’s triangle is that identifiers

are either human-meaningful,
secure or decentralised.

Pick two.

So here’s some examples of identifiers,

so for Bitcoin: Lots of random garbage.

For OpenPGP: Lots of random garbage

For miniLock: Lots of random garbage

So, I think an interesting research problem is:

Can we actually make these things memorable?

You know, I can memorise email addresses,

I can memorise phone numbers,

I can not memorise these. I can try, but …

Then, the last open question I wanna focus on

is that of end-user understanding.

So of course, we’ll know that all devices are monitored.

But does the average user?

Do they know what worms can do?

Have they read these books?

Do they know where GCHQ is?

Do they know that Cupertino has
pretty much the same powers?

<i>Laughter</i>

Do they know they’re living in a panopticon to come?

<i>Laughter</i>

Do they know that people are
killed based on meta-data?

Well, I think not.

And actually this is a poster from the university

where I did my Master’s

and interestingly enough, it was founded by a guy

who made a fortune selling sugar pills.

You know, snake oil, we also have this in crypto.

And how is the user to know

whether something is secure or not?

Of course, we have the secure messaging scorecard

but can users find these?

Well, I think, there’s three aspects
to end-user understanding

which is knowledge acquisition,
knowledge transfer,

and the verification updating of this knowledge.

So, as I’ve already mentioned,
we can do dummy-proofing

and we can create transparent systems.

For knowledge transfer, we can

look at appropriate metaphors and design languages.

And for verification we can

try an approach: Choose an advertising.

And, last but not least, we can do user-testing.

Because all these open questions that I’ve described

and all this research that has been done,

I think it’s missing one key issue, which is that

the usability people and the security people

tend not to really talk to one another.

The open-source developers and the users:

Are they talking enough?

I think that’s something, if we want a new dawn,

that’s something that I think we should approach.

Yeah, so, from my side, that’s it.

I’m open for any questions.

<i>Applause</i>

Herald: Arne, thank you very much for your brilliant talk

Now, if you have any questions to ask, would you please

line up at the microphones in the aisles?!

The others who’d like to leave now,

I’d ask you kindly to please leave very quietly

so we can hear what the people
asking questions will tell us.

And those at the microphones,
if you could talk slowly,

then those translating have no problems in translating

what is being asked. Thank you very much.

And I think we’ll start with mic #4 on the left-hand side.

Mic#4: Yes, so, if you’ve been to any successful

crypto party, you know that crypto parties very quickly

turn into not about discussing software,
how to use software,

but into threat model discussions.

And to actually get users
to think about what they’re

trying to protect themselves for and if a certain

messaging app is secure, that still means nothing.

’Cause there is lots of other stuff that’s going on.

Can you talk a little bit about that and

how that runs into this model about, you know,

how we need to educate users and, while we’re at it,

what we want to educated about.

And what they actually need to be using.

Arne: Well, I think that’s an interesting point

and I think, one issue, one big issue is:

okay, we can throw lots of crypto parties

but we’re never gonna be able to throw enough parties.

I … with one party you’re very lucky

you’re gonna educate 100 people.

I mean, just imagine how many parties
you’d need to throw. Right?

I mean, it’s gonna be a heck of party, but … yeah.

And I think, secondly, the question of threat modeling,

I think, sure, that’s helpful to do, but

I think, users do first need an understanding of,

for example, the email architecture.

Cause, how can they do threat
modeling when they think

that an email magically pops
from one computer to the next?

I think, that is pretty much impossible.

I hope that …

Herald: Thank you very much, so …
Microphone #3, please.

Mic#3: Arne, thank you very much for your talk.

There’s one aspect that I didn’t see in your slides.

And that is the aspect of the language that we use

to describe concepts in PGP—and GPG, for that matter.

And I know that there was a paper last year

about why King George can’t encrypt and

they were trying to propose a new language.

Do you think that such initiatives are worthwile

or are we stuck with this language and should we make

as good use of it as we can?

Arne: I think that’s a good point
and actually the question

of “okay, what metaphors do you wanna use?” … I think

we’re pretty much stuck with the language

that we’re using for the moment but

I think it does make sense
to go and look into the future

at alternatives models.

Yeah, so I actually wrote a paper that also

goes into that a bit, looking at

the metaphor of handshakes to exchange keys.

So, for example, you could have

an embedded device as a ring or wristband,

it could even be a smartwatch, for that matter.

Could you use that shaking of hands to

build trust-relationships?

And that might be a better
metaphor than key-signing,

webs of trust, etc.

’Cause I think, that is horribly broken

for I mean the concept, trying
to explain that to users.

Herald: Thank you. And … at the back in the middle.

Signal angel: Thanks. A question from the internet:

[username?] from the Internet wants to know if you’re

aware of the PEP project, the “pretty easy privacy”

and your opinions on that.

And another question is:

How important is the trust level of the crypto to you?

Arne: Well, yes, actually, there’s this screenshot

of the PEP project in the slides

… in the why WhatsApp is horribly insecure and

of course, I agree, and yeah.

I’ve looked into the PEP project for a bit

and I think, yeah, I think it’s an interesting

approach but I still have to read up on it a bit more.

Then, for the second question,

“how important is the rust in the crypto?”:

I think that’s an important one.

Especially the question of

“how do we build social systems
to ensure reliable cryptography?”

So one example is the Advanced
Encryption Standard competition.

Everyone was free to send in entries,

their design princpiles were open

and this is in complete contrast
to the Data Encryption Standard

which, I think, the design princpiles are still Top Secret.

So yeah, I think, the crypto is
something we need to build on

but, well, actually, the crypto is
again built on other systems

where the trust in these systems
is even more important.

Herald: Okay, thank you, microphone #2, please.

Mic#2: Yes, Arne, thank you very
much for your excellent talk.

I wonder how about what to do with feedback

on usability in open-source software.

So, you publish something on GitHub

and you’re with a group of people

who don’t know each other and

one publishes something,
the other publishes something,

and then: How do we know
this software is usable?

In commercial software, there’s all kind of hooks

on the website, on the app,

to send feedback to the commercial vendor.

But in open-source software,
how do you gather this information?

How do you use it, is there any way to do this

in an anonymised way?

I haven’t seen anything related to this.

Is this one of the reasons why
open-source software is maybe

less usable than commercial software?

Arne: It might be. It might be.

But regarding your question, like, how do you know

whether a commercial software is usable, well,

you … one way is looking at:

Okay, what kind of statistics do you get back?

But if you push out something totally unusable

and then, I mean, you’re going to expect

that the statistics come back looking like shit.

So, the best approach is to
design usability in from the start.

The same with security.

And I think, that is also …
so even if you have …

you want privacy for end users, I think it’s still possible

to get people into their lab and look at:

Okay, how are they using the system?

What things can we improve?

And what things are working well?

Mic#2: So you’re saying, you should only publish

open-source software for users
if you also tested in a lab?

Arne: Well, I think, this is a bit of a discussion of:

Do we just allow people to build
houses however they want to

or do we have building codes?

And … I think … well, actually, this proposal of holding

software developers responsible for what they produce,

if it’s commercial software, I mean,
that proposal has been

made a long time ago.

And the question is:

How would that work in an
open-source software community?

Well, actually, I don’t have an answer to that.

But I think, it’s an interesting question.

Mic#2: Thank you.

Herald: Thank you very much. #1, please.

Mic#1: You said that every little bit helps,

so if we have systems that
don’t provide a lot of … well …

are almost insecure, they
provide just a bit of security, than

that is still better than no security.

My question is: Isn’t that actually worse because

this promotes a false sense of security and

that makes people just use
the insecure broken systems

just to say “we have some security with us”?

Arne: I completely agree but

I think that currently people … I mean …

when you think an email goes

from one system to the other directly

and I mean … from these studies
that I’ve done, I’ve met

quite some people who still think email is secure.

So, of course, you might give
them a false sense of security

when you give them a
more secure program but

at least it’s more secure than email—right?

I mean …

Mic#1: Thank you.

Herald: Thank you. There’s another
question on the Internet.

Signal angel: Yes, thank you. Question from the Internet:

What crypto would you finally
recommend your grandma to use?

Arne: <i>laughs</i>

Well … Unfortunately, my grandma
has already passed away.

I mean … her secrets will be safe …

Actually, I think something like where

Crypto is enabled by default, say …
iMessage, I mean

of course, there’s backdoors,
etc., but at least

it is more secure than plain SMS.

So I would advise my grandma
to use … well, to look at …

actually I’d first analyse
what does she have available

and then I would look at okay
which is the most secure

and still usable?

Herald: Thank you very much, so mic #3, please.

Mic#3: So, just wondering:

You told that there is
a problem with the missing

default installation of GPG
on operating systems but

I think, this is more of a
problem of which OS you choose

because at least I don’t
know any Linux system which

doesn’t have GPG installed today by default.

If you use … at least I’ve used
the normal workstation setup.

Arne: Yes, I think you already
answered your own question:

Linux.
<i>Laughter</i>

Unfortunately, Linux is not yet widely default.

I mean, I’d love it to be, but … yeah.

Mic#3: But if I send an email to Microsoft and say:

Well, install GPG by default, they’re not gonna

listen to me.

And I think, for all of us, we should do

a lot more of that.

Even if Microsoft is the devil for most of us.

Thank you.

Arne: Well … We should be doing more of what?

Mic#3: Making more demands
to integrate GPG by default

in Microsoft products, for example.

Arne: Yes, I completely agree.

Well, what you already see happening …

or I mean, it’s not very high-profile yet,

but for example I mean … I’ve refered to

the EFF scorecard a couple of times but

that is some pressure to encourage developers

to include security by default.

But, I think I’ve also mentioned, one of the big problems

is: users at the moment … I mean …

developers might say: my system is secure.

I mean … what does that mean?

Do we hold developers and
commercial entities …

do we hold them to, well,

truthful advertisting standards or not?

I mean, I would say: Let’s gonna look at

what are companies claiming and

do they actually stand up to that?

And if not: Can we actually sue them?

Can we make them tell the truth about

what is happening and what is not?

Herald: So, we’ve got about 2 more minutes left …

So it’s a maximum of two more questions, #2, please.

Mic#2: Yeah, so … Every security system fails.

So I’m interested in what sort of work has been done on

how do users recover from failure?

Everything will get subverted,

your best firend will sneak
your key off your computer,

something will go wrong with that, you know …

your kids will grab it …

and just, is there, in general, has somebody looked at

these sorts of issues?

Is there research on it?

Arne: Of various aspects of the problem but

as far as I’m aware not for the general issue

and not any field studies specifically looking at

“Okay, what happens when a key is compromised, etc.”

I mean, we do have certain cases of things happening

but nothing structured.

No structured studies, as far as I’m aware.

Herald: Thank you. #3?

Mic#3: Yeah, you mentioned
mailpile as a stepping stone

for people to start using GnuPG and stuff, but

you also talked about an
average user seeing mail as just

coming from one place and
then ending up in another place.

Shouldn’t we actually talk about

how to make encryption transparent for the users?

Why should they actually care about these things?

Shouldn’t it be embedded in the protocols?

Shouldn’t we actually talk about
embedding them in the protocols,

stop using unsecure protocols

and having all of these,
you talked a little bit about it,

as putting it in the defaults.

But shouldn’t we emphasise that a lot more?

Arne: Yeah, I think we should
certainly be working towards

“How do we get security by default?”

But I think … I’ve mentioned it shortly that

making things transparent also has a danger.

I mean, this whole, it’s a bit like …

a system should be transparent is a bit like

marketing speak, because actually

we don’t want systems to be completely transparent,

’cause we also wanna be able
to engage with the systems.

Are the systems working as they should be?

So, I mean, this is a difficult balance to find, but yeah …

Something that you achieve through usability studies,

security analysis, etc.

Herald: All right, Arne,
thank you very much for giving

us your very inspiring talk,

thank you for sharing your information with us.

Please give him a round of applause.

Thank you very much.
<i>applause</i>

subtitles created by c3subtitles.de
Join, and help us!