 He is the creator of VMAX and Gitter. Somebody started, it was probably him, a Gitter chatroom earlier that people have been talking on a little bit, I think. I don't know if he's going to mention that, but hopefully ask him a question about it if he hasn't. He sort of converted from Ruby to JavaScript a year and a half ago, which you guys will love and I, as a Rubyist, will hate. But he sort of saw what the NSA had been doing with data and suddenly got quite passionate about adding privacy into conversations and things online. And that's sort of what he's going to talk to you about today. So if we can give a warm welcome to Mario Pompilio. Hi, Maria. Hello, everyone. So first I'm going to do a small disclaimer about this talk because I'm going to be talking about cryptography and security and I'm not a professional cryptographer. So if you see or have heard something that I'm saying that is not correct, please, during the Q&A, correct me. And tell everyone about it because security is like a very complex topic and it's good that we need to share this information and it's a process. So it's something to have in mind and if you see something that is not correct, just tell me afterwards. So my name is Mauro. You can find me on Twitter under that name. By during the day, I spent my time working in Mainlogitha AM, which is a product that is easy to have integrated chat. So you can use it for chatting with your teams or if you have an open source project, you can have a public room, whatever you can join and talk. And the rest of the time, I spent my time working on VMAX, which is an in progress project I'm developing. This is Alice, my cryptography girlfriend. She actually knows she's a cryptologist now because I told her about. And as you can see, this is screen capture from a browser. We are having a conversation and this is my dad. We are having a, he's using his Android phone. We are having a peer-to-peer encrypted end-to-end chat. And what's remarkable about this is that they are not computer experts. Like Alice works with computers, she's a graphic designer, but she's not an engineer like us. She, like common people, is not aware of cryptography most of the time. And my dad is a plumber as well, so his contact with computers is not like the same we have. So I'm going to try to encourage you during this talk to think more about working on services and developing products and services that are more respectful towards the privacy of your users. Mainly using, through the use of encryption and through use of more security-oriented platforms. For those that are not aware with the term, a cryptography is someone that basically uses encryption to hide all his communications. I guess the Crypto, the anarchist part comes because of the political, like, exceptions of the term. Because we live in a quite privileged society here because we can share our political views quite freely. But there's people that can't because they live in different kind of, under different kind of governments or oppressive regimes that you're not allowed to share your political views freely. So I got interested, and my interest in security started growing up more and more since last year when this man, I hope you recognize him, I hope everyone recognizes this man, Edward Snowden. When he leaked all these documents about the questionable practices, the five eyes, the so-called five eyes, which is like the American government and the UK government and a few more. The practices they are doing about basically trying to collect all of our traffic on the internet. Basically trying to harvest all this data and control and analyze it. And sometimes it's not even legal, and the legality of this is quite a grey area because we have laws that are supposed to protect your privacy and your data, but those laws are bound to a country. And on the internet, you might be using services anywhere in the world and your traffic might be being routed anywhere. So you're not in control of where your data is being stored, what services are you using. Someone coined last year, while this was going on, this was around May last year, the summer of surveillance, but it was more like the start of a surveillance-aware era where we, through these documents that are being released still today, like so much of this that is being released still today. And basically we came to all the knowledge that these government agencies run pretty scary programs like for example Tempora is a program that is being run in the UK. So it's basically like a three-day buffer of the whole UK traffic that the GCHQ keeps for analyzing and for to have access to it. And like other programs like Prism that basically are snooping traffic on fibre optics under the ocean. It sounds kind of like science fiction, but it's a very real thing. So it basically learned that mass global surveillance is not like from a book or an Orwellian book, it's like a reality. And the problem with this is common people is not, doesn't have the same knowledge as us as engineers have to decide what of their activities are private and what is not. People like my girlfriend, my dad or your mom or anyone expects privacy from things that are not necessarily private. So they expect privacy from sending a faithful private message to someone else because they assume that it's not on the wall, so they must be private. Or that the plain text emails you receive in your Gmail account or in any web email service is private. And an email is the most insecure thing. Email is just plain text or in a disk somewhere. Everybody can see something that has the keys to that server and can read it. So they are not, all these services are not private at all. And how private is like, people think that ephemeral things like a video chat conversation that happens over a period of time and then disappears because it's something you, you're having a chat with you and it's like during the last five minutes and then it's gone. It's not really because this is a quote actually from one of the leaked documents about a program called OpticNerve that is GCHQ was running. And it was taking still images from video chats of all the Yahoo users. Yahoo was not aware of this, but they were not including the video conferences anyway. So people that have access to all of these, the lower infrastructure of the internet can easily snoop into these communications. So this shows like a problem with an inherent problem with the infrastructure of the internet. We have centralized services. Like most of the services we use are completely centralized. You go and reach a server and then everything is being relayed through that server. Not just like the pages you receive when you're visiting a page, but also most of the services you use are very centralized. There's a huge lack of encryption. There's like, people doesn't take this into account when they develop applications. And I think they should more and more. And there's another problem that is trust, because with security you cannot trust something that you don't have access to, that you cannot read. So that's why open source is like a very powerful tool. There are solutions to all these problems. There's like big message, there's BGP, there's of the record chat. You can expose services, you can store your email in a Tor hidden service somewhere. But the problem with this is the same as I said before. Like if you tell your dad that you're going to send him an email, encrypt in BGP and tell him to generate a key and send the public key, he will be like, why are you talking about that? People can be bothered to do these things. So where does JavaScript comes in all of this? Where is the position of JavaScript? So I think JavaScript is in a very interesting position. And that's why I wanted to give this talk in the JavaScript conference because the community of JavaScript to start is like everywhere. So everybody that has access to the internet has a browser that runs JavaScript. So it's like everywhere. And also the community, the JavaScript community today is huge. And it's very, very diverse. There's like people that have been doing JavaScript, front-end JavaScript for years and years and they're like absolute experts. And have a UX kind of eye as well. And they know how to do applications that are useful and easy to use. And there's also like the new node people that kind of joined over the last years that is like more hardcore back-end people. So this combination is like really interesting. We have like the whole stack end-to-end can be written in JavaScript. And there's presidents, there's like really interesting apps that have been written in JavaScript and are incredibly useful for a lot of people. One of them is CryptoCAD, which is a project by a guy called Nadim Qwaisi. He wrote CryptoCAD to communicate safely. CryptoCAD is kind of centralized because it uses XMPP as a transport. XMPP is the same technology like Google Chat uses. It's a messaging platform. But all the content you send through these services is encrypted on the browser before leaving it. So uses of the record messaging that I showed before. And then there's MailValue as well, which allows you to send encrypted, PGP encrypted messages using any webmail service. So that's kind of proof of that JavaScript. There's a lot of people that think that JavaScript is not the right tool to write secure services. But this is kind of proof that it can evolve. And I hope in the future we will be more and more aware of this and it will evolve to a more secure environment. So almost at the same time the leaks were happening and all of that, I discovered kind of at the same time WebRTC. And in my opinion it's one of the most promising technologies, like JavaScript technologies, one of the most promising ones. And for all those three problems I mentioned, this is kind of like the three solutions we can find in the JavaScript world. So WebRTC that can help you to write decentralized services, peer-to-peer connected services. We have OTRJS, which is of the record implementation in JavaScript, which is an implementation that CryptoCAD uses. And it's not fully audited today, but there's a lot of security people looking into it. It's improving every day. And we have Open Source, which is probably one of the most powerful tools we have to write applications on top of these two technologies. And OTR is Open Source and WebRTC is Open Source as well. So I started with a project, which is the one I mentioned before, VMAX, because I used to use Skype a lot because I'm from Argentina, I live in London, I live here in Barcelona and I have family here, so I talk with them all the time. I have family living in Argentina as well, so I talk a lot with people online. But since I learned about this, it was like there has to be something better than this. We should be able to have a platform or an application that allows people to use, to have secure communications, but at the same time being really easy to use, so anyone can use it. It's someone that is not a technology expert or an engineer. So this is the main idea. It's like a feature-wise. It's the same as Skype or Google Hangout, but in the browser because it's always implemented on top of WebRTC. There are no plugins of Flash, and obviously it's peer-to-peer and Open Source. The stack as well is... because I like a lot of coffee-script. I like a lot of people I think that have been here today. So I choose... VMAX is reaching coffee-script, like everything back into front-end. The backend is written in Express, which is very, very small, because the only thing it does is signalling, which I'm going to show you in a moment. And then there's a backbone for the front-end, and I'm using Browserify to package everything. How many of you are using Browserify to package your client code? OK. It's a good amount, but you should check it out because it's a fantastic tool, and it allows you to write very concise common JS modules so you can reuse and you can even put an NPM and then just package them into front-end. With VMAX, Browserify, I'm going to show you the code quickly just to show you more or less how the code is structured. So the JavaScript is all... You can do, like, node style requires of your views or your models or everything you have, and then you can just export all of those. So, for example, here, at the top I'm requiring the user model, and the model, the only thing it's doing is... This is a user model which basically handles all of the complexity about the OTR and all that stuff. But at the end, you do just a model export, like you do in a node module, and then you can require that from anywhere in your code. And then when you bundle everything with Browserify, Browserify takes that into account and builds, like, a single JavaScript file that you then... then you can deploy anywhere. And that's... Where is the browser? Here. That's very important in this case because you don't necessarily want to run JavaScript, sensitive JavaScript code in the browser. The browser is, like, really a really insecure platform. So ideally you will run your JavaScript sandbox somehow. So, for example, CryptoCAD is a Chrome extension. So Chrome extensions run isolated. They have access to the browser, but the browser can access the JavaScript that is running inside the sandbox of the Chrome extension. And that way, the same thing does MailVlog. So MailVlog, when you have a form where you're going to write an email, a PHP encrypted email, you click on it and you get, like, a text editor that runs in a different window. That window is running locally. Those JavaScript files and that HTML is being logged locally from the extension itself. So there's no way that someone can, like, because with JavaScript... It's working? Okay. With JavaScript, the easier key logger in the world is on key press event. So anybody can, like, who can on key press event on anywhere that you're running on the browser and basically log everything you're saying. So this is the way you isolate yourself from that. And you can do the same... You can also ship an old WebKit application where you can just have this bundle JavaScript file that you put in a WebKit and it runs isolated in a desktop environment. So I'm going to explain a bit, like, the mystify a bit WebRTC because everybody knows that it's, like, peer-to-peer and it's cool, but no one really kind of went deep into how it works. I'm going to try to explain how it works. It's not super complicated. It's, like, very simple stuff. So support for WebRTC nowadays you can run in, like, most of the browsers, the modern browsers. So Chrome for desktop and Android and Firefox for desktop and Android. And Opera is fully available, like, the features. There's interop so you can call... You can have a connection that goes between a Chrome browser and a Firefox browser or an Opera browser. And there's also, like, native libraries. So you will see that WebRTC has a lot of these video and audio functionality, but, as well, it has a really important part that is, like, the peer-to-peer data that you can send through devices. So if you need it with Java and Objective-C bindings, you can implement something that is a WebRTC client that doesn't expose video or audio or media of any kind. It's just, like, sending and sharing data. So basically it's three... WebRTC is split into three main components. One that allows you to access input devices like your camera and your microphone. One component that coordinates all of the peer-to-peer, like, logic. And another one is the one that allows you to send, basically, arbitrary data. And it's separated into three main APIs. The media stream API, which is the gate user media. Someone showed that yesterday capturing the... was the give streaming. So that was capturing the camera with the gate user media. And what it gives you is, basically, you can pass constraints through it. So... Actually, quickly. So you can... This is the actual call. So you will do gate user media. I'm using an adapter because this is, like, a polyfill. Some of the APIs are namespaced still. But gate user media is the JavaScript API. And then you will pass some constraints. And then it's accessed in an error callback, basically. On the constraints, you can pass... You can say if you want audio and video, or you want just audio and... Or video. In the video you can pass the resolutions you want to access. The frame rate you need. If you're using a mobile device, you can say what camera you want, the user facing camera, or the camera facing the other side. And then, on the success callback, you get basically a stream, a blob, then you can use... You can put as a source for a video element. For example, you get, like, video. Then the RTCPR connection is the main component. Basically, it's the WebRTC itself. And it hides a lot of complexity. It has a lot of... That's a lot of things for you that are really important. The single processing handles all of the encoding for audio and video when you need to send that to a remote pier. For other uses, the two codecs, Opus and VP8, are open source and royalty-free. Google made them open source and royalty-free, which is really cool. And then that's all the security aspects of the communication. I'm going to talk a bit more about that. And the RTC data channel. Once you establish this link between the two browsers, then you can create a data channel between them, which is very, very low latency, because that's, like, straight, peer-to-peer. And then has a WebSockets API, which is, like, super simple. You're going to get code that you're using for WebRTC for WebSockets and basically kind of port it to... Use it with data channels. And it secures the connections using DTLS. But this is still... This is not magic. Both browsers still need to discover each other. So you will do... You need a signaling method to send session descriptions. Session descriptions contain information about how... Basically about what resources are you exposing if you're sending audio and video, if it's just data connection. And the transport you're going to use to send those session descriptions from one browser to the other is completely abstract. It's up to you. You can use WebSockets. You can use server-centered events. You can do XMPP. There's a lot of people using XMPP for the signaling. We'll go over to C. And this is kind of how it looks. You will have, like, a public server that you will use for the signaling. And then once the two browsers exchange candidates... It's called ICE candidates as well, because they have information about your IP address where the other person can reach you. When they exchange that information, then they establish a particular connection. So the problem with this is that we don't have public IPs for everyone, right? So you're always behind the NAT. A NAT basically allows you to have a lot of computers behind the network and then expose them all of them going to the Internet through one single IP. So what this does is it uses these two technologies, a standard term, that allow you to... When your browser tries to connect to a different one, to know what his public IP is, queries the standard server and says, like, what's my public IP? And when does this request, it opens a port going out. And that information is the information that the standard server returns back. So the standard server tells you, okay, you're on this public IP and you open this port, the port 40,000, when you went out. Then you put that information in the session description and you send that to the remote partner. And the other browser will try to connect to that public IP and that port that is open because you opened it when you did the standard connection. It sends... All of this happens is, like, isolated inside the eyes component of WebRTC. That sends... It's not just your public IP. It sends, like, all the IPs that are available. So you will expose your local IP or your machine in the local network and you will also expose the public IP. So if someone can reach you on your private network, then the connection will be peer-to-peer but it will not go out to the internet. It will be established in the local network. This is kind of how it looks. So your peer will go through an app to the standard server, ask for this information, and then send that information through the signaling channel to the other browser. That will do the same and then you will establish the peer-to-peer connection. And the turn server, which is a relay, is what you will use as a fallback. So if you cannot establish because you are behind some kind of a very restrictive firewall or something, what you will do is get this information, send it, if the other partner cannot reach you, they will use the turn server to relay all of the traffic. It's not peer-to-peer anymore. You will need a relay that has to be accessible to all partners but is still encrypted end-to-end because the relay, the only thing it does is relay packets from one machine to the other. It doesn't do any decryption. It can't because the TLS uses a self-sign certificate on each side that is contained on the browser. This is kind of how it works. So the problem with this is that if you use, you have to be careful how you do your signalling, it has to be secure, the signalling itself. So all of the encryption for the data channels and for the peer-to-peer connection is handled by a webRTC, but the signalling you have to basically is your choice. And for VMAX I'm using of the record messaging which usually is used for instant messaging because you're sending encrypted messages but you can authenticate the messages you receive through the signalling. So if someone sends you an invalid session description that is encrypted, that someone else encrypted or is being tampered, you will basically discard it and not use it. So if you want to play with this, I'd really encourage you to play and start using it to build something, just build something crazy. Peer.js was mentioned yesterday, Ben did an amazing demo yesterday. Peer.js is mainly for data. They have media now so you can do media connections but it's mainly data. Then there's simple webRTC and there's a few links. I'm going to share the slides later on. I will talk about the data. This is a lot of projects that are using webRTC for non-conventional video conferencing services. There's ShareFest and ShareDrop that basically allow you to send files peer-to-peer from the browser itself. So basically on ShareFest and ShareDrop is like a clone of an AirDrop that you can on the Mac to when you open it. The interface looks exactly like AirDrop and then you can share files through that. WebTorrent is something similar to what someone showed yesterday in the Lightning Talks. It's basically a webTorrent client that runs in the browser over webRTC. It's a very interesting project. There's a peer server which is a server to serve pages, actual pages from your browser. When you establish a connection, then you can serve content as if you are a web server from your browser itself. The Tor Flash Proxy. Tor is a traffic anonymiser and they have a Flash Proxy that allows you to basically connect to... The Tor traffic can be like a sensor where you are depending on your geographical location and the Flash Proxy allows you to connect to your Tor client remotely through... It used to be through a Flash component but now they are migrating towards webRTC so they are trying to use webRTC to have peer-to-peer connections and basically have a similar routing that they use for Tor on top of webRTC. So there are a few readings that if you want to start, I'd really recommend you go through this post because they have a lot of information about everything I explained but even in more detail. With this you can build basically anything you want. And there's also Discast WebRTC which is the main discast group, the mailing list for WebRTC. And that's it. Basically what I want is to encourage people to start using these technologies that are amazing and are like on every browser, every one of you that has a Chrome browser running or a Firefox browser running here can use it. And that's it. I have a question related to the Heartbleed bug. You mentioned that open sources are the way we can trust software rather than closed source. What is your take on that? Well, the thing is, the fact that it's open source doesn't mean that it's secure itself but at least gives you the chance to go and dig through the code. And the thing we helped with is that at least it was discovered and was fixed. If it was a problem that was in a private and a closed source code you would not be able to even discover it and even less fix it. So the fact that it was open source, it was a very critical bug but at the same time we managed to evolve it. Is that what I said at the start? You cannot assume that everything is secure from day zero. Security is like a process and it's in our hands of everyone in this room to go through all this code and check that it's not doing anything malicious. So that's basically the advantage of the open source. There's another one on the front here. Hi. I'm not a big security expert in nothing. I don't have that much knowledge but from what I see what we are trying to do is check out the middle man or make a direct connection between peers but in our time of mistrust that we have now we know for sure that like a certain certificate of truth is not that trustworthy. There are injections from governments into the traffic. Is it possible in this solution to inject a third peer between the two partners? Yes. No. Do you communicate really like you could receive from one part encrypted to the other and take it back or no? Basically when you connect, when the two peers connect when they first established the connection like the actual connection then they do the DTLS like handshake and that handshake is exactly how TLS works how SSL works in your browser. But you have to go through a server or something, no? No. That handshake is done peer-to-peer itself. Once they manage to establish a connection a TCP connection between them they do the TLS handshake. And at that point you are directly connected to someone else. Before that? So they know about each other they go through a server or something or no? It's through a signalling server. The signalling server sends on these session descriptions one of the fields it sends is a fingerprint of the certificate you have on your browser that your browser generates for that connection. So you put there a man of the middle attack in middle or no? No because if you send a malicious fingerprint that is tampered you can modify that and then you can send it to the other browser but then when they connect the handshake will be invalid because your browser will verify the fingerprint against the other browser. I was thinking more about tunneling so I get a fingerprint of you. If you use a tunnel I'll get another one. I don't know at that level if you can do something on the relay. I see a missing link there is this missing component that you have always to trust at some point in the server or the central lines of internet to give you that trustworthiness that normally you still need some kind of physical access or something to, I don't know if you understand me. If you want to get in detail more or less how it works. This sounds like a good opportunity for a conversation over coffee I think. That's all we've got time for. Don't push off because we're about to do the raffle but let's give Mamma a big round of applause. Thank you.