 My name is Mung Chang. I'm the Johnny Everson Dean of the College of Engineering at Purdue, and I would like to welcome all of you to today's Engineering 2169 and Idea Festival special event. As President Mitch Daniels reminded us that the best way to sing happy birthday to Purdue is 1 50th, is to engage in intellectual dialogues and conversations about the important topics for society. And as the College of Engineering aspires to the pinnacle of excellence at scale, as we break records in our research, academic, enrollment, and philanthropy, we are delighted to have these opportunities, to have conversations with those individuals who have achieved the pinnacle of excellence in his or her own career. And today on April 5th this afternoon, I am just so excited to welcome a personal hero of mine and the national treasure, Vint Cerf. Now, Vint is widely regarded as a father of the Internet. He co-authored with Bob Khan in 1974, the landmark paper that described the foundation of the Internet as we know it today, the TCPIP protocol. And since then, over the past 45 years, Vint, whether it's at MCI or Google, whereas the Chief Internet Evangelist today, or going from DARPA to ICON, has made a difference in how we live, communicate, and work. And for that, Dr. Cerf has received many, many awards and recognitions. I know you are here to listen to him and not to Wikipedia demonstration of his accomplishments, but let me just summarize briefly that Dr. Cerf received the Turing Award, received the Japan Prize and the Queen Elizabeth Prize from UK. He also received from President Clinton the National Medal of Technology and Innovation and from President Bush the American Presidential Medal of Freedom, the highest award that can be given to a civilian in the United States. And today we will divide this one hour into three parts. First with Vint giving speech on the timely topics of software and data. And then I will have the distinct honor to sit down with Vint and ask him pre-populated questions. So the particularly harsh questions coming from the faculty and students in engineering and rest of campus. And then we'll open it up to those who are in the auditorium knowing this is also live streamed and recorded as well. Maybe using Google platforms, I don't know. So we're going to start with the first part and please draw me with a big hand to welcome Dr. Vint Cerf. Thank you. Good afternoon. Thank you. You know, when people clap before you said anything, it's tempting to just sit down because it won't get any better than that. So first of all, I'm not using slides at all. You know, my favorite expression is power corrupts and PowerPoint corrupts, absolutely. So you actually have to listen to what I have to say. Second, I thank you very much for a lovely introduction, Dean Zhang. Of all the introductions I've had, that was the most recent. I feel compelled to give you a quick summary and explanation of my title at Google. It's Chief Internet Evangelist. Some people misunderstand that as a religious title. And in fact, when I hear questions like that, I just tell them I'm geek orthodox and that seems to work out okay. In fact, I did not ask for this title when I joined Google a little over 13 years ago. Larry and Eric and Sergey said, what title do you want? And I said, Archduke. And you know, so they went away and they came back and they said, you know, the previous Archduke was Ferdinand and he was assassinated. In 1914. And it started World War I. Maybe that's a bad title to have. Why don't you be our Chief Internet Evangelist? They said, okay, I can do that. Well, the topic, oh by the way, anniversaries. I have to tell you that in addition to your 150th anniversary and the 50th anniversary of Neo landing on the moon. There are two other 50th anniversaries in 2019. One of them is the ARPA net, the predecessor to the Internet. It was actually the installed first four nodes in 1969. And so this predecessor to the Internet is having its 50th anniversary this year. And in addition to that, in case you didn't know, Sesame Street was also started in 1969. So I called DARPA and I suggested we should do a joint celebration of the ARPA net and Sesame Street. We could have Big Bird come out and do something. So we'll all be celebrating various assembly things this year. The topic of this, my brief introduction here is about artificial intelligence. And I will confess to you that in all the years that I've had light, I'm not an expert in this space at all, but I had light contact with people working on artificial intelligence. And I always thought that AI might be better described as artificial idiocy. Because on the whole, an awful lot of it didn't work out very well. For example, in the 1960s when I was an undergraduate at Stanford, we had the naive idea that if we just put a Russian English dictionary into the computer that we could do language translation. So we did that. And then we put in a fairly simple expression out of sight, out of mind. And we did the translation into Russian and we translated back into English and it came back invisible idiot. At which point we realized there might be more to this language translation than just the dictionary. Now it's pretty clear that we have come a very, very long way in being able to do language translation. In particular, we went through a series of steps. One of them was very sort of rules-based, semantic kinds of things. Then we went into statistical translations where we had large samples of the same document in multiple languages and had relatively good success but still rather weak. And then of course along have come multi-layer neural networks which had made a transforming advance on our ability to do not only language translation but a number of other things as well. And I hope you've noticed that the Turing Award this year went to three pioneers in multi-layer neural networks. It's well deserved because the results have been nothing short of spectacular. However, part of my homily today is to say that machine learning and multi-layer neural networks are not necessarily the same as the sort of general artificial intelligence that people write scary stories about. General artificial intelligence at least as I would interpret it has to do with the ability of a system that includes us, I mean we're systems too, we're just biological systems to take a lot of input and formulate a model of the real world or a model of a conceptual idea in order to reason about the model. And if you think a little bit about how quickly human beings can abstract from concrete sensing, concrete examples, it's really quite shocking. I want you to think about a table for a moment and what it is you know about things that we call tables. The fundamental essence of a table is that it's a flat surface perpendicular to the gravitational field. My guess is most people don't think of it that way. But what we recognize implicitly is that this flat surface will support things against the gravitational field, particularly if the bottom of the object that's supported is flat. So we very, very quickly even at age one or two recognize the properties of this thing even if we don't have the vocabulary to describe it as flat surface perpendicular to the gravitational field. What's interesting is that once we haven't taken on board that concept, then we recognize how many other things can be tables. Your lap can be a table, a box can be a table, a chair can be a table. And so we generalize very quickly. So we take real world inputs, we abstract from them, we build models, we reason about them, and then we apply what we've learned, again applying it to the real world. And I find that to be missing in large measure from most of the artificial intelligence that we enjoy today. Some good examples, of course, of recent excitement coming out of our DeepMind subsidiary at Alphabet, which is the holding company for Google, DeepMind, and the other companies that are associated with it. You all remember the success of AlphaGo and the successful four out of five games that it played against Lease et al. And subsequent examples of the intelligence of that, well, intelligence, special intelligence, narrow intelligence of those multi-layer networks. What was quite shocking, of course, is that after having done AlphaGo, the same company, DeepMind, did AlphaZero. And in that case, they started out only with the rules of go and nothing else. No examples, no playing of games with people, but simply playing against versions of the game back and forth. And in a few days' time, the AlphaZero system was able to play go as well as the previous AlphaGo system did, but with much less manual training. This rapidity of learning, I think, is quite exciting, but we shouldn't allow ourselves to be overly enthusiastic about this because these techniques, in my view anyway, are very deep but very narrow. And so the kinds of things that we're capable of doing with multi-layer neural networks, while they're quite spectacular when it comes to image recognition, looking at cells to decide whether or not they're cancerous or not, or looking at other images to do classifications, we also know that they tend to be brittle. And they're brittle in ways that we don't always have the ability to predict. If we could, we could probably build the systems to be more robust than they actually are. The thing that's a little scary about the brittleness of these algorithms is that if we can't predict how they're going to be brittle or how the brittleness will be manifest, then we have some, should have some concerns about how we apply these technologies and what we rely upon them for. And just as a side note, I am not necessarily arguing that all machine learning is dangerous or bad or that artificial intelligence is going to cause a great deal of problem, but I think we should be aware of the potential. Now, in addition to that, quite apart from artificial intelligence and machine learning and everything else, I actually worry about software in general. And so here we are in the middle of this avalanche of Internet of Things, devices that are programmable that can communicate. And we hand autonomy off to those devices and let them make decisions without anybody in the loop. And it might be handling security, it might be handling the heating, ventilation and air conditioning, it might be handling the microwave oven or the refrigerator. And we just sort of expect them to do what they're supposed to do. The problem is that programmers make mistakes. Oh, that's shocking. I'm sure that most people would just be very alarmed to hear that. If you've ever made a living or survived in your computer science classes writing software, like me, you probably have a little dent in your forehead from the many times when you've gone, how could I make such a dumbass mistake? And the problem is we do make very stupid mistakes and we don't have very good programming environments to prevent us from doing that. So I'm actually more worried about little pieces of software that somebody grabbed off of GitHub and jammed into a video player or a camera, a webcam or something like that, which is vulnerable. So I used to say, the headline I'm mostly worried about is 100,000 refrigerators attack Bank of America. And you know, I used to think that was funny, it wasn't funny anymore. And the reason, because it was whatever, it was 500,000 webcams attack Dine Corporation. And the thing is that we won't even know that our devices are complicit. The refrigerator is keeping the ice cream cold, it's not melting. There's no indication that it's been invaded because it's doing everything it's supposed to do plus this other little thing that it wasn't supposed to do. So we actually are faced with a kind of fragile future if we're not thoughtful and careful about this. Every single person in this room who has anything to do with producing software should feel a real burden to be thoughtful and careful about the software we write and release into the wild. I would like to see the academic community build much, much better tools to help us surface mistakes that programmers typically make. And so whatever I might say about artificial intelligence and machine learning applies double to random pieces of software that become part of the Internet of Things. Everybody here by this time has probably heard about generative adversarial networks and the thing which is so shocking about the results that have been displayed is the ease with which these multi-layer networks can be made to misconstrue the information that they're getting. If you've seen the examples, sometimes changing just a few pixels in an image that looks like a cat will cause the system to declare that it's a fire engine. You know, when we look at this and we say it's not a fire engine, how could you possibly come to that conclusion? And the answer is there are dependencies on the values of the pixels in this multi-layer network that cause it to make mistakes. And I kept trying to think of a cartoon model that would explain this. Now this may not be correct, but it's helped me in trying to appreciate why this could be a problem. So I want you to think about a three-dimensional chart, you know, with X, Y, and Z coordinates. And you can represent every single point in the 3D space with a vector that has three numbers, you know, the X coordinate, the Y coordinate, and the Z coordinates. That's kind of easy to remember and to visualize. Now I want you to imagine a 100 by 100 pixel image. So there's 10,000 pixels. Imagine that we're dealing with a 10,000-dimensional space. Now, right away your brain explodes, but forget about that. Think for just a moment about the three axes, but imagine that the vector is now 10,000 values. And every time you change a value, every time you change a pixel, the vector moves around in this 10,000-dimensional space. So we cluster in this 10,000-dimensional space, vectors that are associated with cats, dogs, and kangaroos, and so on. And what we've done in the clustering is to create hyperplanes in the 10,000-dimensional space. Now imagine somebody changes one or two pixels. I suppose that the values are zero and one, black or white, to make it easy. So a change of a couple of pixels causes the vector to move in the space. What if it moves right past the hyperplane that separates cats from fire engines? And so that's the kind of thing that happens, at least in my little cartoon model, and it's very hard to predict ahead of time how those things will manifest themselves. So I have a list of problem spaces that I hope that you are concerned about. And I bring them up because the real world, the public, and also legislators and policymakers have now become conscious of potential hazards. And of course that sits very heavily on the shoulders of the computer science world. So deep fakes, things that are generated that look like they are real, but are in fact fictitious events that might look like a person that we might care about whose opinion might be important, has said or done something. Disinformation in general has become a huge issue. And we're seeing a lot of that flowing into the net deliberately from, for example, Russia that's trying to essentially disrupt the social fabric of the United States by forcing people to come to grips or come to blows with each other. Botnets, which are easily built because the vulnerabilities in the operating systems are quite evident and easily taken over. So the social and economic side effects of computer science, of networking, of the kinds of things that we build today are becoming increasingly apparent and for many people extremely concerning. And so, and I'm not going to end on such a negative note, but I want you to appreciate that in a sense the success of computing and networking and small devices that are programmable leads to a variety of problem spaces that need to be dealt with. Now on the plus side, so we can finish this part of the day with a positive view, the ability to gather and analyze information is better now than it ever has been. And this is not just about big data. This is about being able to take substantial information, high resolution information and the like, and to do something useful with it to analyze it. And the fact that we can do medical diagnosis better than we could before, the fact that we can find correlations in otherwise dense and complex data sets is ready for exploitation. And I mean that in the most positive sense of the word. So in a way where the beginning of an era where information becomes the paramount value in our society, our ability to manipulate that information to extract value from it is going to be indicative of certainly the remaining coming decade in our social history. So I'm actually excited as much now as I ever have been about the possibilities, but I'm also very conscious of the fact that the same technology which can do all these wonderful and good things which I rely on every day also has the possible potential for harming people and society. And so that's the challenge for us is to try to make sure all the positive stuff happens and the negative stuff doesn't. So I'll stop there and I think we're ready to do some Q&A. And in any case, thanks so much for joining us this afternoon. Well, first of all, let me ask you the I think the most pressing question of the day and the most important one that I've heard collecting questions from the students. And that is what phone do you use and what is the app that you use most of? Well, I have here a pixel which I've turned off so that it doesn't generate funny noises. At what app do I use them? You know, to be absolutely dead honest, no pun intended, I use Google and I am a persistent user of Google and Google Assistant and I'm always astonished at how much information it's possible to obtain quickly. I remember we had an electrical outage at one point and I remember sitting down with a pad of paper and a pencil intending to start writing something that I needed to finish and after about a sentence or so I gave up and the reason I gave up is that normally I'm sitting at a keyboard and I've got Chrome browser running and I always have a tab open to get to Google because about two sentences in I have a question I want to get the answer to and I couldn't because it wasn't accessible and I found myself just stuck. I couldn't get any further until I got the answer to that question so I'm hugely dependent on that particular class of application. Well, you know, I have here a paper entitled A Protocol for Pekkin Network Intercommunication. I remember that. It was authored by Vinton G. Surf and Robert E. Kahn and by the way, it's one month shy of 45th anniversary of the landmark paper that described what is now known as TCPIP, the theme ways that glue that gave us the internet and it started by this short to the point abstract that the protocol that supports the sharing of resources that exist in different packet switching networks is presented, the protocol provides for variation in individual network packet sizes, transmission failures, sequencing flow control into an error checking and the creation and destruction of logical process-to-process connections. Some implementation issues are considered, a modest way to put it, and the problems such as internet work, routing, accounting, timeouts are exposed. Now, first of all, I wish all the papers are written with such concise abstract these days and may I also highlight that, by the way, you can all Google this paper. It's free download. The pictures at the end showing Bint are not in a three-piece suit. That's correct, yes. That was back in the Stanford University where it wasn't required. We were three-piece suits. Oh, wow, those Californians who are in the 70s. Well, a lot of people... Could I just make a... Since you brought up the three-piece suit thing, I want to explain, you know, how did that happen? So I met Stanford and the guys at DARPA say come and run the internet program in Washington and my wife, who's from Kansas, says, Washington, D.C., three-piece suits. And so she goes off to the Stanford Shopping Center and she buys three three-piece suits from Saks Fifth Avenue, one of which is a Searsucker outfit because she knows it's hot and muggy in Washington in the summer. So I show up in my three-piece suit at DARPA and I'm asked to go and testify before some committee. I don't remember which one it is now. And I happen to be wearing the Searsucker three-piece suit. So I did my testimony and I came back to DARPA and, you know, I didn't hear anything. And a few weeks later, the director of DARPA says I want to talk to you about your testimony and I'm thinking, oh, you know, my government job is over, I've screwed up, whatever. So I show up and he's got a piece of paper in his hand. He says, well, I have a letter here from the chairman of the committee. He says, thank you very much for Dr. Cerf's testimony. By the way, he's the best dressed guy from DARPA we've ever seen. And I took that as positive feedback. So I've been wearing three-piece suits ever since. Well, if it secures the founding of the Internet, then so be it. So the question of Int is, by the way, I think of a sharing that history. I never knew it before. Well, what is the part of many outstanding engineering designs here and architectural decisions that you and Bob made back in 73, 74? Which one did you like most and which one the least? Okay, so the thing that was probably most effective is we borrowed from the ARPANET experience the notion of layering and incorporated in that notion of layering is the idea that below the IP layer of protocol, although at the time it was combined, TCP did both end-to-end addressing and also the flow control and re-sequencing and everything. We split that out a few years later. But at the IP layer, below that, we ignored a lot of the details deliberately of what the technology was that supported the flow of packets. And we did that very much in the expectation that there would be new communication technologies coming along that we didn't know about and couldn't predict. Remember, this is 1973 when we're writing the paper, or 74 when it was published. Six years later, optical fiber starts to become part of the telecom environment. So our isolation, deliberate isolation from the underlying technology was very much deliberate, even though it might have meant that we didn't necessarily extract from any particular underlying layer, Ethernet or X25 or what have you, the maximum possible efficiency. But we made ourselves more future proof than we would otherwise have been. So I think that decision was a very important one. The other one, which is I think equally important, is that we chose not to assign addressing structures that were based on any national boundaries. Unlike, for example, the telephone system which adopted country codes. And we did that partly because we were doing this work for the Defense Department. And we assumed that this technology would be used for command and control. That was part of the motivation for DARPA's funding in the first place. And we thought through a scenario that said, well, let's see, if we use country codes, imagine what would happen if the U.S. were confronted with having to attack country B in a couple of weeks and they were using country coded address space. What would you do? You go to country B and say, hi, we're planning to invade you in a couple of weeks. Can we get some address space so our command and control system will work? And, of course, the answer to that is probably no. So we said, okay, can't use that. It has to be topological. So the networks were just numbered based on when they were created, roughly speaking. Now, it's gotten more complicated now with CIDR and other kinds of addressing structures, but the whole idea was to be non-national and so on. So I think those were very good choices. Now, the thing that I thought was super important that turned out not to be is the ability to take an internet packet and if it got to an intermediate router somewhere that was going into a network that couldn't take a packet with that size payload, the idea of fragmenting the packet in such a way that it could be reassembled at the other end. So even if the pieces took different paths after they were broken up, it didn't matter. We could piece them back together at the far end. I thought that was going to be critical because we couldn't know what packet sizes were going to be available in the future networks that the internet was supposed to lie down on top of. Well, in the end, there's even an RFC called Fragmentation Considered Harmful. It has occasionally saved ourselves when you've run into a serious problem, but for the most part, fragmentation led to the reassembly problems that often show up. You have to have enough buffer space to put everything back together again. If you have too many pieces of packets that are not fully reassembled, you run out of buffer space and the system jams up like a Mexican standoff. So that turned out to be not as important as I thought it was. Well, we will have internet in commercial space. I know that meant in the 60s we worked JPL and here at Purdue, and of course we're celebrating July 20th, Armstrong's Lunar Walk, and we hope that Purdue will continue to play a critical role in the future of commercial space. But people ask me, but will I be able to check my email when I go out to the space tourism spots? So I'm confident the answer is yes, and the reason I can say that is severalfold. First of all, in 1998, a team at the Jet Propulsion Laboratory and I got together and said, why don't we design an interplanetary internet? And it wasn't just, you know, let's see what happens if the Martians show up. That was actually motivated by the belief that we had been doing space exploration using point-to-point radio links for command and control and for data recovery. And that seemed so wimpy and weak and un-rich and not robust and resilient. So we started discussing this possibility just after the Pathfinder landed in 1997 on Mars. And some of you will remember that the previous successful landing was in 1976 the two Vikings that landed on different places in Mars and then we had 20 years of failure. So it was pretty exciting to finally get the Pathfinder delivered, although I confess to you, do you remember how they delivered it in a big bouncing balloon? I was thinking if I was the guy who was running the program at the time and somebody walked into my office and said, we're going to deliver your $6 billion thing in a bouncing balloon, I would have thrown them out of the office. It shows you how much I know. So we got together and said, what would it take to allow an interplanetary backbone to evolve? And so the idea was not to go build one ab initio but rather each time a space mission went out, we would carry on board the interplanetary protocols and once the scientific mission had been completed, it could be converted, the spacecraft could be converted into another node of the interplanetary backbone. We started out thinking we could use TCP-IP to do this because it worked on Earth, it ought to work on Mars and it would, but between Earth and Mars the distances are sufficiently large at the speed of light is too slow and it takes anywhere from three and a half minutes to 20 minutes for a radio signal to get from Earth to Mars depending on where we are in our respective orbits which means the round-trip time is double that. And we started thinking our way through what does DNS look like with a 40-minute round-trip time? So you do a DNS lookup, you're on Mars trying to get something on Earth, you do a lookup. By the time you get an answer back, whatever it is has a different IP address because it just moved into another network so that's not helpful. Then we ran into the other problem where planets are rotating and we don't know how to stop that. So if you have something sitting on the surface of the planet and you're talking to it, the planet rotates, you have to wait until it comes back around again so we have it, or satellites in orbit, the same problem. So we have a variably delayed and disrupted environment. So we said, okay, new regime, delay and disruption-tolerant networking. So we developed a new suite of protocols that we call the bundle protocols in order to deal with a lot of those things and, believe me, it's not as easy as it might sound, especially when you get to network management because Ping is not your friend anymore. If you don't know how long this is going to take to get an answer back, you don't know how old the information is or if it comes back really late. It's useless information because the state of the system might have changed pretty dramatically. So we had to develop a whole new sense of network management in addition to everything else. The team is very excited about the current state of affairs. We have standardized the interplanetary protocols. They are running on the International Space Station. They're being used every single day by the astronauts and some of the experiments that are on board. We have prototype software that we wrote before what's running on the Space Station is still in operation on Mars supporting the rovers and the orbiters that are already there starting in 2004. So I'm honestly very excited about this. NASA has agreed that all missions in the 2020s and on will have on board the interplanetary protocols. So over time we expect to accrete an interplanetary backbone as the missions become repurposed as nodes in the network. That's exciting indeed. I thought Google is already working on the fixing of the planet and not to move anymore, but we hear that from the press. There may be some side effects. I know that some faculty believe that their message to university administrators such as myself the round-trip time is like 45 years. Now let me ask you, Avinth, that in addition to engineers and scientists designing artifacts they also design models. And a model is sort of a hard thing to do because you don't know where is your bathwater assumption where is your baby assumption? You've got to throw some out of the window and you mentioned the pitfalls and the perils of these models. What do you think about our fragility of reliance on models? Well, first of all, anyone who's ever done simulation, for example, will know that the simulation is only as good as what you were able to model in the simulation. So if you say, you know, the thing works great, everything's perfect, you go out there in the real world, you try it, something doesn't work. And the reason is that that one thing you forgot to put into the simulation because you didn't know that that was important or you didn't know that was in effect. So if you're going to build models and rely on them, a very high priority is to validate the model. And you have to validate it in as many different conditions as you can in order to be reassured that the model will accurately reflect what happens. Now we have a subsidiary at Alphabet called Waymo which makes self-driving cars. And we've driven those cars, variations on them in the San Francisco Bay Area and in a few other places for about 4 million miles or so, real driving miles. We've also simulated several billion hours or miles of driving in a simulated environment. The reason that that's turned out to be important to us is that, and the quality of the simulation is very important, is because we are trying to test edge cases that we wouldn't normally be able to test in the physical real world, either because we don't have enough assets to do that or we don't want to run over the three-year-old who's running after the ball and say, oh, I guess we have to change that algorithm. So we're depending fairly heavily on being able to feed manufactured data into the software as if the sensors were delivering it. And we hope that the fidelity of that simulation will be sufficient so that we can reassure ourselves and, of course, the passengers in the cars that it's safe to use them. So I am a big believer in simulation, but, again, with the caveat that the simulations need to be carefully validated for their accuracy. Well, fragility of software. Now, first of all, I don't worry about my codes because my codes made so many errors that they don't compile. So there's no impact. But our students here, they write codes that work. And... Work. Okay, that's it. Now, the question is... For some value, it works. Well, but the question, as you posted just now in your inspiring opening remarks, is when you put the virtual with the physical, and by the way, the Purdue Engineering would like to be the best in the world at the interface between what we code and what we touch. But when you put the two together, you know, what works may not work anymore. What's your advice to our students on that? Wow. Well, you know, it could be going to insurance. You know, actually. Cyber insurance, right? That's an idea for some startup of mine there. I'll tell you, cyber insurance is... Don't even... Well, the problem is some people think that if you buy cyber insurance, it somehow you're protected. It doesn't protect you from the mistakes that are made. All it does is possibly protect you from the financial consequences of mistakes. I mean, think about bullying and the terrible accidents that have happened recently. Because of software errors, there's no amount of cyber insurance will save the lives of people whose lives were lost. So, let's talk a little bit about software production, though. One of the things which I think is evident is that a large fraction of the errors that programmers make are fairly simple mistakes off by one bug in a reference to an array. Or a buffer overflow where you read in more data than you allowed space for in the program and it overlays some part of the rest of the program. And then a smart guy will execute the data that was overlaid. There are a whole variety of mistakes like that. And some of them are detectable if you use static analysis. Sometimes, for example, is there a reference to a variable that was never set? That's usually a good sign of a mistake. Especially if you make a conditional expression out of that and you branch off to some random place in the program. So, a lot of those things can be analyzed statistically. Another thing, or I'm sorry, statically, there are even more elaborate dynamic analyses where you actually try various values. You may do what we call fuzzing where you assign a set of values to a collection of variables in the program and you ask, what happens? Does it get the right result or not? Does it go where it shouldn't be? What I would like more than anything is the ability to model the program's intended behavior sufficiently that I would have a programmer's assistant sitting on my shoulder. And what I would like it to do basically is to say something like, you just created a buffer overflow. What do you mean I created a buffer overflow? Look at line number 23. Rats, you know, or some other expression. So, in theory, we should be able to do things like that. We don't have the kind of programming environments that I think we should have. So that's a research problem. It gets worse and you implied it in your question. Today we have the ability to run software in a wide range of devices concurrently. And so now we have potential for race conditions and a variety of other things that are even more complicated to analyze than a single-threaded program. We have parallelism, which we like to take advantage of. And if any of you have been looking at the hardware design and the stakes that have popped up recently, like Meltdown, for instance, among others, the problems get down into the guts of the hardware that's trying to do things cleverly. Like, why don't we execute both paths until we figure out which one is the right one? Which sounds, you know, kind of cool on the surface. But when you dig in, you discover that the mechanisms that are required to do that lead to some side effects, which is exposure of cryptographic keys because you have a side channel that those systems can expose. And so even the hardware design has to be extremely carefully thought through. And again, we need to be able to maybe simulate the environment in which some of these things are going to be executing. So I'm hoping that the research community will actually come up with better programming environments than the ones we have today to help us avoid making really bad mistakes. Well, we want to leave time for the audience for live questions, but three additional questions pop up just so many times from the feedback we collected. And one is 5G and IoT. These are hot buzzwords these days. And one could argue that higher throughput, lower latency, maybe edge intelligence is going to be helpful for many things. But what is 5G in your mind? Well, it's not 4G and it's not 6G. Whatever they are. I've given up trying to figure out what people mean by 5G other than it's the thing after 4G. And people have various definitions of what that might be. Most of them have at least one characteristic, which it's faster. So higher bandwidths are available. The question then will be, well, how do you get those higher bandwidths? One answer might be running at higher frequencies. Another one might be making cell sizes smaller so that you get higher data rate for more bits per hertz out of the signaling system. I don't think that it's a well-defined thing. And so it will end up being something that people will label 5G. And I suspect that we will see multiple instances of things that may not even enter work that will be called 5G because the standards for it haven't been set. It's also a highly competitive space right now. We see this all the way up at the national level where we see people in the U.S. worried about the Chinese initiative 5G, which may turn out to be financially successful because they made a substantially good market out of internet-related devices, Huawei and ZTE in particular, are selling a lot of equipment, especially in the developing world where the price is an issue. So there is a lot of contention here and it's too bad in a way because if you remember the GSM, the success of GSM, which came out of the European initiative, created commonality all around the world. And if I'm about anything at all, it's about interoperability. I really, really want things to enter work. In the IoT space, I have a similar kind of worry about interoperability because the fact that it's labeled internet of things or cyber-physical system doesn't confer automatically on commonality of protocols, commonality of data structures and data definitions. And yet if you're on the receiving end of a bunch of IoT devices, you put them in the house, you would expect that regardless of brand that they would be made to enter work, except a lot of people are just out there to get the equipment out the door, get the money from you and then say goodbye and good luck. I worry, for example, about people maintaining the software that goes into IoT. Some of these devices may be large physical things like heating, ventilation and air conditioning for the last 10 or 20 years. And so who's going to maintain the software that's associated with those devices? We know for sure that there will be bugs. We know that the bugs should get fixed. Somebody should take the responsibility to fix them. We also know that when the device, if it's capable of doing it at all, when the device downloads a new piece of software that's supposed to fix above, the first question you have to ask is, where did this upload come from? What's the source of the new update? And the second one is, did it get altered before it got to me? And so suddenly digital signatures may be your friend in many, many ways. The question is, will other people who make these devices go to the trouble of building in digital signatures without though checking and everything else? And will they commit to maintaining that software? So I realize I've shifted away from 5G to IoT, but I think both of those buzzwords contain a lot of potential hazards for all of us. And when you think about how rapidly this is likely to proliferate, if you look at how quickly smartphones proliferated, they're only 12 years ago, now everybody has a smartphone, or at least practically everybody, sometimes more than one. So in just a little over a decade, this technology has become very, very penetrant all around the world. The same argument might be made for IoT devices. And so once they become deeply penetrant and we become deeply dependent on them, then whatever weaknesses they have will be visited upon us. And so these are areas that deserve a lot of attention. You mentioned Edge, by the way, so I thought we'd come back to that for a second. There's this funny sequence, right? We started out with big, giant, time-shared machines. They weren't even time-shared, they were batch processors. Then they got time-sharing, so 1,000 people can use the same big machine. And then we figured out how to make machines that were less expensive and smaller. So we got departmental machines, like the ones from Digital Equipment Corporation. And then we got workstations, then we got desktops, then we got laptops, then we got pads, then we got mobiles. And while all of this is shrinking, this is a classic example. New technology, big, expensive, only a few people can afford it and we share. And then it gets less and less and less expensive until finally you stick it in your pocket. So now what's happening is that we've got giant clouds of computing that are really basically laptops that have been stuck in giant racks and stuck in some big data center. And there are many, many of those scattered around the world. So we have these giant cloud computing systems and we have all those devices that you and I use at the end, the other end. And then we discover that it would actually be beneficial to have some computing capability at the edge of the net that's local. And why would you do that? Well, some of the little IoT devices are not too good at protecting themselves. Now, light bulbs, for example, probably don't have a whole lot of computing power. And so it could very well be that the number of IoT devices will depend on something between themselves and the rest of the Internet for protection and for control for configuration and the like. And so I see edge computing as an opportunity to do local computation that offloads the devices that are maybe in a residence or in a manufacturing facility or something, protecting them and providing, you know, better utilization of some computation, which leads to the very interesting question of where should I do the computing? Do I do it in the device? Do I do it in the edge? Do I do it in the cloud? And there's some interesting optimization questions that come out of that. Well, you know, I'm biased on edge computing, so there's music to my ears. And, Vint, you mentioned interoperability across domains and maintenance across time. Now, what about freedom of access to information in the first place? Some say that perhaps people are born free or should be, but access to information is not free across the world today. What do you think about, for example, programs like TOR? Oh, that's interesting. Well, you know, you've kind of conflated some things in a very peculiar way, because TOR is... Leading the witness. Yeah, well, no, I wasn't thinking that so much as the conflation, so I'm going to de-conflate this for a moment. TOR is the onion router system, and that's a way of allowing people to get access to information without revealing as much as possible who they are or where they are and how they got access to the information in the first place. This was actually developed by the Naval Research Laboratory, and it was intended to help people get access to information that they otherwise might be harmed if they tried to get to it or to exfiltrate information from someplace to let the rest of the world know what's actually going on. Of course, it also gets used for a bunch of other purposes that most of us would disagree with. But that's what happens with technology. It doesn't know good, bad, or indifferent. It just does what it does, and you can use it in different ways. But let me go back to access to information in general. I'm not a believer that all information should be freely available. I mean, I suspect you would agree with that. There are some things that you would prefer to keep private in the mail or the Google Docs that you create assuming you use Google. So there's... We all do. Well, I'm glad to hear that. And if you're not, shame on you. So the point here is that there is good reason for some information to be widely and readily accessible. An example of this would be research funded by a government, certainly the U.S. government. There is a real interest in making sure that the research results become readily available to everybody. And so the National Science Foundation has rules about commitments of that type. At the same time, there's other information that you want to make sure is access controlled. I mean, the obvious cases are classified information where you absolutely want to control who has access to that. But there's payroll information and medical information and the like. The other thing that worries me is that in our zeal to protect privacy, we may actually inhibit our ability to take advantage of aggregated information. So medical information, for example, if we knew more about people's medical conditions and the diseases that they have encountered, we might understand better if we had access to all that body to contract a particular disease. And so we would want that information to be shared but not personalized. And so finding our way to make information shareable and accessible under the right conditions I think is a very noble objective and it's one that we should strive for. But I think we have the full spectrum to deal with. It's things that should be kept very much controlled and things that should be very, very open. Well, at the risk of conflating multiple questions because I think I only have time for one more question for you. And let me compress multiple questions into this one. The limits of AI. Now, we've got a great team. Kaushik and Anan and the whole team here winning an SRC DARPA National Center in a brain-inspired computing where they're pushing the energy limit to the alpha-go-beat human brain with, you know, one millionth of the energy that is currently using. We're far away from being able to live. When you consider the amount of energy that this little pile of gel uses to do what it does compared with what we would require, we are, I won't say it's hopeless but we are very, very far away in spite of the fact that the tensor machines that Google has been making tensor flow machines are actually pretty damn powerful machines with less and less energy with each new iteration but if nowhere close to the small amount of energy the brain uses. Brain takes advantage of parallelism in ways that we don't fully understand. Well, maybe we should write another proposal at the same time now. There is also the functionality limits of AI. I remember a few years ago I was moderating a panel with Eric Schmidt who was the Google Former Chairman and CEO around the time of alpha-go because what can AI not do? So one question is translation. You mentioned at your opening remarks. What about translating poems from one language to a very different language and well, you know, Eric's answer at that time that well, give me enough poems and I'll be able to learn how to translate poems. So my question to you, Vint, is can AI appreciate beauty? Oh. Well, I think the honest answer is no, if by appreciate, you know, we have some funny expectation of value that the program calculates. I think the answer is no. But can it produce something that a human would appreciate? The answer is yes. And we've seen some fascinating examples of this where in fact, we did put something up on our Google Doodle recently which allowed you to compose a melodic line and then produce a Beethoven-like harmony that went with it. And, you know, I didn't get a chance to listen to everybody's creations or anything like that, but I tried a few and I was surprised at how well the system was able to produce a recognizable Beethoven-like harmony to go with a particular melodic line. The same argument can be made for art, especially where you look at a particular artist and you build a neural network of images able to ingest the essence like Van Gogh, for example, would be pretty obvious dramatic kind of treatment. But we've done this with a variety of different artists and they're showing people, you know, take a picture and then run it through our little dream system and it produces images that are fascinating and in the style of. So although the program may not appreciate what it's done, human beings might appreciate what the program has been able to produce. Well, I would like to remind all the students out there that computer generated answers to your homework may or may not be allowed by our instructors. So please check with them. Now, I will be receiving a whole lot of angry emails from students if I don't at least provide another 10 minutes, if you don't mind Vin to stay on the stage, another 10 minutes to get questions live from the audience. Okay, so just so everybody knows I'm not listening to the baseball game, I have two hearing aids and sometimes the audio in the is not always easy for me. So in theory, if you're talking to a microphone, I'll be getting it straight in the ear, so to speak. So you're not screaming the questions out about wearing it. No, I wasn't planning to do that. So questions from the audience, please. Okay, wait, let me let me get myself set up first. I don't have a mic here. All right, we've got two mics here if you don't mind lining up. Oh yeah, that's a lot of the out of your chair. That's tough. Could we just hand the mics around? This is like hot dogs in the ballgame. All right, please. Yeah, go for it. Thank you for the great talk and you mentioned and you also mentioned how it's very, very important to think about all the use cases of software and prevent injuries. So what do you think of autopilot? Yeah, I don't use it. My wife and I have two Teslas and I don't use autopilot. First, I think that autopilot is misleading and it may lead people into thinking it really is an autopilot and it's a level three or maybe the best level four, where level five is completely autonomous and level three and four have to do with assisting the drivers. And we've already seen a few cases where that's been misapplied and people have been killed. So I think that it is it can be quite helpful, especially if you have all those sensors that can see 360 degrees around. Changing lanes could be a lot safer with the system that can sense whether there is a car or another vehicle in the way. One thing that is missing from today's environment, especially as we contemplate self-driving cars, is the communications capability among the cars. I kind of like the idea of a car announcing to the others in the area I would need to change lanes within the next half a mile or so and have the cars adjust and adapt to that. I don't expect to see road rage showing up among the self-driving cars. At least I sure as hell hope not. I mean that would be really a nightmare. So the answer to your question is we should be very careful about this. Even the guys at Waymo recognize how hard it is to make a really self-driving vehicle. Okay, let me also switch back and forth here. Thank you for the question opportunity. Currently, machine do the jobs that we assign them to do. If a machine has the capability of thinking, what if they reject the job that we assign them to do? Oh, I love that. The robots go on strike. Well, my guess is that we would have to have advanced rather far along before we get to that point. Think about for a moment trying to program something deliberately where you present, first of all, you're saying, does it reject the job that you've asked it to do? So first of all, you have to have a standard way of telling the machine what it is you wanted to do. Think for a moment about Google Assistant because it, in a sense, is taking spoken requests and spoken commands, and it has to translate that first from spoken language to text, and then it has to analyze the text to figure out what was the question or what was the request. And so we're getting closer and closer to the scenario that you're describing. The standardization and the ability to evaluate the query is part of the first step, and then the next step, which is to do something about it. I suspect if you've used either Siri or Alexa or Google Assistant, you've encountered the I don't know how to do anything about that now, or let me look that up on Google. Well, Alexa wouldn't say that, but it would be sort of, let me look that up on the web. And my reaction, of course, is if you idiot, I could have done that myself or something better. So the answer is that for a very narrow class of tasks, you might actually get back something, but it isn't because the device is rejecting you because it's angry or something. It's more like it didn't understand what the task was. You could deliberately program something to appear to be upset and angry and reject everything. Some of you may have heard about, remember Joe Weisenbaum and the Eliza program from the 1960s. Okay, let's talk about anniversaries we were talking over 50 years ago. Joe Weisenbaum at MIT hated AI and he thought that it was a silly waste of time. So he wrote a program that was essentially a transformational grammar. So you could ask it a question and it would react. And so if you said, I'm very tired today, it would come back and say, how long have you been very tired? If you had said, I am very banana today, it would have said how long have you been very banana. So it was just a transformational grammar. It didn't understand what was going on. What was amazing is that a lot of the conversations that the system had with human beings look like normal human conversations, which means that there was almost no information being passed back and forth between either the computer or the human. So I think that it's because we are far from the case where we have autonomous thinking that would be required for the kind of scenario you're describing. So I'm not anticipating the robots going on strike anytime soon. What if robots have the ability to think? Do you think that will cause even more job being replaced by the robots? Actually, so the answer is yes, but you left off the other part of the equation. My belief is that new jobs are going to be created. They always are when new technology shows up. Somebody has to program the robots. Somebody has to build the robots. Somebody has to figure out what the robot should do. Somebody should be deciding what tasks would be useful for them to do. There are a whole raft of new jobs whose possibilities are created. What about the work that people do today and you ask, did these jobs exist 10 years ago? A lot of the answers are no. So I'm not very worried about that. The thing to worry about though is that if your job got automated then you're going to have to do a new job. And the question is do you have the capacity to do the new job? And that's what we should be concerned about. Can I go on just a little bit more on this? So I want you all to imagine that you're going to live to be 100 years old. Some of you will. And imagine your career last 80 years. Now if you remember that the smart phone was just introduced 12 years ago. So if you imagine a career the last 80 years, it's almost certain that you will need to learn new things to be relevant and to continue to have a career over that 8 decade period. Which means that the most important thing we can do is learn how to learn. And also to want to learn. By the way, that's not so easy because if you feel compelled to have to learn something or feel like you must learn something that means that something has changed. People hate change generally. That means they have to do something different. They have to learn something new. Why can't I just keep doing what I've been doing? I was happy then and then I'm not happy anymore. Because I have to do something different. We have to learn how to embrace learning and embrace change and ask for those 8 decades of our career. We need to go on to the next one. Let's go over here. I'm not hearing you anymore for some reason. If you talk to the mic directly. No, that's still not... Is there something wrong with the mic? You could just run over to this mic. It was working a minute ago. This is the engineer's solution to everything. Hi. Yeah, that's much better. I have a simple question. I was just wondering what's your favorite programming language and what's your favorite text editor? Oh. So if I tell you FORTRAN is my favorite programming language, everybody can laugh. Actually I haven't had to write very much in the last little while. That's what programmers are for. So the thing that I've actually gotten interested in more recently Google has a programming language called GO, which we're quite interested in. And so I'm looking for higher level languages that make it easy to describe what it is that I'm trying to get the system to do. I missed the last question though. What was that? Text editor. Actually I'm a fairly heavy user of Google Docs and the reason is not that it's particularly elaborate in terms of formatting and everything else, but the fact that more than one person can be editing the document at the same time. So I'm in the middle of writing a book about the internet for Oxford Press with a colleague in Mexico City. He was at my house for three days and cranked out about 50 pages of material. What was fun and exciting is that he was editing one part of the document while I was editing and editing another, and then we could go peak and see what the other guy was doing, and then we could have conversations about it and argue whether we agreed or didn't agree on whatever was being written. But the part that I liked was first we could do it at the same time to the one document so that we didn't have this problem of multiple copies of the document and trying to merge them together. But the other thing that made it so interesting is that we continued the work after we got back to Mexico City because we just set up a Google Video conference call and joined ourselves on the same document, and we had exactly the same working arrangement that we did before, and that was very attractive. So I'm a heavy user of Google Docs. I am concerned about two things now. One is that I heard Mitch is about to automate engineering dean's job and I'm not capable of doing anything else, so thanks for reminding me about that. The other one is the time check. How about we get just one more question from the audience? Oh, but these guys said, well, why don't we let them ask a bunch of questions and they'll see which ones I can answer? Alright, so and questions, one answer please. Yeah, go ahead. Go ahead. So my question to you is, so what's your take on the requirement of new hardware for the progress of artificial intelligence? Is the requirement like far out in the future or do we require it right now? Well, we already have a small example of that. If you look at machine learning, you can see that TensorFlow stuff is intended to reduce the amount of power that's required, reduce the resolution that's required in the computations. So the answer is no question. There's more to be done in the hardware design, and I can hardly wait to see what the guys at Google come up with next. Yes, sir. Hello, doctor. My name is Tosa Nogan-Jobi and I'm a freshman here, and I'm sure you didn't know you were going to invent the Internet until you probably did it. So my question is, what advice that you know now would you give yourself to when you're a freshman in college? First thing, oh, as opposed to what advice would I give myself about the Internet design? Yeah. Okay, that's not the question you're asking. I would have done IPv6 first, so we didn't have to do it. Except it wouldn't pass the red face test because 128 bits of address space to do an experiment, you know, give me a break. Okay, so the answer to your question, though, about what advice would I give myself? Honestly, the most important piece of advice is read as much as you can that isn't technical, and I don't mean science fiction and stuff like that. I mean, you know, the culturally valuable things like Rousseau things that are you won't have time to read when you get older, so that's first point. The second one I think I would have valued being told that in order to get anything big done that you need to be able to sell your ideas to other people. The Internet didn't happen just because Bob Conn and I did that original paper. It happened because we were able to convince people that they wanted to do what we wanted to do. That's called salesmanship. And it turns out selling your ideas is the best way imaginable to do something big. And so I think understanding that and recognizing that you need help to do a big thing is very important. Yes, sir? So your story about the how long has your banana been story presents my question of chatbots and the idea of like the ever-progressing thing of we talked to this robot and they responded back to a more human type of manner. How long do you think it could be until it becomes a point where we won't even realize we're talking to a robot anymore instead of an actual person? Yeah, this is a great question. Everybody here might know about Alan Turing. And Alan had this test and the idea was a human being was trying to interrogate a human and a computer and the task was to distinguish between the two. And if after a series of exchanges the human was unable to tell the difference between the human and the computer, then the computer had passed the Turing test. Today we have Turing test 2, which I've just made up. Turing test 2, a computer is interrogating a human and a computer. And after the computer has finished interrogating the two, if it can't tell the difference between the human and the computer the computer has failed Turing test 2. And the reason that's important is that we're confronted all the time at Google and with the other people who are interacting with what we think are people on the internet would turn out to be bots. And so the ability to distinguish a human from a bot turns out to be really important because of the potential hazards that botnets create. And so I don't I think that actually we will be tricked very, very quickly into mistaking a computer for a human being. We're getting awfully close to that right now. And the reason this is such a problem is that humans kind of want to believe. So there's a book called The Lone Together by and she talks about human interactions with human form robots even if they just have kind of cartoon faces people project all kinds of social intelligence on these robots that they don't have. And the result is that the human feels rejected if the computer ignores them of course the computer doesn't know that it just didn't understand what you were saying but people react very badly to this. So I think we're already almost in this spot where we don't carefully distinguish human beings from things that are stimulated people. Oh can I just say one other thing if you've ever looked at a robot that's intended to look like a human being the more realistic they are the more creepy it gets until they look like their dead body zombies that are talking and it makes people super uncomfortable. So probably better to stick with very cartoon like simple appearing things because if you try to make it too real it's really creepy. I'll show you this is the real vint serve. Well how do you know? Actually now I'm wondering let's still get to the last two questions. Hi my question is are we living in a simulation? The next question is am I the architect? Which is so the physicists are saying yes that if you think about the way the universe functions they're telling us that it's very possible that this whole thing is a gigantic simulation I hope not but the fact is we might not be able to tell that we were we might not have enough information to tell whether we're in a simulation or not. There's a part from the movie The Matrix and all that there was a book called Simulacron 3 which I think by Robert Gallo that was exactly about that. In fact it could be The Matrix was taken from that book I don't know. So the answer is maybe but we can't tell so just enjoy it. You have a less creepy question that's lost. So my question is you talked about the fragility of software and how bugs are created by human errors so what is your take on the future of using new networks that are trained to generate code and actually do the job of coding as opposed to humans? So I am suspicious of this partly because I'm not 100% clear that the software that's produced is necessarily assured that whatever algorithm is being used to generate the software we have the same kinds of weaknesses that human beings do. Partly because when we try to write an algorithm for generating the software in the first place unless there are some fairly rigid rules the algorithm may actually be as strong or as weak as the class of programs it's capable of writing. So now we get into this question of what's the scope of the programs that can be written by algorithm. The same kind of argument might be made think about a compiler for a moment. It takes a well-defined language in theory you should be able to write a compiler that does exactly what it's supposed to do. Every once in a while I've encountered compilers that don't do what they're supposed to do because it misunderstood the writer of the compiler misunderstood the semantics of what the language meant. So I'm not sure that automatic programming will help much although high-level languages and compilers can be quite helpful. But I'm still a believer in the kind of checking arrangements that at least some during the words have gone to in order to validate the actual produced code. So I wouldn't rely on somebody writing. In the end you're going to have to give a description to some automated programming system of what it is you want to have done. And so then the question will be is the language of the description adequately precise that you can't make a mistake in the specification. And I don't know about you but I've seen lots and lots of specifications that have bugs in them. So it's just a recursive problem just expressed in a different way. I guess that's all the time we've got. I wish that we could have an infinite amount of time to engage in many more questions. There is a faculty panel on AI coming right after this but I think this hopefully real windsurf needs to go to the hopefully real maybe it doesn't matter Washington D.C. where the three-piece suit and your wisdom and intelligence is so much important. Thank you very much.