[SOUND]. Hi everyone, this week we're going to discuss guidelines for secure interaction design. There are a lot of ways that we want to think about security and usability together. A secure system needs to keep unauthorized people out, so authentication is an important topic. We are going to expend next week focusing entirely on authentication. However, a secure system needs to maintain security once an authorized user is logged in and working. The system needs to allow users to do what they need to to accomplish their tasks. And a secured system should do that while protecting the security of the users computer and the larger system their interacting with. When thinking about designing secure systems, the guiding question is how can we design the computer system to protect the interest of its legitimate user? There are a lot of high profile security issues that come up after a user is properly authenticated. Viruses are an obvious issue. Spyware is increasingly common, and is a growing problem. Phishing scams and forged emails often have people give away private information which can later be used to compromise a system either by getting around authentication or by allowing bad actors to take inappropriate actions in other ways. None of these problems are caused by getting around authentication in the first place. And while it's easy to blame the user for doing something wrong, it's not necessarily their fault either. These problems come up when computers fail to behave in a way that the user expects or understands. Designing secure systems that are good with usability can prevent that from happening. In this week, we're going to discuss building secure systems and designing them beyond authentication. This is based on a chapter in Simon Garfinkel and Laurie Kraner's book on secure usability design, and we're relying on chapter 13 by Kah Pei Yee. That chapter presents two main strategies for designing systems that are both usable and secure, security by designation and user assigned identifiers. Let's start with some background and then move forward to the guidelines in those terms. Secure interaction design deals with how to design a system that's both secure and usable. We should start by understanding some major components of that topic. The first is mental models. We discussed mental models earlier in this course. They're ideas that users have in their minds to help explain and understand how a system works. For software to be secure and to help users behave in a secure way, it should be consistent with their mental models and their understanding and expectations. Thus if we incorporate mental models from the beginning, it helps us design better systems. The core idea here is that it's users who are making security decisions, and therefore you must take users into account when designing the security components of a system. This means we don't expect users to be security experts, or to understand all the details of how security mechanisms work. They should be able to complete their tasks safely and securely be relying mainly on knowledge and understanding that they already have. An example by Kah Pei Yee in the chapter that we're using is this. Suppose a user downloads a file deletion program. The program is carefully tested, so we know it reliably erases files leaving no trace on the hard drive. Is this program secure or not? It depends. If the program is presented to the user as a game, and then it secretly deletes that users files, leaving no trace, this is a big security violation. But if the user knows that they are downloading a file deletion program and they are using it for that purpose, it's secure. It would only be a failure then if it didn't securely delete the files. The only difference in whether or not the program is secure is based in the user's expectation. Digital signatures, proper authentication, or any other factors that are entirely security focused, make no difference here because the user expectation has to be met. Often times when people think about security and useability they think of it as a conflict. Useability is suppose to make things easier to use while the perception is that security will make things more difficult to use, but that is really a unfair comparison. Security isn't about making everything difficult. It should make it difficult to do operations that have undesirable effects. And usability isn't about making all operation easy. It's about improving access to operations with desirable effects. Tension only arises when the system is unable to determine whether a particular result is desirable or not. If the desirability of the action is known ahead of time, security and usability actually work together in the system. The point where security and usability diverge often is when security is presented as a secondary task to users. For example, when a user buys a computer, they never have a task in mind of updating it. While installing patches or configuring firewalls may be necessary for security, no one ever gets a computer with the idea of bringing it home, sitting on the couch and installing a patch. These are secondary tasks that really just get in the way of whatever the user's main intention is. The more security can be integrated into the normal workflow of the user, the more usable the security mechanisms will be and the less likely it is that users will try to circumvent them. Security and usability also have something frustrating in common. Software designers often think about usability and security as something to incorporate after they've already designed the software systems. They're not features that are integrated into the product from the beginning. They're tacked on to an already completed software project. It's common to hear people talk about adding security features and we also hear software designers discussing how to fix usability problems after they've basically finished the final product. Neither security nor usability should be afterthoughts. Both should be included in software from the very beginning of the design process. Iterative design, which we've discussed before, is one way to do this. We analyze users needs, then design, then test. After testing we re-evaluate, redesign and re-test. And this cycle proceeds from easy low tech prototypes all the way through the final design. This cycle is common in software design, but it's usually focused on software correctness and functionality. Well that's obviously critically important. Both usability and security can be evaluated in the testing process to ensure that both are included from the very beginning. This helps address the heart of the potential conflict. If we keep in mind at every step that people will be interacting with the security, we can ensure that the security features are useable from the very beginning. Many of the rest of the topics this week will deal with authority as contrasted with permissions, when we're talking about usability and security, so let's define those terms. Permissions are settings within a system that say who can access a file. Authority is who has the power to access something regardless of the permissions. As an example suppose Alice's computer has permissions that say only Alice and her programs can read the files in her home directory. Then, Alice installs a server program that serves up the files in that directory. If she gives Bob the URL to the server, she grants Bob the authority to read her files even though Bob wasn't given permission on Alice's computer. From the systems perspective, the permission settings are being enforced. But outside the world of the system, Bob still has the authority to access the files. This distinction between authority and permission is one that we'll discuss many times this week. So it's good to have those terms defined. So to wrap up, usability and security don't need to be at odds with one another. If we take into account that users will be the ones interacting with the security features of the systems from the very beginning and design the system to make that interaction as usable and straightforward as possible, we can build systems that are both useable and secure.
