 Tout d'abord, il peut être utile de vous donner des conseils sur ce qu'il y a et où le projet est là, et comment on voit notre relation avec Upstream, et spécialement avec Debian. Alors, qu'est-ce qu'il y a ? Ce qu'il y a, c'est l'amnesic incognito-life-système, c'est-à-dire, c'est un système d'opératage live, vous pouvez le mettre sur presque aucun computer x86, vous pouvez le mettre sur DVD, vous pouvez utiliser des bistiques et des cartes, et c'est basé sur Debian, bien sûr. Les principales goals sont de préserver les utilisateurs de l'anonymité et de la priorité. Cela va dans de nombreux moyens. Tout d'abord, j'ai des connections avec l'Internet que j'ai tournée pour la nettoire, qui provoque un niveau raisonnable de l'anonymité, et des features de la convention de la censorship. Les autres principales features de l'anonymité sont que c'est l'amnesic, au moins que vous faites quelque chose spécial, tout ce que vous avez fait en utilisant les tales sera oublié quand vous arrêtez le laptop. Mais ce n'est pas seulement sur l'Internet et l'Amnesia. C'est aussi sur la possibilité de les gens à utiliser l'Internet en un plus safe. Par exemple, on crée beaucoup de tools de cryptographie de desktop, d'encryptation d'insent, d'email, des files, tout ça. Certaines personnes aussi utilisent les tales à produire documents, de faire une production de médias. Certaines personnes utilisent les tales à faire des livres, à faire des films, à éditer des radios, des shows, etc. On voit l'utilisation de la feature de sécurité, parce que même si peut-être vous avez le means technique de protéger vous-même par configurer vos systèmes de diverses manières, peut-être que ce n'est pas le cas pour tout le monde. Et je vois la sécurité et la sécurité de la sécurité comme des matières collectives, surtout quand la communication est évoluée. Donc ce n'est pas suffisant que les gens de l'AVP puissent s'arrêter leurs systèmes et configurer les systèmes pour une meilleure sécurité et sécurité. Parce que si les utilisateurs de l'AVP ne peuvent pas utiliser notre stuff, et notre stuff n'est pas seulement des tales, il y a des tools qui prétendent à proposer un niveau d'anonymité, la sécurité, etc. Puis ils utilisent quelque chose de plus, et collectivement ce sera plus pour tout le monde. The first public tales release was put out in 2009, so it's, wow, five years now. It's the softwareship is translated in many languages. It's three softwares, public and open development. We have GITs, REN9, mailing lists, monthly public meetings, all these things. And we try to document quite well what we're trying to do and how thanks to our design documentation. So now, does it work? Apparently yes, according to the NSA at least. And I'd like to thank a famous tale user for providing these documents. It's called Edward S. And some other more or less famous people apparently have good things to say about tales, so I'll trust them on that. Our user base is quite broad and diverse. We don't really know much about most of our users for quite obvious reasons. But we know some things. We hear from users we meet in those places and we hear from groups that are distributing tales, promoting tales, teaching people how to use tales. So, yeah, we know activist use tales, journalist use tales, at least the one that went through some training and have some idea of what they are dealing with. That is a few. Before going to the next part of my introduction, which is what the project is at right now and what are the challenges we are facing, I'd like to ask if you have questions about just what tales the software is. Anyone? Given the security focus you have here, how do you balance security updates versus anonymity of users? Do you have automatic security updates or do you expect users to manually be aware of that stuff? I'll come to the recycle soon, but we basically release every six weeks and there's an automatic easy way to say yes, I want to upgrade. But it's a live system. We don't do upgrades with apt. Does that answer your question? Anyone else? Okay, let's move forward. So, tales is an operating system that releases quite often. To prepare a release, Curl Clit still takes between six and ten solid days of work, which is a lot. Especially once you realize that we release every six weeks and we ship a release candidate most of the times a week or two before the actual release. So that's six to ten days of work every three weeks, actually. Enjoy. Also, a lot of people seem to be using tales and the numbers are growing up. So in July you had about eleven and a half thousand boots of tales a day connected to the internet. And this usual, the usual one. So a start-up after successfully connecting the internet tales connects for Tor to retrieve an ATOM feed that contains information about the known security issues available at great. So it does call home in the cleanest way we could find because it seems important to be able to warn users that they are using an updated version that has security issues. So we can grab the web server's access logs for this ATOM feed and count. We don't manage the server but I think it's a few weeks, something like that. There are no IPs in these logs and the connections are over-tour. So all that you can learn from this is someone started tales at this time. It's not much. So, and same in July we had thirty-five thousand downloads with the OpenPGP Detach EZO signature which means probably at least thirty-five thousand EZO downloads and probably many more because most users don't really check the signature because, you know, OpenPGP sucks. These numbers tend to go higher and higher every day. The number of boots a day has doubled between last October and July, for example. And it's not just the Snowdon effect because it's been doubling every six to twelve months since years actually. This tends to increase the kind of expectations people have about tales which puts more and more pressure on the people who actually make tales. But for now we are good. The team is quite small. We are working mostly on a volunteer basis. The ratio might change a bit in the next years but it's still unclear. And you can say about a dozen people spend at least a day, a month on tales and about four people spend at least one or two days a week on tales to give you an idea. Now, what are we up to? One thing we've been working on quite hard since two years is to make it clear that we need more diverse contributions from people with more diverse skills. That is, we need UX experts, graphic designers, translators, tech writers, many more kind of skills that when you get in the usual free access to our project because tales about usability, remember? We've also tried to welcome contributions from more diverse people. Our main goal for the next few years is to make the project more sustainable. As I said, putting out a release is exhausting and we're very good at working like hell but this can't work forever this way and it might be better if we spend these days to do more useful things actually. So this is about continuous integration automated testing infrastructure improvements, things like that. If Puppet Jenkins automated tests sounds good to your ear, come talk to me. We also have an ongoing project of improving tales usability thanks to Zach who met us meet some great UX experts we are doing some usability testing sessions testing prototypes trying to improve things a bit from a quite global point of view that includes the website first time user experience installation usage and given the tales getting more and more known as a store it seems that it's also becoming a more and more interesting target for people or entities who might want to know a bit more about tales users so it's also one of our priorities to make tales more secure to mitigate the effects of security holes in the software ship so we're also working on hardening any questions in this part tales development process I'm not sure where it fits how do you protect tales itself against targeted attacks I mean it's fine to say that you have it's open source right but this is clearly to me it doesn't seem like enough so I wonder if this is a project issue like are you taking extra care with your git repositories and signing commits or any sort of things like that we're not signing commits but basically everything that goes into tales gets peer reviewed before it's merged the people who have commit access have to follow some quite strict security policy regarding their data and systems and well it's our answer to that is more social and organizational than technical actually I think as a new member of key ring mate I'd be curious to hear what your requirements are for contributors not because I expect to be able to enforce anything in Debian but I'd be curious to hear what sort of standards we should be asking people to try to follow shall I answer that now or should we talk about it later now it's not exactly public information anyway we came up with security policy just by doing basic threat modeling and looking okay what's the easiest way for an attacker to put tales user at risk for the people who have commit access and then you say okay this is a problem let's make sure this is fixed and this is another problem your rate and rate nothing special I'm wondering what kind of privacy issues and security issues you found in Debian itself that you've had to patch that would be more a question for the next part that well I don't remember exactly but we do report bugs including security or privacy once of course any other question before diving to the tales upstream relationship topic okay let's go in our area in the privacy anonymity focused distributions most projects have lived one to two years max for various reasons that I won't go into now so from the very beginning of this project we've taken quite hard stance and maintainability and trying to keep our delta as small as possible in order not to build an ever growing technical depth and things we'll have to maintain ourselves forever I'll give quite quickly a few examples about this so for example there are things we'd like to have but we didn't do ourselves internally because we don't think it's reasonable to add this kind of maintenance workload to the shoulders of the case project itself like having a GRSEC patch kernel this should be done in Debian instead same goes for all the compile tight hardening flags many people ask us do you rebuild the Debian package to harden them more and the answer is no when we want some software to be more hardened we have it hardened in Debian itself there are examples of what we shouldn't have done this way there are features like we have a fancy open pgp applet that's quite useful for many use cases and this should be packaged and actually it's been packaged so it should hopefully be uploaded in time for GRSEC otherwise no big deal we have backports same for the tails when you shut down tails it raises memory to protect against basically call boot attacks this also would be worth having in Debian I want to have that in my regular Debian system the packaging is ready test test test test work test test test test test test this feature is being packaged we have a package that works fine with cv init but it uses kexec and systemd has another way to deal with kexec we should adapt our stuff to work with it there are various examples of what we can boast about stuff we've been doing upstream we've been contributing to Aparmo upstream to libvert, seahorse various things in Debian we... things like that that will be better to tell you about how great we are the consequences of this project direction is that we have very little tail specific code what we do is gluing things together it's a bit like the way the freedom box project sees itself a bit less radical a bit more usable maybe and we do a lot of social work like talking to upstreams making them aware of our needs finding the right people to do the right work at the right place things like that these days I spend personally much more time doing this kind of social work than actually hacking on takes another consequence of this stance is that we're quite slow and when we are improving something in Debian we might not benefit from it before 2 years or more depending on how fast we are to rebase tails on top of the latest stable release which we suck at kind of another consequence of this choice is that tails still alive which I think we can be quite proud of I also have to say it's often frustrating for new contributors who are very enthusiastic about hey I want to change this change this in tails and then yeah this would be good but maybe we don't want to maintain it ourselves forever maybe instead it should go somewhere else and so it's makes the barrier higher and yeah it's hard but we'll discuss a bit later how this can be improved at least as far as Debian is concerned as I said tails is based on Debian and tails relies very heavily on Debian the project, the infrastructure the social processes the individuals so first I'd like to reaffirm that tails is Debian is a really really good basis for their relatives and I'd like to thank everyone who makes this reel every day I could make a list of various teams and individuals who are helping in particularly but well it would be too long and I would forget too many people you're probably all included in some way so I'd like to go quickly a few ways that Debian could help tails better or the ways that in that you as Debian contributors could give a hand to tails by working Debian itself we always have many one shot small tasks that can give a hand like uploading a lot and making it that's one shot actually we have a few other tagged bugs in Debian BTS so it's I'm going to spend one hour of reel three months and that would be one less hour I have to do things about this and I can focus on test specific things what should I do I'll try the other one I think he replaced the batteries just bring them up test what the remote control interface and this thing so yeah it's really possible to give a hand just by ask me and I'll find something for you well another way to help us help Debian and make tails and Debian stronger is to help us help Debian is to mentor and sponsor contributions from test contributors who are getting involved in Debian it wasn't the case a year ago really a year ago the main person the main test contributor was contributing to Debian directly was me and in August I've had a look and we had 5 test contributors who had stuff uploaded this could be this was sometimes NMU sometimes packages that are maintaining since a few months so things are changing pretty fast in this area and I think it's a really good outcome and there will be more but these are new contributors and they need to be helped they need to be mentored pointed to the right documentation and their packages need to be sponsored we already have a few people who are in this room and that they would like to warmly thank we do this kind of work and we need more too if you have more time a great way to help tails is to improve Debian globally like with adding a partner support or improving it with working on reproducible builds improving hardening build flex coverage and maybe making the default set of flex a bit stricter on architectures that can hold it like PIE where we need a lot of packages to be in good shape and to be improved there are a few examples we need a GRSec kernel we have teams about anatomy tools about OTR that you are warmly welcome to join it would be good to have XOR it would be good to have Wail and system user sessions and many more things it would be good if there were a few improvements made under derivative patches tracking tools this has been discussed recently in the Debian derivative mailing list if you are looking for some smallish coding task that might be for you more to come at the raties both also we and Debian continuous integration things move forward quite fast these days because possibly at some point we would like to base tails on Debian testing or at least quarterly snapshots or something like that and yeah so if you are interested in giving a hand tails by working in Debian we have a page on our website that sums it up and gives pointers contribute slash house slash Debian and now I'd like to discuss with you how tails can help Debian in some way or be a better citizen in the Debian community Mike is yours so I think that actually Debian I think tails is doing a great service for Debian in terms of providing a I know this sounds a little bit strange but in some ways a more visible distribution than Debian is Debian is sort of in the background and there are systems administrators who know about it and use it reliably but working for an organization that cares about civil liberties privacy and freedom of speech tails is known as one of the tools that we should be using and we use it in my work and I have colleagues who have probably never run on a system except for tails so thanks for raising the profile there I think tails also provides an example of how we can improve Debian for privacy and security conscious people and we need that because we don't often have people who agree with that and I think it's helpful for us to have direction to go in so on the user experience side I observe that tails is putting a lot of effort into making things very polished for end users and that seems like the sort of thing that we ought to be aiming for in our broader distro as well so perhaps just the knowledge of what things do real users actually hit these usability studies I think they would be very helpful to have all the issues fixed upstream as well yeah actually once we we have completed the first large iteration of our usability work I'd like to point to the UX experts we are working with for example the DI there's a bit of room for improvement there if people developing DI are interested in this and ready to prepare prototypes implement suggestions and stuff like that of course what sorts of tools would help us iterate more quickly on these sorts of ideas I suspect that most developers don't do a whole lot of user experience mock up testing before they write their code they probably focus on how do I make the thing work and then turn it from a raw API into something that you can get keystrokes into did you have any thoughts on how we can make building usable software either more interesting or more well tooled or I think the main thing on this topic is humility that as software developers you really have to realize that UX and UI design is really some other kind of job that we generally are not good at and once you've realized that it's not so hard to find the right people who have the right skills and they want to work with you but yeah intuition doesn't work great in this area it's just like for optimization what you would guess that users will have problems about when you do some actual usability testing sessions you realize that you are to tell your wrong actually so one of the thing that tells you right now that I miss on my deviant system is the MAC address randomization how much can we get back to more deviant systems is it it's unclear like who should be talk to to make that happen or which upstream to pressure or I don't know sorry that's a hard question yeah that's really hard question if you it's the kind of thing that if you want to make any guarantees about it really depends on a lot a lot of other packages how they interact with each other and this kind of thing that you can't make guarantees in a quite specific system like tails but it's very hard to guarantee that some behavior will be preserved whatever combination among our many thousands of packages you install I submitted a bug against network manager asking for that oh good job apparently we both submitted the same bug to network manager I do think the network manager right now is the right place to merge them and then systemd networkd is the other place and we need more people to follow up on those bugs and say yes these are important and if we could it would be great to have someone follow up with a patch because actually it looks to me like with the patch that I submitted they were willing to consider it but there are some difficult and awkward questions for non ephemeral distributions about MAC address randomization so there's logistical things that need to be sorted out to make that work on that front apple has set up random MAC address during the scanning phase and afterwards it reverts to the normal MAC address so that's a data point from the proprietary world where they're doing better than us I think you're right that this is quite difficult because there are a lot of components involved and it reminds me of the question about log minimization that basically a decade I was pushing on this of various points making patches for syslogs and it was quite hard and then we had this session here at debcomf and suddenly everybody was fine with it and now it seems we should well yeah basically doing a session on something like that or bringing it up at debcomf helps hit a lot of the different points that need to be tweaked or at least seeds it in a lot of people's minds who are responsible for the different packages or in different areas of Debian so as a one person effort it might be overwhelmingly difficult but I think it could be possible it does make me also wonder about other nice features in tales that somehow how can we get those into Debian so people could have them by I don't know installing a package or something just to set up the IP tables rules to route everything over Tor or simple things like that that could be turned into simple things but I've already considered for example packaging our certified DNS thing but there are so many packages that want to touch Resolute Conf and how it's configured that it's really hard to convi to actual users that okay you can install this package and probably it will achieve this result right now you can test it and confirm it but it's very hard to convey the message that this might be broken by any upgrade in the future and yeah one thing in the security and privacy landscape that's very important to be able to convi to users what kind of expectation they can have and in this kind of things without touching aspects of the system that many packages are competing to affect in some way like firewall configuration resolver configuration it's very hard so you could still have something that does the right thing most of the time but now the question is how do you tell people about it to suggest them to install this package saying okay it will probably make things better but maybe not that's more documentation communication to users question than technical one actually on the firewall part I'd like to say that again it's a terrible idea to make everything on a system go through tour you should not do that because they will leak sensitive data which you don't properly audit or like configure them before telling them use tour then usually it doesn't work the way you want one thing that but for example on android platform someone wrote an application it's called our wall and where you can selectively select which application you want to go through tour and block all of us from the network and it's a very good UI but it's very it's super hard to achieve it's easy to achieve on an android system because each application gets their own user ID so you can use that to filter but I thought about trying to make the same thing for a usual Jalipsi DBN system and I was like I don't know so if you have a good idea because I think that's a really good user interface the GNOME community the sandboxing applications and that could be totally part of that I believe it uses container stuff but I'm not sure as an advanced user using DBN for 7, 8 years I was very glad to be able to install tours, tales very quickly and my only disappointment was that the language that introduced what I could expect when I started it, required my background to understand so if it was if the language that introduced it says hi smiley face welcome to this if you would like to know more about how this works click here otherwise enjoy your experience here's the browser and then more people who do not have serious security concerns could be filling the networks with their random noise and it could be made more easy and it's not as targetable as, oh, this is a secret in a group of people using this I don't know if you saw the systemd talk so Josh Triplett basically described it a number of features of systemd and one of them in particular was the idea of unmounting everything at the end and reverting entirely to an initial MFS and that strikes me as a very good opportunity to do a memory scrub so as someone who runs with a lot of encrypted disks all the time I know that including my root volume one of the things that bothers me is that when my machine shuts down it hasn't unmounted root because it hasn't dropped the DM crypt mapping which means that probably there's a chunk of memory that still has the master key for the volume et j'ai l'impression que c'est possible comment est-ce que la mémory wipe est usually taken on a random laptop comment est-ce que la mémory wipe est taken on a random laptop