 It is our great pleasure and privilege to have Douglas Crockford with us here today. Please give him a big warm, fungular welcome. Good morning. I'm going to be talking about the web. Everybody's going to be talking about the web. The web is something that everybody talks about. The web grew on top of revolutions in microcomputing and networking to become the biggest application delivery system in the world, and it has changed the way we do almost everything. It's a tremendous achievement, and we all benefit tremendously from it, but it was not intended to do almost all of the things that it's doing, and as a result, it doesn't do all of the things that it does nearly well enough for us, and we're struggling with how do we fix something which has gotten so big. So I'm going to be talking about how we might make the web better, but first I need to give you an apology. I don't have anything to show you. None of the stuff that I'm about to talk about is real. There are no demonstrations. There's nothing you can look at, nothing you can try, and worst of all, if this is interesting to you, there is no way currently that you can contribute, and that's intolerable. There's no excuse for that. My excuse is I was invited to talk about anything that's of interest to me, and this stuff is really interesting to me, and I hope it'll be interesting to you as well. And the reason I don't have anything to show you is just that this is still really early, so I'm giving you a very preliminary look at some of the work that I'm doing. So the web is this remarkable thing. It began as a hypertext system. There were other hypertext systems before. There was Engelbart system, which was amazing and wonderful, and in many ways we still haven't caught up to Engelbart, but his system was not distributed, whereas the web is. And then there was Ted's Nelson-Zanadu system, which was also an amazing system. It was also incredibly capable and incredibly complicated, and its doom was in its complexity. The web, by comparison, was a very simple system. It managed to succeed largely because of its simplicity. Unfortunately, the web was not able to maintain its simplicity over time. It's gotten very complicated, which is part of the problem now of the web. My biggest problem with the web is its lack of security. That we're now using the web to manage our identities. We're using the web to manage our wealth, we're moving enormous amounts of money through the web. The web was not designed to do that, and because it was not designed to do it, it's really not safe to be doing most of the things that we're doing on the web. This concerns me a lot. I've been going around the world for years talking about the security problems that are in the web, hoping that someone would listen and do something about it. Nobody did, so I'm going to do it myself, so that's what I'm going to talk about. One of the problems we have with security is that we have a big dependence on passwords. A password is a shared secret. You prove to the other party that you are who you claim to be because you know the password. The original computers did not have passwords. They were doing really important work. They were doing weapons design and code cracking, top secret stuff, but there are no passwords in the system. Instead, they relied on perimeter security around the machines, that there are men with guns around the machines, and that was sufficient to give you security. That changes with the invention of the disk drive. Because of the disk drive, it's now possible to have online storage, which means that any program that's running has access to all of that material, and perhaps it shouldn't. This becomes really critical when time-sharing is invented. With time-sharing, many people are making use of the same machine at the same time, and we need to keep them separate so that they're not interfering with each other. That's when passwords really become important in computing. At that time, passwords were effective because it was unlikely that anybody would have more than one time-sharing account, so you only needed to remember one password. Unfortunately, now on the web, almost every site you visit is going to require that you have a password, and good security requires that every one of those systems has a different password. And humans are not capable of remembering that many passwords. And so you see people either reusing passwords, which is not safe at all, or using very weak passwords because good passwords are very difficult for humans to remember. Also, we've got systems in which the whole game is about trying to get people to reveal their passwords. So what I want to do instead is to completely get rid of all of the passwords because they don't work for humans, and instead come up with a system which allows us to have the security that we need with no passwords at all. RFC 1738 was the document which introduced URLs. URLs were an important innovation. And in that document, there was a description of a particular form of URL in which you could include a username and password in the URL, and that would be transmitted to a system in the clear. At least one of the authors of that RFC realized that this was a really bad idea, and so he inserted the sentence, the use of URLs containing passwords that should be secret is clearly unwise, which was an amazing bit of understatement. Even understanding how bad an idea that was, they didn't have a better one. There was no alternative in the document, and they felt compelled to give this really bad one. In fact, early on in the web there were a number of sites which used this, and they very quickly discovered why this was clearly unwise. So I'm gonna talk about what's wrong with the web, because if you don't talk about what's wrong with the web, you can't figure out how to make it right. What I'm about to say is going to be shocking and upsetting to some of you. Many of you have never worked with anything except the web. And to hear it being criticized in public, the way I'm about to is going to seem awful. For those of you who've done applications in other technologies, you already know all of this stuff. You know what's wrong with the web and why all those other systems were better in some important way. But we need to have this conversation. We need to have it right now. So again, the particular problems I'm concerned with are the insecurity of the web and most of its insecurity is due to its complexity. And complexity is a really difficult thing to change. I don't think W3C for example has the power to remove the complexity or to repair the insecurity of the web. All they can do is add more complexity. You can't remove complexity from a system without breaking backward compatibility. And that's something that a standards process cannot do. There are lots of other things wrong with the web that's hard to develop and projects tend to be late and they're not reliable enough and all of that. I'm less concerned about that. My main focus this morning is on security. So let's start with HTTP, the Hypertext Transport Protocol. In my view, it provides three things. The first is, it is a textual format for describing key value pairs. And it's a very fussy ad hoc format. I think there are much better representations of key value pairs. Jason, for example, I think is much better at expressing that idea than HTTP is. It provides for negotiation where a client in a server can have a dialog about what formats and what resources are available and what each understands. That was really important in the early days of the web when the thing was still evolving and different user agents would have different sets of capabilities. It's less valuable now, but we still pay for that overhead of that negotiation on every transaction. And then it's a request response protocol. But its intended use was you give it a description of a document and you wait. It sends back that document and then you disconnect. You may then decide after having read the first document to fetch a second document. And for a simple text retrieval system, that's completely adequate. But it turns out that's not how we use it, that there might be dozens, maybe hundreds of assets that need to be loaded as part of a web page. But the way HTTP works is you can only ask for one at a time and you can't ask for the next one until the previous one has been delivered, which is hugely inefficient. So one way that web browsers have attempted to get around that is by opening multiple channels to the same server so that they can make several requests at the same time so they can not have to keep you waiting for so long. But there are other modes of interaction which are frustrated by this. And I don't think it's a good match for how we want to build applications today. Then there's DNS, the domain name system. This was created as a convenience so that we didn't have to remember and have to type domain name, or I'm sorry, IP addresses, that instead we could type in domain names, which is much friendlier, much nicer. There are some problems with it. One is that it infringes on the trademark system and in many ways is incompatible with the trademark system. And so there's this constant tension between domain names and trademarks. But a bigger problem is that it's not a secure system. That there are attacks on domain name systems such that you might expect that you're going to a particular place and you end up going someplace else, and that's a big concern. So because of those sorts of problems, I have a lot of trouble trusting DNS. There's SSL, the secure socket layer. This is something that Netscape came up with to provide authentication and link encryption, which is really important. All communication should be encrypted. Unfortunately, SSL is very, very complex. So complex that we still have not gotten it working right after, what, 15 years now. It's almost every month another major hole is found in the implementation of SSL. We should have gotten it working correctly by now, and we haven't. And it's because it's much too complex. Much of the complexity of SSL is due to its dependence on certificates and public key infrastructure. The public key infrastructure is an idea in which we can create electronic certificates and trade them around. And a certificate is signed by some authority and it designates that there is some association between some pieces of information, for example, between a domain name and an IP and a public key, for example. But it's, and that system was designed to allow for making decisions about security in an offline situation. But we're never offline. We've gotten the network working pretty well now. Everything that's of interest is online all of the time. And in fact, certificates have big problems in an online system. For example, it might be that you need to revoke a certificate. And that means you need to be online anyway, so having this offlineable system is working against what you're really trying to do. But the big problem with SSL is its dependence on certificate authorities. A certificate authority is some party which is allowed to issue these certificates. The first and most famous of these is a company called Verisign. I don't trust Verisign. I don't know who they are. If I have a certificate from Verisign, all I really know for sure is that somebody gave some money to Verisign. I don't know anything else, not for certain. Wikipedia tells me that Verisign has in the past issued bogus certificates, that Verisign has been hacked. And Verisign has not been forthcoming in telling us what the consequences of that hack was. All of that makes me really nervous about Verisign. But worse than that, there are hundreds of other certificate authorities. And your browser trusts all of them equally. And many of them we know have already been corrupted. It's a lousy system and all of our trust is rooted in this system. And I have no confidence in this system. 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 you're trying to create simple technical documents and have them be formatted on a screen, it's awful. It's really hard to write HTML and to get it right and to get the things to balance. That's why we came up with markdown languages. For the thing that HTML was invented for, markdown languages are much more effective. They're much easier to write, they're much easier to maintain. HTML is awful. Now if what you're trying to do is deliver interactive applications over the internet, HTML is terrible. It wasn't designed to do that either. And while it can, due to a lot of cleverness, it's really not ideal. It was not designed to be doing application delivery. One of the major ways that we use HTML is with templating. Where we have an HTML template and we will somehow insert matter into holes or variables inside of the template. I don't like templating for three reasons. One is that it is an attack vector. It is the way that cross-site scripting attacks happen. Cross-site scripting loves templating. Because somehow something will not get encoded properly and it now gets into a context where it can now become malicious and do bad things to us. And this happens all the time. You look at the trade press, at least once a week we see some major site has gotten owned again because of some problem usually due to templating. My second problem with templating is that it creates this over dependence on HTML. So that every layer of the system becomes focused on delivering HTML. So it tends to create leakage between the layers that everything is focused on HTML. And HTML was not designed to be an application delivery system. And so you get really weird distorted system architecture. The third thing, which I really don't like, is that it's a trap. Because everything now is completely focused on HTML, that means we're never going to get away from it. We're stuck with HTML forever unless we can figure out a way to stop doing templating. Then there's a document object model, or the DOM. This is the API that the web presents to JavaScript. And I think it is the worst API ever imagined. It is just horrible. And you need to be using a library, and there are lots of really good libraries, because they stand between you in this terrible, terrible thing. You should never be writing to the DOM directly because it's just nightmarish. It's awful. You should be using something else. And there are lots of good candidates to use. You've got to be using one of those. But it's worrisome that the fundamental API of this whole stack is such a toxic thing that you have to have some bandages on top of it. Then there's CSS, which stands for crappy style sheets. CSS was designed for the formatting of technical documents. And we're using it now for formatting of applications. And it's really not very good at that. There are some layouts and alignments that it still can't do very well. And then it's very complex. It has very poor modularity. It wants just to have one huge pile of style sheets. And it's very easy for one module to interfere with another one. And it's messy. It's possible to make it work, but it's way too hard. And you deserve something better. Then there's JavaScript. JavaScript is a hot mess. It was made in 10 days. And you can make, it turns out, a lot of terrible mistakes in 10 days. And those mistakes have been compounded over the years by TC39, just adding more good intentions to it. But TC39 can't fix it. They can only add more stuff to it. And so it's going to get messier. They cannot make it cleaner. And there are a lot of people who hate JavaScript. And they think they have good reasons to. They cannot forgive JavaScript for having become more popular than the language they'd rather be writing in. It's not fair that JavaScript is more popular than Java. It's not fair that it's more popular than C sharp or Visual Basic or Python or Ruby or pick any other language. Why isn't my language more popular than JavaScript? And there are a lot of people who hate it for that reason. I don't think that's a good reason to hate it. So I'm proposing getting rid of all of the stuff that I talked about previously. I'm going to stay with JavaScript for a while. I'd really much rather be using a better language. I have not seen it yet. I keep hoping someone's going to give us a new language. Most of the new languages that I've seen come up recently are really just new syntax and old languages. I'm looking for the new thing, the thing that recognizes what JavaScript did right and advances in that direction instead of going backwards. So for now, there's still a good language hidden inside of JavaScript. That's the language I propose we use. So this idea of let's fix the web is not a new idea. Many people have recognized the deficiencies that I just outlined and assumed we can do better than this. Obviously, we can do better than this. Microsoft, Apple, Adobe, Oracle, and many others have all proposed replacements to or major changes to the web. In almost all of the cases, their technology was much better than what the web offers. But in most of those cases, what they were proposing was not open. They were proposing new proprietary systems, new closed systems, which would allow them to capture or replace the web. Unfortunately, all of those failed. The thing that is the best thing about the web is its openness. And I hope that whatever comes next will be as open. But I think the main reason why all of the other proposals failed was they did not have a transition plan. They did not have a way of getting from here to there. What transition plans they had mostly involved trying to capture you. But they didn't think about trying to capture the audience. So I want to upgrade the web. I want to keep all of the things that it does well. Because there are some things that the web does really, really well. But there are some things that it does really badly. And I want to fix those without making it more complicated and without obsolete anything that we currently have. So my model for how to do this is high-definition television. You probably remember that just a few years ago, we were using analog television. In the US, we were using NTSC. What were you using here? Was that NTSC too? PAL? Yeah, PAL was also a very good system, but it was also analog. We wanted to go to digital television. We wanted to go to a bigger aspect ratio or a wider aspect ratio. And it meant changing everything. And in the United States, Congress got involved in the transition because they were really worried about it. The concern at Congress was that if we bring in a new television system, and on January 1 of some year, we turn off the old analog system and turn on the digital system. And a large number of TV sets go dark because they weren't prepared for the transition. And then the Super Bowl happens, there's going to be armed rebellion. And Congress didn't want that. So they had to figure out a way to get this transition to go so that the rebellion wouldn't happen. And they succeeded. And the reason it succeeded was because of something called the set-top box. In those days, TVs were still made out of CRTs, cathode-rayed tubes, which were huge. And so a TV was a big box, which was big enough that you could put a smaller box on top of it. And the smaller box could receive digital signals and translate them into analog signals that the old set could display. Some set-top boxes would be provided by your cable company or your satellite company. In some cases, the government would provide to poor people set-top boxes that would take stuff from their antenna and turn it into analog systems so that they could watch it. So the transition plan was not to make things easier for broadcasters or for program developers. In fact, they made things worse for them. Because for the broadcasters, they increased their cost of operation and program acquisition without any new revenue. So it hurt broadcasters during the transition. And it made it harder for producers as well, because they had to now come up with new equipment and new ways of making shows. And the shows were not worth any additional money. So that was another cost. The people the transition made it easier for was the audience. So that if you were in the audience, you did not need to know if you were watching an analog channel or one of the new digital channels. You might notice that the digital channels looked better. And you might notice that the digital channels take longer to go from one channel to another. But otherwise, everything just worked. And you didn't care about what was going on. And I think that's why the digital transition worked. And so that's the metaphor I want to use for upgrading the web. So in this model, the helper app is the set-top box. The helper app is something that we saw in the very first web browsers. In the first web browsers, if you tried to open or display an image type and the browser did not know about that image, for example, JPEGs were not in all of the early browsers. Ping files took much longer to get put in. So if you tried to display an image that the browser didn't know how to display, it could go to a helper app, which in some cases might be a paint program that knew how to display ping files. And so it would pop up. Or if you were trying to play a MIDI file and the browser didn't know about MIDI, it could open a music player, and that would play. And that mechanism is still built into browsers. We don't use it much anymore, but it's still in there. So I'm proposing that's how we'll get in. So I'm going to develop a helper app. And you can install it on your machine. And then when you try to do stuff in my new protocol, the browser won't know what to do, so it'll run the helper app, and then the helper app will do the thing. Now, I don't expect that most people in the world would install a helper app. In fact, I'm confident that most people in the world will not. But some of you will. So enough of you will be able to try it out and determine if the system works. We need to figure out a way to get everybody using this. So this is my transition plan. Step one, I want to convince one of the progressive browser makers to integrate the helper app, make it standard equipment. I think this should be an easy thing for them to do. Because all the helper app needs from the browser is a rectangle in which you can display its pixels. It needs to be able to send messages back and forth between itself and the browser. And it needs to be able to get UI events. Everything else that the helper app needs to do, it can do for itself. So integration with the browser should be really easy. And so I'm hoping that there'll be at least one browser maker who wants to be a leader in this and will want to do it. I then need to convince one secure site to require its customers to use that browser. It could be a government site or a financial site or a medical site, someone who has a really important need for security, someone who wants to stop taking risks on the web the way it currently works, is willing to tell their customers, you must use that new browser in order to do interactions with us from now on. I think once that starts rolling, then risk mitigation will compel other secure sites to do the same thing. And eventually, I'm hoping we'll see virtually all of the sites will want to get on to this new program. And then competitive pressure will move the other browser makers to integrate the helper app as well. So if all of this stuff happens, the way I'm suggesting, then this becomes standard equipment. And most users will never be aware that this happened. And then once that happens, then the whole world will follow for improved security and faster application development. Because I'm predicting that application development will be easier in this new system than in the current web. And nothing breaks. I'm not proposing changing anything in the way the web works right now. I'm just adding a new set of channels which work very differently, but which can be displayed in the same browser. The system I'm proposing will have very strong cryptography. We'll use elliptic curve 521 for key exchange and authentication. We'll use AES-256 for link encryption. And we'll use SHA-3256 for hashing. Now, there are lots of systems which claim to have strong cryptography, which are weak. Because just using strong algorithms is no guarantee of security. So I'm not making a claim that simply because we're using these, we're going to be secure. There's a lot of other stuff that has to be done correctly as well. But all of these are way overkill for what I need to do. I could be using much weaker forms of encryption, and it would be completely adequate. I'm going with this really strong stuff because I'm paranoid. And that's enough reason. So I'm paranoid. We hear about stuff getting broken all the time. Having these very long codes should give us confidence that we can go a long time before we need to start thinking about upgrading the system. So there's a brilliant guy named Zuko who has a theory about naming systems. He says that there are three useful attributes that you might want to have in a name. It could be human meaningful. It could be securely unique. And it can be globally decentralized, meaning it does not require any sort of authority for determining what the names are. And that the most you can have in any naming system is two of these. You can't have all three. The one that the current web uses is the first one, the human meaningful one. So URLs are intended to be a human meaningful name which allows you to go to a resource. And that's very convenient. But I'm much more concerned with security, so I'm going with the bottom two instead. I want to have unique names, and I want them to be globally decentralized, so there'll be no common authority for issuing these things. You will issue your own to yourself. But they will be the ugliest identifiers you have ever seen. And that Zuko says that's the way it's got to be. So I'm going to be using elliptic curve 521 public keys as unique identifiers. So in base 32 encoding, that means one of these public keys will be 105 characters long, which is impossibly long. A human being cannot be expected to type in an identifier of over 100 characters. It just won't work. So definitely, we're going to need computers to help us manage these things, because the keys themselves are not usable. You just can't. But the good news is there's no way anybody is going to be tricked into giving up their private key, because your private key is going to be 105 characters. No one can type that in, so there's no phishing attack that can work against this. So I'm getting rid of HTTP, because of all of the inherent problems with it. Instead, I'm using secure JSON over TCP, which is, I think, about the best we could hope for. And because it's not going to be a request response protocol, it's going to be a peer-to-peer protocol. So one party will send whatever it wants to the others. Here's an informative message that requires no response. Here's a request that does require a response. Here's a request that could require multiple responses. And the server, for example, could say, here's something you need to know that you didn't ask for, but you need to know it, so that's coming to you right now. All of those things are really hard to do in HTTP. They're going to be trivial to do in this protocol. So there's going to be a class of applications which become much easier to write. Real-time applications on the web will be much easier in this platform using JSON over TCP. So this is what our URL is going to look like. We'll start with the word web. I'm not sure I'm going to get away with that. The web should have gone without. The web should have said web colon, but they didn't. They really screwed up and said HTTP colon instead. So since they didn't want it, I'm going to take it. So we're going to say web. Then you're going to have your 105-digit key, then an IP address. An IP address is either four or three-digit numbers separated by dots or eight-five-digit numbers separated by columns. Again, that's getting on the edge of what humans can manage. And then we've got a capability, which is a private code which has some meaning to whoever you're sending the thing to. So for example, one way this might work is you go to your bank, and your banker gives you a card. And the card has a QR code printed on it, which contains the public key of the bank and the IP address of the bank and a capability, which is key to your account. So when you scan this thing in, you will connect to the bank and the bank will know it's you. And no further identification is needed. You now have a secure connection with the bank, which is now an enduring connection, which will last for as long as your relationship with the bank lasts. So you will never need a password again in communicating with the bank. Another place you might get these would be from a web page. A web page could have a link with a URL of that form. And when you click on that URL, it goes to the helper app, and that stuff happens. I'm explicitly providing the public key and the IP address because I don't trust VeriSign to give us the public key. And I don't trust DNS to give us the IP address. So where does this stuff come from? Google? I mean, Google's going to know this stuff. They already know this stuff. Google can provide this information with its results. I would trust Google before I trusted VeriSign. In fact, most people do that anyway. They'll type in a URL into Google, and Google will send them to the place. That's actually safer than typing in the URL. So I would encourage that kind of behavior to continue. That turns out normal people have pretty good instincts as to how they should be using the web. Let's just keep doing that. Also, I got rid of the slash slash because that was always stupid, right? So we're not doing that anymore. We'll provide software for doing trust management because people can't deal with those huge numbers. So we'll be able to take all of your relationships and we'll put them out in the cloud in a really nice way so that once you authorize someone on one of your devices, you can now access them securely through all of your devices. So all that stuff will be shared and nice. We'll provide you a way of assigning pet names to these relationships, names that are meaningful only to you, names that no one else can see, just to make the thing easier for you to use. Our model of computation is called a VAT. A VAT is a big container that you can put stuff in and nothing can get into it or out of it except through the interfaces that we provide. It provides much better containment than sandboxes. The sandbox was an attempt to do the right thing but didn't go far enough or just didn't do it right. VATs will do it much better. I wish the word VAT stood for something like a virtual architectural, I don't know what it, it's just a big container but it's really good because it means we can have lots of VATs running in the system at the same time and that they can communicate with each other bypassing JSON messages but they cannot corrupt each other. So it means that we can have mashups now that really work, that are strong which allow for cooperation in a way that doesn't allow for security violations which is a really good thing. That's ultimately what we should be pushing for. So having VATs that can communicate with each other allows us to have a computational model which has cooperation under mutual suspicion that I can be working with another entity, could be another company or another party. I don't have to trust them. They don't have to trust me. We just have to send JSON messages in between each other and we can create value for the user. That's a good thing. We've been wanting to get to that point for a long time. The web just couldn't get there. We had some experiments in which we could get kind of half the way there where we could put a component on a page which could not corrupt the page but there was no way to create a thing in which the page could not corrupt the component. And so this VAT model will allow us to do that. So this is a block diagram of the helper app. It's a really simple block diagram. I've only got two boxes on it. The first one is a JavaScript message server, probably Node.js. We need something that can do networking and file IO and local storage and Node.js is brilliant at that. Node.js was not designed to work in this environment and so we're gonna have to completely look at it in terms of its security in order to make sure that we can have cooperation under mutual suspicion because that was not a design goal for Node.js but I think we can get there. Then the other box is Qt. Qt is an application technology that was developed in Norway for a while that belonged to Nokia but it's since been opened. So we're only gonna be using a subset of Qt, just the display part. So in Qt we'll have display VATs, a VAT which can display pixels on the screen. You can give it a rectangle and it can put pixels in that rectangle. In the Qt side, it will not have access to the network, it will not have access to storage but it will have access to Node. So it allows us to have very good definition and separation in our applications, something which gets completely confused in our current frameworks. So if it's involving user interaction in pixels, it goes there. If it's involving computation and state and data, it goes there and it's always gonna be really clear what goes in which. And both sides will be programmed in JavaScript. It'll be a very nice thing. The Qt thing is a much more conventional kind of application framework. It should be very pleasant to use. So I'm not proposing getting rid of the old web because we need the old web. The thing that the old web is really good at is promiscuity, that you can go out and look at lots of stuff and the risk for looking at something that you probably, that isn't what you thought you were gonna see is usually pretty low, especially if you're using NoScript on Firefox, which everyone should be using. If you're going out on the web, you should have NoScript, which is on Firefox and it's great. I would not use any browser which does not have NoScript in it. Because if you go to a site which isn't what you think you're gonna go to, which is really easy to do because DNS doesn't work right, it's good to have NoScript working for you. But the old web, and that promiscuity is good because it allows us to make introductions to things, to have discovery of stuff, of surfing the web, of finding things, learning things, making connections, all of that is really valuable. But then you get to the point where you want to make a commitment, which you might want to do with a merchant or a customer or a bank or your government or even your friends, that whenever I connect to you, I want to be confident that you are you and not someone else. And that's something that the old web does very, very poorly. And that's the thing that I'm focusing on for the new web. And I need both of these capabilities. And I want to be clear at any moment which world I'm in. The old web gets confused, it thinks it can do both of these at the same time and it can't. So there's nothing new here, there's no new science, there's no new invention. I'm using a model of computation called object capabilities, which has been around for decades. So there's no experimentation, this is just building the stuff out and making it open and making it available. So I think the risk of this project is very low. That most of it is just cobbling together components which are already open source or nearly open and making it available to everybody. So in the meantime, keep doing what you're doing. I'm not proposing that anybody change anything that you're already doing. I don't know when this stuff is gonna happen, I can't promise it's ever going to happen. I can tell you what my intentions are, but I can also tell you that the intentions of a programmer are worthless, right? Cause we intend for every project we do to be done on time in a adequate quality and that doesn't always happen, right? Even though we always intended it, and this is one of those too. So it's possible that none of the stuff that I'm talking about will come to fruition. My hope, my intention is that it does. And I'm just giving an early heads up. Don't change anything until next time we talk, maybe I'll have another progress report for you. Cause you don't want to suspend anything that you're doing now on the chance of something that might not happen. Now there's this thing called vaporware that is a special case of thud, fear, and certainty, and doubt which was invented by IBM. Control data introduced this wonderful new mainframe. It was the fastest computer in the world and IBM was really afraid that they're gonna lose sales to it. So they announced that they had a new machine that was even better that was coming out soon and they didn't. And they did that with the intention of stopping people from buying machines from control data, hoping to starve control data so that they wouldn't have to compete with them. Eventually that went to court and IBM paid millions of dollars to control data, but apparently they still kept doing that. Microsoft was doing it for a while as well. It's a really bad practice. No one should ever do that. You should never announce products that don't exist. And that is not what I am intending here. So I'm not telling you not to buy anything that you weren't already gonna buy. Not to do anything you weren't already gonna do because you can't depend on my completing any of this stuff, at least not yet. I'm just offering a little hope, I hope, that maybe someday the web will be as good as you deserve and you'll be able to do a broader class of applications which will do a better job for your users and your customers and that's gonna be good for all of us, I hope. So eventually I get to the point where I'm gonna be able to open this stuff and you're gonna be able to share it and contribute and all that stuff and it'll all be wonderful. I'm not there yet. I'm hoping not too long I will. Until then, keep calm and J.S. on. Thank you and goodnight. His question about what is QT and what its relationship is to the system? So QT in its native form is an application development system. It's got IDE-like tools and it's got runtime and it's got all of that stuff. So I'm proposing taking a subset of that, putting it in the helper app and then the helper app gets put into the browser. So that becomes the thing that you write your applications to or at least the interactive display parts of your application. So in JavaScript, you will create widgets and components and they will display on the screen and will be fully interactive and do all of that stuff and it should be much easier than doing similar things in the DOM because it was designed to do what you're trying to do rather than the DOM which was trying to do something completely different. Oh, HTTP2, so HTTP2 is still, it's worth doing. It's trying to make the old web faster and certainly we want the old web to be faster but it's not secure JSON over TCP so I still want this new protocol. What about secure JSON over TCP? So it's gonna be doing link encryption. It's going to be very fast. It's not gonna be using certificates as SSL does because you're going to have the public key at the time that the transaction starts or that the session starts. So the way you'll begin a connection is you will encrypt the session key in the, using the public key of the system you're trying to connect to and you'll send that. If they are who they claim to be, they'll be able to decrypt the session key and send you back the first encrypted packet of the session. If you can read that then everything's good so we can begin a secure connection in one round trip which is good. Hi, Douglas, here. Thanks for the great talk. We saw that you mentioned about the secure JSON. Would you be able to elaborate a little more on what? What is it? I think I just said that. Okay, sorry. Unless I left something out. But it's secure, but it's fine, it's just JSON. That's what I care as a developer. Yeah, so from the point of view of a developer you're just sending JSON back and forth. So a message over the wire will be a JSON envelope and you can put JSON data inside of that and that will be delivered to an object on the other side and you can designate which object you want it to be delivered to and you can be delivering anything which you can represent in JSON. It will also be able to deliver blobs. So you can say I got this big chunk of binary data which could be an image or some other thing. We can send that as well. I mean, one of the problems with JSON is it only wants to send stuff which is textual. We'll also be able to send binary stuff as well. Yeah, so that's how we'll move everything in this new system. Yes, yes. About the helper app you mentioned, one of them was the Qt and another one was the JavaScript message server. So you said it will be probably Node.js. So I mean, what is like probably in that? I mean, will it be subset of that or superset or enhanced or totally different architecture? So it'll probably be Node.js. I'm still holding out hope for something better and by better, I mean something designed specifically for the thing that I want to do with a security model built in from the beginning. For someone with the right experience, this is an easy thing to do but I'm hoping someone will do it for me and if they don't, I'll use Node and that'll be fine. So one of my problems with Node is that well, first it's got those terrible synchronous functions in it, so I gotta get rid of those because that's inexcusable. The other is you've got things which are extremely convenient, like the Node npm package thing, which is great and that allows you to get code from anybody in the world that can come in and do anything. Turns out you don't want that in a secure environment, right? I don't want anyone to be able to load anything they want into the system. So we're probably gonna have to cut npm out and replace it with something which is less convenient and less nice and all of that because security requires it. Do I have a website or some place where you can contribute? I apologize, again, no, I don't. I don't have anything like that. All I got is what I'm telling you now. I'm hoping to correct this and again, it's inexcusable for me to come here and tell you all this stuff and have nothing to show you and I told you that at the outset and again, I sincerely apologize for that but that's just where I am on this project right now. Hopefully if I get to come back next year, I'm gonna give you some real stuff to look at and in a way to contribute stuff back but I'm just not ready and it's too early. Hey Douglas, so what is your opinion on ES6? Do you think it is gonna benefit the JS community or we have already surpassed that stage? ES6 is done. So the ECMA General Assembly approved it last month and so it's happening. Eventually the browser makers will get around to implementing all of it and then we'll have it. There is some really good stuff in ES6. There is extremely bad stuff in ES6. It wouldn't be ECMA script if we couldn't add a lot of crap to it so that happened but you don't have to use the bad stuff like class. I would recommend, you know, you don't have to do that. Class was the most requested new feature in ES6 and it was mostly requested from people who hate JavaScript, don't wanna learn JavaScript. Can you make it more like Java or C Sharp or something like that and so okay. But that doesn't mean that you have to use it. You know, it is not a validation that you were always right. It's just another way of writing stuff and if you write using class, you will never learn how to use the language effectively and you will, you know, go to the end of your days complaining about how miserable you are using JavaScript and that's just the way it is. If you can learn how to use functions properly then the whole thing changes and you find class, don't need it and there are a lot of things in ES6 like that. My favorite thing in ES6 is proper tail calls which is great so we can finally do tail recursion and continuation passing style and JavaScript which is brilliant so there's a whole new class of things that we could do in the language that we couldn't do before. That's wonderful and there's a lot of stuff that you really don't wanna mess with. We'll take just one more question please. Yeah. Douglas is going to be around so he can ask questions later. So. I'm sorry, where are we? Oh yeah. I had a question. You were talking about this helper app, right? So is it going to be something like a plugin? It's gonna, yeah, it is like a plugin. So will it work? I mean, we had flash, didn't work, right? Eventually somebody's going to implement it in W3C. Yeah, so anybody could develop this thing or anyone could do any other thing. The helper app APIs already exist and anybody can do this. So, just, I've been waiting for someone else to do this and no one has, so I have to do it. So my question is around this concept of making it a plugin. So like you said, right? If I'm using a browser, I have to install it separately. So that's what even Adobe tried to do with flash. It didn't work out. All right, so that's not gonna work. So it will work only with people like you who are highly motivated who want to see what does this do? Can I get this early? Can I see what it does? Is it worth the trouble? If I can convince enough of you that this is good, then we'll try to convince one of the browser makers to make it standard equipment. Cause the thing I'm confident of is if I have to require everybody in the world to download a plugin, it's not gonna work, right? It's got to be standard equipment. And so I need to make this good enough that a browser maker will take a chance on us and plug us in automatically. I'm sorry? Right, my transition plan is that eventually it becomes standard equipment in all of the browsers. That's what I'm hoping. I have no commitment from any browser maker to ever do that. That's where I am in the evolution of this thing. Hello, there was a nice talk. So there was a lot of fuss about web assembly. So everyone says it's gonna be the next web. So what is your thought about it? Which one are you talking about? Are you talking about the binary format? Assembly. It looks like a trap to me. I'm looking forward to a future where we stop doing awful things. And for me, the worst thing about the web isn't its performance. Cause it's actually doing really good. Our stuff runs pretty well. The compute time performance does not appear to be a problem anymore in the JavaScript world. Security is a big problem. Networking performance is a big problem. How fast we can add is in the noise, it appears to me. So to be focusing on that without concern of what other compromises that's going to add to the architecture, I think that may be misplaced. I'm out of time. Thank you, everybody. Thank you.