 So, hello. Thank you for coming. We're gonna give a technical overview of Tails. That's Corona, Intrigeri, and I'm biting bird. What? Is that normal? So, we are all Tails contributors in different fields. I don't do technical things. Intrigeri is one of the oldest Tails contributors, and Corona contributes in some years now. Yeah, two years. So, Tails is the acronym of the Amnesic Incognito Live System. And here is a nice URL where you can have all the information. So, it's a live operating system. It works on almost any computer, except ARM. And it boots off a DVD or a USB stick. And theoretically from SD card too, but it doesn't work very well. So, the focus of our distribution is privacy and anonymity. So, it allows the user to use the Internet anonymously, and also when there are censorship to circumvent it. So, all the connections to the Internet go through TOR, which is an anonymization network. So, that's the first big feature of Tails. And the second one is that there's no trace on the computer you're using, so that after you use it, nobody can see that you've used the computer. So, if somebody were to grab your computer and search for it, they would not know what you have done. Yeah, unless you ask for it explicitly, staging and more. And we have also a lot of desktop and data-producing tools, because some people, some users use it to write books, news articles, video and such things. And they want to be able to create such documents without being traced. So, does it work? So, we have a very good report, not from our user actually, from our, you know, the people we are supposed to protect against. So, the NSA says that it's a pain in the ass. And so, when the NSA says you're making their life harder, somehow you're doing something right. And I guess you can imagine who the famous Tails user who gave us access to the documents where they say that. And there's also Bruce Schneier, who says he uses Tails. So, not bad. So, what are our goals? We took a stance in the beginning of Tails that it was not really common back then to have usability as a security fixture, because Uber geeks were already able to have secure communications. And the thing is privacy is not an individual matter. It's a collective matter. Everybody needs to have privacy. And new users and non-geek users had no way of having access to those, because the tools existed, but they had no user interface or they were really hard to configure. So, we designed a system that gives a quite good level of security with a quite good level of usability. And lots of the time people ask us why we don't include more security features and we have to make a balance between security and usability, because if it's really secure but nobody can use it, then it doesn't bring anything. So, it makes security accessible for most people. Another important point in our project is to have a very small delta to our upstream, so our main upstream being Debian, and we try to not diverge too much from it. So, because the more you do things differently, the more work you have to maintain. The work is not the work of implementing something once. It's the work of maintaining on the long term. And there were a lot and a lot of other security distribution and there are still a few others, but most of them have a very short lifespan, because it's a distribution and we're not a very tiny team compared to Debian, but we're a team. And lots of other privacy distribution were either one person or very tiny, tiny teams, and that didn't make outreach to be joined by more people. Most other privacy distribution didn't take into account the maintenance work and the user support, because even if we try to make it usable, there's a lot of work to teach the users how to use it and to document how to use it. Also, if you want to start such a project, you need to have a long term commitment and to remember to avoid the symptom of not invented here. It's quite common to try to do something that does exactly what you want, but it's best to find an existing software that does something close enough and to make the new features you want in it or use it as it is. So we're trying to do most of our work, well, at least a good part of our work upstream. So we did Aparmo, in Debian specifically there's an Aparmo team, an anonymity tools team and an OTR team who work on things that we use in Tails. LibVirt, Seahorse, Tor and Puppet, our other projects we contributed to in order to, instead of implementing what we needed in Tails, we did it upstream and it took longer and it took longer to fall down to us, but so it's maintainable. When we finally have the new features, we have no work of keeping the new features. So as a result, we have really little Tails-specific code. We mostly do glue work between the code we take from our upstreams and we do a lot of social work. We talk to upstream, we spread the word, we say, oh, that would be great if somebody were to work on that. And we find the people that have the right skills to do the work where it should be done when it's not in Tails. We have a very slow rhythm because we work in Debian, so we have to wait until the next Debian version is released to see the work we've done in Tails. For example, the apartment I mentioned earlier, we did it in Debian, so for two years, there was work going on in Debian that was not visible in Tails. But we finally have it. And Tails is still alive because it's maintainable. So implementation details. So that's where I give my quote. So talking about the implementation, we have to say that Tails is like an implementation or at least the furthest implementation of the sign that we have called privacy-enhancing live distribution. We can use it in that link. The idea with that document was to define like a set of features that any distribution that we like to enforce security and privacy and anonymity for the user will have to have. As I said, Tails is the furthest implementation of this document. Of course, as you know, maybe this is based on Debian. Now currently, it works over Debian VC. And now we are migrating to GC and we try to do in the next months. So what's the main software that runs on Tails? Of course, we use Tor. The Tor browser and Genome. Tor, as probably you know, this anonymity tool that allows the people to connect to the internet to regulate the traffic between different servers in an encrypted way. So it allows to stay or to hide your location. And the Tor browser is this tool that allows to use Tor in an easy way, in a very convenient way. Only you have to install the browser and the seats. So talking about the features of Tails, we said before that the idea is to use the internet anonymously. So the idea is that for all the software that we have installed in Tails, we block all the connections that are not going through Tor. Everything that tries to reach the internet that has not been by Tor is blocked. And we try to have a very good configuration for the tools that we ship so they can connect to the Tor network and it's almost invisible for the user. So the user doesn't have to care about who is going to the internet. He can be sure that everything is going to Tor and so he's protected. We have an alternative to Tor that is called I2P, which does something similar with different technologies, different architecture. This is not enabled by default. The user wants to use it. He has to enable. And we have a user case that sometimes the user is, let's say, in a hotel or in a metro station and he wants to connect the internet but he cannot use Tor immediately and he has to connect to a captive portal. Then we have a safe browser that allows the user to connect directly to the internet but it has a lot of sign-ups and labels to say that you are not secure in that way. So the process of installation of Tails was done before, in a very manually way. We have a lot of documentation about it but now we have a TenZ installer that currently is working only inside Tails but we are working to create a different version for several systems. For example, we are almost done with the Debian version but we also want to have an Ubuntu version, even a Windows version so it gets very easy to install Tails. We are trying to convert this software, which is writing in Python to use GTK3 and UDIS2. So another important feature of Tails that was commented before is that we don't want to leave any trace in the computer so basically we don't write anything in the hard drive in the disks at least in the non-removable disk. Yes, when the Tails is running and it is shut down or the USB stick where it is installed, that is most of the case, is taken out of the computer so the idea is that we whip the memory and erase everything that is there like keys or whatever sensitive information that is in there, we try to delete it but we use, for that we are using this package that is in Debian, the secure delete and more specifically the tool that is called SDMem. So the idea is that we don't want to leave any trace in the computer but sometimes the user needs to store some information and if they are using Tails inside a USB stick, so we are providing the possibility to store some information inside the USB stick in one partition. We are using for that looks and we are using an encrypted GPT partition that we call TasteData. Yeah, the idea is that we are storing there some information that is important for the user like the keys for the email client or things like that. We are using the DMCrit for that and we are using for the file system X4. Yeah, then the backend is implemented in Live Boot and the good part of the tool is written in pair. It's using GTK3 at the moment. So even if we are running a live distribution and when it is running from the USB stick, we would like to provide incremental upgrades so when there are security updates or even features upgrades that we want to provide to the user, it is possible for Hino for her to do it. There is, you can see in the link, there is a design document for that. Yeah, again, only possible when the user is in the USB stick. We are using an incremental upgrade kit and when we try to resolve like the overlapping file system stuff, we are using a squash FS stocking to resolve these upgrades. So this is maybe one of the areas that we need to work more in is the application isolation. For the moment, we choose up armor which is like the most maintaining and the best supported in Deviant. But for the moment, we are only supporting file access isolation because there are some patches that we need and they are not yet there in the kernel. We have to make like some hacks to make it work with the live distribution. For the moment, we are providing isolation with the armor for several tools in tails. For example, the Tor Bursar which is maybe the Tor Bursar and Tor which have the biggest surface of attack. We really try to do a good work protecting only in this moment for file access but also we are providing isolation for PG, Bins, Totem, Vidalia and others. So for the build and the test system, we have the GIF repo that you can access in the link. Take a look. For the building test, we are using Baygrant. We have now automated build and tests which the user can do in their own computer but we also have these set of servers in our infrastructure that we are using to make it automatically because every time more and more we have more often release of new versions so we have to do it in an automatic way. For that, we are using several tools. For example, Sikuli, Libby and Cucumber. If you want to see this working, don't miss the demo on the next Friday that Intriguery is going to show. So for Guadalajara, we have explained, we have several challenges, especially this thing of talents and popularity because this last year we maybe have reached the hype for several reasons, several media news or things like that. So now we are trying to release every six weeks. So it's really a lot of work for the people that we have and we are not having like 14,000 boots every day which is almost three times more than two years ago. And of course for this task and maintaining an operation system is something which requires a lot of work. So we have limited resources and time and we have a really small team compared with the amount of work we have to make. For example, we have done like 3,500 commits but more than 15 people in the last six months. It's really a lot of work and we need more people working with us. So that's it for myself. So I'm going to talk a bit about what you are going to do in the next two years. This is a quite fresh roadmap. We had a previous one for the last two years that we mostly completed. So last month a bunch of tennis contributors met for a week and we had a look and tried to see what was most important for us to do in the next years. So first of all we want to complete the port of taste to DebianJC of course. The ETA currently is early 2016. As always it's been almost done for month in month but between almost done and ready to ship in production for actual users there are sometimes a little bit of difference. We have quite a few ambitions in terms of hardening. That is we want to protect our users better against attacks be them targeted or not targeted. The thing is the more tales is being used by actual people the more it gets popular, the more it gets known and under the media spotlight and also the more it gets high profile users, let's put it this way then the more it becomes an interesting target for whoever would like to cause trouble to the people who are using Taze. So it's getting more and more important for us. I'm not going to go through every line on this line just we'll go through it quickly and give you an overview of the main fields and topics we want to work on. We have already a quite international audience which is good. The custom software and strings we ship in Taze is already translated like in 2015-20 languages which is very good but for in some situations it's not so good because for example if your internet connection is being censored or if you live in a place like some places in England or Germany or other countries where you cannot easily access Tor then you have to use pluggable transports or Tor bridges to be able to connect to Tor and for now for example you have to enter this information, the configuration each time you start Taze which is clearly a pain in the ass. So through this we want to allow users to save this configuration in a persistent manner so they don't have to enter it each time. Similarly our website is the dark corner right now of our localization efforts because it's only translated for languages including English which is not much and clearly not enough and for to solve this problem we are in the process of setting up web tools to make it easier for our translators to contribute as opposed to the current way of translating our website which is based on Git and Git is not the most user friendly tool for potential translators. As said previously one of our main focuses is to make Taze usable for as many people as possible. We're already doing a quite good job at that but there are still some what the user experience people call pain points that is even if the process is mostly easy it's enough that you have one pain point to block someone and if they are blocked they can go further and if the next steps would be easy in the end they won't be able to use Taze. So we are working with user experience experts and that Zach put us in touch with, thanks a lot and to identify these pain points and work on it and design new and better ways of getting started with Taze mainly because currently that's the main pain point. People just don't manage to install it in the first place quite often too often. Our user support team also has plans to make their life easier and as a consequence to improve the quality of how they deal with user requests. This implies some work on the infrastructure side this also implies some software development work because we are shipping a tool called Whisperback which is basically it's something like a report bag it gathers some logs, it gives the user a template to fill in some information what they are trying to do what they are expecting to see and what happened instead and then it sends this as an encrypted email to our user support team so there's a little bit of software development to be done there. Last month when we had a look at the current state of things what Taze looked like these days we had to make some kind of hard choice that is we could either decide it's more or less featureful and work on polishing it, making it more solid, more reliable or we could go into adding more and more and more features and trying to address more and more and more use cases. We decided to not go after feature bloat we decided to focus on our current design goals and so we listed a few things we want to do that we categorize as polishing making the whole thing a bit, I don't know, polished. In the last two years one our main focus was improving the project sustainability because of course it's no use of making a very good tool if it dies into years so we've put a lot of effort into writing automatic tests improving our processes, doing outreach, growing the team and so on and so on and we still have a bit of work to do in this area even if it's not our main focus anymore and to end with in this section we would like to improve a bit the way we deal with money that is we would like to depend a bit less on government grants yes we get money, we use money, we spend money and half of it this year comes from government grants this is something we are not totally satisfied with and would like to change and probably it will be an incremental change probably it will take time so better start early and this would also allow us more likely to have more reliable and steady sources of income that is not depending on whether you will get the next big grant or not that's all for what are our plans for the next two years if you want details we have more detailed documents with all the information I've put that includes links to the actual tickets in our test tracker and you can of course ask us details if you are interested in any specific part of it needless to say we might not be able to do all that with the current team in the next two years and it could be useful if more people came to help us now speaking about that at Debcon puts me in kind of an awkward place I mean I would not feel comfortable asking people to work on Taze if it implies they would put less time into Debian that's not what I'm asking so maybe for most people in the room you actually won't be able to contribute to Taze even if you would like very much which I'm sure because it would imply you would do less in Debian if Debian is in a worse position Taze users are in a worse position and the world is a worse place but maybe you know people or go to conferences or whatever who might be interested and might have spare time or might want to switch from the crappy project of something they are working in and do something else so I'm going to list the kind of skills we currently need the most that is basically everything to be honest for the software development part we are quite well staffed as many free software projects that the getting software developers on board is probably the easiest thing to do because the people create the project are software developers they know how to talk to software developers and so on so the skills we need the most are less different skills that may be technical or maybe not that may be social not, that may be creative or not and here's the list we have pretty good contributors documentation that allows people to find tasks that could achieve given their existing skills or the things they would like to learn they are selling there I'm going to wrap up because we don't have much time left with some contact information so this all was very fast and if you have more questions or whatever you can talk to us because we are here and some of us will be here for the entire depthconf and some more will join us in two days and of course we have the usual set of mailing list IRC website etc etc etc and the slides are already online thank you so thank you for your work on tails it's something that we use critically hi, thank you for your work on tails it's something that folks that I work with rely on heavily we would not be able to do our work without it so that's much appreciated I saw you said people who contribute to Debian maybe can't help because you don't want to divert work from Debian what are ways that Debian can help tails what can we do as an operating system to make the work on tails better, easier more effective okay so I actually gave a talk explicitly on this topic at the mini depthconf in Lyon a few months ago which was called how you can contribute to Debian you might want to refer to the slides for details but in short we have list of packages we rely a lot on and that need more hands be it basic building breaks of course like the kernel, xorg stuff, teams that are understaffed and have a hard time dealing with all the work they have to do like the GNOME team for example we also have a lot of work we do the back-porting work we do because when you implement stuff upstream first as it's been explained already you have to wait for it to land to Debian and maybe wait two more years so we ship a lot of back-ports so we maintain a lot of back-ports and we would not mind some help in that so we can focus on stuff that's more tail centric and less Debian centric and you know so if you're interested in doing some of this you can talk to me in the next few days I'll be happy to point you to all the things one short question you said you know about the daily users of the system how would you measure that without sending information through a public network disturbing the privacy of the user so that's the question we have every time we give a talk so that's kind of funny so since using an outdated system is really unsafe so we really want to make sure that the users have the up-to-date version for that at each boot when you boot tails it checks if there are upgrades and we so the statistics we have are the number of people that check for upgrades and no it doesn't reveal information about the user it just yeah so the check goes through talk and so it's like any connection to any other website you would do and so we only know one tails has booted and we don't know where they were what they're doing or anything we just know they boot they check for updates and that's it I know DKG already said that but I just wanted to thank you your work is really really important and it helps a lot of people and I just wanted to acknowledge that Does it ever occur that in a new version of software there are new features and some of those features fall on home because there was an incident recently the chromium browser would call home to google in a new version that was pushed as a stable security update it would phone home to google and some executable software for which there was no source code fortunately in Debian it didn't run this but that was a close call I wonder can this be detected easily with automated tools or does it involve like a manual source code audit to check that there's nothing new like this added in a new version of a piece of software Do you mean tail specifically or my engineer with Intel do you have tools to detect packages from home we don't wish the thing is that we ship relatively few software that talks to the network and these ones we configure quite carefully and accept that our browser basically they only get updated when every two years when we switch to the next version of Debian so the risks are relatively low the main potential offender would be the web browser of course but for this one we are just relying on the tremendous work done by the tor browser team okay thank you I have space for one more question I think maybe I should add tail is configured in a way when even if it was phoning home except if it was actively looking for user specific information in their configuration cache files history something basically all tail users would be looking the same to their online server that would be reporting back so the risk is not that high well the phoning home risk with some limited definition of phoning home is quite slow in tails or almost non-existing anything more deeper I would call malware instead of phoning home privacy leak and that's a different topic well it looks like everybody has their questions answered so thank you for being here and let's hope we'll talk to you in the next days thanks for your work in Debian