In this video, we're going to look at additional authorization and communication guidelines to help us design usable, secure software. The first guideline we'll talk about here is the user should know what authority others have. That means other people and software, and the authority that those people and software have, to allow access to the user's own information or resources. The points that we want to think about here are, what kinds of authority can software and other users hold? What can we give them, and what can they do with that? What kinds of authority impact user decisions with security consequences? So, what kind of authority can a user hand over? And knowing that someone else has that authority, how does that affect the way the user makes decisions? And finally, how can the interface timely access to information about these authorities? That means when a user's making a decision, how can we show them what they need to know, in order to make a decision based on who has authority? As an example, our operating system has access to, and authority to do, a lot of things on our behalf. For example, it can launch other programs. It can record keystrokes and it can record clicks. We can also give that authority to other programs, but you run into danger particularly when other programs are allowed to launch third programs themselves. This is the basis of a lot of spyware and how viruses get installed on computers. For example, a classic way that viruses used to spread was that people would have an email program running on their computer, and that program would automatically download attachments and launch them. By that program having the authority to launch additional programs, or execute files, it could potentially allow viruses and malware to install themselves on the user's system. Now, sometimes we want users to be able to delegate authority to software to do things, like launch other programs. And the user can't be expected to remember every piece of authority that they've given to other software. Thus, it's important, and these design guidelines are oriented around, making sure that we somehow signal to the user what authority they've given to particular software. Once they know, for example, that the software they're using is able to execute other programs, that can help them make the appropriate decision about how to use that software program. As an example, let's look at our web browser. I'm on a page here for a free game that we can download, and there's a download link right here. Now, if I look at the bottom of the screen, which you'll see appear right here, we can see that that links to an exe, an executable file. I happen to be on a Mac, so we can't run the exe, but for purposes of the demonstration, let's say that if I download this file. I'm downloading something that can be executed and run on my computer. If I click the download link, what's going to happen? What authority have I given to my browser here? Have I said that the browser can automatically download and execute that file without me having to take any additional steps? Have I told the browser, instead, that it needs to ask me what to do when I'm downloading a file? Those two things are going to make me have different decisions. Since this isn't a website that I know well, I may be wary of downloading and automatically executing a file. I may want to download it and check it out first, or test it somewhere. Maybe run a virus scan on it. If I know my browser has the authority to download and automatically execute, I may take a different step. However, if I know that my browser is going to prompt me before I download this and execute it, then I'll make a different choice. I happen to know that my browser is set up to prompt me, so if I click the download link, I'm asked if I want to open it, I can pick the program I want to open it with, I can open it directly in the browser. That's useful if I want to view text files or images. Or I can simply save it and not do anything with it. Knowing that I have this choice makes me personally much more likely to download files because I can click on them, and that I know that I have the option to save them if I'm not quite sure what I want to do. Or to open them and automatically execute them if I want to. However, the important part for design guidelines is that the user needs to know whether or not their browser will automatically execute this file. And that is an authority we can grant. The option's grayed out here, but we have the option to do this automatically for files like this from now on. That means there could be files where I say, open it as an automatic thing, and if I've made the decision to do that, I won't have this pop-up come up and ask me what I want to do. The user should know, whether or not their browser is going to automatically take the option to download and execute without talking to the user, or if the user will be prompted. A good design will let the user know what authority they've granted and not require them to simply remember it. That's something that's not built into the browser software, but for security, it would be a great thing to have built in there to help the user remember what authority they've granted, and then make good decisions based on that. Our next guideline is that users should know what authority they, themselves, have. When we're thinking about specific questions related to this, that includes things like, what kinds of authority does the user hold? How does the user know that they have that authority? What indication do they get? And what might the user decide based on their expectation of authority? So, this is really the flip side of the previous guideline we were looking at. If user has delegated authority to a piece of software, they should know what authority they've delegated, and that helps them makes decisions. Similarly, if the user has their own authority, they need to know that, and that in turn will make, help them make decisions. This is a mental model that the user builds of what authority they have, what authority software has, and what expectations they have for security and how the system will function based on that authority. In the chapter that we've mentioned before in this week's work, Guidelines and Strategies for Secure Interaction Design, the author provides PayPal as an example of where this expectation of authority can go wrong. When a user receives a payment from PayPal, they get an email that says they've received the money, and when they log into their PayPal account, they see this screen. Here we can see that the user, who's me, has received a payment for $51.92. Because we can see, on the PayPal screen, that this transaction has occurred, and at the bottom it's marked completed, I may think that I have authority over this money. Since I would consider it being in my account, just like if a check clears in my checking account, I may feel secure in sending the products to the person who's paid me this money. However, what's not clear is that PayPal actually still has authority over this money while it's in my PayPal account. They can undo this payment, they can pull the money out of my account, and I don't actually have authority over it even though the presentation here may create the expectation that I do. Thus, there's this false expectation of authority for the user, and that can create security problems. In particular, the user may send a product, expecting that they have the money when they don't. Next, we want to make sure users trust the software that's acting on their behalf. We saw some examples of this, when we were talking about whether or not a browser would automatically execute a program, which could turn out to be malicious. Or, whether they trust the software to behave in a way that will not launch malicious software, either by giving them an option of what they want to do with the program that they're downloading, or perhaps by scanning it or doing some other checks to ensure that it won't launch something malicious. When we're thinking about the trust that users should have in software that acts on their behalf, we'll look at questions like, what agents, and in this case we're talking about software, manipulate authority on the user's behalf? How can users be sure they're communicating with the intended agent? How do they know they're talking to the right software? And how might that agent be impersonated? Along with that, we'll think about, how might the user's communication with the agent be corrupted or intercepted? So, as an example of this, we can think about malware or phishing, or other examples where a user may think they're talking to a particular website or to their browser, where they'll share some private information. But they may actually be talking to a malicious website that is mimicking, say their bank's website, or that's mimicking the browser making the user think that they're interacting with a piece of software running on their local machine, where in fact they're interacting with a website. Let's start by looking at some examples of where a password is required from the user, and that password's required by the browser. If we look at how that's done in Safari, we can paste in the URL, and you can see that the window requesting the user name and password, appears underneath the edge of the top bar. This is something that actually would be relatively straightforward to reproduce in fake, on a website. While the browser is what's asking for this, we could create a website, use some cascading style sheets, and make a window that looks just like this that appears at the top of the web page, which is the top of the white area here. That would make it difficult for the user to know whether or not the browser or the web page is requesting the password. Other browsers do this differently. Here, we're looking at the Chrome browser. We're going to paste in the same URL, and when we get it, we get the same Authentication Required message asking for a user name and password. But, this window appears above the gray area of the top bar. That's something that we couldn't replicate with a web page because the area we control with a web page is this white area here. The box requesting the user name and password appears above, higher on the window than that white area that we can control. So it would be impossible to create a web page on Chrome that mimics a browser asking for a password. It would be obvious to the user that the browser is not what's requesting it, it's the web page. Finally, here's the Firefox browser with the same address. And again, we can see the Authentication Required message appears at the bottom of the address bar, on top of this gray area, and not in the area that we can control with the web page. So again, we couldn't mimic the browser requesting a password with a web page because the window that requests it appears outside the area that a web page can control. So, in conclusion, we want to make sure that users know what authority they've granted, and what that means for security decisions. So, If I allow my browser or operating system, or other software some authority to act on my behalf, it should be clear to me when I have granted that authority and what authority I have granted, so that I can make decisions that are secure based on a proper understanding. Similarly, we want to make sure that users know what authority they hold. That allows them to make secure decisions, knowing that they control some information and some behavior, and we want to make sure that users aren't misled into thinking that they have authority when actually they don't. Finally, we want to create interfaces that make it clear what agent, in this case software, the user's interacting with and providing information to. If they know that they're acting with a piece of software or an agent that they trust, they may be more likely to share personal information. However, if it's unclear, they may share security details like passwords or other secure information, with a malicious third party, while they think they're acting with a trusted agent. Thus, making it clear in the interface, who they're interacting with, will make users make more secure decisions. And that really is the goal of all three of these guidelines. The interfaces should make it clear to the user, who has authority and who they're interacting with, so user decisions can be secure and achieve the results that they want.
