Towards a more secure operating system without sacrificing usability
Mueller, Tobias
GNOME is a desktop that cares about its users and their freedom. To be free also includes to have the freedom to use your computer without having to fear of getting compromised or anyone listening to your communication. GNOME takes tries hard to put the user back into the control seat regarding security and privacy. We will see two examples of how GNOME gives you back that control. The first is a classic: The problem of signing OpenPGP keys. The second is the protection against malicious USB devices.
 Hi, everybody. I'm Toby and I'm a GNOME person as you can see and you're here in the GNOME talk. In case you wanted to go anywhere else, now is your final chance to sort of find the right room. Otherwise, I'm happy to entertain you for the next 45 minutes to an hour depending on how much we engage. I'm very happy to engage. So, in case you have sort of any question or in case you, you know, want to discuss anything or if there's anything unclear or you don't understand me very, very well, then please, you know, make yourself heard and we get these things sorted out. Is there anybody not understanding German? Is everybody speaking and understanding German well? You're like raising your hand. Does that mean that you are speaking German or that you are not speaking German? All right. Good. So, does that mean we can actually proceed in German? Okay. How Well, that's how it works and how the GNOME project thinks and how I believe that the GNOME project ensures that we have a safer computing in the future. And I think that GNOME is a very good place for us to bring a safer computing environment. And I would like to convince you a little bit that GNOME is a project that I take care of and what it does well in my opinion. I brought a few case studies with me. I have a few examples that should show that it is exactly committed in this area. And I would like to introduce them to each other and we will fold them apart. So that you keep that in mind that we will see three things that I will introduce. And yes, I will start with a little bit of what is basically to say to GNOME. The GNOME project has written a few things on the road for which it is and for which it is sustainable. And I think a central point of this principle, of this basic value of GNOME is the software for as many people as possible to write. And to ensure that as many people as possible are in the position to use GNOME software and to allow as many people as possible to use their computing. And the extension of this concept is that the GNOME project is responsible for the user experience in the hands. That is now a slightly abstract concept. So what does that mean? It is already user experience. That is supposed to mean that the software as such does not stand on the road with its tasks. And the GNOME project believes that the people use their computer, that the people do the computing because they have a job to do and not because they like to sit on a computer. So the whole mindset is always about which task the user has potential if he uses his or her computer. And how can you create this task as pain-free and fast as possible? And before this background, a few things happen in the GNOME project that I think are most successful. Of which are the translations. So GNOME wants to make as many people able to use their computing. And to do that, GNOME says, I should probably switch back to English. That is no problem at all. I was actually initially offering to continue in English. But no problem. Then we continue in English. That is perfect. Absolutely no problem. So there are many things happening in GNOME. And one of the more successful things I think is the whole story around the language issues involved with people not necessarily speaking English. We in GNOME, we have a quite successful translation story. When there's a new GNOME release upcoming, we have many, many languages being translated. We have the GNOME software being translated in many, many languages in relatively short time. And this is not only a single. This does not only happen a single time, but has happened over the last, I don't know, 80 years or so with GNOME software that we have constant efforts in enabling, well, also non-English speaking people to use, well, to do their computing with free software and especially with GNOME. We also tried to be inclusive. The keyword I had two slides ago was inclusiveness. We extend this term, or we also understand in this term that we enable people who have different, say, physical needs. So we try to make GNOME as usable as possible in the sense that we try to make it easy for people who have different, say, who have needs for different, say, input methods or different reading methods who people who cannot necessarily, you know, read a regular screen because they have some physical challenges to deal with that, well, requires, say, dedicated hardware or, say, color tinting of the screen, these things. We try to think of these, well, issues and we try to make software which enables as many people as possible to use, well, free software. And we take, again, we take responsibility for the user experience for the whole system. We try to remove issues, say, in the stack and do not paper around, you know, bugs. That is, that's becoming visible when we're dealing with things like, say, Bluetooth or with graphic stuff. We don't just, you know, stop at, say, relatively high-level boundary of being, like, in user space and being the software that draws some icons and windows, if necessary, we dig deep down in the stack and fix things as deep as in the kernel. So we want to be as inclusive as possible, as I've said. This is one of the core things that drives GNOME. The other thing that drives GNOME is freedom. Now freedom is a, freedom, the term in itself is quite abstract. But the G in GNOME is GNU, right? And the GNU project is the, well, Godfather if you will, if you will, free software. And as we are on the, on the letters of GNOME, does anybody know what GNOME actually stands for, the acronym? It's a couple of letters, right? Does anybody know by any chance? Exactly, yes, GNU network object model environment, GNOME, right? And as I've said, the G in GNOME is GNU. And so we, of course, are dedicated to software freedom. And software freedom for us essentially means the four core freedoms. Does anybody know the four core freedoms that free software is about? Throw in some guesses. Freedom to use. That's freedom number zero, yes, the freedom to use. Yes, that's actually two, the freedom to, you know, share with your neighbors, to help your neighbors, and the freedom to improve. And there's like another freedom, sort of a prerequisite for these. Freedom number one. The freedom is kind of. Sort of, yes, in order to do that, you have to understand the software. You have to, you have to be able to study how the software actually works. So these are the software freedoms that GNOME is concerned about also. But there's yet another freedom, or I claim there's another freedom. I claim there's the freedom of you being able to use your computer without, you know, risking of being compromised, without you having to be concerned about your communication to be, well, wire tapped into. You want to, you know, do your task on your computer without having to fear that, I don't know, bad things will happen. And I think the GNOME project, or we at GNOME, we're in a good position to enable these, or to deliver these expectations, or on these expectations. Because as it turns out, that filtering out of external information is one of the basic functions of consciousness, according to Barry Schwartz, an American psychologist. And I think we at GNOME, we are quite good at concentrating on the, say, necessary things. And sort of highlighting the things that are, you know, important and making the other things less, say, visible or intrusive. We, as I've mentioned in the beginning, we try to, you know, enable people to do their tasks to make the software that does not stand in your way of, you know, you being successful in performing whatever you set out to do in your computer, with your computing. So we shall try to make decisions, you know, for you as the user, as easy as possible. And we should try to focus on things that are necessary indeed, and do not, say, show things that are maybe not so necessary. And regarding the security of your system, or if you translate that mindset to the security of your system, we end up with, you know, removing the user from the equation of the security system. Because there have been studies which have shown that if you let users take decisions on security-relevant questions regarding your system, you may as well roll the dice, because the user is, well, cannot comprehend the consequences of certain security decisions. And I'm now bringing some examples of, well, these sort of decisions that I think users cannot, well, make in an informed manner in order to sort of convince you of this fact, say, and to lay the foundations for our work at GNOME to make the security system sort of built in without the need of user interaction, or with as little user interaction as possible. I'm claiming that we are seeing problems every now and then, and the problems in general are a dubious feature or a dubious way of, you know, interacting with the user. What are prompts? Proms are these modal pop-ups that come out of nowhere that, you know, stay for as long as you click either option and that force you to take a decision just right now. Probably while you're doing stuff, you know, you're probably in the middle of performing some task, and then you get one of these prompts. You know, you get a modal dialogue. You cannot walk around the dialogue, you have to, you know, do something with the system right now, or you can continue your work. And we think that these prompts, well, are not a good way of dealing, of interacting with the user. These prompts have been quite popular, you know, like a few years ago. You don't see them so much these days anymore, also because people have realized, people making software have realized that prompts are a cheap way of interacting with the user, but not an effective way of interacting with the user. Security prompts are just plain wrong. You must not, you know, build software, security-relevant software which prompts the user. You must just not do that, and you must especially not produce prompts which make a permanent decision, you know, where the effect of the user interacting with the prompt is permanent, where it's not, you know, a one-time decision, but where the answer of the interaction with the user is being stored for future interactions. And why is that? I claim that this is very bad and actually wrong because the user is on the middle of performing a task, and of course, you know, the user want to perform the task. So the user does everything he or she can in order to get back to the task, you know, to the application to continue with their work. And one of my most sort of beloved prompt is this, you know, this prompt is now showing this connection is untrusted. Do you really want to continue? Do you really want to connect? And you know, the user, imagine the user. The user just opened the chat application or browser or, you know, whatever is networking or is performing a network connection or is opening a network connection somewhere, and I mean, the user has expressed the intent to have this application, you know, connect to the internet or do whatever the application wants. And of course, I want to continue. Why on earth would I have opened the application in the first place? And now you can, well, claim, you know, there's some value to this prompt. I mean, it's not that this, that the application developer would have thought of putting prompts, you know, in random places just to annoy the user. Of course, the application developer had a, you know, to inform the user of the connection being somewhat dodgy at least. And you know, how do you handle this situation? Well, the cheap way is to issue a prompt and then let the user decide. I think we must not do that. I think we must, well, in this very case, I think we must just terminate the connection or maybe offer a settings dialogue where we can configure the connection and then while setting up connections, then, you know, have this sort of information being processed. But not, you know, when the user opens the application and potentially wants to start, you know, chatting with someone, then we get this dialogue. This is not cool because the users want to perform tasks. And if we issue these prompts, then users will be interrupted in the task that they want to perform and they will potentially click continue because that's what they want to do. They want to continue. I mean, they don't want to cancel. You just rarely say, oh, I actually just in the last 20 milliseconds, I decided otherwise I do not want to open the chat application. Of course, there's some applications which are less sort of easy to handle. And the way to remove these prompts must involve researching a way to guide the user to still provide the same, say, functionality because as I said, the application developer has the problem now of what to do in this situation, right? The application connects to somewhere. There's a problem. What shall the application do? It's not necessarily clear. And the way to get rid of prompts is to research how to, well, provide a user interface, a user experience to still allow the application to be able to decide what to do and yet does not disturb the user in their tasks. And there's ways around that. And we at GNOME, we do many of these without, hopefully without you even noticing. A prompt that is somewhat funny is this one. Like this software is not signed by trusted provider. Ooh, trusted provider. What does that even mean? The software is not signed. It's yet again the same text. And do not update the package unless you really are sure that it's safe to do so. And this is so much information. And I claim that if you ask counter people on the streets what they would do if they get this dialogue, you could as well have rolled the dice in order to get the decision. I mean, imagine again, imagine the situation where this dialogue comes up. You're probably in your software update program or whatever. And then you have clicked update. Please update all my packages. And then you get this dialogue. And you probably know, you know, how to deal with this situation. You probably can comprehend what's going on behind the scenes. But you're quite a specialized bunch of people I have to admit. Because you've probably, well, had the fortunate opportunity of having a computer science education. You've probably heard about the, you know, issues involved with people manipulating your package store and manipulating packets on the fly, you know, when you're downloading stuff and all. But I claim that most people that we try to, you know, provide with free computing do not have had this fortunate opportunity of having had a computer science education. So this is a, I think this is one of the worst problems that we could possibly have. Because this, if you click now, force install, the, right. So it's like, you know, this is bad on all terms. Like, oh, sorry. Please, oh, please, so the comment was that this prompt does not even tell you what software this is about. And yes, it's quite a bad problem. And it doesn't exist anymore. I mean, I have to admit this is, I needed to pull this out of historic releases because I mean, it's 2017. We tried to improve, you know, on each and every release. And if this was still live, then I would probably not be here because I should rather fix these things. So these do not or should not exist anymore. Another very well concerning dialogue is this. Albert found a new update which fixes your problem. Please run before submitting a bug. PKcon update. That's just repredecent able equals Fedora and so on. Okay. All right. It's probably six past six we have to go. Oh, please wait. The system is being shot down. Okay. Okay. Unluck it up. There's a prompt. Okay. Unluck it up. Yeah, fair enough. Well, try to, you know, find a way of enabling the same functionality like still enabling the application, you know, to take the decision but without the actual prompt. And it's a hard subject. And it's not, you know, that there would be an easy way to do so. And there's no obvious way for each single prompt, but there is ways. Right. So the chat application, well, let me roll back just one and a half steps. There are some applications that are quite special, I think. For example, a web browser is quite special. Web browsers, because web browsers are so, by now, there are, there are, there are a lot of web browsers that are in application platform. So it's, there's no single purpose. It's not a single purpose app. The chat application on the other hand is more of a limited purpose app. It only does the chat thing. And for the chat application, my recommendation, my recommendation now that sounds funny as if I was the inventor, but if you look at other chat applications, what they do is when you set up the application, when you set up the accounts, then you get the sort of request as to whether you want to use this sort of connection information, including the certificate or not. And then in the future, if the certificate doesn't match what you set up, then the connection just doesn't, you know, establish. And there's no prompt. You may get something like connection error, please review your security settings or something. And then you, you know, get the, but without a prompt, but more like an informational thing in the content area of your application. And then by pressing this button, you get to the settings. And then you also know where these things are configured for the future. It's not a one-time thing, but you get to the general settings page where you can then set up the application. Right. Exactly. Yeah. Right. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Absolutely. So, the routing would probably be to guide the user to protect the server administrator or whatever, probably doesn't know that it's so stupid to be part of this part of the topic. Maybe it's a hard problem, yes. I give you that. And if there was an easy fix, we wouldn't have had prompts in first place. The prompts exist because there were cheap4plications developers to do. And what I claim, what makes GNOME a bit different from others say environments is that the GNOME people, well, tend to give these issues a thought at least. And they try to come up with ways to enable, you know, the functionality still, but without interrupting the user as badly as with their prompt. Maybe, you know, there's still a prompt, but maybe it's a, in that case, it probably wouldn't be as bad or as severe as these prompts that we've seen. You wanted to say something? In most cases, such prompts are probably configuration issues and not real security phase. But as a security-interested user, you may bother if a client just connects and gives a small hint because there's already information, transmitter, that are sensible and you couldn't prevent that. So the first part that I got was that most of these things are configuration issues, not necessarily security problems per se. And the second part was too long for me to comprehend because it's quite late. And the last slot of the conference, it's been an amazing 20 hours of soft conference and I'm quite drained by now also mentally. So please repeat. You said you suggest the chat app to just reconnect even if the certificate changed and give the user a small hint that it changed. So the comment was that I was recommending the chat application to connect anyways if the certificate changed. But that's not what I meant at least. I hope it's also not what I said. I said the connection should not be established in any case. Just not. You just not connect. I mean, you just don't because it's not what you set up before. The chat application would probably ask you to set up your credentials in first place, you know, in the initial setup phase. And let's encrypt, for example, it's normal that certificate changes frequently. Right. And in let's encrypt, it's also normal that you have a common root certificate and intermediary which always stays the same. And I mean, if we are talking TLS, then you probably have a TLS credential store and we should of course make use of that. The problem in 2017 still is that these credential stores, these root CA stores are a bit messed up. We have in New Linux, we have no unified way of managing these. But again, GNOME is working on that. There's P11 Glue, P11 Kit which has like some glue code to unify these credential stores because you have several. You have OpenSSL, has their own stuff in somewhere in Etsy, SSL somewhere. You have Firefox which has their own stuff. You have Potentially Thunderbird which I think has their own root store still. And you have probably various other apps who ship their own, pardon me? Java. Exactly. Java has their own key store as well. And you have all these, well, ecosystems which ship their own X509 stores for no good reason really other than that nobody sat down and like worked on unifying that. But again, GNOME is I think one of the few people, also the Fedora guys have an interest in having that unifying. But GNOME is one of the, is involved in getting this sort of fixed and cleaned up. And this again, I attribute this to GNOME being concerned about the user experience and goes down the stack if necessary. This one instance. So yeah, it's not an easy, these are not easy issues. And again, we need to think about that. And again, I think GNOME is one project who does, well, make efforts in thinking about these, please. So how does GNOME approach the developer of this application to improve the user experience? So how does that work? How does GNOME like prod the application developers to make things better? That's what you came up with because you had no better idea. So the easy answer is, well, it's GNOME applications, GNOME just fixes it. That's the ideal case. The GNOME desktop, usually when I give this talk, I spend at least five minutes and asking the people what do you think is GNOME and what does GNOME involve and everything. And then we sort of make straight that GNOME is a desktop environment. That's what people come up with relatively easily. But then what does it mean? Then it gets a bit tougher. GNOME is also a set of applications. And we ship, I forgot the exact number, but it's a relatively large number of applications that we have under all control and that we want distributions to ship along or that they ship with what they call GNOME. And we hope that, you know, if you install GNOME that you get a nice and working and fully sort of suited environment to do your computation. Of course, if it's third party applications, then I mean, at the end of the day, we are out of the game. We can only suggest fixes and if, you know, nobody accepts them. People do. I'm not entirely sure, like, in the chat application regarding things like chat applications. But what I know is that we are concerned with the GNOME forks, you know, the Mate and the M&M, all of them have forked the GNOME code and are sort of changing some strings to not show events, but I forgot the name of the other apps. And if we have fixes, important fixes on our end, we go the extra mile and, you know, inform the other projects and create pull requests for these important fixes. So we do that to the limited extent that we are sort of capable of doing. So we do that to the limited extent that we are capable of doing. And we do that to the limited extent that we are capable of doing. So the question was that with the chat application example, when the user wants to, you know, chat with someone, then it doesn't matter much whether the user gets offered a prompt or some other way of, well, actually, right, you know, the exact way of how the user actually gets to connect doesn't matter because the user goes to, you know, whatever extent necessary to make the connection happen. That's where it becomes. So what's the value of not having prompts? So let's take a question. And the one thing is that in the chat application thing, you might be tempted as an application developer to have this permanent decision thing. If you don't offer this permanent decision in the first place, then you, well, do not risk that the user forgets about or that the user has a chance of reversing the decision in case the user realizes that it was a bad decision. Of course, you get the same effect still with the revised user interaction. I mean, if the user sets up a bad connection, then the connection is bad, sure. But hopefully in the process of doing so, the user also gets to learn how to, well, set it up correctly, you know, in the future in case the user realizes, oh, I've set up the connection wrongly. Now everybody can read my data. This is, well, if you let the user do that, if you give the user the opportunity to do that correctly, then the chances are higher that the user will do it correctly. With the prompt, there's no way you can answer the prompt in a good way because if you select no cancel, then it's not good because the user cannot chat. If you let the user select yes, then it's bad because everybody can read the data. So there's the prompts. There's no good thing about the prompts other than that it's cheap for the application developer to do. But in an alternative way, I mean, it's not 100% good, but it's at least a little bit better in the sense that it's the, maybe, the proper way of setting up a connection and the user can undo the wrong thing that the user did before. But I don't claim there's, you know, the best way of handling the things. I'm claiming, though, that we have better ways than the prompts. But the alternative way of, in the chat application example, I think is a little bit better because, you know, the user learns how to undo things, the user learns how to do things once, and they're valid instead of they're valid sometimes, and sometimes they're not valid when I click cancel or OK or so. So I think mentally it's a bit easier to comprehend that the things that I have in the setting thing are valid, whereas with the prompt thing, the things in my settings dialog are only valid sometimes. OK. So there is another inherent, let's say, law or its attribute to Ellison from some USINX conference from 20 years ago. And this law says that for every click or keystroke required for a security feature, the user basically climbs by half. So if we, you know, make the user do something actively in order for the security to be there, then, well, our system is not as good as if the security was there without the user having to do anything. So we should try to, you know, have built systems which require as little interaction but are still secure, whatever secure means in this context. So these are the sort of, this is the mindset where we are coming from in the GNOME project in general. And now I've promised I'm bringing some case studies and bringing some examples of how I think we do that. And one example is this. Does anybody know what these people are doing? Has anybody ever seen that? It's like a bunch of people standing around. They're like having some sheets of paper and everything. Has anybody ever seen that? A what? It's a key signing party. What is a key signing party? It sounds fun. So what is a key signing party? Right, so the comment was that these people share the keys so that in, like after the fact they can communicate securely. They're building developable trust, very correct. How do you do? Do you understand keys after the talk? I do. You can use this fingerprint because this is what people do. They utter fingerprints to each other. These are 160 bits of information and these people, in the worst case, they're like uttering these bits of information like towards each other. And these are 240 people in these, like in this queue. And this is the typical format of what people deal with, like this is a hexadecimal string, 160 bits of information, the shaman hash of the open PGP key, and people read this out to each other and then they claim to verify identities and all. So you've taken part, you've participated in a key signing party. What do you do after you've stood for three hours in Brussels in January because it's past them time and it's minus two degrees and it's snowing and you get home with your cold and cough. What do you do then? If you put it in your key store so you can use the unit. All right. So you put it in your key store so you read this hexadecimal data of your piece of paper. You're not sure if you're reading A, B, or A or something. And then you transfer the data to your key store, you say, and then you eventually produce signatures, right? And how do you produce signatures? You probably use CAF. CAF is like the tool to use when you're producing signatures. This is the pinnacle. This is the gold standard as of now. It doesn't get any better than using CAF. And CAF is a pearl program. There's nothing wrong with pearl. I mean, people like it or dislike it, doesn't matter much. And in order to configure CAF, you write raw pearl. So if I wanted to use CAF with my parents, say, I not only need to ship a book about OpenPGP and security and everything, I also need to ship a book about pearl because my parents would need to learn pearl in first place before they are able to do the whole key signing stuff. And you could think, if you're mean, that there's like a big conspiracy around the sole OpenPGP security thing because we're using all this weird stuff like Bay 16. Because I haven't even asked you, what do you think I do that because it's a bit fun? How do you think you can communicate 160 bits of information in the least efficient way possible? So you have 160 bits of information on your piece of paper and you want to get that across by uttering something. How do you get 160 bits of information across in the least efficient way possible? What would you do? Finally, you would use base two encoding of the data. And then what you think is the second least efficient way of transferring 160 bits of information via utterances? Base four. Well, base four, you could do that. You could base three, base four and all. Nobody does that. The base eight would probably be the next one, but it's also a bit weird. The next thing would be base 16. It's quite an inconvenient way of sharing this information, but yet people somehow like it and all. And we have this, I get interonting. I get excited. It's not so good. We have loads of problems with the whole infrastructure around because how do you get the, how do you put the key into your key so in first place? Right? You go to the internet and get the key, right? Because how else would you obtain the copy of the key? And where do you get the key from? From a key cell, all right. A key cell was written in OCaml. I know quite a bunch of people. I don't know. I've been around the Free Software community for a long time and I know many people who do programming and all. Yet, I know exactly three people, I mean, knowing how to program in OCaml. It's this weird French dialect from the mid 1600s that by now only three people are able to write programs in. So we have this, everything is a bit weird around this old crypto stuff. And I claim it's a little bit due to the fact that these security people, they mostly are concerned with themselves, which is fine. Free Software people usually scratch their own itch and it's a perfectly valid reason to develop software. But I think we'd be living in a better world if we targeted, say, my parents for using the security things. And again, I think GNOME has a good mindset to actually deliver on that. And I'll quickly show some examples of how I think we could make things better regarding this whole key signing mess, if you will. So how about we have an interface that allows you to select your own key, you know, you get a list of your keys, and eventually you select one, and then you get some machine readable information that you can use with the other party who actually wants to sign your key, that other party would eventually, you know, make use of the machine readable information, then somehow the application would make sure that the key is being transferred in an authentic way so that nobody could have tampered with the key in transit. And then maybe, you know, all it takes is a click of a button and the key is signed. Wouldn't that be awesome? Turns out you can do that already now, more or less, with the application GNOME key sign. And I think it's a, I think it shows how you can, you know, make things better that have been the way they are for 20 or more years, you know, with just the mindset of trying to be not intrusive without, or with trying to be as inclusive as possible, with trying to enable as many people as possible to make use of the, in this case, security system. I've brought a video, but let's skip that and go to something, talk about something that's much more exciting, containerization of applications. We have all the rage now about Docker and images, and now is people talk about Snappy and Flatpak and App Image. And we do that too. So we have, in the GNOME project, we have concerned ourselves with the question of how do we confine applications so that they cannot do harm in case they are being exploited, you know, to be able to mitigate the facts of a compromise. And now you might say, oh, well, just use Docker, right, as a Docker has been around for what, three years or something now or four by now, and, you know, just use that for your application, bundle up everything in one of those images, and then you're good to go. You might be able to do that, but you quickly run into problems if you're wanting to do desktop applications, you know, not as opposed to server-side applications that get along without any interaction. If you're having desktop applications, it's likely that it needs to interact with, you know, not only the system itself, but also with the periphery, like with your printer or with your, I don't know, your sound card or with your camera or something. So you cannot just use, you know, any existing containerization technology because you will need to interact with the rest of your environment somehow, or it's relatively likely that if you're building a desktop system that you will need to interact with other parts of not only the system, but also your environment. So we have Flatpak. Flatpak is a new way of distributing applications in new Linux. So we are, say, not limited to all Linux systems running app-amo, for example. Right. So the question was whether Flatpak is only usable in Fedora, and the answer is no. It's not, say, snappy where you need this app-amo module in order for it to work properly. Flatpak is a technology which basically ships your image. Flatpak itself is only a cool way of distributing your OS free images. So actually Flatpak itself doesn't even do that itself. It doesn't even distribute the image itself. Flatpak only calls or makes use of OS free in order to ship the data, you know, from the server, for example, to your machine in order, well, for the application to then live on your machine rather than, you know, on the Internet. It also doesn't, Flatpak also doesn't do sandboxing itself because it uses bubble wrap for that. Bubble wrap is a project which creates a sandbox, a confined environment where the applications can live in and where they can hopefully, well, not cause any harm for the host system. And what Flatpak essentially does is it connects you, it connects all those bits and pieces and gives you an application delivery mechanism, an ecosystem where you can make your application, where you can bundle up your application and have users download this application conveniently. So the security properties of Flatpak are coming from bubble wrap, as I've said. Bubble wrap is a Linux tool. It makes use of Linux. So any Linux you have, the Linux program, the Linux kernel, you can use with bubble wrap. And bubble wrap makes use of all these modern, nice and fancy kernel features like namespaces, cgroups and secon. Basically what you have is a change route. That's the, like, very old traditional security feature of Linux where you can confine a process to a certain directory on your file system, basically. But it is changed route on steroids. It uses all these other fancy things to, well, to make it more secure still, but also to enable you to punch holes in two or through the sandbox. So the sandboxing facilities is what I call the classic security features. You know, these are classic, classical Linux ways to confine processes, well, in order to limit them in their potential harm that they could do. You know, by bind-mounting stuff read-only into the namespace, you prevent things, you prevent the application from being able to overwrite data. By not mounting things into the namespace, you prevent the application from being able to read data, well, out of the system. By using cgroups, you prevent the application from hogging all your resources. These are all relatively classic ways of making things more secure. And Flatpak, you know, uses all that conveniently without you having to care about any of these things. Yet, I've said something like, well, you need to interact with your environment because that's probably what desktop applications do. So you can punch holes through the sandbox. You can, you know, interact with your, say, X server, with your audio demon, with your debus. You can do all these things by punching holes through the sandbox with, you know, with bubble wrap. You can give it certain arguments and it'll allow you to do stuff that you are not able to do by default. By default, if you call bubble wrap, you get the most restrictive environment possible and you may want to open up the sandbox in order for you to be able to interact with the rest of the system. You might want to complement that though with a more modern approach to security, which, well, we call portals. These portals are interactive means to get to know the intent of the user. Because I think this is one of the core features of these modern security solutions. The core thing is to get to know the intent of the user. You know, you need to find out what the user actually wanted to do. You know, if I open the chat application, it's relatively reasonable that I want to start chatting now. So, you know, as you've said, the user goes to some extent, the user tries to make it possible for the application to do exactly that. And by having interactive portals, interactive dialogues prompts to some extent, we try to find out what the intent of the user was. Now, what is such a portal? Such a portal could be open something with an application, in this case, upper left like which application do you want to, you know, open this URL with? Or we have a printing dialogue. If you press print, then you're being asked what printer do you want to use. These are all relatively classic things, right? People know these already. And we're using these mechanisms to find out what the user wanted to and then let the action, you know, permit the action. So, we can poke holes through the sandbox with these portals to allow privileged operations like printing, but without surprising the user. There's no, we're prompt like, do you really want to print now or something? We are reasonably sure that the user wanted, you know, to print because the user selected the printer. And only then, if we select the printer, the sandbox will be, will be allowing the application, you know, to print the thing. And once the dialogue is gone, the application cannot connect with the printer anymore. So, we're also using these portals as a temporary mechanism to allow access, you know, compare that to say Docker where you can either give and grant access all the time or you cannot because you cannot dynamically adjust the permissions of the application. With this interactive model, we can do that. And I think it's good. And I think it's great. And I think we will see much, much more, well, hype and ramblings around this technology because I do think it's great. I think it's enabling us to do things that we weren't able to do before in a much, much more secure way. So, this is the second thing. Let me quickly do the third thing before we enter the Q&A. Yeah, and then we're good. So, another thing that I am personally concerned with is USB. So, in my previous life, I was assessing the security of USB. And I found out that the, well, just having the port open on your machine opens a relatively large attack surface. Essentially, what an attacker could do is load any, pretty much any kernel driver that you have on your, like, machine. And if you're installing any random, you know, Ubuntu or Fedora, you have every kernel driver there is on your machine. And the attacker is able to interface, to interact with this, with any of these drivers at their will. It's quite scary if you think about it, if you think about that. So the question I think that drove me was, when do you use your USB? And most importantly, when do you not? You know. And then, if you're not using your USB, who else uses your USB? And why are we actually allowing the USB port to work when we are not, you know, even being able to use our USB because we are away, you know? When I'm locking the screen, why does my USB port work? Why does my machine allow an attacker, or, I mean, any person really, to interact with all these Linux drivers when I'm not even here and touching the machine when I'm on the toilet or anywhere else? I don't think we have a good reason for doing that. And USB is an attack surface. It's relatively well known that, you know, if you're exposed to your USB, then you get, well, you might have trouble. You know, there have been incidents in the past and there will be more incidents in the future that make use of the USB port. And I think one easy fix is to, the easiest fix is to, you know, just use some glue and, you know, fix up your USB port and then nobody can ever, you know, plug anything in. Of course, that's not where we are coming from in the GNOME project. We can do that. We can block and unblock the USB in software and we would see a video with my graphics driver worked, but it doesn't and it's also not too bad. What we would see here now is some software which disables USB for a certain device, you know, not, sorry, not device, it would disable USB for a certain class, sorry. So you would not be able to load any, say, CD-ROM drives, you know, any external media because, especially keyboard. Especially keyboard is the common, especially not keyboard, I'm afraid, because you will want to allow keyboards in any case because your keyboard might break. But that's, you know, details, again, that requires you to have this inclusiveness mindset to be able to find out what you need to allow and disallow. Right. Right. So the comment was there, there were attacks simulating keyboards and that's certainly correct. That's absolutely right. Yet, from a technical perspective, these attacks were quite boring. They were not, you know, interfacing with any random kernel driver you had and they were only as powerful as any regular keyboard, which in itself is, you know, quite bad. But if I'm on the toilet and my machine is locked, then I'm fine with that. You know, the keyboard can, the worst thing the keyboard could do is, you know, go through passwords. That's already quite bad, but it's not as bad as, you know, the machine being compromised because it would load the file system driver for, now name any ancient file system that would automatically, you know, be mounted if I plugged in a pen drive and all. So, but yeah, there's issues around that. We cannot simply disable USB when the screen is blocked, although it would probably be already better than the status quo. You know, right now if you have a machine and you plug in USB, your Linux kernel would happily load any random driver that my fake USB device would, you know, make you load, make you to. And it's quite scary actually. Right. Right. Right. So the comment was, can you not control how many keyboards, you know, can plug in? And I say yes. It's, you can think of a solution like that. I think it's, I think it's a bad solution though. I think from a, from the user experience perspective, it's hard to communicate that you can plug in two, two keyboards but not three. It's somehow difficult. You couldn't make prompts to trust. Right. You couldn't make prompts to trust any device. Yes. I would not use prompts though. I would probably somehow show something like, oh, we've detected a new device. Do you want to make use of that? Not with a prompt though. And then if you click, yeah, please set up my devices, then you would get your list of devices and you could then, I don't know, maybe swipe the device to the left or to the right if you want to make use of it or not. Something like that. Or the best case, I think, is to only allow devices if you have an application started. You know, imagine, and now we have the technology. Slowly we start to having this technology. With Flatpak, we have tight control over what applications are doing what with our environment. And why would I load a camera driver? Why would I make my Linux kernel load a camera driver if I'm not having an application open that uses the camera? You know, it's, I don't think it makes much sense to have my Linux kernel do that. With Flatpak, we can potentially determine whether we have an application using the camera and only then make the kernel use or load the camera driver. And I think we have many more things to explore in this area. And we would see some videos which would show some automation around these things. It's very experimental, though. So I've shown you software or ideas in various stages. I've shown you the key-signing stuff which is sort of in beta stage. You can use that already now. These screenshots were not drawn. They were live. I've shown you the Flatpak stuff. It's quite production ready already. If you, you know, do app get install Flatpak, you get all this Flatpak stuff, you can start applications now and you can, you know, do real things with Flatpak just right now. And if you develop applications, you should package it up as a Flatpak and put it up on FlatHop so that other people can use your latest and greatest application as Flatpak. And I've shown you the USB stuff which is very experimental and is more in a research phase. And it also allows, you know, for contributors like you to engage in this sort of discussion and make this real and usable and protect users from, you know, attacks via the USB port. And I'm way over time already. This is also because we had a great discussion. And nonetheless, I want to close it now and of course I'm available here, but for the Internet, we're closing it down and I thank you very much for your attention. Thank you.
 Hi, everybody. I'm Toby and I'm a GNOME person as you can see and you're here in the GNOME  talk. In case you wanted to go anywhere else, now is your final chance to sort of find the  right room. Otherwise, I'm happy to entertain you for the next 45 minutes to an hour depending  on how much we engage. I'm very happy to engage. So, in case you have sort of any question  or in case you, you know, want to discuss anything or if there's anything unclear or  you don't understand me very, very well, then please, you know, make yourself heard and  we get these things sorted out. Is there anybody not understanding German? Is everybody  speaking and understanding German well? You're like raising your hand. Does that mean that  you are speaking German or that you are not speaking German? All right. Good. So, does  that mean we can actually proceed in German? Okay.  How  Well, that's how it works and how the GNOME project thinks and how I believe that the GNOME project  ensures that we have a safer computing in the future.  And I think that GNOME is a very good place for us to bring a safer computing environment.  And I would like to convince you a little bit that GNOME is a project that I take care of and  what it does well in my opinion.  I brought a few case studies with me.  I have a few examples that should show that it is exactly committed in this area.  And I would like to introduce them to each other and we will fold them apart.  So that you keep that in mind that we will see three things that I will introduce.  And yes, I will start with a little bit of what is basically to say to GNOME.  The GNOME project has written a few things on the road for which it is and for which it is sustainable.  And I think a central point of this principle, of this basic value of GNOME is the  software for as many people as possible to write.  And to ensure that as many people as possible are in the position to use GNOME software  and to allow as many people as possible to use their computing.  And the extension of this concept is that the GNOME project is responsible for the user  experience in the hands.  That is now a slightly abstract concept.  So what does that mean?  It is already user experience.  That is supposed to mean that the software as such does not stand on the road with its  tasks.  And the GNOME project believes that the people use their computer, that the people do  the computing because they have a job to do and not because they like to sit on a computer.  So the whole mindset is always about which task the user has potential if he  uses his or her computer.  And how can you create this task as pain-free and fast as possible?  And before this background, a few things happen in the GNOME project that I think are  most successful.  Of which are the translations.  So GNOME wants to make as many people able to use their computing.  And to do that, GNOME says, I should probably switch back to English.  That is no problem at all.  I was actually initially offering to continue in English.  But no problem.  Then we continue in English.  That is perfect.  Absolutely no problem.  So there are many things happening in GNOME.  And one of the more successful things I think is the whole story around the language issues  involved with people not necessarily speaking English.  We in GNOME, we have a quite successful translation story.  When there's a new GNOME release upcoming, we have many, many languages being translated.  We have the GNOME software being translated in many, many languages in relatively short  time.  And this is not only a single.  This does not only happen a single time, but has happened over the last, I don't know,  80 years or so with GNOME software that we have constant efforts in enabling, well, also  non-English speaking people to use, well, to do their computing with free software and  especially with GNOME.  We also tried to be inclusive.  The keyword I had two slides ago was inclusiveness.  We extend this term, or we also understand in this term that we enable people who have  different, say, physical needs.  So we try to make GNOME as usable as possible in the sense that we try to make it easy for  people who have different, say, who have needs for different, say, input methods or different  reading methods who people who cannot necessarily, you know, read a regular screen because they  have some physical challenges to deal with that, well, requires, say, dedicated hardware  or, say, color tinting of the screen, these things.  We try to think of these, well, issues and we try to make software which enables as many  people as possible to use, well, free software.  And we take, again, we take responsibility for the user experience for the whole system.  We try to remove issues, say, in the stack and do not paper around, you know, bugs.  That is, that's becoming visible when we're dealing with things like, say, Bluetooth or  with graphic stuff.  We don't just, you know, stop at, say, relatively high-level boundary of being, like, in user  space and being the software that draws some icons and windows, if necessary, we dig deep  down in the stack and fix things as deep as in the kernel.  So we want to be as inclusive as possible, as I've said.  This is one of the core things that drives GNOME.  The other thing that drives GNOME is freedom.  Now freedom is a, freedom, the term in itself is quite abstract.  But the G in GNOME is GNU, right?  And the GNU project is the, well, Godfather if you will, if you will, free software.  And as we are on the, on the letters of GNOME, does anybody know what GNOME actually stands  for, the acronym?  It's a couple of letters, right?  Does anybody know by any chance?  Exactly, yes, GNU network object model environment, GNOME, right?  And as I've said, the G in GNOME is GNU.  And so we, of course, are dedicated to software freedom.  And software freedom for us essentially means the four core freedoms.  Does anybody know the four core freedoms that free software is about?  Throw in some guesses.  Freedom to use.  That's freedom number zero, yes, the freedom to use.  Yes, that's actually two, the freedom to, you know, share with your neighbors, to help  your neighbors, and the freedom to improve.  And there's like another freedom, sort of a prerequisite for these.  Freedom number one.  The freedom is kind of.  Sort of, yes, in order to do that, you have to understand the software.  You have to, you have to be able to study how the software actually works.  So these are the software freedoms that GNOME is concerned about also.  But there's yet another freedom, or I claim there's another freedom.  I claim there's the freedom of you being able to use your computer without, you know, risking  of being compromised, without you having to be concerned about your communication to be,  well, wire tapped into.  You want to, you know, do your task on your computer without having to fear that, I don't  know, bad things will happen.  And I think the GNOME project, or we at GNOME, we're in a good position to enable these,  or to deliver these expectations, or on these expectations.  Because as it turns out, that filtering out of external information is one of the basic  functions of consciousness, according to Barry Schwartz, an American psychologist.  And I think we at GNOME, we are quite good at concentrating on the, say, necessary things.  And sort of highlighting the things that are, you know, important and making the other things  less, say, visible or intrusive.  We, as I've mentioned in the beginning, we try to, you know, enable people to do their  tasks to make the software that does not stand in your way of, you know, you being successful  in performing whatever you set out to do in your computer, with your computing.  So we shall try to make decisions, you know, for you as the user, as easy as possible.  And we should try to focus on things that are necessary indeed, and do not, say, show  things that are maybe not so necessary.  And regarding the security of your system, or if you translate that mindset to the security  of your system, we end up with, you know, removing the user from the equation of the  security system.  Because there have been studies which have shown that if you let users take decisions  on security-relevant questions regarding your system, you may as well roll the dice, because  the user is, well, cannot comprehend the consequences of certain security decisions.  And I'm now bringing some examples of, well, these sort of decisions that I think users  cannot, well, make in an informed manner in order to sort of convince you of this fact,  say, and to lay the foundations for our work at GNOME to make the security system sort of  built in without the need of user interaction, or with as little user interaction as possible.  I'm claiming that we are seeing problems every now and then, and the problems in general  are a dubious feature or a dubious way of, you know, interacting with the user.  What are prompts?  Proms are these modal pop-ups that come out of nowhere that, you know, stay for as long  as you click either option and that force you to take a decision just right now.  Probably while you're doing stuff, you know, you're probably in the middle of performing  some task, and then you get one of these prompts.  You know, you get a modal dialogue.  You cannot walk around the dialogue, you have to, you know, do something with the system  right now, or you can continue your work.  And we think that these prompts, well, are not a good way of dealing, of interacting  with the user.  These prompts have been quite popular, you know, like a few years ago.  You don't see them so much these days anymore, also because people have realized, people  making software have realized that prompts are a cheap way of interacting with the user,  but not an effective way of interacting with the user.  Security prompts are just plain wrong.  You must not, you know, build software, security-relevant software which prompts the user.  You must just not do that, and you must especially not produce prompts which make a permanent  decision, you know, where the effect of the user interacting with the prompt is permanent,  where it's not, you know, a one-time decision, but where the answer of the interaction with  the user is being stored for future interactions.  And why is that?  I claim that this is very bad and actually wrong because the user is on the middle of  performing a task, and of course, you know, the user want to perform the task.  So the user does everything he or she can in order to get back to the task, you know,  to the application to continue with their work.  And one of my most sort of beloved prompt is this, you know, this prompt is now showing  this connection is untrusted.  Do you really want to continue?  Do you really want to connect?  And you know, the user, imagine the user.  The user just opened the chat application or browser or, you know, whatever is networking  or is performing a network connection or is opening a network connection somewhere, and  I mean, the user has expressed the intent to have this application, you know, connect  to the internet or do whatever the application wants.  And of course, I want to continue.  Why on earth would I have opened the application in the first place?  And now you can, well, claim, you know, there's some value to this prompt.  I mean, it's not that this, that the application developer would have thought of putting prompts,  you know, in random places just to annoy the user.  Of course, the application developer had a, you know, to inform the user of the connection  being somewhat dodgy at least.  And you know, how do you handle this situation?  Well, the cheap way is to issue a prompt and then let the user decide.  I think we must not do that.  I think we must, well, in this very case, I think we must just terminate the connection  or maybe offer a settings dialogue where we can configure the connection and then while  setting up connections, then, you know, have this sort of information being processed.  But not, you know, when the user opens the application and potentially wants to start,  you know, chatting with someone, then we get this dialogue.  This is not cool because the users want to perform tasks.  And if we issue these prompts, then users will be interrupted in the task that they  want to perform and they will potentially click continue because that's what they want  to do.  They want to continue.  I mean, they don't want to cancel.  You just rarely say, oh, I actually just in the last 20 milliseconds, I decided otherwise  I do not want to open the chat application.  Of course, there's some applications which are less sort of easy to handle.  And the way to remove these prompts must involve researching a way to guide the user to still  provide the same, say, functionality because as I said, the application developer has the  problem now of what to do in this situation, right?  The application connects to somewhere.  There's a problem.  What shall the application do?  It's not necessarily clear.  And the way to get rid of prompts is to research how to, well, provide a user interface, a  user experience to still allow the application to be able to decide what to do and yet does  not disturb the user in their tasks.  And there's ways around that.  And we at GNOME, we do many of these without, hopefully without you even noticing.  A prompt that is somewhat funny is this one.  Like this software is not signed by trusted provider.  Ooh, trusted provider.  What does that even mean?  The software is not signed.  It's yet again the same text.  And do not update the package unless you really are sure that it's safe to do so.  And this is so much information.  And I claim that if you ask counter people on the streets what they would do if they get  this dialogue, you could as well have rolled the dice in order to get the decision.  I mean, imagine again, imagine the situation where this dialogue comes up.  You're probably in your software update program or whatever.  And then you have clicked update.  Please update all my packages.  And then you get this dialogue.  And you probably know, you know, how to deal with this situation.  You probably can comprehend what's going on behind the scenes.  But you're quite a specialized bunch of people I have to admit.  Because you've probably, well, had the fortunate opportunity of having a computer science education.  You've probably heard about the, you know, issues involved with people manipulating your  package store and manipulating packets on the fly, you know, when you're downloading stuff  and all.  But I claim that most people that we try to, you know, provide with free computing do not  have had this fortunate opportunity of having had a computer science education.  So this is a, I think this is one of the worst problems that we could possibly have.  Because this, if you click now, force install, the, right.  So it's like, you know, this is bad on all terms.  Like, oh, sorry.  Please, oh, please, so the comment was that this prompt does not even tell you what software  this is about.  And yes, it's quite a bad problem.  And it doesn't exist anymore.  I mean, I have to admit this is, I needed to pull this out of historic releases because  I mean, it's 2017.  We tried to improve, you know, on each and every release.  And if this was still live, then I would probably not be here because I should rather fix these  things.  So these do not or should not exist anymore.  Another very well concerning dialogue is this.  Albert found a new update which fixes your problem.  Please run before submitting a bug.  PKcon update.  That's just repredecent able equals Fedora and so on.  Okay.  All right.  It's probably six past six we have to go.  Oh, please wait.  The system is being shot down.  Okay.  Okay.  Unluck it up.  There's a prompt.  Okay.  Unluck it up.  Yeah, fair enough.  Well, try to, you know, find a way of enabling the same functionality like still enabling  the application, you know, to take the decision but without the actual prompt.  And it's a hard subject.  And it's not, you know, that there would be an easy way to do so.  And there's no obvious way for each single prompt, but there is ways.  Right.  So the chat application, well, let me roll back just one and a half steps.  There are some applications that are quite special, I think.  For example, a web browser is quite special.  Web browsers, because web browsers are so, by now, there are, there are, there are a  lot of web browsers that are in application platform.  So it's, there's no single purpose.  It's not a single purpose app.  The chat application on the other hand is more of a limited purpose app.  It only does the chat thing.  And for the chat application, my recommendation, my recommendation now that sounds funny as  if I was the inventor, but if you look at other chat applications, what they do is when  you set up the application, when you set up the accounts, then you get the sort of request  as to whether you want to use this sort of connection information, including the certificate  or not.  And then in the future, if the certificate doesn't match what you set up, then the connection  just doesn't, you know, establish.  And there's no prompt.  You may get something like connection error, please review your security settings or something.  And then you, you know, get the, but without a prompt, but more like an informational thing  in the content area of your application.  And then by pressing this button, you get to the settings.  And then you also know where these things are configured for the future.  It's not a one-time thing, but you get to the general settings page where you can then  set up the application.  Right.  Exactly.  Yeah.  Right.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Yes.  Absolutely.  So, the routing would probably be to guide the user to protect the server administrator  or whatever, probably doesn't know that it's so stupid to be part of this part of the  topic.  Maybe it's a hard problem, yes.  I give you that.  And if there was an easy fix, we wouldn't have had prompts in first place.  The prompts exist because there were cheap4plications developers to do.  And what I claim, what makes GNOME a bit different from others say environments is that the GNOME  people, well, tend to give these issues a thought at least.  And they try to come up with ways to enable, you know, the functionality still, but without  interrupting the user as badly as with their prompt.  Maybe, you know, there's still a prompt, but maybe it's a, in that case, it probably wouldn't  be as bad or as severe as these prompts that we've seen.  You wanted to say something?  In most cases, such prompts are probably configuration issues and not real security  phase.  But as a security-interested user, you may bother if a client just connects and gives  a small hint because there's already information, transmitter, that are sensible and you couldn't  prevent that.  So the first part that I got was that most of these things are configuration issues,  not necessarily security problems per se.  And the second part was too long for me to comprehend because it's quite late.  And the last slot of the conference, it's been an amazing 20 hours of soft conference  and I'm quite drained by now also mentally.  So please repeat.  You said you suggest the chat app to just reconnect even if the certificate changed  and give the user a small hint that it changed.  So the comment was that I was recommending the chat application to connect anyways if  the certificate changed.  But that's not what I meant at least.  I hope it's also not what I said.  I said the connection should not be established in any case.  Just not.  You just not connect.  I mean, you just don't because it's not what you set up before.  The chat application would probably ask you to set up your credentials in first place,  you know, in the initial setup phase.  And let's encrypt, for example, it's normal that certificate changes frequently.  Right.  And in let's encrypt, it's also normal that you have a common root certificate and intermediary  which always stays the same.  And I mean, if we are talking TLS, then you probably have a TLS credential store and we  should of course make use of that.  The problem in 2017 still is that these credential stores, these root CA stores are a bit messed  up.  We have in New Linux, we have no unified way of managing these.  But again, GNOME is working on that.  There's P11 Glue, P11 Kit which has like some glue code to unify these credential stores  because you have several.  You have OpenSSL, has their own stuff in somewhere in Etsy, SSL somewhere.  You have Firefox which has their own stuff.  You have Potentially Thunderbird which I think has their own root store still.  And you have probably various other apps who ship their own, pardon me?  Java.  Exactly.  Java has their own key store as well.  And you have all these, well, ecosystems which ship their own X509 stores for no good reason  really other than that nobody sat down and like worked on unifying that.  But again, GNOME is I think one of the few people, also the Fedora guys have an interest  in having that unifying.  But GNOME is one of the, is involved in getting this sort of fixed and cleaned up.  And this again, I attribute this to GNOME being concerned about the user experience  and goes down the stack if necessary.  This one instance.  So yeah, it's not an easy, these are not easy issues.  And again, we need to think about that.  And again, I think GNOME is one project who does, well, make efforts in thinking about  these, please.  So how does GNOME approach the developer of this application to improve the user experience?  So how does that work?  How does GNOME like prod the application developers to make things better?  That's what you came up with because you had no better idea.  So the easy answer is, well, it's GNOME applications, GNOME just fixes it.  That's the ideal case.  The GNOME desktop, usually when I give this talk, I spend at least five minutes and asking  the people what do you think is GNOME and what does GNOME involve and everything.  And then we sort of make straight that GNOME is a desktop environment.  That's what people come up with relatively easily.  But then what does it mean?  Then it gets a bit tougher.  GNOME is also a set of applications.  And we ship, I forgot the exact number, but it's a relatively large number of applications  that we have under all control and that we want distributions to ship along or that they  ship with what they call GNOME.  And we hope that, you know, if you install GNOME that you get a nice and working and  fully sort of suited environment to do your computation.  Of course, if it's third party applications, then I mean, at the end of the day, we are  out of the game.  We can only suggest fixes and if, you know, nobody accepts them.  People do.  I'm not entirely sure, like, in the chat application regarding things like chat applications.  But what I know is that we are concerned with the GNOME forks, you know, the Mate and  the M&M, all of them have forked the GNOME code and are sort of changing some strings  to not show events, but I forgot the name of the other apps.  And if we have fixes, important fixes on our end, we go the extra mile and, you know, inform  the other projects and create pull requests for these important fixes.  So we do that to the limited extent that we are sort of capable of doing.  So we do that to the limited extent that we are capable of doing.  And we do that to the limited extent that we are capable of doing.  So the question was that with the chat application example, when the user wants to, you know,  chat with someone, then it doesn't matter much whether the user gets offered a prompt  or some other way of, well, actually, right, you know, the exact way of how the user actually  gets to connect doesn't matter because the user goes to, you know, whatever extent necessary  to make the connection happen.  That's where it becomes.  So what's the value of not having prompts?  So let's take a question.  And the one thing is that in the chat application thing, you might be tempted as an application  developer to have this permanent decision thing.  If you don't offer this permanent decision in the first place, then you, well, do not  risk that the user forgets about or that the user has a chance of reversing the decision  in case the user realizes that it was a bad decision.  Of course, you get the same effect still with the revised user interaction.  I mean, if the user sets up a bad connection, then the connection is bad, sure.  But hopefully in the process of doing so, the user also gets to learn how to, well,  set it up correctly, you know, in the future in case the user realizes, oh, I've set up  the connection wrongly.  Now everybody can read my data.  This is, well, if you let the user do that, if you give the user the opportunity to do  that correctly, then the chances are higher that the user will do it correctly.  With the prompt, there's no way you can answer the prompt in a good way because if you select  no cancel, then it's not good because the user cannot chat.  If you let the user select yes, then it's bad because everybody can read the data.  So there's the prompts.  There's no good thing about the prompts other than that it's cheap for the application developer  to do.  But in an alternative way, I mean, it's not 100% good, but it's at least a little bit  better in the sense that it's the, maybe, the proper way of setting up a connection  and the user can undo the wrong thing that the user did before.  But I don't claim there's, you know, the best way of handling the things.  I'm claiming, though, that we have better ways than the prompts.  But the alternative way of, in the chat application example, I think is a little bit better because,  you know, the user learns how to undo things, the user learns how to do things once, and  they're valid instead of they're valid sometimes, and sometimes they're not valid when I click  cancel or OK or so.  So I think mentally it's a bit easier to comprehend that the things that I have in the setting  thing are valid, whereas with the prompt thing, the things in my settings dialog are only  valid sometimes.  OK.  So there is another inherent, let's say, law or its attribute to Ellison from some  USINX conference from 20 years ago.  And this law says that for every click or keystroke required for a security feature,  the user basically climbs by half.  So if we, you know, make the user do something actively in order for the security to be there,  then, well, our system is not as good as if the security was there without the user having  to do anything.  So we should try to, you know, have built systems which require as little interaction  but are still secure, whatever secure means in this context.  So these are the sort of, this is the mindset where we are coming from in the GNOME project  in general.  And now I've promised I'm bringing some case studies and bringing some examples of how I  think we do that.  And one example is this.  Does anybody know what these people are doing?  Has anybody ever seen that?  It's like a bunch of people standing around.  They're like having some sheets of paper and everything.  Has anybody ever seen that?  A what?  It's a key signing party.  What is a key signing party?  It sounds fun.  So what is a key signing party?  Right, so the comment was that these people share the keys so that in, like after the  fact they can communicate securely.  They're building developable trust, very correct.  How do you do?  Do you understand keys after the talk?  I do.  You can use this fingerprint because this is what people do.  They utter fingerprints to each other.  These are 160 bits of information and these people, in the worst case, they're like uttering  these bits of information like towards each other.  And these are 240 people in these, like in this queue.  And this is the typical format of what people deal with, like this is a hexadecimal string,  160 bits of information, the shaman hash of the open PGP key, and people read this out  to each other and then they claim to verify identities and all.  So you've taken part, you've participated in a key signing party.  What do you do after you've stood for three hours in Brussels in January because it's  past them time and it's minus two degrees and it's snowing and you get home with your  cold and cough.  What do you do then?  If you put it in your key store so you can use the unit.  All right.  So you put it in your key store so you read this hexadecimal data of your piece of paper.  You're not sure if you're reading A, B, or A or something.  And then you transfer the data to your key store, you say, and then you eventually produce  signatures, right?  And how do you produce signatures?  You probably use CAF.  CAF is like the tool to use when you're producing signatures.  This is the pinnacle.  This is the gold standard as of now.  It doesn't get any better than using CAF.  And CAF is a pearl program.  There's nothing wrong with pearl.  I mean, people like it or dislike it, doesn't matter much.  And in order to configure CAF, you write raw pearl.  So if I wanted to use CAF with my parents, say, I not only need to ship a book about  OpenPGP and security and everything, I also need to ship a book about pearl because my  parents would need to learn pearl in first place before they are able to do the whole  key signing stuff.  And you could think, if you're mean, that there's like a big conspiracy around the  sole OpenPGP security thing because we're using all this weird stuff like Bay 16.  Because I haven't even asked you, what do you think I do that because it's a bit fun?  How do you think you can communicate 160 bits of information in the least efficient way  possible?  So you have 160 bits of information on your piece of paper and you want to get that across  by uttering something.  How do you get 160 bits of information across in the least efficient way possible?  What would you do?  Finally, you would use base two encoding of the data.  And then what you think is the second least efficient way of transferring 160 bits of  information via utterances?  Base four.  Well, base four, you could do that.  You could base three, base four and all.  Nobody does that.  The base eight would probably be the next one, but it's also a bit weird.  The next thing would be base 16.  It's quite an inconvenient way of sharing this information, but yet people somehow like it  and all.  And we have this, I get interonting.  I get excited.  It's not so good.  We have loads of problems with the whole infrastructure around because how do you get the, how do  you put the key into your key so in first place?  Right?  You go to the internet and get the key, right?  Because how else would you obtain the copy of the key?  And where do you get the key from?  From a key cell, all right.  A key cell was written in OCaml.  I know quite a bunch of people.  I don't know.  I've been around the Free Software community for a long time and I know many people who  do programming and all.  Yet, I know exactly three people, I mean, knowing how to program in OCaml.  It's this weird French dialect from the mid 1600s that by now only three people are able  to write programs in.  So we have this, everything is a bit weird around this old crypto stuff.  And I claim it's a little bit due to the fact that these security people, they mostly are  concerned with themselves, which is fine.  Free Software people usually scratch their own itch and it's a perfectly valid reason  to develop software.  But I think we'd be living in a better world if we targeted, say, my parents for using the  security things.  And again, I think GNOME has a good mindset to actually deliver on that.  And I'll quickly show some examples of how I think we could make things better regarding  this whole key signing mess, if you will.  So how about we have an interface that allows you to select your own key, you know, you  get a list of your keys, and eventually you select one, and then you get some machine  readable information that you can use with the other party who actually wants to sign  your key, that other party would eventually, you know, make use of the machine readable  information, then somehow the application would make sure that the key is being transferred  in an authentic way so that nobody could have tampered with the key in transit.  And then maybe, you know, all it takes is a click of a button and the key is signed.  Wouldn't that be awesome?  Turns out you can do that already now, more or less, with the application GNOME key sign.  And I think it's a, I think it shows how you can, you know, make things better that have  been the way they are for 20 or more years, you know, with just the mindset of trying  to be not intrusive without, or with trying to be as inclusive as possible, with trying  to enable as many people as possible to make use of the, in this case, security system.  I've brought a video, but let's skip that and go to something, talk about something  that's much more exciting, containerization of applications.  We have all the rage now about Docker and images, and now is people talk about Snappy  and Flatpak and App Image.  And we do that too.  So we have, in the GNOME project, we have concerned ourselves with the question of how  do we confine applications so that they cannot do harm in case they are being exploited,  you know, to be able to mitigate the facts of a compromise.  And now you might say, oh, well, just use Docker, right, as a Docker has been around  for what, three years or something now or four by now, and, you know, just use that  for your application, bundle up everything in one of those images, and then you're good  to go.  You might be able to do that, but you quickly run into problems if you're wanting to do  desktop applications, you know, not as opposed to server-side applications that get along  without any interaction. If you're having desktop applications, it's likely that it  needs to interact with, you know, not only the system itself, but also with the periphery,  like with your printer or with your, I don't know, your sound card or with your camera  or something.  So you cannot just use, you know, any existing containerization technology because you will  need to interact with the rest of your environment somehow, or it's relatively likely that if  you're building a desktop system that you will need to interact with other parts of  not only the system, but also your environment.  So we have Flatpak. Flatpak is a new way of distributing applications in new Linux.  So we are, say, not limited to all Linux systems running app-amo, for example.  Right. So the question was whether Flatpak is only usable in Fedora, and the answer is  no. It's not, say, snappy where you need this app-amo module in order for it to work properly.  Flatpak is a technology which basically ships your image. Flatpak itself is only a cool  way of distributing your OS free images. So actually Flatpak itself doesn't even do that  itself. It doesn't even distribute the image itself. Flatpak only calls or makes use of  OS free in order to ship the data, you know, from the server, for example, to your machine  in order, well, for the application to then live on your machine rather than, you know,  on the Internet.  It also doesn't, Flatpak also doesn't do sandboxing itself because it uses bubble wrap for that.  Bubble wrap is a project which creates a sandbox, a confined environment where the applications  can live in and where they can hopefully, well, not cause any harm for the host system.  And what Flatpak essentially does is it connects you, it connects all those bits and pieces  and gives you an application delivery mechanism, an ecosystem where you can make your application,  where you can bundle up your application and have users download this application conveniently.  So the security properties of Flatpak are coming from bubble wrap, as I've said. Bubble  wrap is a Linux tool. It makes use of Linux. So any Linux you have, the Linux program,  the Linux kernel, you can use with bubble wrap. And bubble wrap makes use of all these  modern, nice and fancy kernel features like namespaces, cgroups and secon. Basically what  you have is a change route. That's the, like, very old traditional security feature of Linux  where you can confine a process to a certain directory on your file system, basically.  But it is changed route on steroids. It uses all these other fancy things to, well, to  make it more secure still, but also to enable you to punch holes in two or through the sandbox.  So the sandboxing facilities is what I call the classic security features. You know,  these are classic, classical Linux ways to confine processes, well, in order to limit  them in their potential harm that they could do. You know, by bind-mounting stuff read-only  into the namespace, you prevent things, you prevent the application from being able to  overwrite data. By not mounting things into the namespace, you prevent the application  from being able to read data, well, out of the system. By using cgroups, you prevent  the application from hogging all your resources. These are all relatively classic ways of making  things more secure. And Flatpak, you know, uses all that conveniently without you having  to care about any of these things. Yet, I've said something like, well, you need to interact  with your environment because that's probably what desktop applications do. So you can punch  holes through the sandbox. You can, you know, interact with your, say, X server, with your  audio demon, with your debus. You can do all these things by punching holes through the  sandbox with, you know, with bubble wrap. You can give it certain arguments and it'll  allow you to do stuff that you are not able to do by default. By default, if you call bubble  wrap, you get the most restrictive environment possible and you may want to open up the sandbox  in order for you to be able to interact with the rest of the system. You might want to  complement that though with a more modern approach to security, which, well, we call  portals. These portals are interactive means to get to know the intent of the user. Because  I think this is one of the core features of these modern security solutions. The core  thing is to get to know the intent of the user. You know, you need to find out what  the user actually wanted to do. You know, if I open the chat application, it's relatively  reasonable that I want to start chatting now. So, you know, as you've said, the user goes  to some extent, the user tries to make it possible for the application to do exactly  that. And by having interactive portals, interactive dialogues prompts to some extent, we try to  find out what the intent of the user was. Now, what is such a portal? Such a portal could  be open something with an application, in this case, upper left like which application  do you want to, you know, open this URL with? Or we have a printing dialogue. If you press  print, then you're being asked what printer do you want to use. These are all relatively  classic things, right? People know these already. And we're using these mechanisms to find out  what the user wanted to and then let the action, you know, permit the action. So, we can poke  holes through the sandbox with these portals to allow privileged operations like printing,  but without surprising the user. There's no, we're prompt like, do you really want to print  now or something? We are reasonably sure that the user wanted, you know, to print because  the user selected the printer. And only then, if we select the printer, the sandbox will  be, will be allowing the application, you know, to print the thing. And once the dialogue  is gone, the application cannot connect with the printer anymore. So, we're also using  these portals as a temporary mechanism to allow access, you know, compare that to say  Docker where you can either give and grant access all the time or you cannot because  you cannot dynamically adjust the permissions of the application. With this interactive  model, we can do that. And I think it's good. And I think it's great. And I think we will  see much, much more, well, hype and ramblings around this technology because I do think  it's great. I think it's enabling us to do things that we weren't able to do before in  a much, much more secure way. So, this is the second thing. Let me quickly do the third  thing before we enter the Q&A. Yeah, and then we're good. So, another thing that I am personally  concerned with is USB. So, in my previous life, I was assessing the security of USB.  And I found out that the, well, just having the port open on your machine opens a relatively  large attack surface. Essentially, what an attacker could do is load any, pretty much  any kernel driver that you have on your, like, machine. And if you're installing any random,  you know, Ubuntu or Fedora, you have every kernel driver there is on your machine. And  the attacker is able to interface, to interact with this, with any of these drivers at their  will. It's quite scary if you think about it, if you think about that.  So the question I think that drove me was, when do you use your USB? And most importantly,  when do you not? You know. And then, if you're not using your USB, who else uses your USB?  And why are we actually allowing the USB port to work when we are not, you know, even being  able to use our USB because we are away, you know? When I'm locking the screen, why does  my USB port work? Why does my machine allow an attacker, or, I mean, any person really,  to interact with all these Linux drivers when I'm not even here and touching the machine  when I'm on the toilet or anywhere else? I don't think we have a good reason for doing  that. And USB is an attack surface. It's relatively well known that, you know, if you're exposed  to your USB, then you get, well, you might have trouble. You know, there have been incidents  in the past and there will be more incidents in the future that make use of the USB port.  And I think one easy fix is to, the easiest fix is to, you know, just use some glue and,  you know, fix up your USB port and then nobody can ever, you know, plug anything in. Of course,  that's not where we are coming from in the GNOME project. We can do that. We can block  and unblock the USB in software and we would see a video with my graphics driver worked,  but it doesn't and it's also not too bad. What we would see here now is some software  which disables USB for a certain device, you know, not, sorry, not device, it would disable  USB for a certain class, sorry. So you would not be able to load any, say, CD-ROM drives,  you know, any external media because, especially keyboard. Especially keyboard is the common,  especially not keyboard, I'm afraid, because you will want to allow keyboards in any case  because your keyboard might break. But that's, you know, details, again, that requires you  to have this inclusiveness mindset to be able to find out what you need to allow and disallow.  Right. Right. So the comment was there, there were attacks simulating keyboards and that's  certainly correct. That's absolutely right. Yet, from a technical perspective, these attacks  were quite boring. They were not, you know, interfacing with any random kernel driver you  had and they were only as powerful as any regular keyboard, which in itself is, you  know, quite bad. But if I'm on the toilet and my machine is locked, then I'm fine with  that. You know, the keyboard can, the worst thing the keyboard could do is, you know,  go through passwords. That's already quite bad, but it's not as bad as, you know, the  machine being compromised because it would load the file system driver for, now name  any ancient file system that would automatically, you know, be mounted if I plugged in a pen  drive and all. So, but yeah, there's issues around that. We cannot simply disable USB  when the screen is blocked, although it would probably be already better than the status  quo. You know, right now if you have a machine and you plug in USB, your Linux kernel would  happily load any random driver that my fake USB device would, you know, make you load,  make you to. And it's quite scary actually.  Right. Right. Right. So the comment was, can you not control how many keyboards, you  know, can plug in? And I say yes. It's, you can think of a solution like that. I think  it's, I think it's a bad solution though. I think from a, from the user experience perspective,  it's hard to communicate that you can plug in two, two keyboards but not three. It's  somehow difficult.  You couldn't make prompts to trust.  Right. You couldn't make prompts to trust any device. Yes. I would not use prompts though.  I would probably somehow show something like, oh, we've detected a new device. Do you want  to make use of that? Not with a prompt though. And then if you click, yeah, please set up  my devices, then you would get your list of devices and you could then, I don't know,  maybe swipe the device to the left or to the right if you want to make use of it or not.  Something like that. Or the best case, I think, is to only allow devices if you have an application  started. You know, imagine, and now we have the technology. Slowly we start to having  this technology. With Flatpak, we have tight control over what applications are doing what  with our environment. And why would I load a camera driver? Why would I make my Linux  kernel load a camera driver if I'm not having an application open that uses the camera?  You know, it's, I don't think it makes much sense to have my Linux kernel do that. With  Flatpak, we can potentially determine whether we have an application using the camera and  only then make the kernel use or load the camera driver. And I think we have many more  things to explore in this area. And we would see some videos which would show some automation  around these things. It's very experimental, though. So I've shown you software or ideas  in various stages. I've shown you the key-signing stuff which is sort of in beta stage. You  can use that already now. These screenshots were not drawn. They were live. I've shown  you the Flatpak stuff. It's quite production ready already. If you, you know, do app get  install Flatpak, you get all this Flatpak stuff, you can start applications now and  you can, you know, do real things with Flatpak just right now. And if you develop applications,  you should package it up as a Flatpak and put it up on FlatHop so that other people can  use your latest and greatest application as Flatpak. And I've shown you the USB stuff  which is very experimental and is more in a research phase. And it also allows, you know,  for contributors like you to engage in this sort of discussion and make this real and  usable and protect users from, you know, attacks via the USB port. And I'm way over  time already. This is also because we had a great discussion. And nonetheless, I want  to close it now and of course I'm available here, but for the Internet, we're closing  it down and I thank you very much for your attention.  Thank you.
froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_0_59.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_60_287.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_288_911.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_912_3731.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_3732_4223.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_4224_5063.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_5064_5231.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_5232_6539.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_6540_7235.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_7236_7679.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_7680_8183.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_8184_11111.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_11112_11243.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_11244_12767.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_12768_13607.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_13608_14723.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_14724_15107.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_15108_18227.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_18228_18383.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_18384_20087.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_20088_21635.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_21636_33719.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_33720_34931.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_34932_35183.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_35184_36119.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_36120_41531.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_41532_41603.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_41604_41651.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_41652_46883.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_46884_49823.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_49824_50387.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_50388_51323.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_51324_51395.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_51396_52127.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_52128_54563.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_54564_55055.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_55056_55379.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_55380_55811.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_55812_56495.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_56496_58499.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_58500_59171.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_59172_59219.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_59220_59579.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_59580_59699.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_59700_59939.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_59940_61427.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_61428_61859.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_61860_62747.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_62748_63527.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_63528_63995.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_63996_65435.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_65436_66887.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_66888_68015.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_68016_68123.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_68124_70379.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_70380_70619.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_70620_71291.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_71292_72071.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_72072_72119.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_72120_73379.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_73380_74915.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_74916_75179.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_75180_76115.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_76116_76679.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_76680_77003.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_77004_77471.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_77472_78011.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_78012_78167.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_78168_86015.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_86016_86231.png froscon2017-2039-towards_a_more_secure_operating_system_without_sacrificing_usability_86232_86255.png
Hi, everybody. I'm Toby and I'm a GNOME person as you can see and you're here in the GNOME talk. In case you wanted to go anywhere else, now is your final chance to sort of find the right room. Otherwise, I'm happy to entertain you for the next 45 minutes to an hour depending on how much we engage. I'm very happy to engage. So, in case you have sort of any question or in case you, you know, want to discuss anything or if there's anything unclear or you don't understand me very, very well, then please, you know, make yourself heard and we get these things sorted out. Is there anybody not understanding German? Is everybody speaking and understanding German well? You're like raising your hand. Does that mean that you are speaking German or that you are not speaking German? All right. Good. So, does that mean we can actually proceed in German? Okay. How Well, that's how it works and how the GNOME project thinks and how I believe that the GNOME project ensures that we have a safer computing in the future. And I think that GNOME is a very good place for us to bring a safer computing environment. And I would like to convince you a little bit that GNOME is a project that I take care of and what it does well in my opinion. I brought a few case studies with me. I have a few examples that should show that it is exactly committed in this area. And I would like to introduce them to each other and we will fold them apart. So that you keep that in mind that we will see three things that I will introduce. And yes, I will start with a little bit of what is basically to say to GNOME. The GNOME project has written a few things on the road for which it is and for which it is sustainable. And I think a central point of this principle, of this basic value of GNOME is the software for as many people as possible to write. And to ensure that as many people as possible are in the position to use GNOME software and to allow as many people as possible to use their computing. And the extension of this concept is that the GNOME project is responsible for the user experience in the hands. That is now a slightly abstract concept. So what does that mean? It is already user experience. That is supposed to mean that the software as such does not stand on the road with its tasks. And the GNOME project believes that the people use their computer, that the people do the computing because they have a job to do and not because they like to sit on a computer. So the whole mindset is always about which task the user has potential if he uses his or her computer. And how can you create this task as pain-free and fast as possible? And before this background, a few things happen in the GNOME project that I think are most successful. Of which are the translations. So GNOME wants to make as many people able to use their computing. And to do that, GNOME says, I should probably switch back to English. That is no problem at all. I was actually initially offering to continue in English. But no problem. Then we continue in English. That is perfect. Absolutely no problem. So there are many things happening in GNOME. And one of the more successful things I think is the whole story around the language issues involved with people not necessarily speaking English. We in GNOME, we have a quite successful translation story. When there's a new GNOME release upcoming, we have many, many languages being translated. We have the GNOME software being translated in many, many languages in relatively short time. And this is not only a single. This does not only happen a single time, but has happened over the last, I don't know, 80 years or so with GNOME software that we have constant efforts in enabling, well, also non-English speaking people to use, well, to do their computing with free software and especially with GNOME. We also tried to be inclusive. The keyword I had two slides ago was inclusiveness. We extend this term, or we also understand in this term that we enable people who have different, say, physical needs. So we try to make GNOME as usable as possible in the sense that we try to make it easy for people who have different, say, who have needs for different, say, input methods or different reading methods who people who cannot necessarily, you know, read a regular screen because they have some physical challenges to deal with that, well, requires, say, dedicated hardware or, say, color tinting of the screen, these things. We try to think of these, well, issues and we try to make software which enables as many people as possible to use, well, free software. And we take, again, we take responsibility for the user experience for the whole system. We try to remove issues, say, in the stack and do not paper around, you know, bugs. That is, that's becoming visible when we're dealing with things like, say, Bluetooth or with graphic stuff. We don't just, you know, stop at, say, relatively high-level boundary of being, like, in user space and being the software that draws some icons and windows, if necessary, we dig deep down in the stack and fix things as deep as in the kernel. So we want to be as inclusive as possible, as I've said. This is one of the core things that drives GNOME. The other thing that drives GNOME is freedom. Now freedom is a, freedom, the term in itself is quite abstract. But the G in GNOME is GNU, right? And the GNU project is the, well, Godfather if you will, if you will, free software. And as we are on the, on the letters of GNOME, does anybody know what GNOME actually stands for, the acronym? It's a couple of letters, right? Does anybody know by any chance? Exactly, yes, GNU network object model environment, GNOME, right? And as I've said, the G in GNOME is GNU. And so we, of course, are dedicated to software freedom. And software freedom for us essentially means the four core freedoms. Does anybody know the four core freedoms that free software is about? Throw in some guesses. Freedom to use. That's freedom number zero, yes, the freedom to use. Yes, that's actually two, the freedom to, you know, share with your neighbors, to help your neighbors, and the freedom to improve. And there's like another freedom, sort of a prerequisite for these. Freedom number one. The freedom is kind of. Sort of, yes, in order to do that, you have to understand the software. You have to, you have to be able to study how the software actually works. So these are the software freedoms that GNOME is concerned about also. But there's yet another freedom, or I claim there's another freedom. I claim there's the freedom of you being able to use your computer without, you know, risking of being compromised, without you having to be concerned about your communication to be, well, wire tapped into. You want to, you know, do your task on your computer without having to fear that, I don't know, bad things will happen. And I think the GNOME project, or we at GNOME, we're in a good position to enable these, or to deliver these expectations, or on these expectations. Because as it turns out, that filtering out of external information is one of the basic functions of consciousness, according to Barry Schwartz, an American psychologist. And I think we at GNOME, we are quite good at concentrating on the, say, necessary things. And sort of highlighting the things that are, you know, important and making the other things less, say, visible or intrusive. We, as I've mentioned in the beginning, we try to, you know, enable people to do their tasks to make the software that does not stand in your way of, you know, you being successful in performing whatever you set out to do in your computer, with your computing. So we shall try to make decisions, you know, for you as the user, as easy as possible. And we should try to focus on things that are necessary indeed, and do not, say, show things that are maybe not so necessary. And regarding the security of your system, or if you translate that mindset to the security of your system, we end up with, you know, removing the user from the equation of the security system. Because there have been studies which have shown that if you let users take decisions on security-relevant questions regarding your system, you may as well roll the dice, because the user is, well, cannot comprehend the consequences of certain security decisions. And I'm now bringing some examples of, well, these sort of decisions that I think users cannot, well, make in an informed manner in order to sort of convince you of this fact, say, and to lay the foundations for our work at GNOME to make the security system sort of built in without the need of user interaction, or with as little user interaction as possible. I'm claiming that we are seeing problems every now and then, and the problems in general are a dubious feature or a dubious way of, you know, interacting with the user. What are prompts? Proms are these modal pop-ups that come out of nowhere that, you know, stay for as long as you click either option and that force you to take a decision just right now. Probably while you're doing stuff, you know, you're probably in the middle of performing some task, and then you get one of these prompts. You know, you get a modal dialogue. You cannot walk around the dialogue, you have to, you know, do something with the system right now, or you can continue your work. And we think that these prompts, well, are not a good way of dealing, of interacting with the user. These prompts have been quite popular, you know, like a few years ago. You don't see them so much these days anymore, also because people have realized, people making software have realized that prompts are a cheap way of interacting with the user, but not an effective way of interacting with the user. Security prompts are just plain wrong. You must not, you know, build software, security-relevant software which prompts the user. You must just not do that, and you must especially not produce prompts which make a permanent decision, you know, where the effect of the user interacting with the prompt is permanent, where it's not, you know, a one-time decision, but where the answer of the interaction with the user is being stored for future interactions. And why is that? I claim that this is very bad and actually wrong because the user is on the middle of performing a task, and of course, you know, the user want to perform the task. So the user does everything he or she can in order to get back to the task, you know, to the application to continue with their work. And one of my most sort of beloved prompt is this, you know, this prompt is now showing this connection is untrusted. Do you really want to continue? Do you really want to connect? And you know, the user, imagine the user. The user just opened the chat application or browser or, you know, whatever is networking or is performing a network connection or is opening a network connection somewhere, and I mean, the user has expressed the intent to have this application, you know, connect to the internet or do whatever the application wants. And of course, I want to continue. Why on earth would I have opened the application in the first place? And now you can, well, claim, you know, there's some value to this prompt. I mean, it's not that this, that the application developer would have thought of putting prompts, you know, in random places just to annoy the user. Of course, the application developer had a, you know, to inform the user of the connection being somewhat dodgy at least. And you know, how do you handle this situation? Well, the cheap way is to issue a prompt and then let the user decide. I think we must not do that. I think we must, well, in this very case, I think we must just terminate the connection or maybe offer a settings dialogue where we can configure the connection and then while setting up connections, then, you know, have this sort of information being processed. But not, you know, when the user opens the application and potentially wants to start, you know, chatting with someone, then we get this dialogue. This is not cool because the users want to perform tasks. And if we issue these prompts, then users will be interrupted in the task that they want to perform and they will potentially click continue because that's what they want to do. They want to continue. I mean, they don't want to cancel. You just rarely say, oh, I actually just in the last 20 milliseconds, I decided otherwise I do not want to open the chat application. Of course, there's some applications which are less sort of easy to handle. And the way to remove these prompts must involve researching a way to guide the user to still provide the same, say, functionality because as I said, the application developer has the problem now of what to do in this situation, right? The application connects to somewhere. There's a problem. What shall the application do? It's not necessarily clear. And the way to get rid of prompts is to research how to, well, provide a user interface, a user experience to still allow the application to be able to decide what to do and yet does not disturb the user in their tasks. And there's ways around that. And we at GNOME, we do many of these without, hopefully without you even noticing. A prompt that is somewhat funny is this one. Like this software is not signed by trusted provider. Ooh, trusted provider. What does that even mean? The software is not signed. It's yet again the same text. And do not update the package unless you really are sure that it's safe to do so. And this is so much information. And I claim that if you ask counter people on the streets what they would do if they get this dialogue, you could as well have rolled the dice in order to get the decision. I mean, imagine again, imagine the situation where this dialogue comes up. You're probably in your software update program or whatever. And then you have clicked update. Please update all my packages. And then you get this dialogue. And you probably know, you know, how to deal with this situation. You probably can comprehend what's going on behind the scenes. But you're quite a specialized bunch of people I have to admit. Because you've probably, well, had the fortunate opportunity of having a computer science education. You've probably heard about the, you know, issues involved with people manipulating your package store and manipulating packets on the fly, you know, when you're downloading stuff and all. But I claim that most people that we try to, you know, provide with free computing do not have had this fortunate opportunity of having had a computer science education. So this is a, I think this is one of the worst problems that we could possibly have. Because this, if you click now, force install, the, right. So it's like, you know, this is bad on all terms. Like, oh, sorry. Please, oh, please, so the comment was that this prompt does not even tell you what software this is about. And yes, it's quite a bad problem. And it doesn't exist anymore. I mean, I have to admit this is, I needed to pull this out of historic releases because I mean, it's 2017. We tried to improve, you know, on each and every release. And if this was still live, then I would probably not be here because I should rather fix these things. So these do not or should not exist anymore. Another very well concerning dialogue is this. Albert found a new update which fixes your problem. Please run before submitting a bug. PKcon update. That's just repredecent able equals Fedora and so on. Okay. All right. It's probably six past six we have to go. Oh, please wait. The system is being shot down. Okay. Okay. Unluck it up. There's a prompt. Okay. Unluck it up. Yeah, fair enough. Well, try to, you know, find a way of enabling the same functionality like still enabling the application, you know, to take the decision but without the actual prompt. And it's a hard subject. And it's not, you know, that there would be an easy way to do so. And there's no obvious way for each single prompt, but there is ways. Right. So the chat application, well, let me roll back just one and a half steps. There are some applications that are quite special, I think. For example, a web browser is quite special. Web browsers, because web browsers are so, by now, there are, there are, there are a lot of web browsers that are in application platform. So it's, there's no single purpose. It's not a single purpose app. The chat application on the other hand is more of a limited purpose app. It only does the chat thing. And for the chat application, my recommendation, my recommendation now that sounds funny as if I was the inventor, but if you look at other chat applications, what they do is when you set up the application, when you set up the accounts, then you get the sort of request as to whether you want to use this sort of connection information, including the certificate or not. And then in the future, if the certificate doesn't match what you set up, then the connection just doesn't, you know, establish. And there's no prompt. You may get something like connection error, please review your security settings or something. And then you, you know, get the, but without a prompt, but more like an informational thing in the content area of your application. And then by pressing this button, you get to the settings. And then you also know where these things are configured for the future. It's not a one-time thing, but you get to the general settings page where you can then set up the application. Right. Exactly. Yeah. Right. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Absolutely. So, the routing would probably be to guide the user to protect the server administrator or whatever, probably doesn't know that it's so stupid to be part of this part of the topic. Maybe it's a hard problem, yes. I give you that. And if there was an easy fix, we wouldn't have had prompts in first place. The prompts exist because there were cheap4plications developers to do. And what I claim, what makes GNOME a bit different from others say environments is that the GNOME people, well, tend to give these issues a thought at least. And they try to come up with ways to enable, you know, the functionality still, but without interrupting the user as badly as with their prompt. Maybe, you know, there's still a prompt, but maybe it's a, in that case, it probably wouldn't be as bad or as severe as these prompts that we've seen. You wanted to say something? In most cases, such prompts are probably configuration issues and not real security phase. But as a security-interested user, you may bother if a client just connects and gives a small hint because there's already information, transmitter, that are sensible and you couldn't prevent that. So the first part that I got was that most of these things are configuration issues, not necessarily security problems per se. And the second part was too long for me to comprehend because it's quite late. And the last slot of the conference, it's been an amazing 20 hours of soft conference and I'm quite drained by now also mentally. So please repeat. You said you suggest the chat app to just reconnect even if the certificate changed and give the user a small hint that it changed. So the comment was that I was recommending the chat application to connect anyways if the certificate changed. But that's not what I meant at least. I hope it's also not what I said. I said the connection should not be established in any case. Just not. You just not connect. I mean, you just don't because it's not what you set up before. The chat application would probably ask you to set up your credentials in first place, you know, in the initial setup phase. And let's encrypt, for example, it's normal that certificate changes frequently. Right. And in let's encrypt, it's also normal that you have a common root certificate and intermediary which always stays the same. And I mean, if we are talking TLS, then you probably have a TLS credential store and we should of course make use of that. The problem in 2017 still is that these credential stores, these root CA stores are a bit messed up. We have in New Linux, we have no unified way of managing these. But again, GNOME is working on that. There's P11 Glue, P11 Kit which has like some glue code to unify these credential stores because you have several. You have OpenSSL, has their own stuff in somewhere in Etsy, SSL somewhere. You have Firefox which has their own stuff. You have Potentially Thunderbird which I think has their own root store still. And you have probably various other apps who ship their own, pardon me? Java. Exactly. Java has their own key store as well. And you have all these, well, ecosystems which ship their own X509 stores for no good reason really other than that nobody sat down and like worked on unifying that. But again, GNOME is I think one of the few people, also the Fedora guys have an interest in having that unifying. But GNOME is one of the, is involved in getting this sort of fixed and cleaned up. And this again, I attribute this to GNOME being concerned about the user experience and goes down the stack if necessary. This one instance. So yeah, it's not an easy, these are not easy issues. And again, we need to think about that. And again, I think GNOME is one project who does, well, make efforts in thinking about these, please. So how does GNOME approach the developer of this application to improve the user experience? So how does that work? How does GNOME like prod the application developers to make things better? That's what you came up with because you had no better idea. So the easy answer is, well, it's GNOME applications, GNOME just fixes it. That's the ideal case. The GNOME desktop, usually when I give this talk, I spend at least five minutes and asking the people what do you think is GNOME and what does GNOME involve and everything. And then we sort of make straight that GNOME is a desktop environment. That's what people come up with relatively easily. But then what does it mean? Then it gets a bit tougher. GNOME is also a set of applications. And we ship, I forgot the exact number, but it's a relatively large number of applications that we have under all control and that we want distributions to ship along or that they ship with what they call GNOME. And we hope that, you know, if you install GNOME that you get a nice and working and fully sort of suited environment to do your computation. Of course, if it's third party applications, then I mean, at the end of the day, we are out of the game. We can only suggest fixes and if, you know, nobody accepts them. People do. I'm not entirely sure, like, in the chat application regarding things like chat applications. But what I know is that we are concerned with the GNOME forks, you know, the Mate and the M&M, all of them have forked the GNOME code and are sort of changing some strings to not show events, but I forgot the name of the other apps. And if we have fixes, important fixes on our end, we go the extra mile and, you know, inform the other projects and create pull requests for these important fixes. So we do that to the limited extent that we are sort of capable of doing. So we do that to the limited extent that we are capable of doing. And we do that to the limited extent that we are capable of doing. So the question was that with the chat application example, when the user wants to, you know, chat with someone, then it doesn't matter much whether the user gets offered a prompt or some other way of, well, actually, right, you know, the exact way of how the user actually gets to connect doesn't matter because the user goes to, you know, whatever extent necessary to make the connection happen. That's where it becomes. So what's the value of not having prompts? So let's take a question. And the one thing is that in the chat application thing, you might be tempted as an application developer to have this permanent decision thing. If you don't offer this permanent decision in the first place, then you, well, do not risk that the user forgets about or that the user has a chance of reversing the decision in case the user realizes that it was a bad decision. Of course, you get the same effect still with the revised user interaction. I mean, if the user sets up a bad connection, then the connection is bad, sure. But hopefully in the process of doing so, the user also gets to learn how to, well, set it up correctly, you know, in the future in case the user realizes, oh, I've set up the connection wrongly. Now everybody can read my data. This is, well, if you let the user do that, if you give the user the opportunity to do that correctly, then the chances are higher that the user will do it correctly. With the prompt, there's no way you can answer the prompt in a good way because if you select no cancel, then it's not good because the user cannot chat. If you let the user select yes, then it's bad because everybody can read the data. So there's the prompts. There's no good thing about the prompts other than that it's cheap for the application developer to do. But in an alternative way, I mean, it's not 100% good, but it's at least a little bit better in the sense that it's the, maybe, the proper way of setting up a connection and the user can undo the wrong thing that the user did before. But I don't claim there's, you know, the best way of handling the things. I'm claiming, though, that we have better ways than the prompts. But the alternative way of, in the chat application example, I think is a little bit better because, you know, the user learns how to undo things, the user learns how to do things once, and they're valid instead of they're valid sometimes, and sometimes they're not valid when I click cancel or OK or so. So I think mentally it's a bit easier to comprehend that the things that I have in the setting thing are valid, whereas with the prompt thing, the things in my settings dialog are only valid sometimes. OK. So there is another inherent, let's say, law or its attribute to Ellison from some USINX conference from 20 years ago. And this law says that for every click or keystroke required for a security feature, the user basically climbs by half. So if we, you know, make the user do something actively in order for the security to be there, then, well, our system is not as good as if the security was there without the user having to do anything. So we should try to, you know, have built systems which require as little interaction but are still secure, whatever secure means in this context. So these are the sort of, this is the mindset where we are coming from in the GNOME project in general. And now I've promised I'm bringing some case studies and bringing some examples of how I think we do that. And one example is this. Does anybody know what these people are doing? Has anybody ever seen that? It's like a bunch of people standing around. They're like having some sheets of paper and everything. Has anybody ever seen that? A what? It's a key signing party. What is a key signing party? It sounds fun. So what is a key signing party? Right, so the comment was that these people share the keys so that in, like after the fact they can communicate securely. They're building developable trust, very correct. How do you do? Do you understand keys after the talk? I do. You can use this fingerprint because this is what people do. They utter fingerprints to each other. These are 160 bits of information and these people, in the worst case, they're like uttering these bits of information like towards each other. And these are 240 people in these, like in this queue. And this is the typical format of what people deal with, like this is a hexadecimal string, 160 bits of information, the shaman hash of the open PGP key, and people read this out to each other and then they claim to verify identities and all. So you've taken part, you've participated in a key signing party. What do you do after you've stood for three hours in Brussels in January because it's past them time and it's minus two degrees and it's snowing and you get home with your cold and cough. What do you do then? If you put it in your key store so you can use the unit. All right. So you put it in your key store so you read this hexadecimal data of your piece of paper. You're not sure if you're reading A, B, or A or something. And then you transfer the data to your key store, you say, and then you eventually produce signatures, right? And how do you produce signatures? You probably use CAF. CAF is like the tool to use when you're producing signatures. This is the pinnacle. This is the gold standard as of now. It doesn't get any better than using CAF. And CAF is a pearl program. There's nothing wrong with pearl. I mean, people like it or dislike it, doesn't matter much. And in order to configure CAF, you write raw pearl. So if I wanted to use CAF with my parents, say, I not only need to ship a book about OpenPGP and security and everything, I also need to ship a book about pearl because my parents would need to learn pearl in first place before they are able to do the whole key signing stuff. And you could think, if you're mean, that there's like a big conspiracy around the sole OpenPGP security thing because we're using all this weird stuff like Bay 16. Because I haven't even asked you, what do you think I do that because it's a bit fun? How do you think you can communicate 160 bits of information in the least efficient way possible? So you have 160 bits of information on your piece of paper and you want to get that across by uttering something. How do you get 160 bits of information across in the least efficient way possible? What would you do? Finally, you would use base two encoding of the data. And then what you think is the second least efficient way of transferring 160 bits of information via utterances? Base four. Well, base four, you could do that. You could base three, base four and all. Nobody does that. The base eight would probably be the next one, but it's also a bit weird. The next thing would be base 16. It's quite an inconvenient way of sharing this information, but yet people somehow like it and all. And we have this, I get interonting. I get excited. It's not so good. We have loads of problems with the whole infrastructure around because how do you get the, how do you put the key into your key so in first place? Right? You go to the internet and get the key, right? Because how else would you obtain the copy of the key? And where do you get the key from? From a key cell, all right. A key cell was written in OCaml. I know quite a bunch of people. I don't know. I've been around the Free Software community for a long time and I know many people who do programming and all. Yet, I know exactly three people, I mean, knowing how to program in OCaml. It's this weird French dialect from the mid 1600s that by now only three people are able to write programs in. So we have this, everything is a bit weird around this old crypto stuff. And I claim it's a little bit due to the fact that these security people, they mostly are concerned with themselves, which is fine. Free Software people usually scratch their own itch and it's a perfectly valid reason to develop software. But I think we'd be living in a better world if we targeted, say, my parents for using the security things. And again, I think GNOME has a good mindset to actually deliver on that. And I'll quickly show some examples of how I think we could make things better regarding this whole key signing mess, if you will. So how about we have an interface that allows you to select your own key, you know, you get a list of your keys, and eventually you select one, and then you get some machine readable information that you can use with the other party who actually wants to sign your key, that other party would eventually, you know, make use of the machine readable information, then somehow the application would make sure that the key is being transferred in an authentic way so that nobody could have tampered with the key in transit. And then maybe, you know, all it takes is a click of a button and the key is signed. Wouldn't that be awesome? Turns out you can do that already now, more or less, with the application GNOME key sign. And I think it's a, I think it shows how you can, you know, make things better that have been the way they are for 20 or more years, you know, with just the mindset of trying to be not intrusive without, or with trying to be as inclusive as possible, with trying to enable as many people as possible to make use of the, in this case, security system. I've brought a video, but let's skip that and go to something, talk about something that's much more exciting, containerization of applications. We have all the rage now about Docker and images, and now is people talk about Snappy and Flatpak and App Image. And we do that too. So we have, in the GNOME project, we have concerned ourselves with the question of how do we confine applications so that they cannot do harm in case they are being exploited, you know, to be able to mitigate the facts of a compromise. And now you might say, oh, well, just use Docker, right, as a Docker has been around for what, three years or something now or four by now, and, you know, just use that for your application, bundle up everything in one of those images, and then you're good to go. You might be able to do that, but you quickly run into problems if you're wanting to do desktop applications, you know, not as opposed to server-side applications that get along without any interaction. If you're having desktop applications, it's likely that it needs to interact with, you know, not only the system itself, but also with the periphery, like with your printer or with your, I don't know, your sound card or with your camera or something. So you cannot just use, you know, any existing containerization technology because you will need to interact with the rest of your environment somehow, or it's relatively likely that if you're building a desktop system that you will need to interact with other parts of not only the system, but also your environment. So we have Flatpak. Flatpak is a new way of distributing applications in new Linux. So we are, say, not limited to all Linux systems running app-amo, for example. Right. So the question was whether Flatpak is only usable in Fedora, and the answer is no. It's not, say, snappy where you need this app-amo module in order for it to work properly. Flatpak is a technology which basically ships your image. Flatpak itself is only a cool way of distributing your OS free images. So actually Flatpak itself doesn't even do that itself. It doesn't even distribute the image itself. Flatpak only calls or makes use of OS free in order to ship the data, you know, from the server, for example, to your machine in order, well, for the application to then live on your machine rather than, you know, on the Internet. It also doesn't, Flatpak also doesn't do sandboxing itself because it uses bubble wrap for that. Bubble wrap is a project which creates a sandbox, a confined environment where the applications can live in and where they can hopefully, well, not cause any harm for the host system. And what Flatpak essentially does is it connects you, it connects all those bits and pieces and gives you an application delivery mechanism, an ecosystem where you can make your application, where you can bundle up your application and have users download this application conveniently. So the security properties of Flatpak are coming from bubble wrap, as I've said. Bubble wrap is a Linux tool. It makes use of Linux. So any Linux you have, the Linux program, the Linux kernel, you can use with bubble wrap. And bubble wrap makes use of all these modern, nice and fancy kernel features like namespaces, cgroups and secon. Basically what you have is a change route. That's the, like, very old traditional security feature of Linux where you can confine a process to a certain directory on your file system, basically. But it is changed route on steroids. It uses all these other fancy things to, well, to make it more secure still, but also to enable you to punch holes in two or through the sandbox. So the sandboxing facilities is what I call the classic security features. You know, these are classic, classical Linux ways to confine processes, well, in order to limit them in their potential harm that they could do. You know, by bind-mounting stuff read-only into the namespace, you prevent things, you prevent the application from being able to overwrite data. By not mounting things into the namespace, you prevent the application from being able to read data, well, out of the system. By using cgroups, you prevent the application from hogging all your resources. These are all relatively classic ways of making things more secure. And Flatpak, you know, uses all that conveniently without you having to care about any of these things. Yet, I've said something like, well, you need to interact with your environment because that's probably what desktop applications do. So you can punch holes through the sandbox. You can, you know, interact with your, say, X server, with your audio demon, with your debus. You can do all these things by punching holes through the sandbox with, you know, with bubble wrap. You can give it certain arguments and it'll allow you to do stuff that you are not able to do by default. By default, if you call bubble wrap, you get the most restrictive environment possible and you may want to open up the sandbox in order for you to be able to interact with the rest of the system. You might want to complement that though with a more modern approach to security, which, well, we call portals. These portals are interactive means to get to know the intent of the user. Because I think this is one of the core features of these modern security solutions. The core thing is to get to know the intent of the user. You know, you need to find out what the user actually wanted to do. You know, if I open the chat application, it's relatively reasonable that I want to start chatting now. So, you know, as you've said, the user goes to some extent, the user tries to make it possible for the application to do exactly that. And by having interactive portals, interactive dialogues prompts to some extent, we try to find out what the intent of the user was. Now, what is such a portal? Such a portal could be open something with an application, in this case, upper left like which application do you want to, you know, open this URL with? Or we have a printing dialogue. If you press print, then you're being asked what printer do you want to use. These are all relatively classic things, right? People know these already. And we're using these mechanisms to find out what the user wanted to and then let the action, you know, permit the action. So, we can poke holes through the sandbox with these portals to allow privileged operations like printing, but without surprising the user. There's no, we're prompt like, do you really want to print now or something? We are reasonably sure that the user wanted, you know, to print because the user selected the printer. And only then, if we select the printer, the sandbox will be, will be allowing the application, you know, to print the thing. And once the dialogue is gone, the application cannot connect with the printer anymore. So, we're also using these portals as a temporary mechanism to allow access, you know, compare that to say Docker where you can either give and grant access all the time or you cannot because you cannot dynamically adjust the permissions of the application. With this interactive model, we can do that. And I think it's good. And I think it's great. And I think we will see much, much more, well, hype and ramblings around this technology because I do think it's great. I think it's enabling us to do things that we weren't able to do before in a much, much more secure way. So, this is the second thing. Let me quickly do the third thing before we enter the Q&A. Yeah, and then we're good. So, another thing that I am personally concerned with is USB. So, in my previous life, I was assessing the security of USB. And I found out that the, well, just having the port open on your machine opens a relatively large attack surface. Essentially, what an attacker could do is load any, pretty much any kernel driver that you have on your, like, machine. And if you're installing any random, you know, Ubuntu or Fedora, you have every kernel driver there is on your machine. And the attacker is able to interface, to interact with this, with any of these drivers at their will. It's quite scary if you think about it, if you think about that. So the question I think that drove me was, when do you use your USB? And most importantly, when do you not? You know. And then, if you're not using your USB, who else uses your USB? And why are we actually allowing the USB port to work when we are not, you know, even being able to use our USB because we are away, you know? When I'm locking the screen, why does my USB port work? Why does my machine allow an attacker, or, I mean, any person really, to interact with all these Linux drivers when I'm not even here and touching the machine when I'm on the toilet or anywhere else? I don't think we have a good reason for doing that. And USB is an attack surface. It's relatively well known that, you know, if you're exposed to your USB, then you get, well, you might have trouble. You know, there have been incidents in the past and there will be more incidents in the future that make use of the USB port. And I think one easy fix is to, the easiest fix is to, you know, just use some glue and, you know, fix up your USB port and then nobody can ever, you know, plug anything in. Of course, that's not where we are coming from in the GNOME project. We can do that. We can block and unblock the USB in software and we would see a video with my graphics driver worked, but it doesn't and it's also not too bad. What we would see here now is some software which disables USB for a certain device, you know, not, sorry, not device, it would disable USB for a certain class, sorry. So you would not be able to load any, say, CD-ROM drives, you know, any external media because, especially keyboard. Especially keyboard is the common, especially not keyboard, I'm afraid, because you will want to allow keyboards in any case because your keyboard might break. But that's, you know, details, again, that requires you to have this inclusiveness mindset to be able to find out what you need to allow and disallow. Right. Right. So the comment was there, there were attacks simulating keyboards and that's certainly correct. That's absolutely right. Yet, from a technical perspective, these attacks were quite boring. They were not, you know, interfacing with any random kernel driver you had and they were only as powerful as any regular keyboard, which in itself is, you know, quite bad. But if I'm on the toilet and my machine is locked, then I'm fine with that. You know, the keyboard can, the worst thing the keyboard could do is, you know, go through passwords. That's already quite bad, but it's not as bad as, you know, the machine being compromised because it would load the file system driver for, now name any ancient file system that would automatically, you know, be mounted if I plugged in a pen drive and all. So, but yeah, there's issues around that. We cannot simply disable USB when the screen is blocked, although it would probably be already better than the status quo. You know, right now if you have a machine and you plug in USB, your Linux kernel would happily load any random driver that my fake USB device would, you know, make you load, make you to. And it's quite scary actually. Right. Right. Right. So the comment was, can you not control how many keyboards, you know, can plug in? And I say yes. It's, you can think of a solution like that. I think it's, I think it's a bad solution though. I think from a, from the user experience perspective, it's hard to communicate that you can plug in two, two keyboards but not three. It's somehow difficult. You couldn't make prompts to trust. Right. You couldn't make prompts to trust any device. Yes. I would not use prompts though. I would probably somehow show something like, oh, we've detected a new device. Do you want to make use of that? Not with a prompt though. And then if you click, yeah, please set up my devices, then you would get your list of devices and you could then, I don't know, maybe swipe the device to the left or to the right if you want to make use of it or not. Something like that. Or the best case, I think, is to only allow devices if you have an application started. You know, imagine, and now we have the technology. Slowly we start to having this technology. With Flatpak, we have tight control over what applications are doing what with our environment. And why would I load a camera driver? Why would I make my Linux kernel load a camera driver if I'm not having an application open that uses the camera? You know, it's, I don't think it makes much sense to have my Linux kernel do that. With Flatpak, we can potentially determine whether we have an application using the camera and only then make the kernel use or load the camera driver. And I think we have many more things to explore in this area. And we would see some videos which would show some automation around these things. It's very experimental, though. So I've shown you software or ideas in various stages. I've shown you the key-signing stuff which is sort of in beta stage. You can use that already now. These screenshots were not drawn. They were live. I've shown you the Flatpak stuff. It's quite production ready already. If you, you know, do app get install Flatpak, you get all this Flatpak stuff, you can start applications now and you can, you know, do real things with Flatpak just right now. And if you develop applications, you should package it up as a Flatpak and put it up on FlatHop so that other people can use your latest and greatest application as Flatpak. And I've shown you the USB stuff which is very experimental and is more in a research phase. And it also allows, you know, for contributors like you to engage in this sort of discussion and make this real and usable and protect users from, you know, attacks via the USB port. And I'm way over time already. This is also because we had a great discussion. And nonetheless, I want to close it now and of course I'm available here, but for the Internet, we're closing it down and I thank you very much for your attention. Thank you.
possible to use their computing. And the languages being translated. We have the GNOME actually two, the freedom to, you know, share concerned about your communication to be, well, task on your computer without having to fear know, the user, imagine the user. The user just that GNOME is a desktop environment. That's what case studies and bringing some examples of how I about OpenPGP and security and everything, I also will see much, much more, well, hype and perspective, it's hard to communicate that you