[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.
