This course focuses on how to design and build secure systems with a human-centric focus. We will look at basic principles of human-computer interaction, and apply these insights to the design of secure systems with the goal of developing security measures that respect human performance and their goals within a system.
Interface Guidelines for Usable Security
Loading...
From the course by University of Maryland, College Park
Usable Security
1111 ratings
From the lesson
Week 4
Strategies for Secure Interaction Design: authority, guidelines for interface design
Meet the Instructors
Jennifer GolbeckDirector
Human-Computer Interaction Lab
[NOISE].
In this final lecture we'll look at a final set of three guidelines for
designing interface features to help security be more usable.
The first guideline is that you want to enable the user to
express safe security policies that fit the user's task.
One problem that happens a lot with security is that there are ways to
control permissions and set policies, but
they're not things that an average user can actually interact with.
So questions that we want to ask for this are things like, what are some examples of
security policies that users might want enforced for typical tasks?
So for example, think about us setting permissions for
who is allowed to access a file or a document.
What are some examples of security policies, access policies in this case,
that users might want enforced for a document?
Then, how can the user express these policies?
And finally, how can the expression of policy be brought closer to the task?
For example, if we're talking about access to the document, the user's task is not to
create that access policy, it's to create the document.
So can we take the expression of the access policy and
bring it more into the document authoring process?
Let's look at some examples of good interfaces and
bad interfaces for doing this.
Let's look at a few ways that we can control file permissions and
how usable those are.
So here we have a file on the desktop open.
And if we look at the information for that file, it pulls up a window here.
And at the bottom we can see Sharing and Permissions.
You can read and write.
That's referring to me.
And then we can see a list of people named here and the privileges that they have.
We can pull down from that menu to see what privileges we're allowed to grant.
Here we have read and write, or read only.
And we can change those permissions for any user that's listed.
You potentially could also add a user.
We could pick someone from the list, for example a test user, select them, and
add a permission for them as well.
Overall this is a relatively easy way of changing permissions when we
compare it with how the same thing might be done in a command line.
Now we have the command line window open and
we can list the permissions for that file.
We have two files here.
We've been looking at the bottom one.
And these are our permissions listed on the side.
For the average user,
that's much more difficult to understand than what's shown in the window here.
Furthermore, if we want to change the permissions, we need to
understand the command to do that, and then recognize that it's changed.
Which we can see it has at the bottom.
But if you don't know this command and
you don't know what these characters represent, you don't know how to
list them, it's basically impossible to do this from the command line.
But for an average user, even using this set of permissions is confusing.
And in my experience in teaching, a lot of people don't know how to
use these permissions at all and they don't really understand what they mean.
At the same time, people do understand the idea of granting permission to files.
And one place that that's actually very well implemented is in Google Docs.
Here we're looking at a test file that I have created in Google Docs, and if
I want to share it there's a button at the top to share this file, and I click that.
I get this set of sharing settings.
There's a link to share here and it tells me very clearly who has access.
Right now it's private.
I'm the only person who can change it.
If I want to change that access, there's a change button.
And doing it gives me a pretty straightforward list of options.
It can be public on the web, and
that's explained that anyone on the internet can find and access the file.
They don't need to sign in.
You can have a level where anyone with a link can do it.
So it's a little more obscure.
You can't just search for it.
Anyone who has the link can access it, but it's not completely public.
And finally, I can share with specific people.
I can pick anyone on this list.
So let's pick this option and do save.
Now we see anyone who has the link can view the file and viewing is in bold.
Again, that's something that I can change.
Now we have this option at the bottom that says, Access.
Anyone (no sign-in) can view, and
if I mouse over this I can change whether they can edit or comment.
These are different than the read-write-execute options that
are traditional to a Unix based system, but they're pretty straightforward.
And they're something that people who are using Google Docs generally authoring
information together, they understand that and it's really part of their task.
They may want to bring other people in to help them edit.
So even though there's a lot of similarities between the options that
are provided here and what you see in a UNIX or
system-based permissions interface, this is much closer to the user's task, and
is much easier for the average user to understand.
That allows users to make better decisions about security, and
achieve the kind of results they want.
Our next guideline is to draw distinctions among objects and
actions along boundaries relevant to the task.
Let's look at some of the questions, and
then we'll explore what this means more in-depth.
First, we'll look at something like: at what level of
detail does the interface allow objects and actions to be separately manipulated?
What we're talking about here is how much detail is
shown to the user about a process that's going on.
For example, if a user's downloading an application from the Web, they can
click on a link, and then a whole series of pretty complicated steps takes place,
from making network connections, to implementing the internet protocols to
actually transfer the packets with that file to the users computer,
the downloading of those onto the users computer, their assembly, and
finally their creation into a coherent file.
If the user's task is just to download an application to run, they really don't need
to see all those details of the process of creating the file.
So it's more secure to hide those because if you expose them to the user,
there's a chance that there may be errors that the user unintentionally introduces
into the process.
At the same time, if we abstract this to too high a level,
we can end up doing something like, the user clicks on a program and
suddenly installs it and it's running on their computer.
That can be tremendously insecure.
And it takes away a level of detail that the user actually might be
quite capable of interacting with.
So you need to think about, for your particular users and
the tasks that they're undertaking, how much detail do you want to show them,
and what should be hidden.
Similarly, we look at what distinctions between affected objects and
unaffected objects the user cares about.
As an example of this, on the Mac, applications are shown as
a single icon that the user can double click and use to run the program.
However, those are actually folders.
And if you get in, say, on a Unix command line you can
see details of those folders and all the files within them.
If a user makes an action within the application, for
example they change a preference,
some files within that folder that the application represents, may be changed.
Does the user need to see those affected objects, or
do they not care that those objects have been affected?
For most users on the Mac, the answer is they don't care about those
internal files, in fact, generally they're unaware of them.
But when you're designing an interface, these things often come up,
where there are files, or objects that get altered.
And you need to decide whether or
not that alteration is something that you expose to the user, or if it's something
that you hide because the user typically is not interested in that distinction.
Our final guideline is to present objects and
actions using distinguishable, truthful appearances.
The core of this guideline is that the user should know what they're looking at
and what they're interacting with.
Questions that we'll think about here include,
how does the user identify and distinguish different objects and actions?
For example, the user may get used to receiving emails from her bank,
and then she receives a phishing email that also looks like it's from her bank.
How is she able to distinguish the different objects,
the phishing emails and the non-phishing emails.
And, similarly, actions.
How is she able to distinguish a desirable action from an undesirable one?
In a usable security system, the interface should reveal that.
We'll also ask in what ways can the means of identification be
controlled by other parties?
For example, if we're looking at a phishing attack, the phishing website may
use a URL or a web address that's very similar to one that the user is expecting.
That makes it harder for the user to distinguish between the two.
If the potentially malicious source can control the way that it's identified, that
makes it more difficult for the user to distinguish good things from bad things.
We'll look at what aspects of an object's appearance are under system control.
So when is the system responsible for how things are displayed?
And potentially, that gives the user some control as well.
And finally, we'll look at all those aspects can be chosen to
best prevent deception.
As an example of how to be truthful and
straightforward and where that fails, we can look at this example.
On the desk top there's two files here.
They're each named file.JPG, it appears.
You can't see any difference in the file names when you're looking at them.
And that alone should raise some suspicions,
because file names need to be unique.
In fact, if we pull up some more information about each of these files,
when we look at them, there's no hidden extensions.
They both really are called file.JPG.
They're listed as jpegs, they're listed as having the same information.
So how is it that we're able to have two files with exactly the same name?
Well actually, they don't have the same name.
One of these is called file.JPG.
And the other one, instead of having the lower case l,
has a capital I, and it's impossible to distinguish between the two,
using the font that shows up in the interface here.
However, if we look at the command line,
you can see when I listed these files before that the capital and
the lowercase are clearly distinguished because of the font.
This is a case where the font actually can hide distinctions between objects, and
this same kind of manipulation is something that's been used in
phishing attacks.
The chapter of the book that we've been talking about in these lectures actually
talks about a site that spoofs PayPal, replacing the L with a capital I, exactly
like we did here, which makes it hard in emails to actually distinguish whether
you're getting an email from PayPal or you're getting it from some spoof site.
These are examples where the interface can be designed to
highlight differences between objects and
actions that could potentially be hidden if we're not careful.
So our conclusions for this lesson are first to make it easy for
users to control access to their resources.
Second, to show a level of detail that's informative and
useful to the user, but not to show anything more than that.
And finally, to make it easy to see the differences between objects and
actions that could be confused.
Overall.
the goal here is to make sure that users get the information they
need to make important security decisions, but they're not overwhelmed or
confused with other information that may lead them down the path of
making insecure decisions, simply because the information is presented poorly.
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2018 Coursera Inc. All rights reserved.
