 We have Erika Portnoy. She's a technologist at the Electronic Frontier Foundation. She develops the Let's Encrypt client search bot, which makes it easy for people who run websites to turn on HTTPS, keeping their users private and secure against network-based attackers. Today, Erika is going to present on making it easier for everyone to get Let's Encrypt certificates with search bots. So let's just give a warm welcome to Erika. And thank you. Thank you very much. Hello, everyone. My name is Erika Portnoy. And I'm a staff technologist at EFF and a developer on search bot, which is EFF's Let's Encrypt client. EFF, if you don't know, is the leading and non-profit organization defending civil liberties in the digital world. Let's Encrypt is a free, automated, and open certificate authority, or CA. And search bot is a tool that EFF makes to get certificates from Let's Encrypt. I'm here today to tell you the story of a tool we built, the people who use it, and what we learned from those people. Hopefully, by the end, you'll have learned a little bit about making software more accessible to millions of users. So our goal with search bot and Let's Encrypt is to encrypt the whole web. When we started the project, it was expensive and complicated to get a certificate. We could solve the expensive part of it, but if it was still complicated, we would not succeed. Complicated is just another kind of expensive. So we built Let's Encrypt based on Acme, an IETF protocol developed in tandem with the service. Acme automates the process of validating control over a domain name and requesting certificates. This allows an Acme client, like search bot, to get and install a certificate with basically no human intervention in the best case. Even better, the client can automatically renew certificates before they expire, decreasing the chance of expired certificate warnings. So our dream was that you could apt install search bot or yum install search bot, run it, and you'd have certificates for all of your sites with no need to edit config files yourself. This has been a pretty successful dream overall. And for most of the people who use search bot, this dream is the reality. So what was the problem here? Why do we think we needed to change things? OK, so I'd like to do a very quick show of hands here. Who here? Raise your hand if you've successfully used search bot before. Awesome, that is great to see. OK, now next group of people, why don't you put your hands back up and then keep your hands up if you've ever gotten a Let's Encrypt certificate, even if not through search bot. OK, I see a few more hands going up. OK, thank you very much. And now what I'm wondering is about, who of these people here have used a shared hosting provider that got your certificate automatically for you? So you didn't have to deal with search bot, you didn't have to deal with Let's Encrypt? OK, yeah, I see a few more people. So it sounds like with this room here we've had a pretty successful group. And you're all what we consider to be the success case. You are the ones that, for the purposes of encrypting the entire web, we are happy and things are working pretty well. Thank you very much. OK, now let's do the darker side of things, show of hands here. What I want to know is who's ever been in some sort of weird hosting situation where you had an environment where you had to do something weird and custom and go into the flags or the settings and you just wanted to get a certificate. And damn, it wasn't supposed to be easy and it took a whole bunch of googling around. And maybe it turned out to be easy in the end, but now you have this script that handles all of that nonsense underneath. Does this resonate with anyone, anyone here? Yeah, OK, I am seeing a not tiny number of hands here. And this group of people is why we decided to launch this project. Because as it turns out, there's quite a few people out there who run into trouble getting certificates and they run into enough trouble that they need to ask for help and this happens on a regular basis. This is a screenshot of the Let's Encrypt community forums. The community forum is a community of kind people who help out other users who are running into issues getting Let's Encrypt certificates. The arrow is pointing to the time stance of some recent posts. So you can see that people are posting pretty regularly. When I took this, this is just in the past few hours. And this is constantly happening at all hours of the day around the world. There's people who are always running into all of these issues trying to get a certificate. And the forums are very active, which is actually great to see that we have a larger community of people who are able to jump in and help people out. But what we'd really like to do is make it so that people don't have these problems in the first place. What is the problem here? Why are they having these issues? What is the underlying cause of the issues that make them need to go to get this help? And so this became our focus question for this project. Why are people having problems? What are those problems? We want to make sure that we're building the very best technology that we can be. But we can't go about improving our technology until we understand exactly where it is that people are having trouble. OK, but that's a pretty broad question, right? Where do we even start? What sort of questions should we even be asking to get at people's difficulties? How do we find out all the different problems that people are having? How do we even start to tackle this? Let me take a brief digression to discuss the psychological phenomenon called the curse of knowledge. Basically, this is what it's called when you forget what it was like to not have known something because now you know it. This comes up pretty often in teaching, for example. Some of the best teachers are the ones that can remember what it was like to not have known it because they'll understand where people are having problems and they can guide their students through those problems to get to where the teacher is. But this curse is also very active in software development. I personally spend all days staring at Sir Pot. I am constantly dealing with it in the terminal. I'm one of the people who interacts with it the most, which makes me one of the very worst people to figure out what the problems with it are. Where are the pitfalls? What are the problems that other people have? I don't know because I know every last detail of this thing and what its edge cases are, but we shouldn't have to expect everybody to know that. And we want it to be able to work for people without them having to have that knowledge. But so what's the cure for this curse? Well, when it comes down to it, the cure is very simple and it's about building empathy. And the way to build empathy systematically and thoroughly is what user testing is. So that's exactly what we did. So our main goal was to find out what we didn't know that we didn't know. We decided to do some good old face-to-face or face-to-skype as the case may be. Watching the user try to accomplish the task using our software and just seeing what comes up. So the very first thing we did before we jumped right into it was to figure out what are some of the questions that we want to answer so that the tester, the person who's watching someone try to use the software, can keep in mind things to watch out for. We want to know things like what searches they use to get information, what sites they end up going to, what commands they're using at the command line, but more importantly, we wanted to know what the user was thinking at every step in this process. So what are they understanding about the process that they're going through and how do they think that the various technologies involved all work and how do they work together? These are the questions that we wanted to get insight into. And we wanted to do all of that in a way that's as authentic as possible to what the user would be doing without us being there in the room. So we wanted to set a task that makes the fewest assumptions possible. We don't want to give them any leading information. For example, if we say, hey, we want you to try to use CERTBOT, we've already told them that there's a tool that exists called CERTBOT out there, but we do want to see how they use it. So how do we solve this paradox? Well, we just make it as broad as we possibly can. The script that we had, we always read out the same thing to have it be as consistent as possible. And what we said is you have an existing website. I would like you to take steps so that when I go to it from my browser, the site has HTTPS, pretty broad. So that says nothing about CERTBOT, nothing about Let's Encrypt, and it doesn't assume anything at all about their setup. Then we asked them this question and we watched and took notes on everything that they did and everything that they mentioned they were thinking as they went through the process. So in the end, what did we learn? What was the problem that stopped people from being able to get HTTPS turned on? Yeah, obviously it turns out that it's not any one particular problem. It's not that they were all running into the same thing. We ran these tests and we ended up with quite a bit of data, pages and pages of notes on our hands. There was a truly daunting, staggering amount of places that just weren't as clear as we imagined they would be to someone who already knows everything about how the software works because of this curse of knowledge. So what we needed was a way to understand this data, to pull out patterns that we could turn into actionable results. And the way that we did this was to put together what's called user personas. User personas are a kind of prototypical person. They aren't any one individual necessarily, but rather a mishmash of related traits that we can use as a framework to start thinking about these problems. If you can imagine someone, even if they're not a real person and just a collection of traits, it's easier to imagine what that particular individual might wanna need because as humans we're more wired to think about dealing with individuals than to think about the general concept of a person who might use this and everyone all put together. So I've put a few examples of some of the personas that we came up with up here. So for example, we have Cat, which is the newbie. Cat is someone who might ask a question like, how do I SSH into my server? She's someone who's maybe setting up her website for the first time and is really excited about doing this. But when we say, okay, so what OS is your server running on? She might say what her local laptop is running instead of what her server is running. And there's these sort of misconceptions that we need to address before we could even get to the certificates part of things in the first place. Another example is Sasha, who is I think what we had always imagined to be our dream user. This is someone who has been running websites for years is maybe someone who administers websites for other people and they know everything there is to know about administering an HTTP website but somehow they just have this weird blank spot in their brain about what HTTPS is and this random gap in their knowledge and we will fill that one gap and nothing else. And actually it turns out that there are a good number of people who do fit this sort of thing. Like it's not completely the case that that's not a person that we're building for but it's certainly not everyone that we are building our software for. And so for each of these personas we came up with the sort of stumbling box that each persona would run into that came up in testing and as well as some opportunities for addressing these frustrations to make the project better based on what each individual's needs might be. So let's take a closer look at one of these personas to understand how we translated our understanding of a persona into actionable goals. Someone we came across often and that we would see pop up pretty often on the community forums is the shared hosting user, let's call him Jack. Jack started making websites in the age of shared hosting and is familiar with GitLab. He's proficient with that and he can get let's encrypt certs if the host provides it but he doesn't use cert bot to do that. He uses, for example, the dream host UX to do it really quickly and what all he wants is a quick, easy and inexpensive way to install certs which honestly don't we all. So some frustrations that Jack might run into is that he's trying to find information when searching online but it's really hard to tell which information is the information for him. What's relevant, what's up to date? It's like there's just a lot of information out there and it's talking about things that may or may not apply to him and he's not quite sure. And if we ask him what server he's running, he may not know the answer to that question and, for example, he doesn't know everything there is to know about certificates like he might not know what a wildcard certificate is because that doesn't apply to him. And this is not to say that he's any lesser or anything for not knowing these things. He just knows the information that he needs to get the job done and that's all he should have to know to be able to get his site encrypted. So in our testing, after some Googling, a user like Jack might end up at the cert bot homepage. This is what the cert bot homepage currently looks like. Let's consider it from the perspective of a shared hosting user. What's going on here is that when you get to the page, you see two dropdowns, one for asking for the web server that you're running and one for the OS that it's running on. Okay, let's take a second and think about what this page looks like to Jack, our shared hosting user. What are some of the assumptions that we have embedded in the design of the page that is given what we show on the page? What are we expecting that the user has or knows? Does anyone want to shout out some ideas? What assumptions are we making? What was that? Knowledge of the software running. Yeah, great, when I heard another one over here. That the person is running a web server at all. Exactly, I heard one back there. No? One more? Yeah, exactly, yeah, that they're running a particular software and that the software that they're running is going to be a server, that there's no other type of software that they're going to be running. There's all these assumptions, other things that are embedded in here beyond the design outside of what you can see here is we're assuming that they're going to be comfortable with a command line. We assume that their website is, that they not only have one, but that it's already up and running and that they can SSH into the server running that server software in the first place, which is really quite a lot of assumptions to be making that don't actually apply to every person who's running a website in general. Earlier, I mentioned that our goal is to encrypt the entire web. That doesn't just mean people who are manually hosting their own websites by SSH-ing in, starting up Apache or Nginx and running it from there. And so what this goal means is it means that we don't want to leave behind the people that aren't using this sort of setup. So our user testing didn't involve statistics, we didn't take like large numbers of things, but based on what we've seen on the community forums and from talking to people, there's a pretty significant number of people out there who we want to help, that we were just largely ignoring with what we previously had. Basically, for many people, Serpot might not be the right way to get the let's encrypt certificate. And if you don't already know that going in, coming to our website can be pretty misleading. So for Jack, his correct answer is to change something in the host settings and not to use Serpot at all. But you can't get that answer from here, okay? Let's do like a silent thinking session here. If you wanted this page to be useful to Jack, what changes might you make to this page? What would a front page that centers Jack's experiences look like? Take a second, maybe tell the person next to you, if you have a cool thought, like we'll just have an answer for yourself ready before I show you what we landed on, okay? I hear some whispers, cool, thank you. I'm sure everyone had great ideas, but this is the idea that we decided to go with. This is the design direction that our team decided to head in to address this problem. So what you see here is a wireframe for an updated version of that very same landing page. Wireframe meaning that it's a sketch of what the elements on the page might be, but doesn't have its design elements finalized. The main thing here is that the design takes a step back and before anything else, it focuses on helping people figure out if Serpot is the right tool for them in the first place. And then from there, our goal is to lead people who visit the site to the place where they can get the information that they'll eventually need. So for the ones who can use Serpot, they'll get those instructions, but for other users, maybe they should be sent towards different information. So we've reframed the overall goal as similar to what we were asking in the user test, getting people's sites on HTTPS rather than using Serpot specifically. Okay, cool, so let's look at a different persona. This one is Jordan. Jordan might be a security professional. I suspect there might be quite a few Jordans in this very audience. So for Jordan, they probably have access to a Linux box on a virtual provider and they've scripted around Serpot with some bash, Python, Perl, something like that. Jordan is a Linux expert who has a knack for finding exactly the right help pages. They get their information on how to use Serpot from reading blog posts that say how to use Serpot with Let's Encrypt, and they've successfully navigated their Serpot home pages instruction generator to get information for their setup. They know to go to SSL Labs to test the quality of their HTTPS setup, and they don't use the Let's Encrypt community form very often because they don't need that extra help. So Jordan is the sort of person who had probably set up HTTPS before Let's Encrypt ever existed, and they're glad that Serpot makes it so much easier. Okay, so do we even need to worry about this person? They seem to be doing perfectly fine. Like, is there anything that we could be doing better than we're doing right now to help this person? Well, one interesting thing that came up in our user test is that this person often has this script around Serpot, and they run the script manually every few months to renew their certificates, which works perfectly well, and is a fine setup, but Jordan probably doesn't know that Serpot has built in automatic renewal functionality, and if we could somehow communicate to them when we can make their lives much easier and they wouldn't have to be going in manually to do this. And on many of our common OSes, it's not even something that you need to set up at all. It'll just happen automatically thanks to the way that it's packaged, and the cert will automatically renew. But how are we failing to communicate this? They came up over and over again that we were seeing that people just didn't know about this. Why couldn't, why weren't we getting this across? Yeah, so taking a look back at our previous instructions page actually makes it pretty clear why in retrospect. We're just shoving this wall of text at users, and so it's pretty clear to see why some of those details might get lost. This is the instruction page, and it just has all this extra information on here. So for example, we have our installation instructions for, okay, we have our installation instructions, but then we also have this extra sub-note about DNS plug-ins, and how do you know if that's relevant to you, and what is this note box at the top here? Are people reading that? Why are they reading it? When wouldn't they be reading it? If you actually just wanted to go do it, which of these instructions do you follow and which don't you follow? It's pretty confusing, and the whole thing about automatic renewal is some text at the end that has a command. Does that mean you need to run the command? No, that's testing it. What do you have to do? There's just a lot of very confusing things, and it's not a clear, simple way of presenting it to the user. So instead, on our redesign, we're focusing on having clear, understandable, enumerated steps without all that extra information. Previously, what we wanted to do is make sure that everyone might have all the information that they need, but what we saw is that when people got to that page, even if the information was there, it wasn't in a form that was useful to them. So instead, we're just going to give them the information that they need for this one particular task in this one spot and handle the rest of the information through the flow of the site. So this is a little overwhelming at first, it seems, but what this diagram embeds is the concept that for any piece of information that someone might need, they don't need to be given it at any given time, but they need to be able to get to that information from where they are in a logical, clear flow. So for example, in the upper left corner is the starting place and right there, you already can get launched into the, okay, well, you have a shared hosting provider who does this for you or you're gonna need to use certbot flow, but maybe you're a little confused or you're gonna need some few extra flags because you need to run some hooks in there or something and so there is a way to get over to the orange corner in the upper right, which is the let's learn how this works section, but you're not in a space to understand what you need to know about how it works when you're actually over in the upper left corner. So you should be moved over to that space and as you flow around the site, collect the information that you need, but which means that for any particular page, you won't be overwhelmed. And we had a very similar problem in the information overload in how certbot itself works. So currently when you run certbot, it asks if you want to redirect HTTP traffic to HTTPS. The current default is to not redirect, which made sense when we were first starting out because we were worried about making unnecessary configuration changes and messing up people setups. It's really not the case anymore. We like claim we're still in beta, but it's pretty stable at this point. And what we saw in user testing is that people would be overwhelmed with this information and like every study on prompts has ever shown, they will cancel the prompt and not click yes. But what happens if you don't click yes here and you go to your website is that it'll show up as being an HTTP website and you're like, why didn't this work? And so one of the things, one of the software changes that we're making is to just do this automatically for people so they don't have to worry about it in the first place. And in fact, this is related to a larger problem that we had. They weren't sure if it had worked or not and they would be confused about that and why would they be confused? Well, this is the output that you would get from the terminal and the note that you've successfully done everything correctly is denoted by the arrow about three quarters of the way through the page and then there's all this extra information so it's pretty easy to miss and then after it there's all this extra information that talks about another step that they might need to take but actually they don't need to take that step in many cases and it's all very confusing to figure out the status of whether or not it was effective in the first place because we want to let everybody know everything that is possibly relevant. And so this is what we hope the new terminal output will look like. There's a lot of things going on here but what I wanna point out is that at the end there's a clear message that the user was successful and a relevant next step for the user to take. Here's how you can improve your website, make it even better by using SSL Labs. And these are just a few of the changes that we're working on. We wanna make it easy for every site on the web to be encrypted and for every website operator to be able to turn on HTTPS as the Serpot team, as the Let's Encrypt team and as EFF, we're committed to working until that's true. And so before we go into questions I'd like to give a big thanks to the Village that it took to put this project out into the world. That's including the team at EFF both on the Serpot coding team and in the design team and at Let's Encrypt and thanks to everyone who helps package Serpot for the various distributions, everyone we interviewed for user experience input from Serpot users to kind volunteers at conferences like this one to security educators and researchers. And an extra shout out to all of the individual EFF members who make work like this possible. EFF is a 501c3 non-profit that defends civil liberties free speech and innovation online and our member support goes directly to projects like Serpot. That is the story of how we are making it easier for everyone to get Let's Encrypt certificates and I hope that you have all found it informative.