 The last lecture of the term that's not a review, so Friday we'll review. But today we're going to talk, sorry, this bug on the slide, I'll fix it after class, about Atlantis, robust, extensible execution environments for web applications. So this is a paper by James Mickens and Mohan Dawon. James is a researcher at Microsoft Research, was recently a visiting professor at MIT. And this is really, so this paper takes us a little bit out of some of the sort of core topics we've talked about in the class. But I think it's a nice way to look at the impact of exo-kernel design principles, because the way James describes this is really as an exo-kernel web browser. OK, so no new members of the 100-hundred clubs, sadly, hoping that we'll pick up some over the next week. There's some groups that are getting pretty close. So we're currently at 83% for the course evaluation. So I am going to release a medium answer question, again, as soon as I write. And I promise I will do this by Friday afternoon. I'm going to start writing the exam tomorrow. As soon as I write these questions, I will release them. You guys will have several days to look at them. But I'm hoping that by the time tomorrow rolls around, we'll be at 90%. And I'll be able to release half of the points on the exam before the exam starts. OK, so today, now I thought about writing slides for this, but here's the problem. You can't outmikings James Mickens. This is an actual picture of James Mickens that I found on the internet. I'm not kidding. This is not Photoshopped in any way. It's a little, he's not quite that wide. The picture is a little out of scale. But yeah, so he is also in several bands. All of his bands consist of one person, which is James Mickens. So he's in several one-man bands. OK, so what I'm going to do today, the first time this semester, the first time in 421-521 history, is show a video of James giving the presentation for this paper at SOSP in 2011. Now here's the only problem. And you may be able to tell this already. For some reason, SOSP 2011 was filmed from outer space or something. Like this video is incredibly blurry. That's just not the preview. It's all just about that blurry. So you can't really see it. So what I'm going to do, instead, is I'm going to use James's PowerPoint slides. And I will play the audio and try to keep the slides in sync. So let's see if this works. OK, there we go. Now over here, oh, don't do that. Don't do that. No. This is sad. OK, well, I guess what I'm going to do is go over here. I'm going to play the talk. This is a very traditional model of the browser which had all this coolness and layout and very post-inducing, and all that. And we're going to strut that interface down. We're going to bring it back to the interface. It's long, long, and we're going to very low-level make the interface mess, again, low-level, and stuff like that. And then we're going to allow the game itself to specify a HTML part. It's not going to be without an interface. So what's nice about this architecture is that it allows the page to manage a new blessing, now that it has a lot of this sort of trucking browser that are correct. Now, I know what you're going to say. All right, so I'm going to pause a couple of times during this just to sort of answer questions. So look. And again, this is, I think, one of the best illustrations of the design principles. Feel free to stop. Clearly, James doesn't care if we interrupt him. So if you guys have questions, just raise your hand and I'll pause the video. But despite what you know or do not know about web browsers, and he's going to get into this in more detail, current web browsers are forced to implement this incredibly complex and large API. So modern web browsers do things like layout. They do things like parsing HTML. They have to run JavaScript in the web browser, which is like a Turing-complete programming language. They're forced to deal with all sorts of new media types that are part of the HTML5 standard. And so what happens, and again, he's going to get into examples of this, is that it's very difficult for every web browser, and maybe impossible for web browsers to implement those protocols consistently. So how many of you guys have ever done any web programming or web development? Okay, how many of you guys have ever noticed that things look different on different browsers? The same code. You guys are kind of used to this, but this is ridiculous. This is not okay. We've grown up with this. You guys have grown up in this sort of broken world. Imagine if, because in theory, the web browser is supposed to do the same thing. So imagine if different versions of Linux sort of treated the system call interface differently. So for example, if you did a read on one version, you might get a read from where the last read took place. You might have to move the file pointer on one version but on another version. So it's this sort of, these type of quirks that drive well developers' nuts. And so James' idea is look. And in addition to the correctness issues of just getting things to look right, which is really frustrating for web programmers, there's also all these security problems that are caused by this massive code base that the web, that the browser has to support. And so James' idea is let's, and remember, remember the exo-kernel design principle. Operating systems are in charge both of multiplexing resources and providing abstractions, but they don't have to do both. I don't have to intermix the two. And so what we're going to end up with here is a very, very stripped-down exo-kernel which is responsible for doing very simple things, like he pointed out. For example, drawing pixels to the screen. That's a very simple interface. And everything else that you're used to being part of the browser web stack is now going to come along with the web page. And web pages can specify the execution environment they want. Do you guys understand the design principle here? All right, let me let James continue to motivate this because it's pretty funny. Why do we need another browser? After all, you can occur drawing special friends in exciting months, like Farmville, like Weirdin' That App, like Online Dating, and pictures like this. It doesn't even matter if it's a screen. Now, that's not very sure, but there's a general seeker about the web page, and that seeker is an attribute, but the protocol is actually a huge asset. So what are you thinking about an attribute but a protocol? Well, a browser stack is more than an application to be presented as a better product. If it is more than an application, then we'll see that it's actually a structure and a better limitation than ours. If it's more than a job server, it's more than a site interaction, if it's less than a four job server stack, it's more than a regular structure. And also, the non-mines are a lot of jobs that are interactive as a browser. Now, in no case will you all see that, because I don't know why, so that's what the web protocol is all about. And while we're talking about plug-ins, let's all look at the civil, let's look at the glass, and the width of it. Don't get into video attacks with these new suggestions that I have to bring to my side of the app. And long story short, there's not much time to do that. As it turns out, writing a web browser requires reporting all these different protocols. And don't forget, if you're a web developer, you're already asking which version of the protocol is the brownie that's trying to target. Right? Because they're very, uh, not those ones where there's not all these protocols. So that should be enough. So, there are two locations to the fact that this area of classification is huge. The first location that no single browser will ever get around. I mean, the principle we're told by a professor that standard is important. Right? But in practice, we have to do web models that there's so many standard and they're so complex that it's going to be impossible for any single browser to provide a lot of communication to standard like, please, you know what you're going to do. Now, the second problem that comes with it is that each browser will be able to use in different ways. Okay? This is smart practice. Right? If you make any two browsers you're going to know, fire up, IE doesn't matter. If you want your web page to run on both of those browsers, you're dealing with two sets of documentation works. You're dealing with two sets of documentation efficiently. Okay? So this is an extremely problematic. So you're going to have to use some case study to show you how the browser will build and then will look back at it. Now, that discussion is going to motivate the design implementation on your web browser. You're going to get these slides of implementation and then I will also give you some way to work and I'll teach you a little bit about it. Okay? So I go up and I say, well, man, these web browsers are terrible. It puts the professor's professor in the lab with a game on them and says, J, wait, he's calling. When I go, he's got some trash and he's got some library, but J, wait, he's doing it like that. It's going to hide a little bit of the line in the middle of the lab and it's going to be cool to consider a basis to be running out. So, this is probably going to keep other people attentive. But even if you make them aware of the web browser and they don't want it to be tampered, when essentially you think they're going to tell you, it's going to look like a nice little element of what's in your part of the building. And so, for most people then in these browsers, it's going to take a day or two and then it's going to present a nice browser interface to a new web app. Now, anyway, actually, browsers are murder scenes. Okay? So, what they do is they present a point and see what this means is that J, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, But this is a huge pain in the butt, right? Like if you guys have written, I use jQuery, right? And probably before seeing some of these examples, I would have responded the same way that these mythical professors that James Benz time talking to would do, which is I would say, who cares, right? I mean, the right way to deal with this problem is to build JavaScript libraries like jQuery that are able to hide the complexity, right? But if you guys have written code for websites, you know. Particularly, I mean, I always find this with layout. I only recently started to actually write much JavaScript and do sort of client-side JavaScript coding, which is really cool. But even when you're trying to get layout, I mean, how many people have had to use weird layout techniques that tried to get things to work on multiple browsers because they just wanted something simple to work, right? Like I want to be able to center something. You don't think that would be so difficult. And yet you end up with four lines in your CSS file, one of which is parsable by WebKit, one of which is parsable by IE version 7. And if you want to talk about IE pre-version 6 or something, just forget about it because it's like a whole different standard for HTML. It doesn't even, it's nowhere close, right? So you have to sort of give up on those people that are using those old browsers. Now maybe those people deserve to be abandoned anyway because they should update IE and stop using IE altogether in general, but anyway. So I mean, if you guys have done Web programming, you've probably encountered these sorts of problems. Despite the fact that things like jQuery have been around for a long time. But so let me allow him to use some examples to try to convince you why jQuery is not a magic bullet. So James said in the first round, round one, let's say you have a very simple web page in here. You've got a plug inside of the data inside of the HTML tag. First, you go right. So the round one does is going to take the station on the form of the DOM tree. The DOM tree is an H that's right at the top of the data structure. We're going to have another verb attack in HTML structure. So my example of one is going to be this event propagation problem. Now, the standard of human life, there is an official looping page in this problem. The category is a target-based model of it. So the looping I have learned, and during the catch-base, the browser is creating the path. And that's a composational tag. All we have is a secondary looping in this case of the web. So the browser can catch a phrase in the event it's a relational tag of the DOM code. So it's having to find the catch-and-hand. The interest test, so that the browser has to set a line. Then it takes you to make a non-prolificative loop. To the loop it's not going to catch a phrase. And then the browser needs a non-prolificative loop. Ah, now we're at the target-based in the natural rate of the minute. So what has a non-prolificative loop in it is well-picked. So we trace that reverse tag in the catch-and-hand. The did tag has a non-prolificative loop in it that has to be complicated on the long-node. It has a non-prolificative loop in it. Now, one. So here's the bottom line. I just want to pour up that main-free base in it. Right? That's all I want. Now, Farfax says, yeah, OK. I'm going to say, yeah, OK. I am not going to say, yeah, OK. I am going to say, I will not support the catch-and-hand. Cheers. Yeah, yeah, the process is good. Now, this is huge and problematic. Why does it have to pull the catch-and-hand? Because if the browser is a non-prolificative loop, maybe, right? Some of these non-prolificatives are wider. They're a little wider than what I'm going to give you. Other than the non-prolificative loop, they're a little more minimal. But they still possess a little bit of a characteristic. And then they're non-prolificative, so pour up the line. And it will look a little more disgusting than an individual like the station. So, James Victor's browser is in the end, R2. So, let's say, I have a kind of like NMAX from San Francisco, right here. So I take my mouse and look at that X-box. That's very little to focus on. OK? And I'm tying my key into that X-box. Then I take my mouse and move it somewhere else. And I grab the board, or at least it should. So here's the bottom line. I just want the board that the boy can have if I actually want that. What's going to happen? I even tell your dad. Chrome is going to say, sometimes I'll write it. I'll just have to see what's going to happen. I'm going to say, one board, I'll give you a board. In fact, I'll give you one board. Once again, these non-prolificatives are not for people. I don't really know. I'm afraid of it. So the bottom line is, what I'm going to do is I'm going to specify, now the size of the percentage of the board is young. So the first one, take it here. I want one to be slightly smaller than the other to be as specified in the percentage of the equals in the data size. Basically, I want labels like that. See what the person in the NASA can do. Feed my health, please. I don't trust it too much. Well, I just say, yeah. And then this is going to happen on most of our events. Why do you want that? There it is. Oh, it's there. And in fact, this is why it's so bad. Right? Because if you're a web developer, you spend all the hours you're going to be trying to do, you don't like this. OK? So what do you have to look at? You spend all these conditional code maps in your associated with Firefox, and there's an I, and so on and so forth. In other words, what's in it? Why does it happen? Well, this happens because of the respect of the web page of the developer and yourself. The HTML, the state department, the government, it's all completely different. Basically, you have to develop an informational CSS to this black box partial parameter. And then you go over to that. You get an all string, you get a bitmap. And then whatever happens, acts. Only if you plan a table out of the browser. So John's script is a very introspective one. OK? It's very popular with other people. And so this is very common, if you want to do a full learning action. You want to add a game page to your computer, some cool assets. So for instance, let's say there is a publication of an object, you know, a function on that object. So what you can do with it, enable the browser to just get on the drive. This is a login and reboot. And so if I have a decision to that old member function, then it's going to overwrite that function with a login function. The decision is lost back to the game. It goes back to the game. And then it goes to the number one. And it's back. Well, I can use that. I could run, be there, and go to the web, and go around. See, it's very, very, very much the same. Why does this happen? Well, the reason this happens is because we can see lots, lots of objects in the browser. And they're reflected in the JavaScript. So it's going to get an element that looks like this. An element you're going to find in the add-ins. So you can do the global orchestration, right? And so essentially, when you and the JavaScript layer go to that function, you're essentially making it a kernel wall. Think of the browser proper as kernel reference equal to a wall. And here, the object, though, is essentially looking at the user layer. So you're going to just add a kernel to a wall there. Now, what happens is that you're going to get an add-in. The browser is going to just unfathom the lease. So what happens is the browser has all these internal references and all the stuff that exists in your world up to the user layer. So what this means is that when you try to do that, when you try to do these static displays, then you can only see that reference that is left on the lab. But when you start sharing anything, and you can create stuff like that, sometimes you disturb a variant of what you've got. Because there's only the one where it runs. And that's why this questioner is kind of a cracker. So this raises a full box question. How do you fix all this? And is that from the night of the day way to the evening? All right. So I think this is a good place to just stop and see if PowerPoint will bring the slide up again or not. Let's try to get PowerPoint another chance. Oh, now it's totally. There we go. All right. So again, the way to map this onto operating systems, particularly on exo kernels, is to sort of think of, and it's more complicated because, which is funny, given that it's a web browser, it's an application. But you can think of the program that's running. So remember back to last class, and when we talked about virtualization, it's a lot of effort made to preserve what it was referred to as the application binary interface. So that's the assumptions and applications that are compiled for particular architecture make that allow them to run on a bunch of different machines that run the same operating system. That's the reason you can use tools that install binary programs on your computer that have not been compiled against the libraries that you're using because there's a agreement between the kernel and the application that is expressible at the binary level. There's agreement about how to perform system calls, what those system calls are going to do, et cetera. So this is a good interface. The problem with web browsers is think about it. I mean, web browsers get HTML sources that they have to convert into both a DOM tree in order to allow them to be manipulated by JavaScript but also render them. So those are two separate places where I can get things wrong. Then the browser also has all this CSS that's supposed to parse. And that's its own language. So I've got to take that. I've got to map that onto the HTML and combine the two in some way in order to affect the markup in order to affect what things look like. Then I've got all this JavaScript that comes down with the page, which is, again, a terrain-complete programming language that is allowed to do all this stuff. And if that wasn't bad enough, JavaScript is maybe the worst language. In my opinion, there's a lot of things about JavaScript that I like a lot. But if I was going to give millions of web programmers a language that they could force other people to run who are only guilty of the sin of having browsed to their website, JavaScript is not the language I would have chosen. It has a lot of these. James just showed you these sort of funky properties where you can manipulate JavaScript in ways that are exciting if you know what you're doing and terrifying if you don't know what you're doing or you don't trust the person who's trying to do it. And so to some degree, you can think of the browser as providing an interface. That's what browsers do. That interface is huge. And it's complicated. And as you pointed out, despite the fact there are all these standards about how this stuff is supposed to work, multiple people and multiple companies at various points in time have sat down and tried to implement those standards and produce very different results. And so that creates all these problems that you're trying to solve. OK, let's let James continue. The design of the page. At the top of it, we're going to have a strong and isolated component. Now, we're going to look at the opposite of the interpreter. It is isolated from being in and out of it. And now we're going to do that in fact, we need to get into this problem. And so this is very, very nice. Once you get used to the process of turning it, we'll see that it's happening because we've used all the special features that influence things of the logic of the interpreter and they show them. So what's the indication of that? And there's no change in its sensibility. We're still showing all the problems we have in the whole structure of the component being bi-optimal. All right, so this is another place where I just wanted to stop and sort of highlight the analogy to the things we talked about in the class. So this is, if you guys remember, back to micro kernels, the idea was I would reduce the, and I think there's more security implications here, I would reduce the trusted code base, the part of the code that really has permission to do certain things. Because in the monolithic browser world, you can think of all of that code, all the code that's required to parse and execute JavaScript, all the code that's required to parse and execute HTML as sort of the equivalent of running in the kernel. It's privileged code. Now it's not running in the kernel kernel, it's running in the web browser kernel, but what does this allow it to do? What are some of the things that a malicious web browser, or if I can trick the web browser into doing certain things that it's not supposed to do, what are the types of things that I can accomplish here? I mean, why would people care about web browser security? Yeah, yeah, so that's a great point. The web browser, you entrust the web browser with a bunch of stuff. Frequently those password systems aren't particularly good, but it's a convenience, we use them to fill in credentials and stuff like that. But what else? Let's say you don't do that. Let's say you don't bother with that, I'm not gonna, I don't trust my web browser to store this stuff. What else is going on normally? Yeah. Well yeah, okay, so the point, yeah, there's a lot of chances for a website. If I can trick you to go into a website, if I can launch a phishing attack to get you to go to the website that looks like that one, maybe you don't, so you might go to a website that's trying to attack you and you might say, oh, I can tell this isn't the, this isn't the Bank of America website. I can see it, it doesn't even look right. And then you navigate away, but in the process, that site has sent down some JavaScript that is running your browser already, okay? So if there are vulnerabilities in the JavaScript evaluation that allow malicious websites to penetrate into the browser kernel, they don't even need to steal your password through some sort of phishing attack, right? I mean, people are a lot dumber than this, right? I had a friend used to work at Facebook in security and Facebook had a bunch of problems for a while because people would essentially cut and paste large portions of JavaScript into their web browser, right? Like, people are that dumb, okay? It's like, click on this link to see the Osama Bin Laden death video, right? And what that link actually does is runs in the context of your current Facebook session and sends spam to all of your friends using JavaScript, right? But people are like, ooh, you know, I don't know what this link is. I don't know why this link is like six pages long, but why not? Why not give it a try? So, but again, so let's say I can get you to click on a webpage that sends some malicious JavaScript down to your browser, but let's say you don't have any passwords or any personal information like credit cards stored in the browser. What else can that code do? Yeah, but again, it's running, remember, it's running as an application, so I'm assuming that the kernel is getting its security model, right? Yeah, maybe, I'm thinking of something more fundamental, yeah. Well, yeah, so you guys have heard of tabs, right? You guys sometimes use like multiple web browsers, tabs, and people do this. So the code that's running in one tab, let's say I've got my actual banking site in tab A and I load some code in tab B that's malicious and exploits a flaw in my browser that allows it to sort of inject code that runs into the browser kernel, that browser kernel can see anything. It's not bound by the cross-site scripting policies. It can certainly log the keystrokes of me as I enter my username and password into the other tab. So, particularly tabbed environments. You can think of tabs as apps that are running inside your web browser. Each tab or each new window, if it's running essentially in the same process, represents a new application that the web browser is supposed to run and one of the things web browsers are supposed to do is isolate those tabs from each other. Otherwise, like if a tab could access data from an unrelated tab, then all bets would be off. There'd be no way to make tabs bouncing safe because one website could just randomly steal stuff from the other website as you type data into it. So that's not supposed to work. That's not supposed to be something that can be done. But if the web browser is buggy and I can exploit a vulnerability, then I can do that. And so here the idea is, let's take the JavaScript interpreter in runtime, which it's very unlikely is necessarily, I'm gonna get right because JavaScript is a programming language. Web browsers include a compiler in a runtime environment. I mean, that's again, and I think it's compiled in JavaScript. Just one of the worst design decisions ever made in human history, right? But we're stuck with it, right? We're living with it now. We're living in that world that we created. So I can do that, but I can sort of avoid giving it access to some of this underlying state. And that's the goal of the micro-colonel browser. But as James was pointing out, that still leaves me with these, stuck with a particular browser's implementation of a particular standard, right? So I can't necessarily use this to fix some of the cross-browser incompatibility problems because if I have multiple micro-colonel browsers, they all do things a little bit differently. All right. Okay, so let's do the same process of finding that code of the network, and it's going to be perfect. Now, at this point, do you want to accept that the standard is low and has to be? In this case, let's negate the barcode to the barcode we have here, find that we're great. So if that barcode, I don't actually do anything like a boundary or anything like that. And so, what happened next? You lived from a specific way to do that. That will be a significant amount. You know, I don't know if I can find it, get it over with it. What happened with this one? All right, so does this make sense? So essentially what I'm doing is I'm replacing these fixed components that are involved in web page parsing and running JavaScript with components that the page itself specifies. And then, if you'll notice here, the Atlantis kernel interface. So before this interface involved running JavaScript and parsing CSS and interpreting HTML, now it's bitmap rendering, right? Creating and destroying frames, windows, right? Messaging between frames. It's really simple stuff. Low-level GUI events like clicks and key presses delivering those to the page. And then, of course, dealing with various types of HTTP sockets that would be probably used by most modern web pages, by JavaScript libraries to do, to sort of create interactive web pages, right? So I've taken this big, buggy, complicated, huge, you know, standard of an interface, and I've reduced it down to the tiny, tiny number of things that a web browser really has to allow pages to do. And I can potentially do these very safely. And I've moved all the complexity up until this upper layer, which the page itself can actually specify. So the page knows exactly how its HTML is going to be parsed. So let me try to explain what's happening here, if you guys haven't done, don't understand how web browsers work. So again, I mean, the interactivity of web browsers you guys are used to is entirely due to the fact that there's a programming language called JavaScript that's running in your web browser, and it is able to manipulate the page at runtime. So if you guys use things like Gmail, or any sort of, basically, if you use a modern web page, you know that this happens. There are changes to the web page that happen that don't involve you doing anything. And even if you do do things frequently, the changes to the web page are caused by JavaScript. There's JavaScript that runs in Gmail when you perform a certain action, and it does a bunch of stuff. It probably sends a message to the server saying, she just archived this message, and then causes the message to be removed from the list of messages that are in your inbox. That's all JavaScript, but that page is being manipulated at runtime by, that's sorry, the page is all HTML. It's being manipulated at runtime by JavaScript. And if you want to see how bad the world is without these features, how many people have tried using Gmail without JavaScript, like the super slow connection version? I don't even know if that's still available. You guys should try that someday and see how much fun it is, because you're gonna hate your life within about three minutes. It's really sad, you have to click, you have to hit buttons all the time. It's really terrible, it doesn't refresh itself automatically, it's just not good. Unless you have a problem with email, and email addiction, in which case I would strongly encourage trying that because it will probably help you. But here what's happening is that, what I'm doing is let's say there's a comment box on the page, and you've entered some information into that comment box. And what I'm doing is I'm taking the parent element, or I'm taking some element on the page and I'm replacing it with the data you typed. So for example, you might have entered something and do a comment box, and you hit submit, and in the past maybe what would have happened is that submit would have caused a post to the web server, and the web server would have responded by redrawing the entire page, but we live in the future now. And so JavaScript does this internally, just updates an element on the page using the data that you've entered. The problem is, if this is poorly done, now there's ways to do this safely, this is a bad example, don't write this code, but if this is poorly done by the JavaScript developer or by the website developer, they may have caused the web page to execute JavaScript code in that pages context. So you, and this is sort of what created these problems, these certain Facebook vulnerabilities that people discovered. It was there were ways to get Facebook, if you cut and pasted certain code into Facebook, to run that code, that JavaScript code, as Facebook. So Facebook's JavaScript libraries, because of the cross-site scripting policy, have access to all this internal information, all these data structures about you that they use to render the page, things like who your friends are and stuff like that. And they can issue requests and queries to the server to find out other stuff and those queries are coming from the page and so the server is gonna respond to those queries. And so if you can get a website to execute JavaScript code that you wrote, you can exploit that website in all sorts of fun ways. And if that website's a banking website, you can imagine all sorts of nasty things you can do. So this is bad, okay? And this is something that we would like to avoid. So, and James will talk about how you can use Atlantis to avoid this type of thing, because the thing, the problem is again, web developers do this stuff, they're not all heroes. They don't all see you, they just get to you, and you get time, you get to know them, and you can do some more in the back of the show how you listen to them in the paper. It wasn't nothing about this architecture that now we don't have to wait for the browser to open up an interface with any question of integration. You can just do the back of the page, pull over there, and it's on here. And so the query shows that they load on the script. All right, so just to try to explain this completely. So what I'd like to be able to do is take the JavaScript on the page, take the page, and alter the way the inner HTML property of DOM elements works. So that when I assign to it, or perhaps when I read from it, I want it to sanitize its content. So I want it to take its content, and there's ways to take that content, and if it's JavaScript, if I can detect this JavaScript, I could just fail or crash the page or whatever, but I could also take that JavaScript and run some text replacement on it to convert it to text that is not going to be interpreted by the web browser's JavaScript. So at that point, the web browser would be like, this is weird, I don't know why this person wrote a bunch of JavaScript into the comment box, but that's cool, I'll just put it on the page properly formatted, and I don't know why. Maybe it's a coding website, maybe that's what they wanted to do, right? But it won't execute the code as JavaScript or try to avoid. Okay, I'll just go through the rest of the slides. So they chose some performance results, you might think that there's a penalty to doing this, it turns out the penalty is pretty slim in most cases, and look, this is a prototype, so you can imagine optimizing this in the future, and then he goes through some related work. So any questions about this? I think this is a nice project. What were we talking about? Yeah, yeah. No, no, no. Okay, sorry, let me make this clear. This is a developer mistake, right? This is a developer error, but the point is that it's possible that I want my web browser to fix things like this automatically. So I might want to say, this particular version of the DOM tree does not allow inner HTML things to be set to JavaScript or be executed as JavaScript, right? And so the idea is this is, yeah, if I have access to this code, I can fix it, right? If I don't have access to this code, right? And that's why I'm saying I can just, if I realize this is a problem and people are exploiting this vulnerability, I don't have to wait for developers to fix their web pages, right? With Atlantis, I can just fix the web stack, right? And do it that way. Or a developer that's worried that their page might have this vulnerability, or a company that's worried can fix it in one place and then use that runtime on all their web pages and fix all the problems at once, right? So that's the other way, this one. Questions, yeah? Yeah, so there's definitely some penalty the first time. So what they do, of course, which is the obvious thing is they hash this, right? This is sort of like other static browser assets. So the question is don't, isn't this gonna cause page load times to go up quite a bit? Because the first time I load a page, it uses a new Atlantis set of libraries. I have to out down those libraries and execute them? Yes, absolutely. I think James's argument would be that there aren't going to be very many of these. They aren't gonna change that often, and so the penalty is sort of minimal because I download it once and then a bunch of pages use it. And I can keep it around, I can cache it the way I cache other static browser assets, right? Good question. Yeah, uh-huh. Oh gosh, I will confess, I have not looked at the paper details recently. Can you ask the question on Piazza? And I'll answer it. Yeah, sorry. I've been caught. Yeah, this is just a cool, I just like the idea of this paper. The implementation is interesting to those, and I will be happy to answer that question. Other questions? Yeah. But remember, so remember, the page gets to specify its own resources, right? This is what's critical to understand about it's very similar to an XO kernel. So an XO kernel application can be compiled against libraries that are built that use the XO kernel interface, but it can use whatever one it wants, right? So this is sort of the dream of XO kernels. I could have a Windows flavor library and a Linux flavor library and a BSD flavor library, and an application gets to choose whatever it wants, right? And when it's loaded, it sort of says this is the runtime I wanna use. Atlantis is very simple. So pages have full control of this. Can it expose pages to vulnerabilities? Of course, right? That, you know, again, no one is ever really going to know everything about how a particular library works, particularly a third-party developer, but what it would allow you to do is, if you're a developer and you wanna make sure your page is safe, not only do you have a lot more certainty about layout, but you can use a library that's updated frequently that responds to security vulnerabilities, right? It's a lot easier. So this is another interesting point about this product. It's a lot easier to patch something that gets loaded at runtime than it is to patch the thing that's loading it, right? So people may have been ignoring the Windows Update thing for weeks and not seeing that there's a new version of IE available, whereas the page can respond immediately. So as soon as there's a vulnerability located, the developer of the library can fix it and the page can get the new code. But this is a huge problem, actually. So just anecdotally, this is also something that frustrates Google about the Android ecosystem, because Google is very good about patching Android to respond to security problems. But the problem is, they patch it, they release a new version of Android to the vendors and then it sits there for days, weeks, months sometimes. So they have these security concerns about Android because of something they've known about. They fixed it three months ago, but sadly you don't have it yet because Verizon has not decided to roll a new platform update. And so that's sort of a similar analogy of what would happen in a browser. You have to rely today on Microsoft, Mozilla, Google to fix browser security problems. With this architecture, you don't have to do that. You can get the fix as soon as it's available. And I'm sorry, you have to rely on those companies to fix the security problems and push updates in a timely way. And to be honest, I mean, how many times do you want Chrome to update per day? With this, you can update the library much more quickly. That's a good question. All right, so on Friday we'll do, we're just gonna do sort of an open mic, ask me anything style review session for the exam. Hopefully by that point, you guys will be at 90% and I'll have released half the exam. So I will see you guys on Friday.