 Good evening everybody It's great to be in front of such a vocal crowd Tonight I'm going to give you a progress report on something. I've been working on called the safe project For years. I've been traveling around the world talking about the world wide web and the things that are wrong with it And the things that we needed for it to do better hoping that somebody would Do it you know fix it take care of it I completely failed in that mission. I didn't convince anybody to go on and try to make the web better So I have to do it myself. So that's what this is about the safe project So it's all about the web The web is the most successful Software project in history. I think I mean it's everywhere. It's it's conducting so much of our lives and It's really not good enough for doing all of the things that it has to do Because it wasn't designed to do those things it was intended to be a simple document retrieval system And it's kind of okay at that but it's being pushed way beyond its limits And it's much harder for us to to develop on it than it should be and it's not nearly as secure as it should be the biggest problem with the web is its lack of security that it was not intended to be Moving money for example through the wires, but we do that all the time. We're moving goods and services and and Private stuff and it's all out there and it shouldn't be so we can look at the the history of security in computing and It begins with passwords The very first computers did not have passwords They depended entirely on physical security that there would be men with guns Between you and the computer and if you wanted to get close to the computer you had to get past the guys with the guns And that was a pretty good system for securing the systems But it didn't scale When disk drives were invented Things changed especially when time-sharing was invented with time-sharing it became possible for people from a remote location to connect to a mainframe and Do some work on the machine? And they needed to make sure that the people who were connecting to the mainframe were allowed to You know particularly that they were going to be paying for it and That they could not get to the files of other customers who were also on the same time-sharing system And so passwords were used and that's when passwords come into computing And at that time passwords worked pretty well because typically you would only have one time-sharing account So you only had to remember one password So it was pretty easy Then when personal computing happened we went back to having no passwords So the original PCs original Macintosh no passwords didn't need them because The only storage they had was floppy disks and so physical security again was effective That changes when disk drives started getting added to PCs and then when networks started getting added to PCs and now suddenly Everything's wide open and they start putting passwords on them. So every machine has at least one password now Then when we start getting on the web At first it's just a document retrieval system all documents are available Everybody can read everything But then we start putting private stuff on the web and that means now we have to have some way of Making sure that people who are not authorized can't get to the stuff So the first site to do that said well, we'll just use passwords because they work to be for and Then the second site said yeah We're going to use passwords to and then the third and the tenth and the hundredth and the thousandth We're probably a million sites now all requiring passwords And it turns out that people are really bad at managing passwords that we cannot remember More than one or two of them and we now have to remember one for every site with which we have a relationship And it doesn't scale it doesn't work and we can look at the history of passwords on the web in the RFC that first described URLs in that RFC there was a format for Sending passwords as part of the URL and the passwords would be sent in the clear At least one of the authors of the RFC recognized that was a really bad idea And he managed to add the sentence the use of URLs containing passwords that should be secret is clearly unwise Which is an amazing bit of understatement Because it's Yeah, it's way worse than unwise But that's where it starts so that that's the origin of the web in URLs and So the authors knew that that was not a good idea, but they had nothing better to propose That was sort of the state of the art at that at least the state of the art of the thinking of the authors of that RFC And clearly that was inadequate for dealing with the world that we're living in now And we haven't progressed far enough away from this original misconception So we need to fix that so we need to fix the web But before we can fix the web we have to understand what is wrong with the web, right? If we don't understand what's wrong with it, we're not going to be very effective in fixing it So I'm going to talk about what I think is wrong with the web now most of you are Making your livings in the web is that right and I'm guessing a lot of you have never worked in any other medium that the web is all you know and So what I'm going to tell you now may be shocking and upsetting that But it's going to be true every word is going to be true So let's get started. So the biggest thing wrong with the web from my perspective is that it is insecure and Its insecurity is rooted in its complexity because the web has been growing by fits and starts and the standards and Miss practices and all that stuff It's it has gotten to be much more complicated than it needs to be and that complexity is itself the cause of insecurity and That's not something that's easily fixed So let's look specifically at what we've got first. There is HTTP the hypertext transport protocol it's a protocol that was intended for document retrieval and You can think of it as being three things first. It's a Format for key value pairs. That's how a request is indicated and how response comes back It's it's a really finicky Weird inconsistent format. I think they're much better formats to consider for that role Jason for example I think is pretty nice It's It's also a negotiation protocol And negotiation was really important in the early days of the web because the first browsers didn't understand all of the image formats and so if a page was requesting an image It would have to tell the server, but I only know about jpegs I don't know about pings and I'm not sure about jpegs and and and so this negotiation would go on where The browser would say this is what I understand and the server would say well This is not what I know how to give you and eventually they'd figure out Something that they could display That's not important now, but it used to be important today. It just wastes bandwidth There's all this stuff going back and forth Which is not necessary because the browsers are now very capable and can handle anything the server can give them and Then finally it's a request response protocol and the way that works is The browser makes a request for a document and waits and then the server sends something back and then the plan was The browser would disconnect because it had the document and then the user would read it for a while And then they might click a link and then go to another server and Wait for another document so on but that's not what we do today Today you'll load a page and that page will then ask for hundreds of additional assets It's asking for grips and style sheets and especially images and other assets And so you've got lots and lots of traffic going back and forth trying to get this stuff But this protocol wants to do it one thing at a time all you want an image, okay? Boom got the image another image. Okay, boom Boom so you're waiting for all of these round trips. It's really slow So to mitigate that the browsers will open up multiple channels to a server So they can be doing lots of HTTP requests at the same time because that's the only way to get it to an acceptable level of speed But opening all those additional channels increases the complexity without actually adding any value Then there is DNS the domain name system The domain name system was a well-intentioned thing so that people wouldn't have to memorize and type IP addresses that instead We could type words and things and in order to get to sites, which is definitely an improvement But it's not compatible with the trademark system And so there's constant legal legal bickering about what can be a URL or what can be a domain name and what can be a trademark So that's a mess and particularly when you apply it internationally where there's all the trademark systems tend to be National it gets really really complex, but worse than that. There's security problems inherent in DNS. There's domain squatting. There's domain poisoning That just because you type you can correctly type in the name of the place you want to go doesn't guarantee that that's where you're gonna get to There's SSL secure socket layers This was something that was developed by Netscape when they recognized that sending everything in the clear was not going to work for Doing the the commerce applications. They were anticipating so they came up with a way of encrypting and authenticating based on a system of Certificate authorities Unfortunately, the system that came up with is way way too complex so complex that it still contains Serious serious errors, which we're still finding 20 years after its release That's pretty bad a lot of why it's so bad is because of its dependence on cryptographic certificates the model was that You could have a certificate which would assert some relationship that some party can be represented by some key But all the certificate really tells you is that somebody gave money to Verisign or to some other company It isn't actually proof of the thing that's inserting it But it was this that system was intended for being able to validate Relationships in an offline world But we're totally online now, so it's solving the wrong problem We're at least it's solving the problem the wrong way In fact what because the certificate authorities are so unreliable There's now a need for checking the revocation which was something that shouldn't have been necessary But it is which means in real time We have to connect to the authorities to make sure that their own certificates aren't aren't bogus now So in trying the offline thing didn't work we're doing the offline thing, but we're doing it in a backwards way worse than that I don't trust the certificate authorities the most famous of them is Verisign and We know that they've been hacked and They have not been forthcoming about how they were hacked That's that's Verisign. I don't know who they are or or what their procedures are or if I can I don't know if I can trust them I just don't know worse than that there are hundreds of other certificate authorities that your browser trusts equally to them Many of whom have been hacked have been corrupted and have done terrible things But we still trust them all it's a lousy system. I I I don't like it Then there's HTML the hypertext markup language is HTML a good thing or a bad thing It depends on what you're trying to do if what you're trying to do is to mark up simple technical documents Which is the thing that it was designed for it's really not very good. It's fussy. It's complicated It's hard to use. It's hard to use correctly. That's why we invented markdown languages For marking up simple documents markdown is so much more effective wiki Wikipedia could not work if everybody had to write in HTML. It's just too fragile too brittle Now if what you want to do instead is to deliver interactive applications through the internet It's terrible because it wasn't designed to do anything like that and it's just not very good But we've gotten extremely clever over the years of figuring out ways of trying to push our applications through this crappy little document system which has this weird little assortment of tags which really don't relate to anything that we're doing but It made sense at CERN 25 years ago, so that that's what we're stuck with The the major way that we use HTML is templating It first started on the server side now It's even happening on the client side on the browser side that we're seeing browser side templating Which I think is crazy. I hate templating for three reasons the first is that It's insecure. So this is the vector by which XSS attacks happen. It is possible to do templating correctly I've never seen it done correctly that we still see cross-site scripting attacks happening all the time You know you can go to any technical news site and search for XSS and you're gonna find one just happened this week Every week they're always happening So it's you know, it's like the browser is a pointed gun a gun pointed at your head and templates are what pull the trigger then We get a the second thing is that we get a fixation on HTML so that everything is about Turning into HTML that that finds its way in the pipeline It's in every tier going all the way back to the database schemas everything is committed to HTML And that turns out to be a really lousy Architecture, but it's all we can think about you know, we have this fixation on HTML and then finally It's a trap because if everything is flowing to HTML in this brittle architecture We're never going to get free of it. We're going to be stuck in HTML land forever Then there's the DOM the document object model This is the API that the browser presents to JavaScript and it may be the worst API ever imagined It's Right, you know, right? I'm not telling you. I'm not telling you anything. You don't know it. It's It's just awful. It's the wrong level of abstraction. It's fussy. It's error-prone. It's it's not portable It's just awful a lot of people who use JavaScript and say they hate JavaScript What they're actually hating is the DOM. They don't know where JavaScript starts and where the DOM starts and Everything on the DOM side is just awful Then there's CSS crappy style sheets CSS was designed for marking up of technical documents and we are using it for all kinds of stuff with There are a lot of extremely clever people who figured out how to make it work despite its limitations There's still some things that it doesn't do at all or it doesn't do well or easily There's some alignments and layouts that it really can't do And a lot that it doesn't want to do that we kind of force it to do anyway. It's just way too difficult No other application system in the universe ever tried to do anything like CSS It's just it was in the browser and we needed some way to make things Look better and that's what we're stuck with Then there's JavaScript JavaScript is a hot mess JavaScript was designed in 10 days and it turns out you can make a lot of mistakes in 10 days But the good news about JavaScript is that there's actually a brilliant little language hidden inside of it and And it works now the reason I think the web has survived and prospered to this point is because there is JavaScript in the browser That whatever is wrong with HTML whatever is wrong with CSS With JavaScript we can fix it we can work around it And so we spend most of our time working around things not being productive, but we're able to because of JavaScript So there have been many companies who have tried to replace or capture the web Microsoft Apple Adobe Oracle many others large and small all thought well the web is so obviously deficient We can make something which is so obviously better and win And in most cases their tech technology was definitely better But in most cases their technology was not open that what they were trying to do is to capture the web turn it from an open system to a proprietary system and I I think it's actually good that none of them have succeeded Because the thing I like best about the web is its openness that Anybody including any of you can at any time decide I want to create something on the web Which could potentially reach everybody in the world, and I don't have to make a deal with anybody I don't have to get permission with anybody. I don't have to share my profits with anybody. I can just go and do that I Think that's brilliant. I love that and I don't want to give that up That's something that the web does uniquely that no other application delivery system can do I want to preserve that But that's not why they failed. I think the reason they failed was because they did not have an adequate transition plan They did not have a plan which could move The whole world or at least a large enough fraction of the world to their platform Their focus was on you but not on the audience So my plan is to upgrade the web. I don't want to replace it. I don't want to capture it I want to keep it doing the things that it does well But upgrade it so that it can better do the things that it does badly So my metaphor for doing this transition is high-definition television This is a major technological evolution that the whole planet went through recently And it was a difficult one, but from the point of view of the audience. It was relatively painless so in Before each TV we had analog systems my country. We had NTSC. I'm guessing here you had pal maybe Which were okay analog systems, but they had all the problems of analog systems We wanted to replace them with digital systems, which were completely incompatible the equipment Had no compatibility at all and it was a difficult transition but We made the transition work for the audience Not for the broadcasters HDV was a terrible time for the broadcasters because it meant they had to buy New plants new equipment new transmitters new antennas all of this stuff in order to put their signal out So they had to operate analog Broadcasting and digital broadcasting at the same time, but with no additional revenue so that it hurt there was no stuff for them and Similarly for the producers of programming they had to buy new cameras. They had to get better sets New recorders new editors, you know the whole production stream changed But they couldn't charge any more for their programming because look that money was fixed So it hurt them too For the audience we didn't notice it in my country Congress was very concerned about the transition their concern was that if on January 1 of some year they turn off analog broadcasting because they want to release that spectrum to Digital applications things that you are probably working on or could benefit from they want to take that that spectrum back But if that meant that a couple weeks later half of the country wasn't going to see the Super Bowl There's going to be armed rebellion And they didn't want that so they want to make sure that the transition went smoothly for the voters and The way they came up with to do that was the set-top box They used to be television sets were great big Cubic things that were big enough that you could put another box on top of them And there was a little box which could read digital signals from the air and convert them into analog signals so that you could watch them on your TV and Our Congress made it possible for poor people to get those boxes for very cheap or free And as a result of that the transition happened very very smoothly So for most viewers they were unaware of whether they were watching analog channels or digital channels Except that maybe the digital channels looked a little better when they worked or Channels changing suddenly got a lot slower But other than that it worked and it was painless And and that's what we need to do. I think in order to to fix the web so in on the website The helper the helper app is the set-top box. Does anybody remember helper apps? This is something that used to be in browsers a long time ago the early browsers didn't know how to do everything They didn't know how to display certain image types. They didn't understand certain protocols They didn't know how to play sounds so if you had a page that asked to do any of those things Then the browser would open up some other program to do that for it I would open up a paint program to show an image or a music program to play a sound or whatever That's still built in all the browsers. They still have that you can go searching through all the menus and you can actually find it So I want to take advantage of that. I want to be able to put this new mode You know the digital form of the web and Make that available in a helper app, which you could then download and use so that you could test the system out I'm very confident that I could never convince the audience to do that But I can't convince you to do that maybe And so the industry can kick the tires on this thing and decide if this is something that we like and then we can make a For an informed decision about whether we want to take the next step So this is my transition plan So step one I need to convince at least one progressive browser maker to integrate the helper app It should be an easy thing for them to do all the helper app is going to need from them is a Rectangle that it can put pixels on to it needs to be able to get UI events And it needs a JSON channel so that it can communicate to the browser two way That's I think that's all they have to do so integration should be pretty easy Then the next step is I have to convince at least one secure site To require its customers to use that browser that now has this new mode built into it the safe mode and the benefit to that organization whatever it is it could be a Financial institution or a government or a medical institution or whatever that they have such need for its security And they have been burned so much by the web That they're willing to tell their customers. This is how you have to use our services now You have to use this particular browser And if you come to us with any other browser, we take you to a screen which says you got to go get that browser I think then risk mitigation will then convince other sites to do the same thing. So It's sort of like penguins. You know how penguins work, you know, you've got a bunch of penguins Standing on the ice flow and they want to go in the water because they're lovely fish in the water But they're also leopard seals and sharks and things in the water which eat penguins And so they're all looking into the water really curiously trying to decide if it's safe or not They're all kind of pushing each other toward the edge and eventually one of them falls in And then all the other penguins look to see if he gets eaten and if not they all jump it So I think this could go like that Then Competitive pressure will then move the other browser makers to integrate as well because you don't want to be the last browser maker to have this app You don't want to lose audience share in that way and Then I think the whole world will follow because they'll want the improved security and Faster application development. I think that Will provide a much easier way for you to write applications and That should certainly be a benefit And nothing breaks. I'm not proposing changing anything about how the standard web works that everything about the web stays Exactly as it is, you know the old analog system Remains an analog system with all of its its properties, but that we're adding essentially a new set of channels Which provide a different kind of programming in a different way, which is has benefits over the old system and You will decide which system you want to use. There'll be nothing to compel you to use one over the other so in order to Make this as safe as it needs to be we're going to be using strong cryptography We're going to be using elliptic curve 521 for authentication and key exchange. I'm going to be using AES 256 for link encryption and shawth 3256 for hashing now Just using strong cryptography is not a guarantee of having a secure system In fact, we've seen lots and lots of occurrences of people claiming that the cryptography was really strong And then they provide big leaks and side channels and things like that So I'm not promising that because this is what we're using We're going to be safe. I hope we're Going to be safe for other reasons. This is necessary, but not sufficient for achieving security So there's a very smart guy named Zuko who came up with a model for naming systems and in his model There are three highly desirable Aspects that you could get in a naming system, but you can all get at most two You know, there are lots of things where you can get at most two out of three So the web decided for just one the web has Human meaningful names at least to the extent where you think a URL is something that's human meaningful then I'm going the other way. I'm going for securely unique and globally Decentralized because I need those two in order to get the security I need so as a result of that I'm going to have the ugliest nastiest unfriendliest URLs you've ever seen I'm going to be using elliptic curve 521 for public keys and Be or the public keys as unique identifiers and because we're using public keys for identification it means People will never have to type in another password The they may have a password on their device and they may have a password on their browser But that's it. They will never send a browser Send through the browser to another site a password and so that means that all of the memorization problems that people have and all the problems with phishing and and Social engineering all the ways that people can be tricked into giving up their passwords They will not be able to give up their passwords because there will be no more passwords We're going to be using secure Jason over TCP. That's going to be our new protocol and Because I like Jason and I like and I love TCP TCP is one of the smartest things ever invented and HTTP uses it really poorly But we're going to use it well We're going to be able to do sessions and it's going to be really efficient and very flexible You'll be able to have full duplex two-way stuff going on will be great So this is what our URLs are going to look like Our protocol name will be safe. I'm still thinking I might change it to be web because it's a letter shorter and I like things that are a little shorter and the web should have taken web and they didn't right they have several chances and So they don't want it. So, you know, it's available. I Might take it. So then after the colon is your public key in base 32 encoding. It's going to be a hundred and five characters long Which is past the ability for most humans to tolerate that So even if you knew your private key, it's going to be a hundred five characters You know someone going to try tell me your password. I'll kill you and you go, okay, you know You know, even if you could remember it. I don't think under duress. There's any way you could actually correctly Name a hundred five letters. It's just Impossibly hard. So we get some security in that Then there's an outside an IP address the IP address is Eight five digit numbers separated by colons. That's pretty close to the limit of human tolerance to and then you can optionally have a slash and then a special capability number which indicates what We intend to do with this connection So humans are not going to type these things ever we just can't do that So the machines will manage these for us But if we can get one of these somehow then we could be confident We are going to get to exactly the machine that we asked for and nowhere else and That it will be authenticated and we'll be encrypted and everything will be good So there are lots of ways we could get these You know because we're explicitly putting our IP address and public key in the URL It means we don't need the domain name system and we don't need verisign Which is good because I don't trust either of those institutions to get me to where I'm going But if I can get a proper key Or a proper address we can get there. So where do you get them? Well one source of these is going to be Google, you know where I wouldn't trust verisign I would trust Google if I asked for PayPal and PayPal says this is the the safe URL for getting to PayPal I would believe them. I think Google is probably good on that Another way we might exchange these is when you go to your bank your banker will give you a card Which has a QR code on it which contains? the server that your account is on and The bank's address and your special account Transaction which will then when you scan it connect you to that account and you're guaranteed No one else will ever be able to get into your account and you'll never need to remember a password You probably don't even need to remember an account number. It'll all be properly encoded So we're going to be providing a trust management system Which will record all of your relationships so that you don't have to remember them And there'll be a pet name system where you can assign your own names to these things So you'll never have to look at the 105 digit things You'll when a new account is or a new relationship is established you get to name it however you want and The system will manage that for you. We can put all of that stuff in the cloud So all of your devices will be able to share this stuff Computation will happen in a sealed container called a vat a vat is like a sandbox except it doesn't leak The sandbox sandboxes leak, right? And that's a problem. I have a cat. Let me tell you that when the sandbox leaks That's a bad thing So we're going to allow multiple entities to be running in the system at the same time But each will be in its own vat the vats will be able to have Jason communication between each other But they will not be able to corrupt each other So that means if you have a transaction that requires cooperation of multiple parties We can have them all running in there all working cooperatively Not being able to confuse or rip each other off which would be a really good thing So finally we can do mash-ups and all the super mash-up things that have just been too dangerous to contemplate up till this point So this model allows us to have cooperation under mutual suspicion which is a really good Computing model to have in a world that's as distributed as ours is So this is specifically the development plan Part one is safe node safe node is a cryptographic module that'll run on node.js safe node provides the Think the algorithms I talked about before and also a really good random number generator The random number generator that comes with JavaScript is not nearly good enough particularly for generating the 521 bit keys and guaranteeing that they're going to be Pretty unique you need a much better set of rent source of randomness. So what we're going to be doing is Mining our own entropy and we'll be getting some of it from the operating systems operating systems are fairly good at that But they're not good enough so to augment that We're going to use your microphone We'll turn your microphone on and pull noise out of the microphone Until we get enough entropy in order to get good random numbers and we'll do the same thing with your camera We'll turn it on for a couple of frames. We're not looking at you We're just trying to get noise out of the pixels in order to build enough entropy so that we can Construct good random numbers and those good random numbers become the basis of our security We thought this was it's so important. This was the first problem. We decided to solve There've been lots of other systems that tried to do similar things where this was the last thing they did For example when SSL was first released it was broken almost instantly because their sources of of entropy Were the process ID and the time of day Turned out that that wasn't good enough so that's that's where we started So it's available now You can go to safe.place and that'll direct you to github. It's publicly available and github It's an MIT license. It's free. We're not we don't have a plan to make this a full-service cryptographic library It's just the cryptographic libraries that the safe project needs But you're welcome to use it for any purpose We're putting no restrictions on it at all Mostly it's using existing open-source stuff. We're just packaging it and providing the entropy mining Part two is going to be the safe protocol. That's going to be the secure Jason over TCP providing the secure sessions I'm really excited about this. I think it's got lots of applications, but it's the thing that we're going to build everything else on Part three is going to be safe resource management. So we need to be able to move assets back and forth between different machines and I think the web has demonstrated that doing things by location and name Isn't good enough. So what we're going to do instead is ask for assets by hash So do a cryptographic hash of something then you ask for the thing with that With that hash code And because it's a really big number the likelihood of collisions is virtually non-existent That means when you get something back you can verify that it matches the hash and there is no way you can ever receive Something which was not exactly the thing that you asked for it also has really nice properties that it doesn't matter where it comes from So we can move caching Anywhere it doesn't matter we can if Your service provider wants to do its own caching they can watch every resource that goes by and keep a copy of it And if they see that you're asking for something they can They can be the first refusal on on delivering that be very very efficient And avoids the the staleness problems that we have in the current system Part four is going to be safe apps. So we're going to build a system in which we can write JavaScript applications by cobbling together no JS and cute Anybody familiar with cute cute is a really nice system that was developed in Norway. It Provides a very nice Model for doing interactive applications. We're not going to use all of cute just the display parts So the parts that put things on the screen and and handle UI events and that stuff It's a much more rational model than what you get in in browsers with HTML and DOM and CSS. So it's going to be a very nice way of creating applications Also, we can have visual vats with cute Which means that you can have a third party in a fourth party in a fifth party share screen space with you and Everybody can guarantee that they can't get out of their rectangle into other people's rectangles They they can't cause problems for each other, but they can do the cooperative thing that we want to So I think that's going to be pretty nice Also another benefit that we get from that is we're not going to have two event loops node is going to have its event loop which is going to be managing state and talking to the network and Cute is going to have its own event loop, which is going to be dealing with graphics and UI events So I think that means we're going to get higher performance Because you can have more stuff going on at the same time I think it also means we're going to get a much better programming model because currently on the web Everything gets really confused yet since everything is focused on HTML generation You get really messy architecture, but now we're going to have really clean architecture You got the stuff that's concerned with the state and communication and you got the stuff That's concerned with presentation and interaction And I'll be very clear separation in those two sides communicate with a Jason channel then the next step is we're going to take the safe app and Rebundle it as a helper app something which could be linked to a web browser From that point on it will then be up to the browser makers to decide to integrate this My hope is that ultimately they decide to take the easiest path to integration Which means they'll simply take the thing that we provide and plug it in That they won't attempt to Reimplement it if that's the way it goes that means that safe apps Will run exactly the same on every browser. How nice would that be? No more compatibility issues everything just works So the goal of the safe project is to provide safe and effective relationship management on the web I think it's something that we really need the web is suffering for the lack of that currently So the old web gave us promiscuity that you could go to any site anywhere in the world at any time look at anything and They probably weren't going to be able to do any damage to you Most of the time and that turns out to be really good that allows us to do introduction and exploration We used to call it surfing It that was a really good thing, but eventually you need commitment. That's what the new Thing is about that we want to make relationships that can be defended by the system itself And that's the place where the web is currently failing And I think that kid takes us to an internet of people where we can be much more distributed we can Maybe do some disintermediation that you can create your own communities in your own stuff It should be great. There should be lots of ways of using this new system So anytime Anyone is talking about Security you should be really suspicious because generally we don't know how to do it very well and in fact You know the problems that you have to make sure that it does what it should that's always a problem of software When you're talking about security, it's even more important that it doesn't do what it shouldn't That's a really difficult thing to test for and usually we don't find the problems until too late And we know that no software is initially secure that we just don't have the technology to create new complex stuff That that is free of error. We just don't know how to do that yet But I believe only a minimal approach can produce software that is eventually secure So if we can do this stuff and make it minimal and make it stable Then as we find the terrible and embarrassing bugs will quickly fix them and eventually we should converge on something Which is really good and only a minimal system design can do that Maximal systems complex systems can't and that's why we are still finding terrible bugs and SSL After 20 years of practice that after 20 years you would think we would have found all the really serious bugs But what happens is that if software reaches a certain level of complexity There's this conservation of error, which cannot be Resisted that anything you add or change or modify or improve is Likely to cause new errors So there's nothing new here. There's no new science. No new technology Everything here is based on theory, which has been well understood for several decades This is just a minimal practice trying to take the least we can do in order to Provide the relationship management that the web is going to need and we anticipate some applications beyond just fixing the web the first one is backstage connectivity that We can replace rest and soap and and those other nasty things with The safe protocol so all of your servers and all of your services then get connected with safe connections Which should be more efficient and more secure and that'd be a pretty good thing Then the next point is safe mail, you know the email system suffers from a Design decision that was made at the very beginning When email was first being practiced You couldn't get an email account Unless you were part of the government or the university or something like that You needed access to a multi-million dollar computer in order to get an email account and that all by itself was sufficient to defend the system But then we opened it up to literally everybody in the world and it turns out that's not working so well and we're getting buried with spam and and Fishing attacks and other sorts of problems So much so that it significantly degrades the value of the email system That there's a really good chance that an important email that that you really wanted ends up in your spam folder and you never see it So I propose another mail system that works the opposite way That you can only receive mail you can only send mail to parties with whom you have these secure relationships And that means no spam can ever get in there and no fishing can ever get in there all that's good Now the really tragically bad thing about that is that you can't send the mail to anybody You don't already have a relationship with and I propose two solutions to that very serious problem The first is letters of introduction so If you need to send a message to him and you know that I know him and you know me you can ask me to Forward a message and it may be that your social networks can help you figure out that relationship and we can make that work In the cases where that doesn't work. I propose postage That you can put some money and attach some money to a message and I can I can advertise that I will reject any message from strangers that don't come with at least a dollar So if you send me a message and I'm happy to have received that message I'll refund the money to you. And if not, I'll just keep the money Having a system of postage like that would completely change the economics of spam and fishing I think could Completely eliminate it almost immediately So that'd be an interesting thing to try then finally safe OS This is a an interesting thing that if if we replace no JS in our system with node OS You know node running as its own operating system We get a really nice little application delivery system with about 1% of the complexity of Windows or Macintosh There might be some really interesting things we could do with that as well So it's the safe project if if you want to know more well There's not a lot to know yet, but you can see part one you can get the Safe node library go to safe.place and watch that location as we go forward. We'll be putting more stuff there so I Don't know that this is going to work. I mean so far everybody who's tried to do this has failed And there's no guarantee that this is going to be successful, but I'm optimistic. I think we have a chance So there you go. That's the safe project. Thank you and good night