 Cool. Hi. Thanks so much for coming, and thank you so much to Bernard and Victoria and everybody. Actually, I'm just going to say it. Last year was the first time I came to FOSDEM, and I showed up thinking, now I'm a designer. I don't know what's going on here. There's nothing for me. I walked into the open source design room, and I was like, this is fascinating. This is fantastic. I need to come next year. I need to come every year after this, and this year I'm given a talk. So I hope that, yeah. Thank you. My name is Molly, and I am a senior designer and researcher at Simply Secure in Berlin. We are a small design non-profit based in Berlin. We have an educational mission. So we host events, gatherings, meetups, most recently a one week design residency in Berlin for people to work on security, privacy, and trustworthiness-related technology. We make toolkits. We do a lot of research, design, and consulting ourselves as well. We helped with some open source projects in the past. We helped with a lot of the prototype fund projects in Berlin. We helped with the tails rebranding, helped some with the tour style guide, and a lot of these were collaborations with some of the other folks in these rooms. So our main areas of interest are open source, privacy security, and decentralization, and most importantly, trustworthy technology. This might seem to you like it doesn't even go together, like design and security aren't those completely different topics. I know I used to think of security as a technical property, like design, I make it usable, security, and engineer makes it secure. And those are totally separate processes that have nothing to do with each other unrelated. I think it was moving from the US to Germany, which is sort of a more privacy and security conscious society, a society that's a little more conscious of how you use your personal data, that I realized there was a really powerful connection between design and security. Okay, I'm just going to show you this. Is this right? But okay, what if we put this post-it note somewhere else? This secure? You're probably thinking, yeah, definitely not. We're probably really not if this computer belongs to the same person who wrote the post-it. All right, what about this? In the snack box is this secure? We actually can't answer this without a lot more questions. Is there a copy of this information anywhere else? Who else knows where who else is aware of the existence of this post-it and has access to the information on it? Is this information easy to relate to a particular individual, a particular identity? Is this information current or is this just like old? Is it accurate? Is it updated? And key, is that your secret sex snack stash or is that a snack box that everybody uses? As anybody who has done anything with security knows, security is super context dependent. What is your threat model? The thing is that design is also really, really context dependent. Design and security have a lot in common in that you can't do design without answering a whole lot of questions. Security, like something you pretty much always do and some things you should pretty much never do. But there is a big middle ground where design, like security, depends on your context. You can't just make something that is good in the abstract. Who is going to be using it? What is the context? What is the world around it? So before we dive into some security specific examples, let's do a little bit of comparative exploration around what design choices can do to a technology application that is, I think, pretty similar. I'd like to look at just part of design. Okay, so visuals and words. This is part of design that a lot of people think of when they think of design and it is super important. I want to look at how visuals and words are used when we are presenting a VPN. I chose VPNs because it's a tool that basically does the same thing under the hood. Okay, we've got some difference in security features. We've got some difference in like account management, pricing options, but like basically the same thing. So it's really the look and the feel of the whole tool and the visuals and how they work together that determines quite a lot about a few different VPNs. This is just, I just went through the internet and pulled some home pages. Here we've got something that tells us on the very front page it is for the truly paranoid. Okay, cool. This one on the other hand, MOVAD, is aimed more towards people who think that they are using a VPN as sort of something they personally want to watch, should be able to have everybody should be able to use a connection that allows them to get to access all content. This Nord VPN is kind of for people who want to think of a VPN as being something that's not special or not paranoid. It's like a normal cost of doing business. They don't use a lot of technical vocabulary and they've got this very like star alliance, gold, international business kind of background. Borderless world, et cetera, et cetera. This one, perfect privacy, seems to me to be for people who think they are, anonymize your internet. I'm not even sure what that means. And the website is actually quite short on technical details, but they've got these very site graphics. Okay. And this one, people do not want technical attributes. They're focused on something that seems friendly and easy to use. This is for the, I just want to watch Brooklyn Nine-Nine crowd. There's literally no technical vocabulary anywhere on the page. So clearly there's no like best way to design even branding for a VPN or no typical VPN user or like best practice for designing this homepage. But if you're in this room, you know that design is not just the visuals and the words. Design is really importantly the way that you organize a tool and the choices that people are permitted to make within it. Let's go back to our VPNs. VPN has a command line interface you can use. There are many, many choices. And you need a lot of background knowledge even to know what choices exist. So probably the widest range of possible choices and the least help making those choices unless you want to read a lot of documentation. They also do have a lot of documentation. I'm making now I wanted to show the command line one. Nord VPN. We've got a graphical interface here. This is the really business oriented one. Fewer choices and but still a graphical representation of a technical concept. You can go into a country here and like favorite a particular server. So the concept that there are different servers in each country is exposed to the user and that's a choice they can make. Let's look at tunnel bear. What can you do here? You can literally choose a country and then you can choose tunnel no or yes. You can also connect and disconnect. Those are literally the only choices you can make. There is no technical vocabulary on this slide except for the word tunnel and even that is explained with this little Super Mario like tunnel in different countries. You had no options. The only choice is yes no. So which one of these is a usability best practice? We've been talking about design in general but in security we often have to make choices about how to depict something fairly complicated and these stakes are very high. We can't be like maybe you get it maybe you don't whatever I don't really care because if somebody uses it wrong there is a lot that is at risk. Your design choices can cause security holes. Are you familiar with the concept of a desire path? This is like this is the normal path but this is cutting the corner and everybody cuts the corner because why yeah there's so many around here. So many actually all around yeah all around this campus. Why would you stay on the normal path when this is much shorter? This is how people are going to use any tool that you make. Confused people will create workarounds and you're not going to like those workarounds. If you have too much information or information that is really preachy or condescending kind of treating people like they are stupid then they're going to tune out or get annoyed and people will do whatever it takes not to think about security. Nobody likes thinking about security sometimes even when it is literally their job to think about security. They need to do something else. They're trying to message somebody. They're trying to pay a bill. They're trying to transfer information between devices. It's a paradox. We need people to kind of act against their immediate interests in for their long-term interests. We want to educate them but we also don't want it to be preachy and condescending and this is why I've wandered into this corner of design because I think this is one of the thorniest and most interesting design problems we have. Do people actually need to understand how everything works? This is an engine. Maybe you just need to drive the car unless your job is an auto repair person. Maybe you just need to know how the user interface of the car works and not necessarily the engine. Let's look at two security concepts where design has been trying to make it a little bit easier for people, non-technical people to interact with that security concept and let's see how that's going. Let's look at key handling and password management. All right. Key handling. I did not know until maybe four years ago how public and private keys worked. I didn't need to know. Then somebody sent me an encrypted email that I could not open and I did some Googling. I thought, oh, this is the thing. All right. I Googled and found a diagram kind of like this. And I now know kind of how key handling works. I've got a private key. The other person has a private key. I have a public key. The other person has a public key. In order to send a message to them, we combine my private key and their public key and then only they can open it. But they can open it when they know, when they have my public key and their private key and somehow this all works together cryptographically so that only though that particular combination opens the message. There. I have given you my understanding of how this works. And that's a lot more than a lot. Thank you. There's a lot more than a lot of people know. And I would say it's actually way more than most people need to know in order to have access to encrypted messaging. Signal has made huge strides in this regard. I really like the way that, so here I'm texting with Eileen Wagner and something changed. Your safety number with Eileen has changed. Does not tell me that, and he says, does not say anything about my public, about public keys and private keys. It tells me something has changed that I need to verify. And then this shows up and it kind of encourages me to meet up in person with Eileen Wagner and either scan the QR code or make sure that these numbers are the same and then I can mark as verified. I would say that actually we could make this even, WhatsApp has made this even simpler by just saying, here, Lawnmire's security code changed. And I kind of like this subtle thing of rather than saying your security code with her has changed. It says something has changed on her side. And it makes clear that I need to make sure that she still has that phone. Maybe she got a new phone. There's something changed in the technical settings on her side. And when I tap this, it tells me I should have screen grabbed that. It tells me in very plain language that I should meet up and make sure that the phone still belongs to her and that it's still really her. Otherwise we can't be sure that it's encrypted. I think this is really neat because it exposes exactly what you, what you, a person who doesn't know anything about cryptography, needs to know about making sure that your message can only be read by the person you're sending it to. Cool. Let's look at password management. I was dismayed to discover that a friend who had internalized the idea that passwords needed to be something that you remember and something that follow a certain like set of, they need to be longer than 15 characters and have special characters, whatever. So she had a great password and she was using it everywhere. No. Cool. Okay. So I thought, all right, we need to set you up with a password manager. But there was no way that this person was going to use an external password manager. I use KeyPass XC. This person took one look at it and was like, absolutely not. Even last pass, this would have all not worked. I thought, okay, in-browser password management has gotten pretty good. Let's set you up with the in-browser password manager. The way that in-browser password managers work, a password manager is a place that keeps all your passwords. So you can have a whole bunch of different strong passwords and then access them with one master password. And this way you can have different passwords for different websites. Just what this person needed. This person, I should say, was over 60. And this remembers your password on the website where you're probably using the password and just like types it in for you. Cool. I thought this is just what you need. Well, when I was trying to figure out which password manager she should use, Chrome kept grabbing the passwords incorrectly and then there was no way to edit them manually. So when Chrome got this wrong, I could not go in and put the correct password in. Chrome would like mix up the username and the password. Yo, that's really bad. I thought, all right, Safari and Firefox have got to be better. Okay, Safari and Firefox, you can edit it within the in-browser password manager. But here, my friend thought that this was the password on the website. So what she did was go into the Safari password manager and change all of the saved passwords in the Safari password manager and thought that she had then changed all the passwords on all the websites in the process, losing all of her passwords. Her mental model of how a password manager worked, she thought this was the website, was like completely different from what I had expected it to be. That is a big, big problem. So is this functionless design just like not explaining what's really going on underneath the surface? Is that helpful or harmful? Is it dangerous to not offer choices and to oversimplify a complex problem for the sake of helping people understand it? Well, I really wish it had explained it more. How on earth are you supposed to figure this out? You might be wishing that I could offer you like a best practice or a guideline or a checklist, and you might at this point be a little annoyed that I'm not, that I am saying it's really context-dependent. Sometimes you want to show people how the engine is working, and sometimes it just needs to work and they don't want to think about it. Well, I can actually ask... talking to people. And this is... you can do research, use a research remotely. I've done lots of it, if you're thinking, no, we're all distributed, you can still do user research. If you're thinking, no, we never do any kind of research because we believe in protecting people's agency and privacy and anonymity, you can still do that. I do it all the time. There are a lot of best practices in place so that you, yes you, can do design research on your project. No matter how hard your user group is to reach, you think no matter how technical, no matter how non-technical, this is super, super important. Engaging with people and finding out what are their mental models around what it is you're doing. So, the two techniques that I would recommend, and if you were at Olayna's talk earlier, she said this much, much better than I am and has a whole talk about it. So, watch... what was it, 2 p.m.? It's called 130. It's called the dangers of not doing user research, and she spells out a lot of techniques for doing this. I am going to highlight just the two that you... that I... One is asking people about their mental models. So, ask somebody, how do you think encrypted messaging works? You need to approach them in a way that it's really clear that you are not quizzing them, that this is not school, you are not trying to make them look stupid. You're just really curious how they think. What do you think a password manager is? I am really wishing I had asked my friend that question. The other thing is to watch somebody use your tool. Ask questions like the contact in the secure messaging app or try changing a password, and you will learn so much from correcting and not explaining. This is possible to do remotely via a whole lot of screen sharing tools, but it actually is quite easy to do if you're just sitting next to somebody, then take notes. You cannot rely on the way that you think about something security, privacy, and trust related, being the same as the way other people will think about it. And it is so important that you do this because you're going to end up with usability related security holes you had not even thought of. A lot of this is in our knowledge base on simplysecure.org. We have sample research guides. We have guides for how to plan your research. We have some of these usability best practices I told you about. Our goal is to make research possible for you. The question you have about how this works that you're not finding research around security, privacy, and trust to be something that everybody in this room is able to do. Thank you. Yeah, questions? We haven't yet. So the question was have we done anything around securing your own wallet, especially as cryptocurrencies become more and more widely adopted? This is a fantastic question and this is on our long trello list of things to look into more. And I really think we should pursue it. Thank you so much for bringing that up. Not yet. Nope. And there should be. Thank you. Yeah. That was a brilliant talk. Thank you so much. Can you tell us a bit more about simply secure and the work you're doing with that? I asked, and again, watch Alina's talk earlier, the cost of not doing user research. You need to see this. She asked what is simply secure and a bit more about the work that we're doing. So I actually only started there about eight months ago. So some of the work I'm talking about, I have to say, has been my co-workers, our former executive director, Scout Brody, current executive director, Georgia Bolin, and my colleagues, Amy Elliott and Andaleen Wagner have been doing work around supporting other people in their design processes and occasionally doing design consulting ourselves. My favorite thing that we've done lately is this design residency in Berlin called Underexposed. We had 10 people from all over the world come and work on security, privacy, and trust-related problems through the lens of some of the more developers, some were artists, some were researchers, some were designers, and then presented our results at the end of the week. We'll have a wrap-up post about this.