 Alright, thank you Douglas so much. Next up we'll have a fireside chat, so I'll bring the chairs up here. So we'll start up with very basic questions and then after that we will kind of open it up to the floor for all of you to ask Douglas some questions. So I did a little bit of survey among the community members here. We are all here to kind of get Douglas's perspective on the evolution of the web because he has been in this industry for just so long. So Douglas is this your first time with the Singapore developer community? I think it is. Well no, first time I came to Singapore was in the 90s I think and it was at a conference at the Raffles Hotel I think. Do you remember what conference? This is interesting right? You didn't remember which conference was that? No, I don't remember the conference, but what I do remember is that they flew me out here, you know, they paid my expenses, you know, bought the ticket and put me in the hotel and there were ten people in my audience. Ten people? Yeah, it was like… A lot more today. Why did they do that? And it wasn't just me, there were some other Americans who had come from California and they were really upset, you know, it came all this way over to Singapore and there were only ten people, you know, why would we do that? Well, let me tell you something, we have a very young but growing web community in Singapore and let's have a show of hands. How many of you play with CSS as part of your daily engineering software, CSS? Alright, how about HTML? Some kind of template in which you kind of touch on, you know, handlebars or moustache. How about JavaScript in the front end? Woo! Woo! That's how JavaScript first got started, right? And how about JavaScript in the server side of it, like Node.js? So there you have it. You are here in 2015 and the web community in Singapore has obviously grown a lot and I'm sure all of you have a lot of questions, but let's start with the very first one. Save project you said and you said that one of the company, apart from the browser, you said one of the company that would be useful is a company that needs security, so PayPal? Certainly PayPal has a big need for security as do all of our competitors, as does virtually everybody else. You know, we're particularly sensitive to it because we move so much money through the net. That's right. It's not unique. There are lots of other companies who are putting all of their assets in the net as well and I think we all need relief. We all need to have systems that are much more reliable so that's obvious. Right. So the next question would be, it came from a few of you, is about the languages that web primarily uses and you talked about the fundamental problems with HTML and then CSS. So do you think there is room for more languages in the web? I wish there was. So the problem isn't with room, that a well-designed language has a very small compiler and a very small runtime. So there's no space limitation on putting a new, better language into a browser. It's all security. That we have spent 20 years figuring out how to make a JavaScript environment safe and if we were to put any other language in there, we would be starting over. And it's not just, the damage can be worse than what we're playing with now. Because you can visit, the most evil people in the world are allowed to send you scripts. If they can trick you into getting you on your URL, they can send you the worst possible stuff. And if we allow them their choice of programming languages, they will choose the language which makes it easiest for them to get in and do really bad stuff. Not just stealing your cookies, but trashing your system. Stealing your identity, turning your machine into a bot, all of that stuff. That's a real concern. Now, I am about done with JavaScript. You know, it should not have become as important as it did. And the fact that it did is at least partly my fault. Sorry. So I am really looking forward to seeing the successor language. And I hope we can figure out a vector by which we can take that new language and put it into the web. Safe might be the way to do that, since at least until we get it finished I have some control over the platform and I might be able to get a second language processor into it if it's credible. But I haven't seen that language yet. So if somebody is working on a language which is kind of in the same class as JavaScript, but much more rational and much more productive and safer in all of those good things, if someone has figured that out, please let me know and I'll see if I can get it into the safe project. And if safe goes, then maybe this other language could come along. Right. So there you have it. If you're working in a language, talk to Douglas. So, well, the next question is obviously about JavaScript, which you have a lot of perspective about. Recently JavaScript in the last five years has gone through this sort of renaissance with NPM, which Sebastian kind of pointed out while we were having a discussion. So do you think JavaScript can go beyond the web? It is already going beyond the web like in sysadmin, networking, hardware. Where do you think the dominance of JavaScript will? It's getting into everything. Yeah. Yeah, it's all over the place. So do you think it will just grow more than the node and NPM ecosystem? I don't, it's not node and NPM necessarily, but it has some nice properties. And despite its terrible failings, it actually has a better security model than virtually every other language. And so it's finding its way into all sorts of stuff. And as more people learn it, there are going to be more people wanting to use it to solve other problems. And it's displacing other languages like Java is losing ground to JavaScript. C++ has lost a lot of ground to JavaScript. Because the engines have gotten so much faster and Moore's Law has done such incredible things on memory capacity and CPU design, JavaScript is fast enough for almost everything now. We're just on the threshold now of JavaScript being fast enough for doing games. So there's a whole market opening up for JavaScript as the principal programming language for game development. Who would ever imagine that? That was inconceivable just a couple of years ago. But that seems to be the track we're going on. And if JavaScript gets into the game consoles, wow, that is a whole other thing. Absolutely. All right, so since there are so many of you, we will really get to the audience questions. Maybe something about the SAFE project or the evolution of the web. Yeah, anyone? Zoris? Yeah, so thank you for the talk. I can sort of relate to you saying that HTML is not the perfect platform for the UI. But why QT in my opinion? QT is great. It's a more old fashioned, and I mean that a really nice way of doing things where you talk about the buttons on the widgets and all the things you want and you've got nice layout components that you can use to present them. So you'll have a much easier time of making displays at work in large and small formats. You don't have any CSS. You just tell things what they're supposed to look like and they salute and look that way. You don't have to trick them into looking the way they're supposed to. It should be a much more pleasant thing. The one thing against it is you're not used to it. And so there's going to be an adjustment. But eventually you'll recognize this is just a much saner way to develop applications. Okay, I saw a question. Nora? It sounds like the idea of the SAFE helper app is to introduce another runtime into the browser. Which kind of sounds very similar to what we had very common until a few years ago with browser plugins like Flash and Silverlight. Which are also kind of a sandbox environment inside the browser. And up to that time they had a more robust presentation model than HTML. Their language is very feature packed and they can use some messaging protocols that are not HTTP, no one thought of TCP. So they still died out even though Flash released became open source. So the community could just pick it up. What makes you feel that SAFE could end up in a better place to evolve? I think it's the transition plan. So the plan for both Flash and Silverlight was to first capture you. And they figured if we can get all the developers then we'll win. My approach is instead I want to capture the audience. I want to make this transition as easy as possible for the audience. Even if it means it's going to be more painful for you. Because ultimately it's the audience that matters. And that needs to be the focus. The other thing is that they were trying to capture the web and I'm not. I don't want to own any piece of it. I just want to make the web work better for everybody. So there's an openness component to SAFE which was not part of Flash or Silverlight. So I think that's going to make a difference. Hi, Sebastian. Hi, thank you. So I used to be a long time ago involved with XMPP. Which I guess failed because it was not using JSON instead XML. But it was also trying to make the web open and have more of a bi-directional duplex stream to exchange data between applications in a decentralized manner. Also rely on DNS which is another reason for it to be failing. But do you think that seeing messaging applications like instant messaging applications could be a good angle to gain adoption for a protocol like SAFE instead of the web? Definitely. Because I see the web as being the bigger problem. So that's where I want to focus. But the things you're saying are exactly right. I'm not proposing that there are any new ideas in my plan. That the reason you tried that stuff a few years ago was it was the right thing to do. And you just couldn't find a way to convince the world at that moment. And I might not be able to either. But I think we have to keep trying. All right, Tianan. So just how we talk about new programming language for the web traffic. So what's your opinion on that? What's my opinion on the web assembly? I have a problem with CPU architecture in general that we're still working with a low level von Neumann model where any instruction can potentially go to any cell in memory. And that causes terrible performance problems. And it causes terrible security problems that running stuff well in CPUs is just really hard. And even though Moore's law has caused him to get so much faster, sometimes it feels like we're not getting much benefit from all that increase. So I would like to see more research in language-oriented CPU design so that instead of the programming model being assembly language with instructions and registers, it's higher level languages. Like I'd like to see work on a JavaScript processor, a processor especially for JavaScript so that we can get language-based security into the hardware and all the efficiency that comes from doing that. So my problem with web assembly is it's taking the broken architecture and doing it, you know, it feels like a trap to me. Like we're never going to get free of this stuff if we're now emulating it in the web. I get frustrated with our lack of progress. Our industry talks all the time about how innovative we are, but then you look at what we're doing and go, wait a minute, that idea is at least 50 years old. You know, when are we going to get onto the good stuff? You know, I'm getting really impatient with that. Good parts. Yes? My name is Jack Bao. So I'm just wondering how do you see developers that you talk to or developers that you need to help to propel this project? I bring this project forward. Well, ultimately, this is going to depend on you that if you decide that safe is not something you want to risk, then safe is not going to happen. So part of my effort is to convince you that this is worthwhile so that you can convince your colleagues that it's worthwhile. Eventually, if we can get critical mass on this, then there's a chance that we might win. Well, the code is open source on GitHub and have a look at it if you want to contribute in other ways. Tim. So have you approached any browser vendors about this and what is their reaction to it? I have not. And the reason I haven't is because I'm still vapor at this point. So I don't want to go to them until I've got something that's real. I mean, there's been so much vapor in the web, right? And even this talk is premature, but we're friends, right? So I'll share it with you, but I'm not actively campaigning yet and I don't want to start the campaign until it looks like we're going to get it right. Okay. Cool. How about you? Who's working in this project? I'm sorry? Who's working in this project at the moment? It is just you? I have some brilliant people at PayPal who are actually doing the work. And they're great. Jesse, do you have anything? No, they're in San Jose. I saw Chinme. Talked initially about passwords. And one of the things that I still have but never actually got used was client authentication. Would some model like that, like every client has their own certificate and uses something like that to authenticate? Oh, definitely. Maybe a better solution than passwords. Yeah, absolutely. Absolutely. Yeah, that's what we're doing. Again, there is nothing new being proposed here. It's all old ideas that are good ideas that for whatever reason have not been adopted yet. And the thing that you're suggesting is exactly the right thing to do and we're doing that. I saw, yes? Because of security and decentralization, you're looking for blockchain-based? Blockchain-based security. Bitcoin is not my thing. So you're going to have to... Yeah, good luck with that. I have real concerns about that stuff scaling, that there's so much crap that's trying to get into the blockchain. When the whole world is putting everything into the blockchain, I see nothing but collapse. And if the collapse takes down your financial system, that's kind of a bad thing. So I could very easily be wrong about that, but I don't think I am. But, you know, good luck with that. Saris. Yeah, so the safe URL is based on public key cryptography. So how do you expect normal users to secure their public key and what happens if the site of the public key gets compromised? Okay, so the thing they have to keep private is their private key, that they can actually broadcast their public key. We're going to have some policies, so we're going to be trying hard to protect it. For example, we're going to have policies we will never put their private key on the wire, ever in any form, even encrypted. When it is in storage or in memory, it will be encrypted all the time. So there's still a potential that if someone can corrupt your operating system, you can get at it from beneath, and that is a concern and we worry about that a lot. So another thing we're going to be campaigning for is to get our operating systems fixed because they're not protecting us adequately. And, you know, with the Snowden revelations, we're finding that there are more of those things to worry about than we thought we should be worrying about. So that has an impact on all of us. So what will be the strategy to pass the private key across different devices? So we'll probably encrypt it and put it on a USB stick and then you can carry that to your other devices. Tim? How would you tell people to go check out your website without DNS, like for example this URL? It doesn't, won't you need to invent something that's like DNS in order to do that? Possibly. There might be an opportunity for the next Google to do things like that. Another thing you could do is, you know, you could have a billboard with a QR code on it. That's your driving bar, you can click it. You know, so we're making it really hard for humans to do this stuff but we're trying to make it easier for the machines to do it on our behalf. I saw one question. Yes. Do you have any timeline for the same project when you can use your computer to upgrade your work? That's a really good question. He's asking what my timeline is. And I'll tell you why I'm not going to tell you. I have an idea about how long it should take and I know from experience it'll probably take four times that long because that's just how it goes, right? That's not news, I hope. The making of good software takes time and if you try to make it take less time, it takes more time. And it's really important to me that we get this right. So I'm not telling anybody how long it's going to take because I don't want to be committed to ever have to make a date before it's good. Most of us never get the opportunity to practice that way but somehow I've lucked into this situation where I seem to be getting away with that. And I'm going to keep doing that as long as I can. I think I had, I saw a hand. Yes, Joshua? You mentioned about the shortcomings of CSS. So in your mind, what do you think is the ideal way for layout, for example, as well as auto-layout which is constraint-based? Yeah, it should be a constraint-based system. Constraints are great and Qt provides layouts and mechanisms like that for doing that. So, yeah. Check out Qt. Yeah, check out Qt. Qt was part of Nokia for a while and then it got spun out. It's open now. It's really clever stuff. Initially, it was a C++ platform. A few years ago, they put a nice JavaScript layer on top of it. They've got a friendly little language called QML which sort of looks like JSON or Java FX. It lets you specify things in a friendly way. I think that's going to be a lovely way to make applications. How about you, right at the end? I'm a patient about servino web. So people say that security and slowdown web. How do you convince these people that this being done in slowdown is supposed to be? Because you're going to use drop-in question to try to do it right. Security slows down web. That's only if you don't do it right. So if you look at the SSL protocol, it's extremely complicated. They have to do several round trips before they can get a handshake going and set the thing. We will establish a secure connection in one round trip. That's the best you can ever hope to do. And we can even set it up that for most connections, we don't even need to do a public key exchange. That we can instead exchange prepared tokens and so we can even skip that processing. And then it should be really fast. It should be really fast. And because it's a full duplex interactive protocol, it's going to be much faster than HTTP for doing everything that you're doing. And it will also allow you to do things that are very difficult to do with HTTP like push. If the server has something and it needs to tell the browser, it doesn't have to wait for the browser to ask for it. It can just shoot it out. And if you asked for something and you need to ask for something else before the reply came back, you don't have to wait for the reply. You can make the next request. If the channel is clear, you can go ahead and send anything you want. So that's going to allow you to, it's a different programming model. So you're going to have to get used to message passing because that's how everything is going to be working now. It's not going to be, you know, request response is sort of like a procedure call. You know, you stop until it's happening. But doing procedure calls across the network is crazy because the network introduces a huge amount of latency. But if you're message-oriented, then you can get a pipeline going. You can get some latency compensation. Performance gets much, much better. How about the last row over there? Yeah, I was just getting ready for the CSS question. What do you see that way on mobile? Mobile on CSS. So my plan is that our helper app ends up in mobile devices as well. So that exactly the same model. And then you'll have JavaScript enhanced layouts, which get really smart about how to deal with a very constrained screen size. So my, they haven't demonstrated this yet, so I might be making false claims, but I'm confident that we're going to be able to pull this off, but you're going to be able to develop applications which look good on the big screen and which will scale reasonably onto the small screen. That can get smart about you have to collapse these things into a little three-line gadget and so on. I think you'll be able to do that. All right, Sebastian and then you, Sebastian. Thank you. Have you considered working with other companies on this yet, or especially standards bodies? We're not talking to other companies yet, so now that we have opened the first piece of it, I'm sure that's going to present opportunities. I'm not considering standards at all yet. A major problem with standards is that the standards process cannot correct the problem of complexity, which is the root of the problem. Standards can only increase the complexity. They don't have the power to do anything else. Also, there's a tendency in standards making to do experimental stuff in a standard, which I think is terrible and we've seen bad stuff come from that. So, I'm still in a research phase, right, and it would be irresponsible to be proposing standard setting until we have proven that it works. Once we've proven it, then it becomes a matter of standardizing a best practice, and that's an extremely reasonable thing for a standards body to do. So, once we get to that point, then we'll look to the industry and the standards community to help us do that, but not until we've done the rest of our work. How about you? We got into deficiencies of the HTTP part involved. It kind of sounds like HTTP2 is solving some of the same problems that you're attempting to solve. HTTP2 is solving some of the same problems, but they can't eliminate the complexity. And so, I think the SAFE protocol will still outperform it in new applications. Saras? Yeah, so you use security system or TCP or instill HTTP, but how do you use that to transfer large binaries like videos and images? So, we probably don't want to move videos over the SAFE protocol, but for large binaries, we'll be able to move blobs in the SAFE protocol. And code it in JSON? No, of course you can do that, and you can put films in JSON format too, but I wouldn't recommend that. The JSON protocol will be able to move two things. It can move JSON payloads, and it can move blobs. And you can put a JSON header on a blob and say there's a blob coming, and it's got this crypto hash, and it's going to be this long, and it goes, and then we'll retrieve it on the other side, verify that the crypto hash is correct, and it's the right size, and then deliver it. So, we'll be able to move binary payloads very efficiently. Right, Thomas? What's your thoughts on projects like AMP that essentially take the complex parts of the web and try to say, hey, this is the subset that you should use to make, like, a better web, specifically a mobile with AMP? Is that, like, a valid approach to reduce complexity over time, that, like, not use things eventually will not be supported anymore? Oh, sure. It's a much smarter approach than trying to use every feature that's available. I'm a big believer in subsetting, right? I'm an advocate of using just the good parts. Because I believe that only the power of good can defeat the power of bad. Wouldn't that be a healthier approach to fixing the web rather than trying to construct an alternative that needs to be, like, very, like, hard attached to it? No, I don't think you'll ever get all the way there that way. There's just too much wrong. That kind of scraping away at it is not going to get us there. If it could have, we would have gotten there by now. But it's still a growing platform, right? Yeah, it is a problem that it's still a growing platform. I mean, as it gets more complex, the security problems become more difficult to deal with. That complexity is the root of the problem. And the standards process cannot reduce the complexity. They can only increase it. And as they keep increasing it, the security problems get worse. So as a matter of practice, I think it is wise to try to subset the system and try to make it smaller. But at its root, the complexity is still in there and is still waiting to compromise you. Right. What other questions? How about you? I was just thinking, what do you think would happen if there wasn't the same project? Do you think the web would get to a point where it would just completely break and it would be some kind of fun? I was reminded of that. The doomsday of the web. Maybe not. Because I think we would have already said it was doomsday already, right? We've had so many big crashes and heartbreaks. And it seems like you can't shame the web. No matter how stupid it gets, it's, well, it's the web. What are you going to do? And we keep investing in it. So maybe that goes on forever. I don't know if that's sustainable or not, but it has gone on a lot longer than we expected it would. Do you think it's because it's open? Open is the really only admirable thing in the web, that the world's biggest open system is wonderful and that it has somehow survived all these proprietary attacks is wonderful and that it has survived its own incompetence. And that's wonderful, too. But I don't know if that's sustainable. We'd like to know, what's your thought on two-step... Two-step. Two-factor authentication stuff. Yeah, two-factor authentication. So I had a problem. I was in... Where was I recently? I was in the Netherlands last week or a week before. And my phone died. The battery was... And I'm trying to log in, right? And Google is saying, we're going to send you a phone number. And I go, well... And then there's a button where you can click on something else. And I say, okay, something else. And they come back, okay, we're going to send a message to your phone number. And I go, no. I was offline for a week because my phone broke. Now, the reason we're doing two-factor authentication is because we know that the one-factor is a complete failure. Right? So I'm trying to fix the one-factor. Reduce the complexity. Yeah, if I can get the one-factor working the way it was supposed to, then we don't need another one. I saw Noa. Earlier, when somebody asked you about how to connect, I think, with another device, the same service or website, whatever it will be. In the future, you said maybe you could put it on a USB stick and smooth it around. Today, if some disaster strikes, let's say you cause everything to fire, you can still, wherever somebody, password, recover something. You can reset passwords through your email and you can still recover. What would happen to someone in that future that you lose this particular one that you've done to your disaster? Right. So if you lose your private key, you are totally screwed. There is no way you can recover it, which I think is actually the best thing that we're proposing because it means that NSA doesn't have it, the Red Army doesn't have it, North Korea doesn't have it, nobody's got your private key. And if you lose it, then you're going to have to start over. I would recommend that you keep your private key in a safe deposit box or someplace that you trust, so that you don't get screwed. As long as you have any one of your devices, which hasn't been destroyed or captured, you can recover everything just with that one device. So if you're so unlucky that you lose everything and your bank is also destroyed, then yeah, you're screwed. But I think you're better off than you are now. Martin? That's right. You're okay, so your phone died, isn't it? Wouldn't you be left with that situation? With a single key? You wouldn't have your private key with you apart from on your phone? No, every device you own will have your private key in it. Would all of your devices be elsewhere? Or would you have it on your laptop too? Yeah, your laptop would have it too. Every device you have, every smart device, you could even put it in a refrigerator if you wanted in your TV. Google is refusing to interact with your laptop in any way. It needed your phone. Yeah, I was trying to log into Google on my laptop and it wouldn't let me because my phone wasn't working. I saw one question. How about you? So a lot of the same project is about fixing what's wrong with the web, right? And it's using JavaScript as a major component within it. But as you said earlier, JavaScript has some things that would need fixing themselves. So in the process of the same project, what are the things, if any, that you want to fix within JavaScript? I don't have the power to fix JavaScript. I tried and tried and tried and I couldn't. TC39? Yeah, I was in TC39 for some years and I managed to get ES5 out. So, you know, ES5 was great. And my mission was always to try to reduce the complexity of language, try to make it less weird and less bizarre and less creepy and all that. And I failed. I could not stop that. So, you know, that's not a fruitful avenue. What I can recommend is that there is goodness in JavaScript and if you just use the goodness, it's almost like using a really good language. It's the good parts. Yeah, and you can do that. You know, JSLint is free. You know, if you're using JSLint, your programs get better. They really do. And a lot of people cry. I don't know why my programs get better, you know. But they do and they should. You should want your programs to get better. So there's that advice. Now, the SAFE project will not require that your stuff pass JSLint. Our stuff will pass JSLint. I guarantee you any JavaScript that is released through the SAFE project, it will pass JSLint with no warnings because we want to write good stuff, not like some other people. So that's how it goes. So it's really up to each of you. You know, you can write good JavaScript or you can write crappy JavaScript. You know, it's like using the Star Wars analogy since the new movie is coming out. JavaScript offers you a choice. You can go Jedi or you can go Jar Jar. And a lot of our brothers go Jar Jar. But you don't have to. Use the Force. Alright, I think that was a great discussion. Use the Force, yes. And I'm a great ending to it. So once again, thank you Douglas Cutler.