 Hello everybody. Hi. So this is the first time... Hold on, I got my mic straight. My first time speaking in front of security folks. Usually I talk about my stuff in front of Ruby on Rails programmers. So... Oh, no. No, okay, who hates Ruby on Rails? Raise your hand. Who thinks Ruby on Rails stole your Java lunch? Oh, no. I hate to tell you, but Sun took that by making it very big and hard to eat. Just the Ruby part, yeah. So, a bit about me. How many people actually know who I am? I'm like sort of famous. I am. I'm serious. Don't laugh at me, dude. Say again? Oh, maybe. Actually, I've given my autograph out. Yeah. I've signed a boob. Have you signed a boob? Oh, okay. No, okay, so I'm a programmer and basically got into the Ruby on Rails stuff most recently and wrote a web server called Mongrel. It's a really tiny little Ruby on Rails web server. There's some people whose entire companies are built on that, so they're going to be really pissed off when I change the license to commercial and make them pay me. Ha, ha, ha. No, I won't do that. I'm sorry. No, it's totally free, and it was a web server that I wrote maybe about a year and a half ago. So that's kind of where I got a little bit of my fame. And also since then, basically just speaking and talking and being sort of funny and obnoxious. And I have a laptop that has a screensaver, so Legos will see this. Anyways, so my talk today, though, is about something that's not Ruby on Rails, but there is some Ruby in it. And my talk is about social stuff, not tech stuff. So when I start talking about this, a bunch of you are going to scream, but it's a technical solution to a social problem, and it's not. It's actually a technical solution to a technical problem that was created by a social problem created by another technical solution. Okay? So once you can wrap your head around that, you'll get it. And we'll see if this works. I'm using, like, ghetto arch Linux, which turns off my main screen, so you'll have to be my eyes. All right, so first off, my project is called U2. U2 is the Maori word for this revenge system that they had in New Zealand back in the day. It was literally like if your son had killed someone else's grandfather, then 100 years later they could make that guy pay three pigs and some land or money or whatever. And it was this really intricate system of retribution and revenge and reputation, and it carried along family lines. And I got the name U2. I had been working on this project for, you know, like two years thinking, you know, hey, how can we add more social controls to internet communications? Because I gotta tell you, IRC blows. Who likes IRC? Like, honestly, who likes IRC? Okay, like four people like IRC. But do you think IRC could be better? And you notice my math is off? I mean, totally, the crypto is going to suck in this thing, right? Okay. It was actually more like 25, I don't know. So, okay, IRC just sucks, right? It seems to be like real-time spam. It's just the worst thing possible, okay? So I thought, how am I going to get rid of IRC? Like, IRC is so bad. And I said, oh, what I need is, you know, come up with... I was studying sociology at the time, social network analysis. I was like, you know, let's add some of the social controls that you have on the internet, or, you know, in regular human communication to the internet. Like, for example, you can walk away from people. You can punch them in the nose. You can call the cops on them, these kinds of things. Let's see if we can do that. So this turns into this huge, almost philosophical exploration. And I have this problem. I can't work on a project until I have a name for the project. I read this article about this guy who's an actor in New Zealand, and he gets pissed off because Amazon took four days to send him a book instead of two. So he does the research, files the claim, gets $3,000, and tries to invalidate the one-click patent, and actually comes pretty close to doing it. And in the middle of the article he goes, and I felt it was time for a bit of Utu. I go, oh, Utu is like this great word. What is that? He's like, oh, it's a Maori system of revenge. It's the Sumerian god of the dead. It's like a really great name for the whole project. And the grand experiment is it's a sociology experiment. I want to see can you actually try to solve a social problem, right? Basically really poor communications on IRC with a technical solution. So it's doomed to fail, but I want to see how far the envelope can you push. How much can you do with it, right? So what I've got is kind of three pieces of the philosophy for Utu. And when I say I want to kill off IRC, right, is I want to basically try to not really replace it. I don't even think Utu will make a dent in IRC. There's just too much porn, trolls, griefers, assholes, dickheads, operators, botnets. I mean IRC is great for like 90% of the people on the internet, right? I mean all the people running Tor and FreeNode and all that stuff. Oh those guys are great. I want that 10% of the internet that actually wanted not waste their day chatting with other dicks and jerks, right? I actually want to have meaningful communications and not have to do a little spam. So what I came up with is kind of the cornerstone of human communication. And this is just me and I don't know shit. You have to have strong identity. So you have to know who I am and who you are. This is why we have passports, why we move around, why we have identity, why it's also kind of difficult to subvert. It's a really flexible concept. It's hard to define. So that's a difficult piece. You have to have reputation. So you have to know my reputation. When I started this presentation I wanted to do. I said I'm a hacker. I've coded a parser. I wrote a web server. How many people here wrote a web server? Is your web server famous? Okay. Ha! I have a reputation. It's not a... Huh? Oh you wrote it in real language? I did too. Half of it's in C so suck it. Unless you did PDP 11 assembler you ain't better dude. Okay. I'm sorry guys. So the idea with this is if you have strong identity, reputation and retribution, and there's some interesting philosophical pieces to that, then you can actually add some of the controls. So let's say, for example, strong identity. First off, you know who I am. So there's ways of building a reputation around them, attaching some identity and some events, some historical moments. You also have retribution. You can make part of the reputation building actually telling you off and other people will find out about it and telling other people, hey, this guy's Zed's kind of a jerk. If I mix all this together, then I can actually start adding together or bringing back some of the social controls that you get on the internet as is. I mean in human communication as is. So here's the problem though. On the internet nobody knows who the hell you are. It's actually just connected computers. Huh? Oh, I'm sorry. I typed this like two minutes before they're coming in here. I'm like totally dyslexic. Yeah, this is going to suck. Don't worry. You'll have to get past it. I gave a presentation once and it was going to be on mathematics, testing and security. It was going to be awful. And I said, so to prevent it, I said there's going to be this guy. I called him that guy and I had responses and that guy's a guy, he's a guy who's always in the back. So when you say that you're using like a cryptography element of elliptic curve and it's 192, you know, I was like, I don't care. Just shut up. It's a presentation. But I like you guys talking. Okay. So, seriously, you're not, I mean, no. So it's who. It's who. So, yeah, sort of. Come on, we've got to get through this. I only got 50 minutes and the goons are going to kill me. Then you have reputation. So once I identify you, oh and the identity right, the best I can do is you have a key. So the whole system is based on asymmetric cryptography and you get a key. Now the problem is that you can make keys. They're just like bits. They don't have any meaning or anything like that. So in order to kind of get around that, we're playing with it, is it'll be invitation only. So someone else, just like the same with the PGP Web of Trust. Someone else will say, yeah, I certify that that guy is so-and-so and he can come in. And that actually turned out to be a really difficult problem because if you take a system like say Gmail or some of these other invite systems where they don't really care who the receiver is, there's only one half of it. They know that you are a certain person. They give you a giant chunk of a lucky number. But if you want to actually care who the other person is, you almost have to do a three-way handshake. So you have to do, I certify that I want to give this to Joe and then Joe comes in and says, oh yeah, that's actually from Zed. So then I certify I want to be invited and then Zed goes okay and I want to say that Joe comes in. Which is something you don't see in a lot of other invite systems. Basically there's no non-repudiation on the actual handshake between including and people. So once we have that, once we got this non-repudiation and this invite and a key, well that's about the best you can do. I mean there's not much more. So what this has to do then is we have to base the rest of the system on reputation. So this is going to be basically collecting of information about who hated you, why they hated you, where they hated you, which rooms, how it happened. And this will build up over time your reputation and then eventually people can be proactive. They can just say they just don't want to talk to you and see 300 people hate you or you've hated thousands of people. So when they say you though, they mean that key. We can't really say the person and that's the best we can come up with. And this is kind of a basic philosophical thing. There's people been arguing about it for a long time. This is the concept of identity. Well let's hold off on that for a bit. There's like a Q&A session. Just let me be funny and then heckle me a bit. That guy. Anyway, I'm sorry man, I'm just teasing you. So then we have retribution. So retribution is really hard to do on the Internet because the basic protocols just don't let you boot people off. You don't really know where they come from. They can go through NATs. You have no real way of stopping them. But with identity and a solid key that's been invited, we kind of do. We can actually play some retribution against your key. We can do certain things to you, which is what we'll see in a second. And this is where I get the concept of hate. So the whole point of U2 is that it's a chat network where you can hate people. And the process of hating them actually makes them calculate hash cash. Now it's not the real hash cash because that had some technical problems but it's mostly you make them try to break a weak cryptography problem. And you can scale it. So I can say I hate you at 16. And then you have to calculate up to about a 2 to the 16 random number, right? And try to break that. So with that kind of retribution and the fact that this is all signed and encrypted, I can now start gathering information about who hates who, who talks to who, where they come from. And we can start looking at the social problem. Because what this turns into is it turns into a weighted social network that you can actually analyze and crunch numbers on and start saying, well, OK, if we change the hate model to be this way, or we change the hate model to be that way, how does the social network change? Do the jerks go further away? Another alternative to hate is that it's distance. Because people aren't prevented from talking to you, it just takes them a little while longer. So it's like if I hate you and you go to the back of the room, you have to yell at me. You could yell at me there. But back of the room would be harder, right? OK, see? All right, so the thing is, I'm a programmer, but I'm a super duper lazy programmer, which is probably why my stuff tends to run reasonably well. This is the entire protocol. I send two bytes for the size so that you only get about 64k. Remember, it's a messaging protocol. So I'm not trying to send huge files or anything like that. It's just text messages, whatever. And then I send a data structure. So I'll show you what the data structure is. Do we have any Lisp fans? There's got to be like 10 Lisp fans in here. Oh, seriously. Come on, four. Oh, five. All right, rock. Yeah, yeah, exactly. It's all the parentheses waiting their arms down. You don't get it. So what we have within the protocol. So the basis of the protocol is that you have your, remember the seven layer Burrito, right? The seven layer ISO protocol standard that nobody ever uses because it was designed by a bunch of telecom idiots in Europe. OK, yeah. IP goes up to about maybe layer four. And after that, you're kind of on your own. So what the two bytes do is they give me my framing. So framing in internet protocols really blows. You've either got HTTP where the framing is kind of boundary based, and then they've got seven different boundaries. They've got MIME types and content lengths and connection close operations and things like that. So the framing is kind of mixed in. And the problem with that is you run into the classic escape problem. You always have to escape something that could be actual data and differentiate it from the framing. With this system, you can do just pre-framing. It's not a binary versus a parsed protocol system. It's I frame the protocol with just two bytes. You get a little more fancy with it, but I found you don't need anything more. And that sets up the actual frame that gets layered on top of TCAPIP's randomness. And then the receiver knows, OK, I'm just going to read this much. That's the message. So then the actual data that's transmitted is this weird-ass protocol I created called Stack-ish. It was actually a joke. It was an XML joke. There were other people who were whining that XML stole Lisp's S expression and then made it really bad, which is kind of true. So what I did is I said, oh, yeah, well, you guys just, you suck because S expressions are hardcore. You've got to be really good, but this is a fourth stack-based S expression system. You've got to be hardcore to do that. So what you get is if you read the bottom, you see I've got a root, a child, and then two nodes under the child. And then right above that is the Stack-ish. And all it is is the exact same data structure, exact same properties as S expressions, exact same everything. What the difference is, and this is nice for network protocols, is you know when you're done, you know exactly how much you're going to read, and I have a new thing in it called a blob. It's like a net string from Dan Bernstein. It's just literally, I tell you how much is going to be in the string, a colon, and then that's the string. So that way everything is pre-sized. The frame sets up the entire data message. Any binary elements are framed within net strings. Works great. Because it's stack-based, it gets loaded into trees really easy. You can actually build a tree online. You don't need to maintain any others to actually do anything. It's very easy to parse. So that makes your protocols nice and small, fast, simple. So now the semantics of the protocol are pretty simple. You've got a hub. A hub has a bunch of people talking. And these people talk on routings or rooms. And then as messages come in, the hub just sends them to different rooms. The hub is fairly dumb on purpose. It actually doesn't really store anything on disk or do anything major. It will eventually just because you have to, you can also just try to keep it in memory. The hub is only about 5,000 lines of C code. It's fairly well documented, very straightforward C code. Nothing really advanced. I didn't write my own crypto. I'm just borrowing everything I can. It's very tiny. And it only runs in about 7 megs of RAM. So you can actually fire one of these things up really quick, easy. It's an ANCC for the most part. And then the dating and coding is just ASCII text. Now the problem that you have is everyone goes, oh my god, you need UTF-8 because the internet's international. The data and coding can be pretty much anything you want. And just today, I had a bug. You know, you never change anything five minutes before a presentation. So I'm trying to get the client to work. And I found out if I type a whole bunch of As, it blows up. I'm like, oh. Because all my unit tests only use like tests as the message I was sending because I'm brilliant. And so what I had to do is, I had to go into the client and dig around. And I'm using JRuby for this and Java. And it's like, you know, it's a lot of fun, but you know, it's kind of nasty to try and dig through. And I find out I was using a file writer, which translates UTF-8, and I'm trying to send binary data. So I had to use a file output screen. So that's the problem you run into. If I just say it's ASCII, that's it. Then what you can do is if you have to send UTF-8, you put it in a blob. The blob doesn't care, and the receiver's responsible for figuring out what to do with it. So the actual encoding and transport is very straightforward. And remember, it's simplicity, right? You can't have bugs if there's no code. So it's very, very simple and straightforward. All right? You're laughing. That's true. How many people believe that? Why are the Java programmers raising their hands? Huh? Seriously. Okay. That's right, called out. I think we should beat them with sacks of oranges. I'm sorry. I'm not that violent. I swear, I'm just being funny. Am I being funny? Good. All right, cool. Anyways, so the main thing is in the protocol, right? I wanted to use SSL, but there's a problem with SSL is that it was designed way back in the decade when, you know, everyone had a 386 computer and they were trying to surf their porn and they wanted to really pay for that porn. And so then SSL came out and they go, damn, these computers can't calculate any crypto. The server has to do it all. And so the problem is you can take an SSL client, connect, give some bogus data, make the server do some crypto, and disconnect. Because, you know, there's no control over TCPIP. And since you never really gave a client certificate, the server has no way of blocking that certificate the next time. It's just really difficult to control. So I went and I did some research and I used this mechanism called, hello? Called ISO Mechanism 648-2 Without the Hell's Sinking Vulnerability or something like that. It's in a book. I just looked at the book and it said, do this. And the main thing that that protocol there was is it was a peer-based protocol that used asymmetric crypto only to do its key exchange. It does the key exchange for the session key and then identity exchange. So you can tack people's identity on, they have to have a valid key, everything works. Public crypto key, all that. But it was peer-based. So originally the protocol was designed so that the client did less work than the server, but it's peer, so I just switched it. So what happens when the client connects, the server goes, this is my key. The client has to go in and calculate all this crypto and all this stuff to validate who they are and then gives it to the server. The server can easily validate that and if it's wrong, the server can put that key in a blacklist and then boot them. So the server doesn't do the calculations first. The reason for doing this kind of protocol is that TCP IP doesn't give me any real controls over which clients can connect or where they're coming from or who they are. So I have to rely on the next layer, the framing and the semantics and the cryptography. And if I can sit in and design the protocol, assuming people are going to bust it, spam it, that basically everyone in the internet is a fucking asshole and they need to be taken down, which is the way you should be designing your software. If it goes on the internet, it's a social piece of software. It shouldn't be designed assuming everyone likes you. That's what they did back in the DARPA days. What have we got? We have HTTP. Right? Remember, I wrote a web server. I'm going to milk that for everything it's worth, right? I'm going to be like 90. I wrote a web server. Move my wheelchair. So by taking the approach that it goes on the internet, it's social. Eventually, some person is going to hack it. Eventually, someone's going to try and abuse it. Then what I can do is say, all right, well, let's do as much as I can. I'm not going to be able to stop everyone. All some guys got to do is fire up 200,000 machines and just do TCP connects and take down my little VPS. But if the server and the protocol, like from the base of the protocol on up, is designed to make it so that it's harder. It's not making it impossible, just harder. Then what I'm doing is banking on the predator concept. A predator, when picking two different types of prey, will pick the weakest one. So there's IRC or some other, like, website or something in denial service, or mine, which is a little more difficult. They got to get an invite and they got to set up a cluster and they got to do all this stuff. They're just going to move on. So this is why I don't really want to kill off IRC because I need them to suck off all the evil. Right? You know, I just like, you know, go... Oh, wow, man, this is two things, really hard to... Oh, IRC! All right, I'll run my botnet on that. So the cryptography that I used is the number one rule is you never write your own crypto because there's people way smarter than me. Right? I mean, way smarter. And there's people who actually, like, get paid money by the government to do that. And I'm not a cryptographer. In fact, I'm really, really bad at math, as you guys saw. These are the standards I used. This is nothing fancy. The library I used is this one called LibTom Crypt. It's a small, ANSI-C-based one, totally free and grab it, do whatever you want with it. Right? It has all these standards in it. First off, AES. Nothing new there. There's test vectors. There's everything valid that it's working correctly. 256 bits. There's this weird problem where if you use an asymmetric crypto and then you try to wrap it like you use it to establish a key for a symmetric, they have to be the same key size. Otherwise, they're just not useless. You get the lowest one. The problem is, is elliptic curve cryptography has weird key sizes. So you can't, you have to match them. And the only matching is that you get 256 or 64. It gets really weird. So this is actually insane. This is probably way more than I actually need. And then SHA-256. So those are all matching. And then 128-bit nonces. Those are just rotated as the messages go back and forth. And then that's the mechanism that I'm using. And the cryptography, CCM. I don't even know what it means. But basically, I forget what it stands for. But it's basically, it hashes it and does the HMAC and all that stuff in a very standard way that NIST has decided works really well. And AAD is additional authenticated data. So this is the stuff where the header goes in. The header is just crap that everybody knows anyways. It's like the message and when it was sent and stuff like that. So it's not going to be encrypted. It kind of has to be read and validated before the actual messages is peeled out and decrypted. So it's just authenticated though. So I'm going to tamper with that. And then finally, I'm using Fortuna, which is a pseudo-random number generator. Okay, so who got all that? All right. Okay. And by the way, you can actually take, there's one C file that does all this. And if you wanted to get a glimpse into how to actually implement something like this, it's very well commented and documented. You grab the one C file and go through it. And if you wanted to audit it, I'm trying to rewrite it in a literate style. So I've got these two implementations of it. U2Protocol.info is where you can go and get like basically the code and whatnot, but it's a little rough. Where you want to go to is saving the internet with hate.com. And that's actually, yeah, I think if you go there, you'll kind of like that site. Mostly, basically, it's this presentation in written form. And it almost made it so I didn't get my job at Bear Stearns. So lots of cussing. And then IHateRubyForge.org is the client I'm going to show you. The client is done in JRuby, which is basically Ruby done on Java because real Ruby kind of blows. And like bad. If you want your eyes to bleed diarrhea, go read the garbage collection code. Now, it'll take you a while because the garbage collection code is spread over about maybe 7,000 files. You know, so you'll have to like figure out where it all is, but yeah. Just go read the garbage collection code for Ruby. Java is great, but kind of on the slow side. So you'll see. I mean, it takes like, you know, 30 seconds to start up the client stuff. But it's a lot of fun because what I can do is then I can use a nice kind of fairly proven platform that's been pounded on a while. And then I can get some JRuby love and I can use my Ruby language and whatnot. And actually, I don't necessarily prefer or not prefer Ruby. It's just that a lot of people who are interested in the client know Ruby. So they'll be able to go in and write plugins. They'll be playing with it and everything. And all this stuff is GPL-ed free. It's open. You guys can grab it. You can do it. I'm not making any money off it. I just want people to play with it. It's totally fun. So one other thing I've done is I've tried to implement some really secure coding practices. And what I'm doing is kind of like a self-analysis, a statistical self-analysis of this. So as I code... Oh. All right, good. The guy kept telling me that my resolution was insane. So maybe I burned that one out. So what I do is I run Valgrind on my stuff all the time. I have a testing suite that reruns every time I do a build. And it just sits there and just rolls in a loop. And then I have these stats that print out like how many stack buffer overflows I've had and how many null pointers and how many errors and messages and how many other messages I do. And Valgrind is fantastic. If you are working on C and you're not running your stuff on your Valgrind, you're a fucking moron, all right? I mean, just straight up. Or Purify is another commercial one, if you want to do that. Valgrind is great, though, because it's free. It works everywhere. All you Mac fans, I think, get used to work on PowerPC and they switch to Intel chips, so now you're screwed. They just don't care anymore. But under Linux, it's great. And you basically run your source code. It works really good. Does it stuff? Basically, it prints out wherever all the source lines that you have, buff overflows, null point or de-references, trying to use memory wrong. And by doing this, I'm basically doing a statistical analysis of all my stuff. I'm calculating these numbers and at the end of each release, I go in and calculate the statistics and try to figure out how many defects I might have injected versus coding or testing. It's completely nerdy. It's so weird. I have stats up in graphs. You have to kind of get into statistics. But if people are interested in that, let me know. It's one of the things that I'm doing to just kind of play with how can you write secure code. Everyone tells you write secure code, but they don't know how to actually tell you how to do it. It's a bunch of voodoo. So this is kind of going out through the back end. Write a tool that's really good in tests and stuff that tell you when you're not writing secure code and then use statistics to kind of keep it low. Keep your stats low. So what I'm testing when I do statistical quality control stuff is how many valgrind errors I get, unit errors and logged errors. So that's the program itself saying, I found this is wrong, that's wrong. And normally when you code in some of these new fancy languages, you don't have these problems, right? You don't have these buffer overflows so much or anything. Well, you're supposed to not have them, but yeah. And when you code in C, you have all these buffer overflows and memory problems and memory leaks. So by running under a tool like this and then keeping track of it, you can actually keep your code small and secure. But the problem is that it's really tedious. So this is why I didn't do the client in C. It was just too much for me to do a nice, gooey client, everything in it. And I also review my code fairly frequently. I'll take a source file and I'll open it and I'll actually go bottom up, top down, and I'll try to review it. But I really do want to get other people to go in and review the code and check out the source and everything. And then when I code in C, I'm using this library called B string. Everything is pre-sized. Like you notice when it did the protocol, from the base up it's pre-sized. It knows how big everything is. Like today when I said I had that bug, it was actually given the wrong frame size and that actually just turned into a protocol error. The server didn't crash, so when I do this, I'm also doing a kind of a belts and suspenders style of programming where, you know, you ever see those idiots walk around in your office, they have like the suit, the belts, and the suspenders, just in case their pants fall? Right. Belts and suspenders programming. It's, you know, Java's belts and suspenders programming. I want a string variable name equals a string. I said I want a string new and then, you know, that's belts and suspenders programming. Just in case you don't get a string. You got to make sure it's a string. Three times, four times, five times, just in case. You might not get a string. Because nobody's doing type inference, right? No. Right? Haskell's another belts and suspenders kind of style programming. Programmers shouldn't worry about code execution. What the fuck are you talking about? That's the whole point of writing a program. So with C, the belts and suspenders that you have to do, you have to do this, is always checking return values and then always making sure that you bail out and always making sure you clean up. Okay. So what I've got is these really nifty macros that kind of do that. You go code and you go macros. I'm basically using the C preprocessor as a code generator and it's code generating me this ghetto style exception handling. And it works. But, you know, I kind of want to do something different. So I'm looking to maybe write a little bit of a mod to C that I would best play with. But this is the kind of program that I'm doing to make sure that the hub stays up. And it's been running pretty successfully so far. I mean, it hasn't crashed or anything. Oh, like four, so. She asked what is most users? Like, I think 16 at tops, right? It's really small, but I pound the hell out of it. What I would like and reason why I'm kind of coming here and being a little obnoxious is I'm sure I've pissed off some really smart person out there and they're going to go in and really just rape this thing. I would love to see a picture of like somebody like bent over a barrel and, you know, I owned your code. Cool. Where? That'd be great. So one of the things I'm trying out also is the server always change routes into a directory, right? I don't know if there's too many other servers that do this, but this one, when it demonizes, it always change routes into a directory. So if it gets compromised, it's just you have that one directory. I'm not sure if I did it right. So if anyone knows how you're supposed to do it right, let me know. I called some function called daemon. So I don't know, does Linux do that right? We'll see. I don't leave any resources open really. Like I said, I try to run everything I can in RAM, and it only opens files periodically. So the directory that it changes routes to just has data that the hub needs. That's it. It doesn't have anything else. Ah, so let's do a practical demonstration. This is a sort of practical demonstration. So over there is the chat client, and you can see it's super fancy. Now, some interesting things about it is I'm a huge fan of parsers. When you do a protocol, you're translating text. And parsers are the most well-established, researched way of properly translating text. That's pretty much what you're doing. So I write a lot of parsers. Most people, when they write network protocols and servers, they do this by hand, and that's how you inject defects. So if you have a parser generator, and it's well-written and well-established, and you can generate something that parses text, then you remove, one, a source of errors, and two, a source of time sync. Some quick analysis that I did of the Apache source is that a lot of the defects are just in the handwritten parser for HTTP. So when I wrote Mongrel, and it's like every standard parser knows exactly when it's done, when it's in error, when it's supposed to be working right. When I did this, we were running the project with a PIP. It's like the OpenID project. And someone started pounding the server and hitting it with security attacks. And then Mongrel was just going, oh, that's not valid HTTP. That's not valid HTTP, and just blocking. And it blocked about 80% of the attacks straight off. It wasn't doing anything security-wise. It wasn't checking anything. And it was a fairly loose parser because the browsers don't get it right. So this is the thing that you get. When you write your parser by hand, you're basically making a blacklist for the input. You're basically saying, this is how it should go out, oh, accept this, accept that, accept that, accept that. When you write a parser, you're basically making a whitelist. This is the only allowed grammar for this particular text stream. And that's pretty much the standard when it comes to security, is you use whitelists wherever you can. And that's why when I do parsers and when I do protocols now, it's always a parser. Even with this one, with U2. So on this, there's a parser that actually translates the emoticons and the text and turns it red and everything. That's actually parsed. So it's actually parsing it, tokenizing it, and then handing it to the chat pane. So that makes it harder for someone on the other end to send you stuff that would bust your client because when it comes back from the server, it gets parsed and translated. And if it can't parse it, just prints it out as text. And since I have the concept of a blob, then it's just a binary thing. It gets printed out. Now, I'm sure there's probably something weird in the Java chat pane that makes it so you can totally hack the hell out of that thing, but can you hold it? Yeah, can you wait a little bit? Yeah, you can totally do it in all the servers that way. But yeah, just a second. What we have down at the bottom, this is just simple JRuby. And that's just the standard chat pane there. Nothing big to it. The code... That's kind of the core of the code in Ruby that parses out the stack-ish protocol. I mean, that's pretty much it. Since it's a stack-based protocol, all you have to do is just lexically analyze each piece and then follow the stack. You don't have to actually do any grammar or anything like that. So this removes one more kind of pain point or potential attack area. You can actually have some grammars that have recursive elements that can be attacked. But this is just a straight lexing. Now, this is Ruby code. So this is kind of using the Ruby string scanner and Ruby's known to have some problems. So... And then... This is... So this is the code that's actually doing the swing GUI. And if you notice, it's doing Java. It's using swing and everything, but that doesn't look like swing code. As what this is, this is basically just a Ruby library I wrote called Proflegassi. So this is basically doing the swing. The reason why I'm showing you this stuff is that if you want to contribute, this is kind of the most difficult stuff you have to do. If you want to work on the client and play around with it, this is basically fun kind of Ruby hacking. If you want to get in on the server and see how that's going, then you can do that too. And this is actually the entire chat pain that you're looking at. Is that fairly readable? Kind of readable? Sucks-ass? Who's asleep? Sorry. I'm trying. And then if you look off to the right, the bottom right over there, actually I can swap this. I did a presentation in Boston. The only question I got at the end for most people was, what's that window manager you're using? I'm like, I just talked for an hour about cool cryptography and stuff, and you want to know my window manager? Yeah, it's really neat. It's DWM. Or just meet me afterwards. If you see over there, see that stuff where it's showing transitions, it showed the messages? Okay. The core of the hub is based on a finite state machine. So what happens is, those are events that are going through and the hub's processing them and telling you where it goes. This is again, it's making a whitelist for how the hub should behave. So if it goes into any bad states, if it goes into any direction, like if someone figures out a way to try to get it to do something it wasn't anticipating, the great advantage of using a parser in state machines is that if you have these mechanisms to make it a whitelist for what the program should be doing and specify it, then you get a better response when it's attacked. The response in this server is basically just a crash to abort. But you can actually handle errors a lot better. So there's some security flaws? The 10-minute sign. So the security flaws that are in it are mostly because I'm still debugging it and still putting it together. So right now the header, there's an ID that's just sequential, that's so that I can go and actually see what message might have died and stuff like that. There's no versioning on the packets. It's pretty much just in flux, so I say here's a new version, go grab it and then people use it. Eventually we'll put a version in the header so that keeps track of it. And the cryptography that I'm using, how I'm using the cryptography, hasn't been evaluated. So the library that I'm using has been evaluated by a few companies, but my stuff actually has been evaluated. Questions? Okay. Two, go for it. Oh, I'm sorry, okay. That's the whole point. Let's go back over this. He said I'm a dumbass because I'm not talking about the revenge system. Right? Yeah, cool. I'm sorry, I'm sorry. So I went over the protocol and everything and because I figured you guys, look, the whole point of U2 is that you have this revenge system in it and what you're doing is when you're chatting you're going to add the social controls that you get when you talk to regular people. The problem is it's an internet protocol so there's no way to really enforce things. So what it does is everyone has a unique key and have an invite path or who's invited them. So when you come in and you talk, I kind of know your key. And then I'm also able to ask the hub info about you. I'm going to say, hey, who hates this guy? Where is this guy coming from? Who invited him? Okay? How many times has he been hated? What's his average hate level for the whole system? I want to make it where the client can go in and basically say, I don't want to talk to people that have this kind of reputation. Okay? So that gives you your reputation and it gives you your strong identity. Now the revenge part is really interesting. When I talk to men, they go, ooh, revenge. When I talk to women, they go, ooh, why do you have hate? So I have an alternative concept. Okay? It's actually distance. When you hate someone, the calculations they do give you distance. It gives that person distance from everybody else. So if you imagine you're chatting in a room, right? Over there. And there's some guy who's an obnoxious ass. What will end up happening is after the writer peoples pictures. And what I want to do is have four little pictures for each person, right? You'll have people can put a little picture on their IM. You'll have four. One for I'm neutral, I'm happy, I'm sad, and I'm angry. And when you hate someone, the receiver of your hate will see your picture change to the angry picture. And what they'll get is this list, Joe hates Frank, Joe hates Frank, Mary hates Frank, Alex hates Frank. What this translates into technically is that the people doing the hating pick how much they hate you. It's a two to the something. So let's say they pick a 16. Then that turns into a random number and the hub says, hey, okay, in order to do that, you gotta pay a tax. So you calculate some hate first. So the hater calculates this tax and then submits that back to the server. And it's all signed and validated with the crypto. The hub goes, okay, great. And it tallies up this kind of rolling average of everyone who hates this person in the room. And then every time that person who's the receiver has to talk, they have to calculate this hate again and again. So this effectively slows them down. When you get a hate that's around say a two to the four, two to the ten, it's not too much of a penalty. It's like maybe a second at the most, two seconds is the most modern computers. When the calculation gets up to around two to the 16 to say about two to the 20, it turns into minutes, tens of minutes. When it goes above 20, it turns into like hours. Because it's fairly exponential. So what you're getting is this kind of tax that people have to pay to hate someone once. And then after that, your average is calculated based on what they voted for you. Now, this is kind of up in the air. What I'm doing is calculating information and data about who hates who and using these hate calculations as a weighting, and then I'm going to be using some social network analysis. There's a really great library called iGraph. There's another library called Prefuse. And those are going to be part of the visualization. As you chat, you're going to be able to see who hates who and get information about them, get nice graphs. So this is all merging back into, you have this retribution that translates into your reputation, and that impacts your identity online. So you're going to be building up this identity. When you have this retribution system, there's a lot of stuff I don't know. There's all sorts of odd social things that I don't know about. I don't know if an average is going to be good. I don't know if I'm going to have it reset. I don't know if it's going to have to decay. Something one guy recommended is when you first join, you're a juvenile. You get three months to be an ass. And then you have your juvenile record expunged. And then you get to be an adult. And then it applies from then on. I'm like, that's actually a really great idea. Another one is, for whatever reason, love does not work on the internet. It just doesn't work. If you have people calculate love, that's a positive thing. So what they'll do is they'll just calculate all the positive stuff they want. It doesn't penalize anyone. But hate, nobody wants to calculate that. It's a penalty. So being forced to calculate that acts as a deterrent. Now I'm pretty sure there's some kind of philosophical basis for this or whatever, but basically I can't let you to some charity by doing some work for them, say, SETI at home or something like that. And then the charity will tell the hub, yeah, that guy's a good guy. Pay his hate down by about this much. So you do charity work. The what? No, I'm not. Can you tell me later? Okay, cool. Yeah. That's part of the whole social experiment. So I want to see how this plays out. This is the part where you're getting into wild territory where I don't know. I don't know much data analysis and research as I can. And it could be that's the whole, like this whole social part is just a total failure of it. Did that explain it well enough for everybody? Okay, let's get one more question. Super quick. You and the hat. Yeah, that guy. Right, so you'll have a reputation. Yeah, you'll have a reputation. And you'll have this kind of tree. You just keep inviting yourself. You invite like thousands of bots and everything. And what I want to try and do is you can actually do this weird stuff in social network analysis where I can cluster you together because you all act the same. And I can actually just lop off that whole arm of the network. Right? So basically, cabal analysis is what I'm calling it. But I don't know. It could totally be that some really pissed off dude at Google goes, whatever. And also keep in mind that I'm not trying, like when I say strong identity, I actually mean like stronger identity. When I say denial service resistant, I mean more resistant. It's not completely possible to stop it all the time, but I'm just trying to make it a little more difficult for people trying to attack it. So that way they'll go somewhere else. That's the basis for it. And then the central thing about it, after you just got done doing Tor, this is kind of the inverse. We're basically saying we want to identify everyone. We want to know exactly who they are. Shut the hell up if you don't like it, go use Tor. Right? So when you use Tor is you can just make all your data go through those three data centers in Washington, D.C. where they calculate about 15% of all the traffic. And if you ever study statistics, you realize 15% sample is actually enough to figure out just about everything you need to about 90% of the traffic. Thank you very much.