Against the silos: usable encrypted email & the quest for privacy-aware services
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Kaneko, Kali
Kali Kaneko - Against the silos: usable encrypted email & the quest for privacy-aware services At the LEAP Encryption Access Project we aim to make secure communications both easy to use and easy to provide. We bring some tales (and some, hopefully, tools) from the quest for user-friendly crypto software. How to make people love the email experience in the 21st century, without risking their privacy. How to encrypt data locally, sync it to servers that you can lose, and still be sexy. - Technologies that allow for privacy in the communications, allowing the escape from the pervasive massive surveillance, have been there for some years now, but yet its use by the general public is far from widespread. The challenge, in our view, can be defined by one of making usable crypto. Usable for the end user, usable for the sysadmin and for the fellow application developer. In the quest for massive adoption of encryption technologies, we've been forging several python packages to solve different problems, always standing in the shoulders of giants. We bring some tales from the trenches to share, from our humble experience trying to deploy clients and servers to provide Secured Encrypted Internet Tunnels and Encrypted Email. This includes interesting challenges dealing with key management, automatic and secure software updates, and processing of email while using stock cloud providers, while still being resistant to hostile environments. We'll show a webmail email user agent based on this architecture, a promising future for decentralization and privacy. We'll also talk about how to store locally encrypted data, and will present Soledad (Synchronization of Locally Encrypted Data Across Devices). Soledad is a library with server and client components that allows the development of different applications based on client-side, end-to-end and cloud-syncable encryption of private data. We'll play with some toy apps to showcase its features and potential.
 So without further ado, please give a big hand to our next speaker who will be talking about encrypted email. Hi, I guess you can hear me right. Welcome. Buenas, Egonom. I guess you are not in the wrong talk. We are here to talk about encrypted privacy-oriented services, especially email. I'm going to confer something. I just finished the slides ten minutes ago. So this is my practice. A little bit of history. We are in a very interesting place. We are going to talk about old protocols. I'd like to introduce some history about the places we are in. This was a shipping company, a shipping factory that started in 900 and ended in 1984. When I discovered that on Wikipedia, I said, well, this is a really good omen to talk about privacy. In the riots with the police, one person, one worker was killed here. By the way, the slides are in here. Many of those things are linked because I don't want to get too technical. I am here more interested about talking about tools. This is the Karol crane out there. We have the whole year. We have IRC. We have mailing lists to discuss about technical details. Actually, I'm merging two talks. Holger Krekel, I guess some of you know it. I just met him two months ago. He was going to give another talk about two words secure email. For personal reasons, he couldn't make it. I decided to put together some of the conversations we were having and try to merge the talks. I'm intending to do two different parts. One more about high level philosophical questions, if you want. And strategy, because we are a community that builds tools. And the other part is about actual tools. So I work in something called lib encryption access project. We gathered four years ago to decide to make encryption accessible. My role in the team is this. I'm probably not the best person to be here giving this talk, but I was just passing around Europe and nobody else could come. So forgive me for my ignorance. This is my first talk in kind of a serious manner. I started doing Python 10 years ago, but this is the first time I'm actually trying to present something to the world. So, what do we want to do? We want to make privacy usable at all levels. And the motto is we kind of feel that we have to defend the right to whisper. Because privacy is about the right to whisper. Some of the really smart guys that started this project are coming from these kind of collectives. Someone here has a rise up account. Good. A rise up is a tech support collective that gives support for activists. It's like the GMA for social movements. And this is a problem. Because when we start centralizing things, we have a single point of failure. But we are a non-profit. We are something more than a non-profit. We are kind of a distributed network of people that think alike, that wanted to do something in some specific way. And just we look for the way of getting money to do it. By using grants, by using research projects. But we are more people, than the people being paid by the particular project. And this is very interesting. Because it frees you from the startup mindset. So, I probably, since I knew I was going to be very nervous, I probably took the tips for speakers to literally. But I kind of found it fun. So, I'm going to present an adventure in which we meet the non-heroes, I'd say the anti-heroes. That go on a quest, find some weapons, you can guess which kind of weapons we use. We met some allies in the road. We, probably this is the only thing important from this talk, the monsters we are finding. Because we are kind of learning in their way. And the adventures yet to come. And my goal here is to convince you that this is important and interesting. And we'd like to have your feedback. Disclaimer. Leap is a highly opinionated project. With a highly opinionated team that builds highly opinionated tools. And this talk is given by a highly opinionated person. So, don't take me too seriously. When I say something is bullshit, just take it as a shortcut for, this is what I think. But I like to, yeah, you know. So, now you know the team. I'd like to mention that we are not just coders. We tend to forget about the other people in the teams that make that possible. So, kudos to the other people that are not cis admin or coders. We have one woman that the only thing she does is trying to get money through funding research for allowing us to keep coding. And that's much appreciated. So, the quest. Already said that. I guess if you are here is because you are interested in privacy. And so probably it's obvious in this context that privacy is not for privacy minded persons. We cannot think that privacy is something fundamental. Privacy and communications are a fundamental human right. And it's about the right to whisper. Privacy as the cyberpunks, cypherpunks said is the right to choose who I communicate with. And we think that we need to be able to choose who we communicate with when talking with our friends. By the way, this is a very interesting link. In case you don't know it, just click on it and read something tonight. This is the typical thing. Like, okay, we need to do privacy oriented tools for journalists because they have to keep secrets, what sources and so on. Our saints, the whistleblowers kind of appreciated in the community. And we everybody understand that they need privacy and secrecy. You probably work in a startup environment. If you are in China doing some wonderful research for selling a big thing, probably you want secrecy. Communicating with your CEO to avoid all the Chinese industrially Spanish. Or maybe you are thinking about changing jobs and you want to communicate with another CEO and being able to blast your salary away. How many people here knows this guy? This guy was the one that hacking team. Okay. Here you have the whole tutorial about how he did this thing. Let's say I'm interested in interviewing Phineas Fisher. He's probably the most wanted hacker right now that is not in jail. So probably the only way to communicate with him is going to be GPG. How many persons here actively use openPGP encrypted email? Good. Now I understand a bit more where we are. Probably I need secrecy to communicate with my lawyer, with my package maintainers. Thank you guys. But yeah, seriously, when I'm traveling in India, I really, really, really would like to or need to, my mom being able to understand what PGP signing a mail means. Because if not, whenever I'm going to be kidnapped, because I'm a little white guy with a credit card in my pocket, it's going to scam her for money. So in general, the whole society, the point is that the whole society would need to, if not understand, at least being able to use the magical trickery that cryptography gives us. And we have fucking failed to do that for the last 30 years. But you get the point by now. We need, our friends use the whole society. If without privacy, the whole society cannot work. You probably, yeah, I think you probably remember the crypto wars some years ago. Now we have a very much interesting movie. For those who don't go to the countryside, this is a silo. A silo is something where you put the grain and from there you get the cookies in the supermarket. So we are now in the silo world. And this is a very interesting moment to be. This is from a Tim Berners-Lee article some years ago. You can see that the cool things were, weren't so cool at the end. Some of them were, some of them died. Ha, ha. Smart guys. In Dante Alighieri Divine Comedy there is a very big explanation about the layers of hell. Well, it's an interesting thing with a historical value. We now have a special place in hell, in the technological hell we all live in, for the people that use GPG. And I'm not trying to be smart or metaphorical here. This is fucking real. In my surveillance device, I need to have at least four, five different apps to communicate with different kind of friends. I don't know if this is the right order, but you get the idea. Some people think that seeing Alistar is totally secure. Thanks, Moxie. We can discuss about Federation. Some people think that WhatsApp is secure because it has end-to-end encryption. Some people, I don't know why, think Telegram is a cool thing to have. It's kind of open source-ish thing. But you know what? This is complete bullshit. This is my run minute. It's unacceptable that if I want to get Raspberry Pi from some nice guys in there, I have to get a Twitter account. No, no, no. Twitter is not a tool for communication. Twitter is not a fucking protocol. It's a fucking company. You get the point. This guy, Michael Hayden, former CIA director. The most important fact in the last years probably has been, for my bias view, this one. Metadata kills people. And it is not a bunch of nerdies that says that. This is the important thing. You were called paranoid five years ago. Now, it's not that we think they do it. It's that they fucking say it. So we have a nice pun on the concept of the killer app. They are actually, metadata is actually killing people. But in some sense, we all want to have killer applications, killer libraries, killer operative systems, whatever. And we are all here selling things or recruiting people. And the key, this is from a Snyder book. The key to being in this place is that the things we do in the clouds, the internet or whatever are convenient and free. Free as in beer, mostly. We believe kind of in free as in freedom, but whatever. All the whole open sources thing. And this is a race, my friends. If we want users to use things, we have to do convenient things and kind of free things. So it's like fighting the enemy with their own weapons. And this is the holy grail for encryption and privacy and all that. We all are kind of looking for the thing that does the right thing, the right manner, without the user needing to do a fucking PhD. So we use your tool. And your tool might be many things. Your tool might be infrastructure, forces admin. How many people here maintains mail servers? So you know the pain, my friends. Things need to be usable also for developers. I'm really amazed by learning so many things about how to make properly usable interfaces for libraries. And at the same time, in the bottom layer of hell, we have the end users because we are highly opinionated and we tell them what they should think like. So this is what Leap project and its many branches and heads try to do to attack the hard problems and the interesting problems at many levels, making things so simple that you cannot screw it. I'm not going to talk about the system in part because that is mostly written in Ruby. No, just because. This is called the Leap platform and it's for sysadmins to install systems with properly configured defaults and so on. For mail, we also do DPM but I'm going to focus on mail here. We're kind of presenting some libraries. I'll get there in second part of the talk and we have some desktop applications for users. Intermission. Usually people will get out of the talk at this point saying, ah, but the user doesn't care. The user doesn't care because we don't make them think that it is possible. We are kind of shaping their view of the world and what is possible for them and not. We also think that the user is not going to pay but probably the problem is not in the user. Probably the problem is ourselves. I think it was Tanker that wrote a very nice postmortem on the whiteout thing with secure email and they basically were putting numbers on how hard it is to monetize the market for privacy. But it exists. People is willing to pay. After Snowden, governments, universities, like whole sets of huge amounts of people were willing to put money on secure email. We can discuss what security means because they probably want to keep their private keys for the use their citizens or whatever. But the need was there and the tools were ready. So there is another thing. Come on guys, like commodityization goes on many layers. We can put the value on the services and let people earn money through billing for a fucking mail service and it can be as less as 50 cents a month. If you get 50 cents a month or one euro for two months for 100,000 people, you get some nice cash for some developers to code in a valley beach. So probably the model we want to go is to cooperate in a way that we are not only our fishes but building the tools for everyone to fish and be happy. So in the end we want crypto but we want roses too. This is my fundamental truth. I have been working with email for four years and I fucking don't know what email is or why people don't use it. This kind of puts things in perspective. We think that Twitter or Facebook are the big silos but they are just a tiny spot there on the whole volume of email communication and that is only a small subset of spoken language. So come on, it's not going to die anytime soon. I'm going to skip this. If you are the kind of person that don't take this as a fundamental truth, you have statistics and surveys and you can see the data. So the weapons. We kind of brought some weapons from our previous, some people have been like 20 years in this business. And for the client parts and the synchronization parts we kind of choose Python because it was kind of obvious. We were very happy four years ago. We were told that all the hard work is done. The crypto is done. You need some glue code, blah blah blah. The shoulder giants. It is really true. And we have the crypto there. And crypto is very effective. It works. And we know that it works because in the leaks about NSA we know that there are two things that they really get mad at. Strong crypto and tor. So it works. It works for a bunch of nerds. But we cannot explain the whole things that are needed to properly use or to properly be in a kissing party to the persons. This is what Snowden made to make Greenwall able to have a fucking GPG key. It's an ugly 10 minutes video showing how to use GPG in Windows. It doesn't work. When you have a nerd doing usability studies and doing things for the public, it doesn't work. And at the end, this is how we verify things because we are fucking lazy. So what if I told you that we don't really need the users to understand the RSA concept that is awesome, but we don't need it. We probably can have just some layers that do the magic underneath. A very good study 16 years ago showed that the mental models that we have to study is ability in crypto are not valid. So we probably kind of have the criminals we deserve. So our plan four years ago in the happy moment of the relationship with the whole project was this. Very simple. Three points, glue code, everything nice. Oh boy, how long we were. So the thing here is getting GPG management easy and in a background manner and put it on the cloud because users have multiple devices and they want their GPG keys to be there. Put it on the cloud. But at the same time, we want to put them on the cloud in a manner that the FBI does cannot get them when they get a server. And it was like the later part. Okay, we just use the normal make clients. Simple, right? So we went on a quest and four years later, we have 10 Python packages that are some shit. This is a very good book. It says 2000 programmers, three years, four hundred seventy hundred bucks. We now have kind of eight thousand bucks in the fucking issue tracker. And we thought our project was simpler. So we do the management. I'm not going to talk too much about it here. The logic there is probably 20 lines. Just fetching keys from key servers. They are kind of broke. So we need to figure out a new model for sharing his. And trolling the web of tasks and all that. But yeah, key manager. Discover the key and that's the right thing. Trying to establish trust relationships between all keys and new keys and trying to get scores for how good a key is depending on its source. And we want to kind of share the common parts of it out of leap. So the nice part is what do you use for local storage to have your secrets always store locally in the client and in the server. So it was there. It was done. The only thing you have to do is to hack some setup.py script to do bindings for SQL Cipher. That's transparent as 256 encryption on top of SQL. Fine. Spaghetti is there. It works. And we have to merge the pie three four because we are fucking lazy. But it is there. It is usable for many other projects. So the big, the important part of the talk. It's called something something called solid that which is basically the idea of we manage the keys. We put them on a magical library that's the synchronization of data that has been locally encrypted in a way that the server can never tamper with it or infer anything useful about it. The design documents are there and the code is there. Security goals encryption in the client side and get the local storage has to be resistant. To online offline attacks and to that, the tampering on the server cause we have to assume the service malicious. Same goals consistency. Same flag. We don't want to single the data has to be multi platform. We fail at even think about mobile. We are on the desktop part. And these things are in the far future for now. Well, not so much for this. And for usability, we need something that is available so the user can always get his data. User needs to recover the secrets if they forget the password. And we want to have something general cause we also want to express this to things like having a pocket application or a to do application or whatever. So probably something of this sound similar to what the Ubuntu one guys were doing. So we said, hey, so super nice. And they had a library that was basically an abstraction layer to put JSON documents on a storage and sync it. And so we started using it and doing hacks on top of it. Now we kind of have fork. Although if the project gets to the life again, we probably can use the whole thing again. So we put couch on the server and we put SQL cipher on the client. We have another thing to be for metadata and a pool to do things with a key manager and new PG. The password never arrives the server cause we do something very smart. It's a cell knowledge thing called SRP. We derive keys to get stronger keys from smaller inputs and we basically do encrypted blocks and put them on the store and things. So this is the secrets. The blocks have is just a JSON document with a cipher text of the original thing you put in there. You create things using things. Only that. The thing for mail is that we have like the whole mechanism for mail to arrive on the traditional SNTP world, put it on your inbox, decrypt it, do the pieces and put them on the storage. So you can process your mail on one device and have your already seen inbox in many other devices as long as your GPG keys. And you have a very simple rest API to sync. Allies. We kind of trust on Thunderbird. We wrote a Thunderbird plugin. We have a desktop client that exposes iMac and SNTP proxies locally. Thanks to all this, this server was kind of easy and nice to do. Thanks to all these people. And we kind of started collaborating with ThoughtWorks because they said, oh, this is very nice encrypted replication of data so we can put them on a server. This is our client. And this would be the mail user agent. This is the server part with the code GDP blogs. And what the pixelated project is doing is putting all this in a server and serving a Python user agent that does the webmail. So we can put our clients in their server, but we also close the loop and we take the webmail and put it in our local client. And you can do the two things. The corporate mode in which the private keys are in the server or you can use it shipping it inside a desktop only application. And look like this and people is really excited about this kind of Gmail-ish things that do all the right magic in the background. Monsters. My biggest regret is not having dealt with complexity before. And that probably comes from our relatively unexperienced with big projects and Python and packaging and so on. We start having too many packages. It's fucking unacceptable. New customers find it very difficult to understand where each thing is. When you start overloading inheritance things get crazy very quickly. We also have some kind of complaints about the whole twisted deferred thing for newcomers, which is kind of a religious war. But right now it is very nicely isolated so people can just use the REST API and forget about the things that are happening in the background. Another thing that has delayed us a lot is trying to get in the client server thing, your local demo, mixing together the QT paradigm with its event loop, the twisted iMap server, and some other things. Simplify. We are at that point now trying to simplify it. The thing works. The thing has tests. People is contributed. We have a big company like ThoughtWorks contributing code, but we need to lower the barrier to do a significant contribution to the project in general. And some adventures are ahead. Part of the team now is working in a couple of European Union research grants that have to do with key server validation, key exchange, and trying to bridge, trying to tend some bridges across different privacy projects. We want to share some of the knowledge and even code. And Panoramics is another cool project about doing mixed master networks for privacy. We are one of the first clients to implement a new draft, a new standard proposal, which is called Memory Hole, that tries to attack the design error in mail, in a centipede, that all the data, all the headers are going in clear text. Last week we were at the OpenPGP summit, and it seems that Thunderbird has already implemented this. So the whole idea is that you put all the headers, you put them inside the encrypted and signed mail, and you replace the headers with dummy steps. So you have a very nice and simple way of protecting the mail while in transit. There are also some nice proposals to do forward secrecy in OpenPGP, doing something quite similar to what the signal protocol is using, this ratcheting mechanism, to avoid that if an attacker can get some of your keys, it cannot recover the whole... It is a story, it is there, so trying to break the reconstruction of the whole communications. This is probably going to be something really, really exciting in the next year. And in Soledad, we are in a point where we are not finding any important bugs now, but we need to do some things for a scale. One of the main things we are going to do in the next months is trying to break the atomicity of the syncs, because right now everything is the same pool, and that's kind of shitty. We want to be able to sync all the keys first in a new device, and then probably all the headers, and then probably the attachments on demand. We have to deal with event-to-unconsciousness in a nice manner. There's a lot of things that need to be done, and that's it. This thing is my fingerprint, and for the young people, this is not a Twitter handle. This is something called IRC. We are there, and I'd be very, very happy to talk to you guys and learn all the possible things you can communicate with me. So thanks for an absolutely fascinating talk. We have managed to leave a full ten minutes for questions. In fact, almost eleven, which I think is a great idea. I have a million questions, but you don't want to hear my voice, so I hope you have the same questions in your heads that I have in mind. Who would like to have the first one? Thank you very much for the talk. Do you have any idea how to deal with a big amount of encrypted email, how to search in it? What to do with a start-away encrypted email when the keys elapse? What to do in the long run? What we are doing now is that we, it's different in this case. In the original BitMask client, what we do is that we don't store the encrypted blocks anymore. We use the very nice and old code in the standard library for, it has like ten years ago, ten years code that pieces, cast the pieces of the MIME 3 and we store all the metadata in different documents in the document store, and we delete the original encrypted block. So we can do efficient search mainly by headers. We can build indexes for searching for the main things in headers. Pixelated project is using a different approach. They are using push, I think it's pronounced like this, and they do full text search on the whole body of the mail. And they store, what they do is that they build the index for doing full text search locally, and they encrypt the index and they store the key for this block inside Soledad. So you have locally quite nice and efficient index to do any kind of, we probably could do the same with NodeMatch, just trying to block and encrypt the things with NodeMatch and just store the keys for the encryption inside the metadata database. More questions. I came across an encrypted email client called MailPile, which sounds kind of simpler but less ambitious. Can you compare the two? Because I felt you were trying to get done in time, which was great. But when you started saying here, let's have a client in the server and a server in the client, I was lost. I need probably better diagrams for that. We are really similar to MailPile. Actually, the Pixelated project started to consider using MailPile for the frontend. The things that we, I personally found MailPile kind of monolithic and we tried to decouple the things to play nice with the whole provider infrastructure. So MailPile is probably doing this whole thing in the client. They do their web server thingy, they do all the handling for GPG and they do the storage. It's basically the same thing. It's a webmail with encrypted local storage. They don't attack this, as far as I remember, they don't attack the replicability problem. So we kind of started from the upper layer and this is a very hard constraint. I got MailPile running with my agent. So at the end, I don't care. We kind of focus on this layer and the user agent should be pluggable. MailPile is really, really nice and for the amount of funding they got, they are really far in terms of features. So I really would like to plug it into the whole Solidarn Encrypted Storage. Good. Yes, the main difference is replication. That's great. Okay, any more questions? Yes. So one of the things I've been struggling with is can we really escape it? I mean, even if we use something encrypted, people will communicate with us Gmail. Even if we use encryption, if it's on the phone, I mean that's either Android, I mean it's either Google or Apple. So can we really escape it? Or is the only way to communicate securely is just, you know, low tech, just meeting people? That's the only thing I have an answer for that. It is totally true. Our code now, haha, I kind of screwed it. We had code in GitHub and we are moving to another GitHub instance in which a requirement is that you have an email that is not from one of the big mail providers. As you say, it doesn't make any sense if you are hosting a mailing list server with some pretensions of privacy and one only person in the mailing list has a Gmail account, end of the game. Have you read Moxie Marlin Spike's recent rant about the end of Federation? It's a very interesting discussion going on in the community. Because he thinks that having central control allows you to reach a lot of people, like deploying something. My personal impression is that that is not the main goal. Like Federation doesn't really need to mean that you are sharing, isn't it the open source problem or the creative problem in an abstract way? We are open, but the big corporations are less open. So they are open to our things, our code, our conversations or whatever. They can do data crunching, they can do data mining on it, they can make money out of it and they return zero. I really started being scared about the Federation thing when Google closed down the XMPP endpoints. Because that means they are fucking going to kill all the interoperability. And for me, mail is important because it is like the last place or common language. It is the only universal identity anchor. If we lose that, we are screwed. More and more, with Facebook, it is going to move towards GSM identity pieces. So I don't know, hard question. I want you to believe. You said GSM identity pieces? What was that? What I am meaning is that right now for all the social networking silos, mail is the identity provider. It is your reset for everything. But more and more, if you look at the peripheries of the capitalist system, they are starting. New people, younger people, doesn't have an email. They only open an email for opening their service account and they forget the password for the email. And more and more, I am seeing this trend about the GSM SIM, the chip, being your identity anchor. They can build about it. So are you saying that email is the only right way and there is no future for protocols like signal or something like that? I am not saying that. Mail sucks. Mail actually is for spam. And we are going to have a big problem about spam if we encrypt all the metadata and for work and for university and whatever. But this is the pragmatic approach. I am really excited about things like POM that have POM. It is a project I think by Adam Landlitz, which maybe I am mistaken. But it is like an experiment towards a new messaging protocol with security considerations from the beginning. But right now, it is something that 10 nerds are using. My point with this being strategically important is that mail is going to be there for a while. And we cannot wait. There are situations in the world, like, I don't know, you are running an abortion network in Malaysia. You cannot wait 10 years until the hackers can't with the right tool. So consider all this crap. I have been talking about some transitional strategy until we kind of have some decent protocol in place. It has to be open and federated. And the thing you were talking about was POM. P-O-M-D. Thanks. Oh, questions. What's the time? We got time for about one more. Yes. Hello, hi. Hello, hi. I think one of the things you mentioned in your talk was really important. And it is around the question of why normal people either don't do it or can't do it. And it is around usability. And I think in the open source world we have lots and lots of people who are technically very good. We are enthusiastic about pushing the boundaries in terms of protocols and the cryptographic correctness and all the rest of it. And whether it is cryptography and email or whether it is something like LibreOffice, I think there is always a stumbling block which is the usability for normal people. And it is a shame. I mean, I am older than most people here. I have seen over the years great ideas which are intrinsically excellent fail because Granny Smith didn't understand the word or the icon looked wrong. Something that was relatively easy to fix. So my question is to what extent are you doing the user research, the user testing with normal people to say, actually we don't need to put the effort into our key replication or whatever it is because the thing that is stopping people is something else completely as observed by a more disciplined understanding of how users interact with what you are building. Let me search for one little thing. I didn't have time to get into it. This is absolutely important and usually it is not hard coded into the processes of the groups because we have the, I'd say, the engineering bias. We think we know. We think we are gods. We think the users are fucking stupid. And that's a very wrong... I'm generalizing. Just trying to be funny, but that's a very wrong approach and we don't realize about it. I've been talking kind of about mail, but the first part of the project we were trying to solve another different project problem which was secure VPM. The idea was having a Trojan horse because users are not going to install a desktop client for email, but they probably won't a desktop client if it is the only way to get VPM. So we spend... now we have our regrets, I have to say, but we spend some time trying to solve the other project, the other problem about VPM, cross platform and so on. And if you don't know this blog, just subscribe it. Subscribe to it. This is Gas Andrews and he gave some workshops about disability studies in a very scientific way and came up with a long list of very interesting things that need to be changed because our mental model, basically, for how the user understand and reacts to the application was not optimized. We fucking need more of these things earlier, during, afterwards. I cannot mention that one of the challenges right now is to close the feedback loop with these kind of things in a faster way. Okay, that's it. Thank you very much. Huge hand for this wonderful...
 So without further ado, please give a big hand to our next speaker who will be talking about encrypted email.  Hi, I guess you can hear me right. Welcome. Buenas, Egonom. I guess you are not in the wrong talk. We are here to talk about encrypted privacy-oriented services, especially email.  I'm going to confer something. I just finished the slides ten minutes ago. So this is my practice.  A little bit of history. We are in a very interesting place. We are going to talk about old protocols. I'd like to introduce some history about the places we are in.  This was a shipping company, a shipping factory that started in 900 and ended in 1984. When I discovered that on Wikipedia, I said, well, this is a really good omen to talk about privacy.  In the riots with the police, one person, one worker was killed here. By the way, the slides are in here. Many of those things are linked because I don't want to get too technical.  I am here more interested about talking about tools. This is the Karol crane out there. We have the whole year. We have IRC. We have mailing lists to discuss about technical details.  Actually, I'm merging two talks. Holger Krekel, I guess some of you know it. I just met him two months ago. He was going to give another talk about two words secure email.  For personal reasons, he couldn't make it. I decided to put together some of the conversations we were having and try to merge the talks. I'm intending to do two different parts. One more about high level philosophical questions, if you want.  And strategy, because we are a community that builds tools. And the other part is about actual tools. So I work in something called lib encryption access project.  We gathered four years ago to decide to make encryption accessible. My role in the team is this. I'm probably not the best person to be here giving this talk, but I was just passing around Europe and nobody else could come.  So forgive me for my ignorance. This is my first talk in kind of a serious manner. I started doing Python 10 years ago, but this is the first time I'm actually trying to present something to the world.  So, what do we want to do? We want to make privacy usable at all levels. And the motto is we kind of feel that we have to defend the right to whisper.  Because privacy is about the right to whisper. Some of the really smart guys that started this project are coming from these kind of collectives. Someone here has a rise up account.  Good. A rise up is a tech support collective that gives support for activists. It's like the GMA for social movements. And this is a problem. Because when we start centralizing things, we have a single point of failure.  But we are a non-profit. We are something more than a non-profit. We are kind of a distributed network of people that think alike, that wanted to do something in some specific way.  And just we look for the way of getting money to do it. By using grants, by using research projects. But we are more people, than the people being paid by the particular project.  And this is very interesting. Because it frees you from the startup mindset. So, I probably, since I knew I was going to be very nervous, I probably took the tips for speakers to literally. But I kind of found it fun.  So, I'm going to present an adventure in which we meet the non-heroes, I'd say the anti-heroes. That go on a quest, find some weapons, you can guess which kind of weapons we use.  We met some allies in the road. We, probably this is the only thing important from this talk, the monsters we are finding. Because we are kind of learning in their way.  And the adventures yet to come. And my goal here is to convince you that this is important and interesting. And we'd like to have your feedback.  Disclaimer. Leap is a highly opinionated project. With a highly opinionated team that builds highly opinionated tools. And this talk is given by a highly opinionated person.  So, don't take me too seriously. When I say something is bullshit, just take it as a shortcut for, this is what I think. But I like to, yeah, you know.  So, now you know the team. I'd like to mention that we are not just coders. We tend to forget about the other people in the teams that make that possible.  So, kudos to the other people that are not cis admin or coders. We have one woman that the only thing she does is trying to get money through funding research for allowing us to keep coding.  And that's much appreciated. So, the quest. Already said that. I guess if you are here is because you are interested in privacy.  And so probably it's obvious in this context that privacy is not for privacy minded persons. We cannot think that privacy is something fundamental.  Privacy and communications are a fundamental human right. And it's about the right to whisper. Privacy as the cyberpunks, cypherpunks said is the right to choose who I communicate with.  And we think that we need to be able to choose who we communicate with when talking with our friends. By the way, this is a very interesting link.  In case you don't know it, just click on it and read something tonight.  This is the typical thing. Like, okay, we need to do privacy oriented tools for journalists because they have to keep secrets, what sources and so on. Our saints, the whistleblowers kind of appreciated in the community.  And we everybody understand that they need privacy and secrecy. You probably work in a startup environment. If you are in China doing some wonderful research for selling a big thing, probably you want secrecy.  Communicating with your CEO to avoid all the Chinese industrially Spanish. Or maybe you are thinking about changing jobs and you want to communicate with another CEO and being able to blast your salary away.  How many people here knows this guy?  This guy was the one that hacking team. Okay. Here you have the whole tutorial about how he did this thing.  Let's say I'm interested in interviewing Phineas Fisher. He's probably the most wanted hacker right now that is not in jail.  So probably the only way to communicate with him is going to be GPG. How many persons here actively use openPGP encrypted email?  Good. Now I understand a bit more where we are. Probably I need secrecy to communicate with my lawyer, with my package maintainers. Thank you guys.  But yeah, seriously, when I'm traveling in India, I really, really, really would like to or need to, my mom being able to understand what PGP signing a mail means.  Because if not, whenever I'm going to be kidnapped, because I'm a little white guy with a credit card in my pocket, it's going to scam her for money.  So in general, the whole society, the point is that the whole society would need to, if not understand, at least being able to use the magical trickery that cryptography gives us.  And we have fucking failed to do that for the last 30 years. But you get the point by now.  We need, our friends use the whole society. If without privacy, the whole society cannot work.  You probably, yeah, I think you probably remember the crypto wars some years ago.  Now we have a very much interesting movie. For those who don't go to the countryside, this is a silo. A silo is something where you put the grain and from there you get the cookies in the supermarket.  So we are now in the silo world. And this is a very interesting moment to be. This is from a Tim Berners-Lee article some years ago.  You can see that the cool things were, weren't so cool at the end. Some of them were, some of them died. Ha, ha.  Smart guys. In Dante Alighieri Divine Comedy there is a very big explanation about the layers of hell.  Well, it's an interesting thing with a historical value. We now have a special place in hell, in the technological hell we all live in, for the people that use GPG.  And I'm not trying to be smart or metaphorical here. This is fucking real. In my surveillance device, I need to have at least four, five different apps to communicate with different kind of friends.  I don't know if this is the right order, but you get the idea. Some people think that seeing Alistar is totally secure. Thanks, Moxie.  We can discuss about Federation. Some people think that WhatsApp is secure because it has end-to-end encryption. Some people, I don't know why, think Telegram is a cool thing to have.  It's kind of open source-ish thing. But you know what? This is complete bullshit. This is my run minute.  It's unacceptable that if I want to get Raspberry Pi from some nice guys in there, I have to get a Twitter account.  No, no, no. Twitter is not a tool for communication. Twitter is not a fucking protocol. It's a fucking company.  You get the point. This guy, Michael Hayden, former CIA director. The most important fact in the last years probably has been, for my bias view, this one.  Metadata kills people. And it is not a bunch of nerdies that says that. This is the important thing. You were called paranoid five years ago.  Now, it's not that we think they do it. It's that they fucking say it.  So we have a nice pun on the concept of the killer app. They are actually, metadata is actually killing people.  But in some sense, we all want to have killer applications, killer libraries, killer operative systems, whatever.  And we are all here selling things or recruiting people. And the key, this is from a Snyder book.  The key to being in this place is that the things we do in the clouds, the internet or whatever are convenient and free.  Free as in beer, mostly. We believe kind of in free as in freedom, but whatever.  All the whole open sources thing. And this is a race, my friends. If we want users to use things, we have to do convenient things and kind of free things.  So it's like fighting the enemy with their own weapons. And this is the holy grail for encryption and privacy and all that.  We all are kind of looking for the thing that does the right thing, the right manner, without the user needing to do a fucking PhD.  So we use your tool. And your tool might be many things. Your tool might be infrastructure, forces admin.  How many people here maintains mail servers? So you know the pain, my friends.  Things need to be usable also for developers. I'm really amazed by learning so many things about how to make properly usable interfaces for libraries.  And at the same time, in the bottom layer of hell, we have the end users because we are highly opinionated and we tell them what they should think like.  So this is what Leap project and its many branches and heads try to do to attack the hard problems and the interesting problems at many levels,  making things so simple that you cannot screw it. I'm not going to talk about the system in part because that is mostly written in Ruby.  No, just because. This is called the Leap platform and it's for sysadmins to install systems with properly configured defaults and so on.  For mail, we also do DPM but I'm going to focus on mail here.  We're kind of presenting some libraries. I'll get there in second part of the talk and we have some desktop applications for users.  Intermission. Usually people will get out of the talk at this point saying, ah, but the user doesn't care.  The user doesn't care because we don't make them think that it is possible. We are kind of shaping their view of the world and what is possible for them and not.  We also think that the user is not going to pay but probably the problem is not in the user. Probably the problem is ourselves.  I think it was Tanker that wrote a very nice postmortem on the whiteout thing with secure email and they basically were putting numbers on how hard it is to monetize the market for privacy.  But it exists. People is willing to pay. After Snowden, governments, universities, like whole sets of huge amounts of people were willing to put money on secure email.  We can discuss what security means because they probably want to keep their private keys for the use their citizens or whatever.  But the need was there and the tools were ready. So there is another thing. Come on guys, like commodityization goes on many layers.  We can put the value on the services and let people earn money through billing for a fucking mail service and it can be as less as 50 cents a month.  If you get 50 cents a month or one euro for two months for 100,000 people, you get some nice cash for some developers to code in a valley beach.  So probably the model we want to go is to cooperate in a way that we are not only our fishes but building the tools for everyone to fish and be happy.  So in the end we want crypto but we want roses too. This is my fundamental truth.  I have been working with email for four years and I fucking don't know what email is or why people don't use it. This kind of puts things in perspective.  We think that Twitter or Facebook are the big silos but they are just a tiny spot there on the whole volume of email communication and that is only a small subset of spoken language.  So come on, it's not going to die anytime soon. I'm going to skip this. If you are the kind of person that don't take this as a fundamental truth, you have statistics and surveys and you can see the data.  So the weapons. We kind of brought some weapons from our previous, some people have been like 20 years in this business.  And for the client parts and the synchronization parts we kind of choose Python because it was kind of obvious.  We were very happy four years ago. We were told that all the hard work is done. The crypto is done. You need some glue code, blah blah blah.  The shoulder giants. It is really true. And we have the crypto there.  And crypto is very effective. It works. And we know that it works because in the leaks about NSA we know that there are two things that they really get mad at.  Strong crypto and tor. So it works. It works for a bunch of nerds. But we cannot explain the whole things that are needed to properly use or to properly be in a kissing party to the persons.  This is what Snowden made to make Greenwall able to have a fucking GPG key. It's an ugly 10 minutes video showing how to use GPG in Windows.  It doesn't work. When you have a nerd doing usability studies and doing things for the public, it doesn't work.  And at the end, this is how we verify things because we are fucking lazy. So what if I told you that we don't really need the users to understand the RSA concept that is awesome, but we don't need it.  We probably can have just some layers that do the magic underneath. A very good study 16 years ago showed that the mental models that we have to study is ability in crypto are not valid.  So we probably kind of have the criminals we deserve. So our plan four years ago in the happy moment of the relationship with the whole project was this.  Very simple. Three points, glue code, everything nice. Oh boy, how long we were.  So the thing here is getting GPG management easy and in a background manner and put it on the cloud because users have multiple devices and they want their GPG keys to be there.  Put it on the cloud. But at the same time, we want to put them on the cloud in a manner that the FBI does cannot get them when they get a server.  And it was like the later part. Okay, we just use the normal make clients. Simple, right?  So we went on a quest and four years later, we have 10 Python packages that are some shit.  This is a very good book. It says 2000 programmers, three years, four hundred seventy hundred bucks. We now have kind of eight thousand bucks in the fucking issue tracker.  And we thought our project was simpler. So we do the management. I'm not going to talk too much about it here. The logic there is probably 20 lines.  Just fetching keys from key servers. They are kind of broke. So we need to figure out a new model for sharing his.  And trolling the web of tasks and all that. But yeah, key manager. Discover the key and that's the right thing.  Trying to establish trust relationships between all keys and new keys and trying to get scores for how good a key is depending on its source.  And we want to kind of share the common parts of it out of leap.  So the nice part is what do you use for local storage to have your secrets always store locally in the client and in the server.  So it was there. It was done. The only thing you have to do is to hack some setup.py script to do bindings for SQL Cipher.  That's transparent as 256 encryption on top of SQL. Fine. Spaghetti is there. It works. And we have to merge the pie three four because we are fucking lazy.  But it is there. It is usable for many other projects. So the big, the important part of the talk.  It's called something something called solid that which is basically the idea of we manage the keys. We put them on a magical library that's the synchronization of data that has been locally encrypted in a way that the server can never tamper with it or infer anything useful about it.  The design documents are there and the code is there. Security goals encryption in the client side and get the local storage has to be resistant.  To online offline attacks and to that, the tampering on the server cause we have to assume the service malicious.  Same goals consistency. Same flag. We don't want to single the data has to be multi platform. We fail at even think about mobile. We are on the desktop part.  And these things are in the far future for now.  Well, not so much for this. And for usability, we need something that is available so the user can always get his data.  User needs to recover the secrets if they forget the password.  And we want to have something general cause we also want to express this to things like having a pocket application or a to do application or whatever.  So probably something of this sound similar to what the Ubuntu one guys were doing. So we said, hey, so super nice.  And they had a library that was basically an abstraction layer to put JSON documents on a storage and sync it.  And so we started using it and doing hacks on top of it. Now we kind of have fork.  Although if the project gets to the life again, we probably can use the whole thing again.  So we put couch on the server and we put SQL cipher on the client.  We have another thing to be for metadata and a pool to do things with a key manager and new PG.  The password never arrives the server cause we do something very smart. It's a cell knowledge thing called SRP.  We derive keys to get stronger keys from smaller inputs and we basically do encrypted blocks and put them on the store and things.  So this is the secrets. The blocks have is just a JSON document with a cipher text of the original thing you put in there.  You create things using things. Only that.  The thing for mail is that we have like the whole mechanism for mail to arrive on the traditional SNTP world, put it on your inbox,  decrypt it, do the pieces and put them on the storage. So you can process your mail on one device and have your already seen inbox in many other devices as long as your GPG keys.  And you have a very simple rest API to sync.  Allies. We kind of trust on Thunderbird. We wrote a Thunderbird plugin. We have a desktop client that exposes iMac and SNTP proxies locally.  Thanks to all this, this server was kind of easy and nice to do. Thanks to all these people.  And we kind of started collaborating with ThoughtWorks because they said, oh, this is very nice encrypted replication of data so we can put them on a server.  This is our client.  And this would be the mail user agent.  This is the server part with the code GDP blogs. And what the pixelated project is doing is putting all this in a server and serving a Python user agent that does the webmail.  So we can put our clients in their server, but we also close the loop and we take the webmail and put it in our local client.  And you can do the two things. The corporate mode in which the private keys are in the server or you can use it shipping it inside a desktop only application.  And look like this and people is really excited about this kind of Gmail-ish things that do all the right magic in the background.  Monsters.  My biggest regret is not having dealt with complexity before.  And that probably comes from our relatively unexperienced with big projects and Python and packaging and so on.  We start having too many packages. It's fucking unacceptable. New customers find it very difficult to understand where each thing is.  When you start overloading inheritance things get crazy very quickly.  We also have some kind of complaints about the whole twisted deferred thing for newcomers, which is kind of a religious war.  But right now it is very nicely isolated so people can just use the REST API and forget about the things that are happening in the background.  Another thing that has delayed us a lot is trying to get in the client server thing, your local demo, mixing together the QT paradigm with its event loop, the twisted iMap server, and some other things.  Simplify.  We are at that point now trying to simplify it. The thing works. The thing has tests.  People is contributed. We have a big company like ThoughtWorks contributing code, but we need to lower the barrier to do a significant contribution to the project in general.  And some adventures are ahead.  Part of the team now is working in a couple of European Union research grants that have to do with key server validation, key exchange, and trying to bridge, trying to tend some bridges across different privacy projects.  We want to share some of the knowledge and even code. And Panoramics is another cool project about doing mixed master networks for privacy.  We are one of the first clients to implement a new draft, a new standard proposal, which is called Memory Hole, that tries to attack the design error in mail, in a centipede, that all the data, all the headers are going in clear text.  Last week we were at the OpenPGP summit, and it seems that Thunderbird has already implemented this. So the whole idea is that you put all the headers, you put them inside the encrypted and signed mail, and you replace the headers with dummy steps.  So you have a very nice and simple way of protecting the mail while in transit.  There are also some nice proposals to do forward secrecy in OpenPGP, doing something quite similar to what the signal protocol is using, this ratcheting mechanism, to avoid that if an attacker can get some of your keys, it cannot recover the whole...  It is a story, it is there, so trying to break the reconstruction of the whole communications. This is probably going to be something really, really exciting in the next year.  And in Soledad, we are in a point where we are not finding any important bugs now, but we need to do some things for a scale.  One of the main things we are going to do in the next months is trying to break the atomicity of the syncs, because right now everything is the same pool, and that's kind of shitty.  We want to be able to sync all the keys first in a new device, and then probably all the headers, and then probably the attachments on demand.  We have to deal with event-to-unconsciousness in a nice manner.  There's a lot of things that need to be done, and that's it. This thing is my fingerprint, and for the young people, this is not a Twitter handle.  This is something called IRC. We are there, and I'd be very, very happy to talk to you guys and learn all the possible things you can communicate with me.  So thanks for an absolutely fascinating talk. We have managed to leave a full ten minutes for questions. In fact, almost eleven, which I think is a great idea.  I have a million questions, but you don't want to hear my voice, so I hope you have the same questions in your heads that I have in mind.  Who would like to have the first one?  Thank you very much for the talk. Do you have any idea how to deal with a big amount of encrypted email, how to search in it?  What to do with a start-away encrypted email when the keys elapse? What to do in the long run?  What we are doing now is that we, it's different in this case. In the original BitMask client, what we do is that we don't store the encrypted blocks anymore.  We use the very nice and old code in the standard library for, it has like ten years ago, ten years code that pieces, cast the pieces of the MIME 3 and we store all the metadata in different documents in the document store,  and we delete the original encrypted block. So we can do efficient search mainly by headers. We can build indexes for searching for the main things in headers.  Pixelated project is using a different approach. They are using push, I think it's pronounced like this, and they do full text search on the whole body of the mail.  And they store, what they do is that they build the index for doing full text search locally, and they encrypt the index and they store the key for this block inside Soledad.  So you have locally quite nice and efficient index to do any kind of, we probably could do the same with NodeMatch, just trying to block and encrypt the things with NodeMatch and just store the keys for the encryption inside the metadata database.  More questions. I came across an encrypted email client called MailPile, which sounds kind of simpler but less ambitious. Can you compare the two? Because I felt you were trying to get done in time, which was great.  But when you started saying here, let's have a client in the server and a server in the client, I was lost.  I need probably better diagrams for that. We are really similar to MailPile. Actually, the Pixelated project started to consider using MailPile for the frontend.  The things that we, I personally found MailPile kind of monolithic and we tried to decouple the things to play nice with the whole provider infrastructure.  So MailPile is probably doing this whole thing in the client. They do their web server thingy, they do all the handling for GPG and they do the storage.  It's basically the same thing. It's a webmail with encrypted local storage. They don't attack this, as far as I remember, they don't attack the replicability problem.  So we kind of started from the upper layer and this is a very hard constraint. I got MailPile running with my agent.  So at the end, I don't care. We kind of focus on this layer and the user agent should be pluggable. MailPile is really, really nice and for the amount of funding they got, they are really far in terms of features.  So I really would like to plug it into the whole Solidarn Encrypted Storage.  Good. Yes, the main difference is replication. That's great. Okay, any more questions? Yes.  So one of the things I've been struggling with is can we really escape it? I mean, even if we use something encrypted, people will communicate with us Gmail.  Even if we use encryption, if it's on the phone, I mean that's either Android, I mean it's either Google or Apple. So can we really escape it?  Or is the only way to communicate securely is just, you know, low tech, just meeting people?  That's the only thing I have an answer for that. It is totally true.  Our code now, haha, I kind of screwed it. We had code in GitHub and we are moving to another GitHub instance in which a requirement is that you have an email that is not from one of the big mail providers.  As you say, it doesn't make any sense if you are hosting a mailing list server with some pretensions of privacy and one only person in the mailing list has a Gmail account, end of the game.  Have you read Moxie Marlin Spike's recent rant about the end of Federation? It's a very interesting discussion going on in the community.  Because he thinks that having central control allows you to reach a lot of people, like deploying something.  My personal impression is that that is not the main goal. Like Federation doesn't really need to mean that you are sharing, isn't it the open source problem or the creative problem in an abstract way?  We are open, but the big corporations are less open. So they are open to our things, our code, our conversations or whatever.  They can do data crunching, they can do data mining on it, they can make money out of it and they return zero.  I really started being scared about the Federation thing when Google closed down the XMPP endpoints.  Because that means they are fucking going to kill all the interoperability. And for me, mail is important because it is like the last place or common language.  It is the only universal identity anchor. If we lose that, we are screwed.  More and more, with Facebook, it is going to move towards GSM identity pieces.  So I don't know, hard question. I want you to believe.  You said GSM identity pieces? What was that?  What I am meaning is that right now for all the social networking silos, mail is the identity provider. It is your reset for everything.  But more and more, if you look at the peripheries of the capitalist system, they are starting. New people, younger people, doesn't have an email.  They only open an email for opening their service account and they forget the password for the email.  And more and more, I am seeing this trend about the GSM SIM, the chip, being your identity anchor.  They can build about it.  So are you saying that email is the only right way and there is no future for protocols like signal or something like that?  I am not saying that. Mail sucks. Mail actually is for spam.  And we are going to have a big problem about spam if we encrypt all the metadata and for work and for university and whatever.  But this is the pragmatic approach. I am really excited about things like POM that have POM.  It is a project I think by Adam Landlitz, which maybe I am mistaken.  But it is like an experiment towards a new messaging protocol with security considerations from the beginning.  But right now, it is something that 10 nerds are using. My point with this being strategically important is that mail is going to be there for a while.  And we cannot wait. There are situations in the world, like, I don't know, you are running an abortion network in Malaysia.  You cannot wait 10 years until the hackers can't with the right tool.  So consider all this crap. I have been talking about some transitional strategy until we kind of have some decent protocol in place.  It has to be open and federated.  And the thing you were talking about was POM.  P-O-M-D.  Thanks.  Oh, questions.  What's the time? We got time for about one more.  Yes.  Hello, hi.  Hello, hi.  I think one of the things you mentioned in your talk was really important.  And it is around the question of why normal people either don't do it or can't do it.  And it is around usability. And I think in the open source world we have lots and lots of people who are technically very good.  We are enthusiastic about pushing the boundaries in terms of protocols and the cryptographic correctness and all the rest of it.  And whether it is cryptography and email or whether it is something like LibreOffice, I think there is always a stumbling block which is the usability for normal people.  And it is a shame. I mean, I am older than most people here. I have seen over the years great ideas which are intrinsically excellent fail because Granny Smith didn't understand the word or the icon looked wrong.  Something that was relatively easy to fix.  So my question is to what extent are you doing the user research, the user testing with normal people to say,  actually we don't need to put the effort into our key replication or whatever it is because the thing that is stopping people is something else completely as observed by a more disciplined understanding of how users interact with what you are building.  Let me search for one little thing.  I didn't have time to get into it.  This is absolutely important and usually it is not hard coded into the processes of the groups because we have the, I'd say, the engineering bias.  We think we know. We think we are gods. We think the users are fucking stupid.  And that's a very wrong... I'm generalizing. Just trying to be funny, but that's a very wrong approach and we don't realize about it.  I've been talking kind of about mail, but the first part of the project we were trying to solve another different project problem which was secure VPM.  The idea was having a Trojan horse because users are not going to install a desktop client for email, but they probably won't a desktop client if it is the only way to get VPM.  So we spend... now we have our regrets, I have to say, but we spend some time trying to solve the other project, the other problem about VPM, cross platform and so on.  And if you don't know this blog, just subscribe it. Subscribe to it.  This is Gas Andrews and he gave some workshops about disability studies in a very scientific way and came up with a long list of very interesting things that need to be changed  because our mental model, basically, for how the user understand and reacts to the application was not optimized.  We fucking need more of these things earlier, during, afterwards.  I cannot mention that one of the challenges right now is to close the feedback loop with these kind of things in a faster way.  Okay, that's it. Thank you very much.  Huge hand for this wonderful...
Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_0_791.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_792_995.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_996_3215.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_3216_3287.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_3288_3539.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_3540_3899.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_3900_4571.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_4572_4979.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_4980_6743.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_6744_9503.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_9504_10283.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_10284_11723.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_11724_12071.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_12072_15899.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_15900_18683.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_18684_20183.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_20184_21167.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_21168_21587.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_21588_21947.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_21948_22499.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_22500_23723.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_23724_24311.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_24312_24911.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_24912_25007.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_25008_25295.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_25296_25427.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_25428_25655.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_25656_26195.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_26196_26303.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_26304_26759.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_26760_26939.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_26940_27131.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_27132_27179.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_27180_27719.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_27720_27767.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_27768_27923.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_27924_28859.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_28860_30527.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_30528_33023.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_33024_34055.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_34056_35087.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_35088_37931.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_37932_38051.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_38052_38147.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_38148_38651.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_38652_38879.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_38880_39539.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_39540_41423.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_41424_42479.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_42480_43331.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_43332_43631.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_43632_43715.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_43716_43811.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_43812_45503.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_45504_51239.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_51240_51455.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_51456_52019.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_52020_52631.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_52632_53567.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_53568_53855.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_53856_54563.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_54564_61523.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_61524_61955.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_61956_63155.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_63156_67367.png Kali_Kaneko_-_Against_the_silos__usable_encrypted_email___the_quest_for_privacy-aware_services_67368_67375.png