 everybody. If people have been coming to DEF CON or black hats or paying attention to information security pretty much for the last, I don't know, ten years or so, this man needs very little introduction. He blew my mind the first year that I came to DEF CON at DEF CON 13 and I was just telling him I cited his stuff in a paper in law school so it's my distinct pleasure to introduce to you all Dan Komisky. Holy crap, we're back at DEF CON. Who here is actually here for their first DEF CON ever? Awesome, welcome, welcome to Vegas. At least our version of it. You know, I've been coming here for 15 years and I actually do talk about a lot more things than just DNS. You know, I want to thank all of you for being here because it's not like I really told you what I'm going to talk about. That's the fun part, right? So why am I here? Why am I coming up, come back to Vegas? Well, I like hacking and that should be a surprise. You know, the primary thing that we break as hackers are assumptions. People think they know how the world works and then there's how they really work and there's a difference. Now, just because we're breaking assumptions and we're dealing with the way things really work doesn't mean we understand what we're doing. You know, what do you think happens when you mess with the system and you don't know how it works? Well, it falls over and breaks. We just defined that as a good thing. But there's an advantage to knowing how things actually work. We can fix things nobody else cares to if we can bother to care to. So I want to talk about something that I really, really like. Guys, I like the web. I do. I think the web is the most interesting advance in technology, certainly that I've seen in my career. HTML is a very interesting property people don't realize. It was the first document format. You could just put crap into it and it would render something. Like it wasn't going to crash, okay? Like this shouldn't be weird, but you know, if you got like a hammer and you hit a nail and you miss the nail, it's not like the board turns into like a fish. Like it does something. It dent the board, but it's still a board. Most file formats for documents, if you got it wrong even a little, it didn't need to be some magic super skilled fuzzer. It would just die. There's this great phrase, surfing the web. Ever realize how weird this phrase is? Guys, you don't surf cobwebs. That's terrible. But the experience of just being able to go ahead and I'm on this site. Now I'm on that site. Now I'm here. Now I'm there. It was so compelling. We got this incredibly weird phrase to be popular. The web, the web is always up to date. It's not stale. It's not old. It's not like a version. You know, oh my God, how are we going to patch 950 million web pages? You know, the web is always live. And I like that property. And it's not how the world necessarily has to work. Mobile does not work that way. Your phone does not work that way. I'm not saying mobile is bad, but it is optimized for you using way less internet. You have to accept installation, you have to wait for download, you have to wait for a home stuff on your home screen. Mobile has a lot of friction. Applications get old. They get stale. You can't just like re-download them on demand because they're like 25 megs. And the worst part is the permissioning. Either you have the Apple situation where you need permission to put something online or you have the Google Android model where it might actually work a lot better if you needed permission because there's a lot of crap out there. The web has an amazing security model. Really, really it actually does. The browser represents a neutral broker. Not in terms of like people who approve your code, but software that approves other software. And it is implementing two major ideas. The first idea is the same origin policy. The same origin policy basically says, look, we've got one user. We've got one program, the web browser. And that program might be at two sites. One of them is CNN. One of them is Gmail. CNN doesn't get to read your Gmail. This shouldn't seem strange, but it was a revolution. The idea that you can have mutually distrusting programs where the only intersection between them is the user. It might not even be two tabs. It might be two elements on the same page. You have this thing called an iFrame that we're going to talk a lot about in this talk where you could potentially embed a piece of PayPal. And that piece of PayPal could say, hey, do you want to spend $1,000 and buy something? And somebody else, you know, that top page can't be like, forget the user. I'm just going to use some JavaScript. I'm just going to click that button, make some money. That doesn't work because the web made sure it didn't work. There are other issues and we're going to talk about them. The other thing about the web is that it should be safe to surf anywhere. It's really weird if you look at the web, okay? The web requires you to download and execute our unaudited arbitrary code and execute it blindly. That's how the web works. But in return, you know, users require the web to make sure that anything executed is heavily constrained. It lives in the most aggressively tested sandbox that has ever been deployed. Again, not perfect, but that's the model. We've had to do things to make this safe. We've had to majorly pull back plugins. Active X, gone. Java, gone. NPAPI, gone. Flash not looking so good. We keep pulling back because this is a really hard challenge. Malvertizing. There's kind of a thing going around where people say, oh, you know, everybody should run web ad blockers because advertisements might contain dangerous content. This is because advertisements might actually contain dangerous content. This is true. It's just not exclusively true. Question. You know all these terrible like click bait, listicle sites that are out there that everyone kind of complains about? What? You think these are wildly more secure than ad networks? Are you joking? Who do you think is making more money? Who do you think actually has budget for security? These little crappy sites? No. So if you follow the malvertizing pattern, you end up basically saying, hey, it's not safe to browse all these arbitrary sites, get content from anywhere. You really should have a small list of sites that you get content from because those are the only places that are trusted. So, you know, Facebook and Twitter and nothing else, right? That sounds like the web. Not to me. That sounds awful. Don't want that future. Now if you want to say, however, everyone should run ad blockers because advertisements are annoying and make the web slow. Now you've got potentially a different point. You've got a totally different story. Now to tell you, I've actually been working for the last couple of years to clean up the advertising ecosystem. Somebody's got to. And one of the questions has been why are ads causing all these performance problems? Turns out it's our fault in security. The same origin policy, as wonderful as it is, can be a problem. This is a surprising finding even for me. Bear with me. What is the ultimate goal of the same origin policy? Protect the user. We fight for the user. Okay. You have all these mutually distrusting entities. And the assumption under the same origin policy is if I include some content, I'm a parent page and I'm going to include a frame and advertisement or whatever else. The only thing that it can do is it can draw pixels in this frame. And I just need to make sure that it doesn't like take over my clicks, you know, take over my pixels. It's got to live in the box. And that's the only thing bad that can happen. Turns out that's not entirely accurate. Turns out stuff can be completely invisible and still make your web browser really, really slow. And you're not allowed to tell. You're not allowed to find out that some frame on your page, some advertisement on your page is gunking up the works. Because as far as the system knows, gunking up the works is an impossible thing. You can't make it slow. It's just in frame. Everything's instantaneous. So same origin policy means the parent should not be able to measure cross-domain iframes. Let me ask you a question. Since when did we hackers respect should not? So, uh, so I wrote me a CPU monitor in JavaScript. Works cross-domain. It's kind of great. You go to a website, it goes, hey, you just hey, iframe, you're somewhere else. But go load some stuff and this thing goes, what are you asking me to do? And this is a big say. We'll go ahead, we'll go to a little site Metafilter and you'll see, yeah, it goes ahead and does some work, but it's taking way, way, way less work. So it works much faster. So this is a way of measuring what's going on. Anyone got a theory for what trick I'm pulling here? Because it's kind of fun. By the way, this works everywhere. It works in IE, Firefox, Chrome, mobile, every browser since like the beginning of time. Any theories out there? Can't hear you, but someone tell me if he was right. Yeah, check it out. Um, so you can just ask the browser to do something in 250 milliseconds. And then you find out if it actually did. So you set an interval. You're like, hey, keep trying to do something and then find out the gap between attempt and reality. If it happens instantaneously, that means, if it happens precisely at the 250 millisecond mark, yeah, browser was idle. If there's like a 20 or 30 millisecond delay, browser's somewhat busy. If there's 1,000, 2,000, 3,000 milliseconds, we've got a problem. We've got some things doing a lot of work. Um, and there are various ways of getting these timers, but this is what you're doing. How you, so I've been building this code out. Call it nice.js. Um, and it has two functions. One is to find out if a page is slow. Two, if you're doing something that might make a page slow, how about we wait until later? So you can actually schedule events. You can do like a set idle timeout. So it will only do some action when we're not trying to actually, I don't know, do useful things for the user. So what do we have here in terms of usefulness? Well, for the people trying to make web pages, we have a very easy way of seeing if the page sucks. But of course, a bunch of us are hackers. We also have a way of seeing across the frame boundary, some things going on in there. It's very hard to know what, but you do get to find out some things going on at like 60 frames a second. So there have been various cryptographic attacks that have taken lovely advantage of this sort of stuff. Could we fix this problem? Uh, well, as it happens, because it's in every single web browser ever, it's kind of core to the way web browsers are built. Frames inside of us kind of share the event loop. So they're using resources that we're trying to use. So if they're busy, we're busy. And if we're busy, they're busy. It's all a big line. It's like a queue. Um, so you really have to redesign the browser to try to fix this. Uh Chrome is actually doing stuff like that. They're going to try to make iframes work in their own processes. They're going to try to make them independent of their parents, but still you're sharing a CPU. Like it's not like there's like two computers there. So even if it's not blocking, it's still going ahead and other things are trying to do work at the same time you are. You probably can tell just by the fact that the CPU time is different. Do we want to fix this? Is it a good thing for the user that random things can be included on a web page and no one can tell it's making everything slow? Absolutely not. You should be able to measure if you're delivering a bad experience to users of the internet. What we might be able to do and what I think this is actually going to go towards is I think because ultimately, I don't know if you guys know this. People have been, even you're like a publisher of an ad site, of like a, I don't know, some news site. You have no idea what content you're including from advertisements. You just don't know. You just run this script. It brings stuff in. You can't even tell if it's good or bad. So I think by design we can say, hey, I've got a frame here. Tell me if this particular frame is using up all the CPU cycles and is making things slow. Or if it's not, if it's being very quick, that is how you get to the point where people can manage their performance impact. And also you can return that data at lower frequency so it doesn't break crypto. So let's step back for a second. What have I just done? What is the conversation that I just had in front of all of you here? Given this hack and oh, it's a hack, what should browser developers do? It turns out that's a complicated question to answer even if you just have the metric of what's best for the user. We have a theoretical harm. Maybe somehow there's some dangerous stuff that you can see through the timing attack. And you have an actual real world problem. The web is drowning under poorly performing web pages. So which is the thing that we want to protect? How difficult would it be to fix? We have different things we're going to do versus from a one line fix that just works to we have to re-architect the world and it's not going to be fixed after we do that anyway. That matters. And how useful would a proper implementation be? Maybe this isn't a bug, maybe we should double down and make it an awesome feature. If you want to go ahead and make things better, this is the conversation that you have to have. If you don't want to make things better, that's totally fine. It's okay. I'm not sure why you're at my talk. Have you seen my hat? If it was any more white, it'd be clear. But you know, it's cool. It's cool. I like making things better. That's just me. We tell you something else that same origin policy is making us blind to. You know, three steps. Our first step, step one, buy ad space on a popular site. Step three, profit. Anyone know what step two might happen to be? Turns out there are some unknowns out there. Check out this stunt. It's called ad stuffing. It's one of the reasons your browsers are increasingly sucking. So what people are doing is they're buying ads on popular sites and then they're putting 10 more ads in that ad. You don't see it. It's all invisible. Your browser's choking on this stuff. And same origin policy as lovely as it is, is why nobody can audit for this stuff. It's ugly. There's no limit. 10, 50, 100. They'll just keep doing it all day. You don't notice anything on screen. Meanwhile, you turn around and you run a sniffer and you know, it's like that, anyone remember that ad with the Indian and the tear going down? That's totally happening. So there's this whole thing called view ability. And it basically comes down to maybe we should be able to notice there's a bunch of stuff that's loading that nobody can see. Maybe that's not good for anybody but the scammer. You can see this stuff with nice such as because the CPU goes through the roof. There are various tricks that try to go ahead and detect, huh, I'm in a box that's one pixel by one pixel. Sometimes these tricks work. Sometimes these tricks are even mildly efficient. Sometimes they're not. I have a question. Should this be a hack at all? So who here knows what click jacking is? The only environment in the world I can have that many hands go up. Alright, so I'm going to show you the worst case. You may not know what click jacking is. So there's this dialogue and it's in the middle of flash. And this dialogue is basically a permission dialogue that if you happen to click allow, flash gets to see your screen camera gets to listen to your microphone. That's the permissioning model. The viewability problem is the beginning of click jacking. They're the same problem. Viewability, the harm is done just because it loaded, just because it executed. But there was no user interaction. But that rabbit hole gets a little deep because the whole point is you show somebody important warning. If you click allow you may be recorded and then you get the actual user interaction. If the user doesn't know what they're giving permission to, the interaction doesn't mean anything legitimate. So we call these attacks that try to hijack user interaction, click jacking attacks. And to defend against them, we basically make the web suck. What do I mean by that? So here's PayPal, right? If you buy something on PayPal and you're on ebay, who they can trust, you get to buy something on ebay. You have a confirm and pay button. But if you're anywhere else besides ebay, no, it navigates you somewhere else. Be like, go to the store, you go to buy something, you go to the cash register, like, yeah, actually we can't take your card. Can you go over there, go to the visa store, get a receipt and like find your way back here and then like give us the receipt, we'll let you buy something. That'd be a terrible bottle. But it's what we do on the web because it's the only way PayPal, off of ebay, can know when they present something to you that it's not been manipulated, that no one went ahead and tried to hijack the interaction. You can go ahead and say, oh, it should say a thousand dollars, but we're going to put a little icon on it and it just says one dollar. I'm like, sure, I'll buy that for a bucket. Now you're out of grand. That sucks. Twitter, Twitter actually knows a thing or two about web design and when you go ahead and you click something to retweet it on a foreign page, it does a pop up. People hate pop ups, but one of the most popular sites on the internet has to use pop ups because it's the only way that Twitter can know that you're not just browsing random sites and retweeting random things, that it's actually you. We have this terrible design that's being maintained. Some bugs need to be judged by the crap they create in their wake. We normally fix click jacking by turning off embedding entirely. There's a header, it's called X frame options, and it disables I frames entirely. Or at least controls where they can be. It says, hey, that thing you were doing in the web was nice, but still too dangerous, so you know, go make your side ugly. That sucks. Content embedding is one of the cool parts of the web. So people are doing pop ups, doing navigation to a safe domain. Some sites are doing crazy stuff like forget it, forget the security model. We're just going to engage in JavaScript versus JavaScript warfare on the top frame. What? We have a really good security model and we're going to abandon it, but that's what people have been having to do to avoid the risks of content embedding. Adobe can't do any of that stuff. They have a box and it needs to show up on screen. And if it is not actually on screen, the world comes to an end because users can be spied on. But Adobe's got a bit of an advantage. Those guys got native code execution. So check out this. Adobe destroyed click jacking, at least for camera and microphone. We've got the thing fully visible. Let me tell you, it works. You put it in a frame that's too small. It doesn't even load. No, I know you're trying to mess with me. You put stuff on top, it renders, but you try to click stuff, nothing happens. You move it off to the left of the page, nothing happens. Go ahead and try to do all these stunts with eye frames. So as far as flash nose is totally on top, everything's cool. You know, it's got like all of its pixel space there. But somehow it knows. When it's inside the eye frame, this actually works up here in the plane. Not when the eye frame is too small. Not when there's stuff on top of the eye frame. Not when the eye frame is off to the left. That's kind of cool. I wonder what they're doing. Even if you move that stuff around, you can go ahead and say, hey, we're going to take this little box here and have it follow the mouse. So wherever you click is always right under the allow button. Adobe knows it's moving. How? How are they doing this? Well, I don't, I don't know how else I can say this. They make Photoshop, they can tell by the pixels. Adobe is semi fuzzily comparing the expected stuff, whether they hope they're going to display to the actual rendered output. There's a fuzzy comparison. If you render their dialogue at 56% opacity, it works. If you render it at 55%, it doesn't. If you put on top of it a 25% present image, it works. If it's a 225%, it doesn't. If you have the original be 75%, it, and with a 25% overlay, it doesn't. They have comprehensively dealt with this problem. Cool. Good job, Adobe. Glad not getting spied on. Maybe not by you anyway. So, I guess Flash can do with HTML5, can't again? No. Because this solution is terrible. You never want to read pixels back from the GPU. It's like you got a 10 lane freeway. Nine lanes are going out. One lane is coming back. You don't get to read pixels back, especially not repeatedly, which you have to do to know if things have been moving around. You're turning the browser into a video parser. So in this one context where security is absolutely overwhelmingly necessary, and the youth is precisely fixed to a scenario where it's almost never going to have that dialogue up. It's not like all the time. Okay, here we can scrape some pixels. Nowhere else do we get to do that. But, you know, it's not like we can't patch browsers to. Adobe can patch Flash. We can patch browser engines. The HTML5 people, W3C, have been working on fixing viewability and clickjacking. They actually have a group called Web App Sec that has a proposal called UI Security, which says, hey, maybe content should know if it's being displayed or not. If it's not, it should be able to respond to that. It recommends pixel scraping as a general implementation strategy. Quit trying to make pixel scraping happen. It's not going to happen. But can something happen? I am finally getting into a standards body. I'm becoming a W3C invited expert because I want these clickjacking bugs off my web. How are we going to do it? All right, check it out. Layers of abstraction. Okay, browsers don't really know what pixels they're actually displaying on screen. They kind of make a bunch of stuff up and be like, I don't know, GPU, you figure it out. That's really how it works. But it's not like the browser is without knowledge. It knows we're descending to the GPU. Web pages are composed of layers. It's like a sequence of transparencies on top of each other. Let me show you the DEF CON web page here. The DEF CON web page looks nice, simple, well composed. We're going to sort of go into the matrix here. Turn it on its side. This is where your computer looks at the DEF CON web page. Firefox is a 3D view. We turn things on its side. We see it's a bunch of stuff that's smacked on top of each other. There are layers here. Well, this is what the computer sees. Could we make the computer see something else? Pixel scraping is an attempt at auditing. It's saying we have so freaking many ways of putting something on screen that, I don't know, let's see what happens after. We're building this thing called iron frame and it is an attempt at correctness by design. We're going to take the layer, so the original name for this was Jenga. We're going to take the layers that are at the bottom. We're going to drop them on the top. We're not going to guess. We're not going to check to see if the right thing is rendered. The only thing that could be rendered is the right thing. Why is it not called Jenga? Because what happens when you play Jenga? Things fall over. Now we have to make sure we don't put too much on the top. That layer on the bottom might be huge, but we can measure the position and size of what our space should be and we only make things that big. So let me just show you this working under chrome and blank and then, but before I do that, let me explain why you never use the word just when it comes to browsers or anything that might be hard. Just as a four letter word. All right, so we're going to start. Here's a tweet. It's inside a bunch of hidden eye frames. Let me tell you there's no way of this frame to know it is being framed and that's why if you were to interact with it, it would create this pop up. Now I have a bunch of slides here where I can show it to you, but forget it. Defconn, we're going to do it live. All right, so check it out. On our left we have our favorite Swift on security Twitter account. There's no security implied. No matter how this thing is messed with. It's not showing you. What? Uh, huh. Windows P duplicate. Come on, you can do it. That's right. All the time I spent in Redmond had some reason. All right, check it out. Um, we have the tweet. It's fully visible. It is in fact interactable. We have the tweet over here. It is fully visible. It is interactable. This thing is shrunk down. It's like three or four eye frames up. It's shrunk down. It has no way of knowing, but we got a big red grout, red border here. Nope. Can't use that. Let's keep going. We're going to put some stuff on top of our, uh, of our tweet. Fully interactable when in the insecure mode. Over here, if you look, it's actually popped on top. It's fully visible. Boom. We get to interact with it. Scroll down some more. We're going to go off to the left. This thing is off to the left. It's not fully visible. It's interactable in the insecure mode. In the secure mode, it knows you can't mess with it. Mouse follow. This is the trick. You go ahead and you have only place this thing, mouse can be, is where it'll click through and do something nasty. So we're going to have this follow the mouse. No, I have to activate it. There's the button. Remember this follow the mouse. You'll notice it's following. Um, eventually it will get somewhere. So it's yellow. Was yellow mean? It's mean it's here. It's visible, but it hasn't been visible for long enough. Once it is visible though, it is interactable. Um, now here's my question. Anyone in the audience think I'm doing like silly little stuff, you know, no real attack is going to get through here? You're like JavaScript badasses out there? Alright, so check it out. Let's have some fun with this. Uh, we're going to go ahead and make this 50% opaque. We're going to pop up the 50% opaque. Now it's fully visible. We're going to go ahead and put 10 X, um, icons on top of ourselves. So there's 10 of these things are all 10% visible. We're going to pop on top of all of them. We're fully visible. We're going to have a drop shadow. Now look, this is an element. It's not even on top of us. It's like way over there and it's going to crap some pixels on us. God damn that was annoying, but we're going to pop on top of all of that and it's going to work. Um, oh, it's not working because it's not fully visible because it wasn't fully scrolls into space. It knows about your scrolling. Now it's fully visible. Uh, blurring, unblurred. Clip path. We're going to draw a giant X over our frame. Nothing can go and no, no, we get that too. Just fine. Uh, I don't know. Is there anything else? Zoom? So check this out. Scale 3D. You can literally take imported content and flip it and reverse it and it's still a thing that you could interact with and still this code goes ahead and finds that something bad has happened. Turn it on its side. It finds something bad has happened. Use the visibility hidden element. It goes ahead and makes it visible. So here's the really crazy thing. It's not like I did a bunch of special cases here. This, see if we get slides back. You can do it, I believe in you. Go protect it, go. Securetape by design is a thing, okay? Uh, I'm not saying that what I'm doing is perfect, but all of those things that you just saw, all of those, I'm going to go ahead and make messed up content on the internet, all of those attacks failed because of one class of fix that was, uh, actually using the way the web browser worked. So, um, I want to talk to you about the gory details here. No one just bribed me like, hey, I wrote some code, but you never get to see it. No, let's talk about how this stuff actually works. Um, what it means to move a layer. Now I'm talking to you about Blink, the renamed engine from WebKit inside of Chrome. Um, but all the browsers work this way. They have to. It's hanging out with the former head of internet explorer and his jaw dropped. He's like, damn, this is the anti-hack. You're working with the actual graphical layer to build a security policy we've been struggling with for 10 years. So that's pretty cool. What does this look like? What do we gotta do here? Gotta satisfy three requirements. We have to promote content to the top layer. We have to actually get it on top. Then we need to make sure we haven't put too much on top, which requires a bunch of measurement. And finally, we have to report back how much was promoted. The way this security model actually works is not, oh, I make things red and I make things yellow. You're actually sending messages to the thing that you promoted saying, here's how visible you are. What do you want to do with that information? I don't know. You figure it out. It's your page. Your PayPal is not going to have the same policy as Twitter is not going to have the same policy as anything else. So here's the information you need to decide what the right thing to do is. All right. So what do we have to work with? Oh my God, browser internals. I got like nodes and frame trees and frame views and layout views and layout objects and jet layout, box model objects and deprecated paint layer and graphic layer and graphic layer tree builder. Wow. Browsers are complicated. Uh, crap. Uh, so let me make your life a little easier here. You got three layers to worry about. You got a thing called a document layer. You got a layout tree of layout objects. You got a layer tree of deprecated paint layers or graphics layers. I'm going to teach you what these things actually are. And I don't want anyone here to think this is a final implementation. I am still a hacker, not a web developer. But still, let's talk about what's going on in this beast. First off, there's the document object. I don't mean the document object in JavaScript. I mean the document object in C plus plus. It's basically, uh, uh, the DOM without the guard rails. You can do anything in here. Um, that doesn't mean you should do anything in here. This is the same view that you're coding with in JavaScript with the security removed. So you can go ahead, move things around. But anything you move, remember the bad guy also has JavaScript access. They can see what you did after. They can also feed you bad stuff. So be careful what you read. Layout object. Layout object is interesting. This is the first layer where the graphics engine goes, okay, I don't need all this JavaScript stuff. I don't need all this like, you know, weird things over here. What I need to know is, what are you trying to draw? So you've got like a block flow for HTML. You've got like an image for a layout image. These things still know what they are. They're just stripped of anything that is not relevant to the graphical subsystem. And this is what actually moves around. You know, you move an object, like it's styled and all that kind of stuff. But it's still not blank transparencies. No, the blank transparent. Oh, before I go to that, anyone here ever do like website design and he's like test to see if anything has changed? Anyone? Yeah, so if you were actually doing that, um, this is the layer you want to dump to be like, what is the web browser actually showing the user in a form slightly less annoying than pixels? But your transparencies are the layers. So you have deprecated paint layer and graphics layer, different methods look like the same underlying structure. Um, and here is basically, I've got some stuff here and stack, stack, stack, stack, stack. It doesn't know what it is, it just know that it's pretty pictures. Many objects can share the same, uh, graphics layer. This is a problem because we have a particular object that we want to move. We don't want to move objects that were already there. We want to specify this eye frame needs to be movable. It turns out there's a trick in web performance called transform equals translate z zero. That will go ahead. It will turn this very simple layer tree and do actually a fairly complicated layer tree. You might think this is really slow, but most of these layers are not actually drawing content. They're not creating pixels. They're just applying rules. Uh, throw a scroll bar here, cut off some content there. And, but this is kind of this complex tree. We can take this crap at the bottom and be like, you know what I found is that everything in iron frame could be implemented at document, layout object or graphics layer. You can always do it multiple ways for various values of security, difficulty and stability. The game that you are playing is it's sort of a fight between absorbing the browser's existing knowledge of what is or isn't supposed to happen versus suffering the browser's assumptions. Because it was never designed to do this kind of iron frame moving. So it like thinks it's working in different world. Things are supposed to be the same documentary and you're violating its assumptions. So that's your fight as you're building this. Where we are right now is it looks like an actual movement of content works really well at the graphics layer. That is a thing that wants to be able to move, has all the right methods, has all the right stability. Figuring out what should move is a different story. Um, that is possible in graphics layer, but it's hard. I'm right now using the actual document layer. There's this amazingly useful method called bounds in viewport space that says eight i-frames deep with all of these scrolls and all of these transforms and there's been a zoom done. We're all the way down here. You are covering pixels 100 to 300. This is you. Cool. You can take those numbers and you apply it to the graphics layer and everything is good. So I'm just gonna do this thing. I hope I actually don't lose all of you. Uh, first we gotta find our document element. When you have an i-frame, that's like another web page in your web page. And so you have a document and you have an i-frame, it has a document. That is what I want to raise. Now, why do I want to do it this way? Well, if you don't have an i-frame in the way, you could potentially just say, you know, pages are filled with elements. There's this box, that image, that advertisement. You can just say, well, we're just gonna put that on top. But if it's not across an i-frame boundary and not across a domain boundary, some bad guys just like, sweet, you're trying to raise yourself up, I'm gonna put you back down. Cause we are living in the same security domain. You need to actually use the security model if you want there to be a security model. I don't like check box features. And then once you're inside that i-frame, what should you, you could potentially amplify anything. You could raise any element. I just want to raise all of it. Why? Because I want this to actually be a thing that's testable. There's like a bazillion different HTML elements within any bazillion different rules. Let's go ahead and get this working on one of them. And that one of them is everything that's inside the i-frame. And then we'll clip it from there. Next up, we actually got to raise our layer. That means we need to find our layer. The route to there, at least that I've been doing, you go to the document, you ask for its layout object, you go to the layout object, you ask for its layer object. You ask for the layer object, you get the graphics layer backing. It's very much an over the river and through the woods reality that we're up to here. So you find the graphics layer for the i-frame, which by the way you had to promote with that translate Z trick so there actually is a layer. Then you got to find the root layer. And it's really easy. You're just like root graphics layer, add child i-frame graphics layer. It just works. Sweet. I say that because there's lots of other ways that don't just work and you scratch your head a lot. Okay, your graphics layer is too big. You have taken whatever was all the way down there. You've lifted it up. It's potentially huge. You've got to fix that. So how do you do that? The way I'm doing it right now is super kind of janky. Okay. So you're inside an i-frame, right? You might be inside like 10 i-frames. I saw one site, 57 i-frames deep. What the heck? I have no good idea. So you've got to like walk your way up. You've got to think of these frames like keyholes. They're smaller than they're, they're always smaller than they potentially could be. So what you're doing is you're constantly saying, I'm a thousand by a thousand, but I'm going to keep getting smaller up. No, I've gone through here. I've gone through there. You're trying to figure out how big you are by the time you make it to the top frame. Now the reason you're doing this manually, normally graphics layer would do this for you. But you don't like all the transformations graphics layer is going to do to you. It's going to go ahead and put stuff on top of you. You need to be on top of. And that is not just occluding objects. That's all the transformations like blurs and what not. So we go ahead and we walk up the stack. What next? Now we've gone from a thousand by a thousand to a hundred by a hundred. We're not done. Because the top viewport, hey you know that theory that isn't an i-frame? Where like a user actually scrolls? They might have scrolled you off screen. They might have recently scrolled you. That is not a frame boundary, that's a viewport boundary. So you've got to intersect with the viewport. Okay. Now you figured out how small you're supposed to be and where you're supposed to be. You got to shrink that stuff. So we apply our bounds. That's done using a set position and set size. You have to take the scrolling into account because that wasn't taken into account all the way back in the viewport and the bounds in viewport space. And then you've got to tell your layer, hey you've had these bounds set. Apply them. System will do it for you. You wish you would be done but as it happens there's one last step all the way in all those frames. Those subframes could have scrolled too. You need to take the subframe scrolling into account. So it turns out there's a function set offset from layout object. So ultimately use all three of the layers that I described to get not just stuff raised up, but raised up correctly. But it works. It works quite well. And then your final step is to go ahead and report back and say hey guy, here's where you are, here's how visible you are. It's so easy. Yeah, that's why you never say the word just. Alright, so some issues. You need to actually get this into the compositing pipeline. The deal is there's a whole bunch of steps in a row that need to happen in the proper order for a web page to render properly. And right now we're just sort of saying, hey, do it. I'm JavaScript, I order you to do it. So you need to actually get to the point where the thing is maintaining itself because other things will cause new layouts to happen. And it's going to blow away your fix. Another problem is it would be nice if this was a little more stable. It's mostly stable. Usually it's displaying things when everything's in the right compositing mode. By which I mean it aborts if it's not. It'd be nice if it was easier to schedule stuff to happen at the right time, but it's a little hard in browsers. And there's some issues with mouse input as well. Hit testing gets weird when things are being moved around. The biggest issue with this design is probably do we really want to be forcing things to be on top? Aren't we altering the design of web pages? Well, my design that I want is failing closed. It's basically saying, look, whatever is reported is absolutely the correct thing. It might be ugly, but that's what's visible. The alternative is failing open. You read the tea leaves. You analyze. You audit. You're auditing at the layer level instead of the pixel level. The browser guys think they can do this. They think they can figure out the minimum on modified rectangle. That's what the guys at Firefox call this. I don't care about fail closed or fail open. I just want something with a really nice bug bounty on it. So hey, you want to make a bed on this? Get your checkbook out. Mine is going to be less expensive. The original thinking was that position and size was good enough. How many legitimate time to someone putting stuff on your content and they're not trying to hack you? Well, you know, designers, they're like a thing called drop shadows. So, you know, you have a frame that's on top and it's like kind of like drawing a nice little smooth shade just to make it look good. And it's not malicious, but it's there. Could we potentially support that? Yes, but not with the toys that I have at my disposal. Maybe it's in toys that people will build me. The deal is I've got this world here up here that has a drop shadow on it and that world is, it's viewable, but it's not like our viewable. The area we want to promote that we want to actually record as being fully visible is down here. We want to be able to split our layer into and promote the bottom half and not the top half. That is not really easy with the present architectures. Chrome has something called replica layers that looks like they might be able to do that. God help me, I haven't been able to figure out how to do it. We probably do the actual compositor to support what I'm up to. But there's one more thing that I want because I am a greedy bastard if I'm trying to secure the internet. Thus far somebody can draw a fake Twitter. They're just pixels. I mean they don't work with like your credentials, right? Like when you hit the retweet on the fake Twitter, what's it going to do? It doesn't know who you are. It's fake Twitter. What if we wanted to use an iron frame for like single sign-on? What if it's the thing that actually collects your credentials? What if you're supposed to put sensitive information in there? Now it can be absolutely perfectly viewable, but you don't know who it really is. Well what's our solution to that normally, okay? Look, iFrames have always had input exclusivity. That means when you talk to an iFrame you know it's just the iFrame that gets your keyboard and mouse events. We're now getting output exclusivity. That means whatever pixels are there, the frame knows that it's there. If we have input and we have output, we can update the address bar. We can go ahead and say, hey, I know you're on randomsite.com, but right now what you're interacting with is actually Coinbase, is actually Twitter, is actually PayPal, is actually anyone else. No more messing around. Fix some stuff. So here's what I got to leave you with. First of all, we can kill clickjacking. This bug's been around for ten years. We can kill it without breaking what makes the web special. We can do crazy things as hackers, okay? It's not just about blowing things up, although that too. We can defend the vision of the open web. And we can realize when we try to do this, my god, it's gonna be hard. It's gonna fail the first time, the second time, the tenth time. And that's okay. All the greatest hacks that I have ever seen have been, you fail, you fail, you fail, you succeed. I'm just saying the success can be a little more. And finally, these ad stuffers that are making sites slow, they go stuff themselves. That's what I got to say. So I may actually, it looks like I have a couple minutes for questions. Anyone want to ask something? Oh, the question is am I going to make this public? One of the fun things about joining W3C is you have to make this public. Everything goes, look, I actually want this in web browsers. This isn't just to show off. So yeah, the code would be public, but I was too busy making it. I made a hallway at DefCon and I'm like, wait a second. This can work on Twitter. And thus now I'm sitting down in a hallway coding it up. So yes, this will be public. Code will be out sometime next week. Presentation will be on Dan Kaminsky.com sometime the next eight hours. Another question. Anyone else? Go for it. You want to come up and talk to the mic? If I can barely hear you, I want to imagine if I can barely hear you. Here, take it out. Testing, testing one, two, three. Sweet, we got double mic going on. Sweet, I'm on the secure wired mic. Hi, Dan. What's up dog? Three months ago when you were conducting your research on Port 3478. I can bear it. You're louder, louder. Three months ago when you were conducting your research on Port 3478, which is emulating stun traffic. How much beer are you going to buy for everyone who responded to that? It's sort of related to your research. You know, sometimes you scan internet. Sometimes internet scan you. Any other questions about JavaScript? I'll see you tonight, dude. All right. Web developers, if you've got some interesting ideas how you want to use this stuff, I'm going to make it so you can build beautiful things that don't suck. Security is going to give you a hand. That's what I got.