Achieving the Web Isolation Nirvana — How far along are we?

the next talk is titled as achieving the web isolation nirvana how far along are we the presenters are pedro fortuna and justfeed nagra he also goes by jazz both are representing j scrambler thank you over to you hello everyone it's great to be back to a real live stage and it's of great joy to be sharing it with my dear friend jasvir so our talk today will be about web isolation um it resulted from a retrospective thought exercise on the last 20 plus years of web isolation so what are we looking for we're looking for a series of principles or reasons that underlie what we have done as a community right what we've done wrong and

what kinds of lessons we can learn from them and that's what's going to drive the structure of our talk today but before we get too far let's introduce ourselves so my name is pedro fortuna i'm a co-founder and cto of j scrambler and i've basically been working with security for as long as i can remember i guess that brings that to me my name is justfairnagra most people call me jazz that's what you should call me too uh and i guess i've been working in security for as long as uh pedro can remember so we want to start with a little story a pedro there's like 30 minutes remaining before happy hour and you want to do like we're the only

people that stand between all of these people and uh a well-end drink you want to do story time yeah i mean we are on a movie theater so i thought that storytelling is the is actually the perfect spot to be doing it let's do it so we want to tell you a little story about the ship um which most of you have heard about you want to guess what ship this is yup the titanic yep so basically um it was built in belfast in northern ireland in their famous shipyard which i was actually lucky enough to visit some years ago and we want to talk about how it was built so many people don't know this but

the titanic back then it was bleeding edge in many ways all right so um [Music] for instance the bottom of the ship was split into 16 water type compartments and it could withstand up to two adjacent compartments completely flooded without compromising the ship but depending on the specific location of the hit it could go as high as four adjacent compartments completely flooded okay so this technique is to ensure the stability of the screw of the of the ship uh despite the presence of damage so that's like the worst case scenario they could think of back then and that's why the titanic was deemed to be unsinkable but we all know how this story ended when the titanic hit the iceberg

the six forward compartments were compromised and even though it didn't end well the compartmentation was actually a great idea so and it's still used in chip design to this day basically the basic idea is that damage to a single section of the ship won't compromise the other sections okay uh but the problem with the titanic was that its implementation was flawed but we'll tell you more about that later wait seriously you're going to leave this cliffhanger there fine why don't you tell us a little bit about web isolation a completely different topic seemingly right sure so the the first attempt to do web isolation inside the browser was introduced by the same origin policy to

restrict how two cross-origin documents can interact with each other but restrict how if we can embed a third-party scripts being loaded directly from a third party server and it will actually have the same amount of privilege than any other script any first party script running on that page so it turns out that embedding is permitted as per the the same origin policy what is restricted is writing to or reading raw data from cross-origin documents so the reality is that the same origin policy is complex has lots of exceptions and to this day most developers don't fully understand it which is frequently the source of security issues a couple of years later we got iframes okay with which we can isolate two

documents in different uh two scripts into different uh cross-origin documents but soon enough people would like started like poking holes through it trying and finding ways to have those cross-origin documents communicating between each other um and basically only 13 years later we we threw the towel and finally introduced or made it official by introducing the web messaging api with which two cross-origin documents can communicate voluntarily but that didn't fix all the problems uh iframes had too much power for instance an iframe document can navigate away the top window uh among other things and uh and basically it took a while but 13 years later we got iframe sandboxing with sandboxing we can greatly reduce uh the amount of privilege that iframe

document has but at the same time we got a bunch of different attributes that with which we can relax some of these restrictions uh back roughly at the same time we got content security policy version one uh with which you can set a domain based allow listing which was later found to be completely broken plus it's hard to to manage later versions fixed it but they are not straightforward to set up but the main critique on csp is its lack of granularity i mean with csp you can either fully allow a script into the page and allow it to do whatever it wants or completely block that script similarly you can fully allow a domain

to be contacted or fully block that domain so it has no granularity at all and ends up not working because of that so the main problem with this isolation and defense mechanisms is that people keep fighting them keep trying to open holes to relax them into getting them to work with for their applications jason p and porce are good examples of that um maybe if they were more flexible and and and granular uh people wouldn't find the need to to try to hope uh open holes on them uh can you go back a slide yep i've been talking to some people over lunch you really think that that small jason p hole represents the real

size of jason p well uh i accept your critique but i i think jason p is is long gone so i prefer to reserve the bigger hole for the csp string we're gonna edit these slides after this talk okay that's fair so here you can see a timeline of the these features you will notice a huge gap between 97 and 2009. so we really have to wonder what the browser people were doing what were doing during this period it was a comment on that as a browser person i'm embarrassed by that 10 years all right

so pedro's described a whole bunch of browser primitives that have existed that we have used for isolation some of these properties work really well some of them less well but what is interesting the question that is interesting to me is can we use the browser primitives that browsers provide to build an isolation mechanism that is solid i believe that the answer is yes and you don't need to believe me uh we the community has built all kinds of interesting isolation mechanisms based on the primitives that browsers provide to build a wide variety of interesting isolation mechanisms that i'm going to go over all of these essentially boil down to one of two different mechanisms on the one hand you

have transformation where you are changing the source code of the of of third parties or first parties on the other hand you have virtualization where you are changing the environment that the code that you're executing runs in and and essentially those are the only two real mechanisms that we have available to us i have plotted three different projects that i am familiar with that that do these there's a while there's a vast variety of other projects that also do this kind of thing there's uh google kaha way off on the on the corner there which does uh virtualization uh to remove the dangerous part to make the apis that are called uh less dangerous it also uses transformation to

simply extract and throw away the dangerous parts of our pro of a third-party piece of code uh there's a project called js reg which some of you may be familiar with which uses a lighter weight transformation uses regular expressions to remove the known bad parts and throw those away and then we have j scrambler's web page integrity which pedro i'm sure can speak a lot more authoritatively about which uses mostly virtualization but also browser primitives to not just mitigate how bad some third-party code can be but also uses browser primitives to monitor what kinds of dom things dom mutations are occurring and essentially all uh virtualizat all sandboxing projects use some combination of virtualization and transformation in

order to achieve the security properties that they are shooting for um but by a long shot this is my most favorite transformation a program transformation for security uh it might not look like much but it is actually the basis for almost every uh language based sandboxing mechanism ever ever executed what does this mean sorry pedro uh what do you have you have a series of functions uh alert functions that you are calling what are these you can think of them as system calls in the browser so these are functions that are provided by the browser that you are calling you also have these other properties you have strings and you have arrays which are native types provided by the browser and

you also have functions that you yourself have written here's the deep piece of insight if instead of allowing the third-party code to use whatever the browser provides you instead allow the caller of this third-party function to provide what functions are called what system calls are called what native types are called what you get is the ability to control how much power a third-party piece of function gets to have if you take every arbitrary piece of code and you turn it into a closed function where every piece of code is controlled by the caller you get a kind of sandboxing which is extremely powerful not only that of course you can do this with javascript can you do this with

html and css as well and the answer is yes in fact it's even easier to do it with html it's even easier to do it with css why because css and html are less expressive than then javascript so take for example the code on the [Music] on your right where a piece of code a piece of styles sheet was able to change arbitrary b tags to have them have the color blue by prepending dot gadget one two three what what have you achieved you have made it such that the number of html elements that are affected by this particular css rule has been limited to those that are the children of classes that have gadget one two three as a class

you have limited the sections of code on your page that some particular third-party css can affect similarly with html you are able to subset the html so that only some small part of your html can be affected by third-party code so that's um tool number one in your security toolbox what is the second one the second one is virtualization now i call it virtualization it's really just polyfills and you all know what polyfills are right what are polyfills polyfills are where you have some browser that's not able to provide all of the functionality that you need what do you do you end up writing something which plugs that gap it emulates the missing piece of

functionality all that virtualization does is essentially the same thing but it also allows you to plug in the same kinds of functions in the cases where the functionality was provided originally here's what i mean so let's say let's say that you have the need to provide date to some third-party function in this particular case you don't care maybe you don't care that this third-party function can do some kind of uh cash timing attacks you you you know you trust that this third party code cannot do this and what will you do you will provide an identity version of date you provide the original date function to to this third-party code in another case you want to be like oh

i think the browser just crashed oh

this would be an excellent time to make fun of some browser right don't do this at home all right um i was genuinely about to make fun of a browser i'm not going to do that now wait i'm still going to do that okay so activex for those of you young enough to remember used to be a part of a browser that we are very happily gotten rid of mostly that that provided too much power and if you if you provided activex access to some third-party code it would be able to do much more than you were wanting to do but what you might want to be able to do is allow people allow some third party

to have xhr access but you don't want to be able to allow it to xhr to some arbitrary place so what do you do you use virtualization to provide an attenuated version of xhr an xhr that's able to do all of the things that xhr can do but only to the origins you control or very maybe xhr via some particular proxy and now all of a sudden you've largely limited the amount of access that this xhr has how did you do that you provided an attenuated version a new version of xhr polyfill version of xhr that is only able to do a subset of things that xhr can do and this is a very powerful thing because let's say

you happen to have a browser that i was about to make fun of that did not provide you xhr but it provided you with a much bigger ability it provided you with activex much bigger but what you were able to do is provided an attenuated version a smaller version that used activex but emulated what xhr did right like so you can provide attenuated versions of document you can provide attenuated versions of location what does attenuated mean in this case it means that you've largely limited what access this third party code has access to which means that the attack surface that you are providing to any particular given third-party service is much smaller um oh am i going in the wrong direction

the third thing that's the second control the third control that i am providing uh what do you want to have look every isolation mechanism that one has has holes in it we all know this to be true in fact this conference is an example is evidence that every isolation mechanism every sandboxing mechanism that we have has holes in it sooner or later the cleverness of attackers like the people in this room the stupidity of uh the sandboxing people like the people on the stage is such that uh sooner or later it's going to break it is going to break that's not what the important part is what is important is that when it breaks we know that it has broken and we know

the ways in which it has broken and we can do something about it what do we need for that what we need is two things we need to be able to know what is happening out in the wild on our web pages and then we need a closed feedback loop such that when it happens we are able to do something about it now one of the things that you can use is virtualization virtualization means that every time you're using an api not only does it do what it is says on the tin what it says it's going to do it can also do some additional action like send a message back to us to say hey

in addition to sending an xhr which we weren't expecting this piece of code did this extra thing if you want a simpler example of this csp uri reports are an example it doesn't use virtualization but it gives you visibility into what is happening or that what is happening that is resulting in vulnerabilities on your web page being taken advantage of by attackers right you get reports on how these vulnerabilities are being taken advantage of oh in order to do this what do you need you need collectors which collect messages events from what is happening in the wild you need analyzers that collate all of this information into coherent reports and then what you need further

is visualizers and decoders that summarize and visualize and give you some action that you can take as a result of seeing what is happening in the wild um [Music] the thing that i want you to take away from this talk is the principles that underlie all of these different things if you think about what is the message of the theme of this particular uh b-sides it is what is it that it takes for us to get off the ground and for us to get off the ground instead of having a large number of ad hoc responses to individual attacks what we need is general principles and i'm going to describe three general principles that i feel

underlie the idea that we want which gives us web isolation principle number one compartment size the size of the units of isolation is very important you can imagine having the entire origin or you can have a domain you can have a web page you can have an individual script you can have an individual api you can have a tiny little action and each one of these gives you finer and finer granular control over what third parties are able to do on your websites now the advantage is the finer grained control you have the more control you have over what amount of damage your third party can do on you there's a very favorite phrase that i use every

time somebody says do you trust me or do you trust the script instead i reframe that question as what is the extent to which you are vulnerable and the smaller the granularity the smaller the extent to which you are vulnerable to a particular script or to a particular function or to a particular action on the other hand what you have is the finer grained your level of granularity is the harder it is to set up like the more configuration it takes the more you have to think about how much do i want to make myself vulnerable to this script or to this script or to this script and unless you have some mechanism some tooling that gives you

automated control over the decisions that you have to take you are overwhelmed by the decisions that you are needing to make size matters and the smaller is better the second thing is isolation material now the stronger our isolation mechanism is the better off we are the problem is that the mechanisms that we use for isolation today were built using well built for a web that we have long stopped using to develop developers develop in a very different way pedro talked about csp and he talked about iframes but in each one of these cases because the way in which we develop web applications we don't develop web applications where it's individual pages right we develop web applications that

are single page apps we develop web applications very differently from when these security mechanisms were developed what do developers do when they face impedance on getting things done what they do is come around come with workarounds they drill holes into the isolation mechanisms that browsers provide and that's fantastic they're getting their work done the problem is from a security point of view every hole that they drill makes it harder for the materials to provide the isolation if you have a ship what you need is something that is firm each of the compartments need solid foundations and essentially by working against the developers mechanisms for development we make it harder for developers to get their things done and they drill holes and

weaken the material materials that we use for isolation which brings me to the third point which is visibility and user-friendliness do i say this i say this right did you know that developers are people too developers are people too and they need user friendliness on the developer side right any time that we have apis for security that make developers jobs harder what they do is come up with mechanisms to work around what it is that we are doing to save them to protect them the other thing is visibility sooner or later each one of these mechanisms fail and what we need is visibility when these mechanisms are failing if you had a ship let's say

you would need an outer hull and an inner hull and every time the outer hole is breached you want to know about it whenever the inner hull is breached you want to know about it why not because you know it gives you somebody to blame but it gives you the opportunity to work out how to respond in a way that lets you fix it complexity is the other part of this there are a number of things that developers need to keep in mind keeps growing it's very very hard i i walked around the the vendor floor today and i feel like i have a large amount of expertise in the security field i've been a member of the security community

for a long while and there's large numbers of things that i don't even understand and i worry about developers having to face a similar kind of complexity what we need is something that aligns sufficiently well that developers understand what security mechanisms they're employing and where the failure modes of those are i think that this brings us back to our cliffhanger what do you think yeah so we promised to tell you exactly why the implementation of the titanic was flawed basically because the compartments were still too big and definitely the materials were not iceberg ready so it would need stronger materials the damage model obviously was incomplete or incorrect which translating to our context means that the threat model was wrong

and last but not least lack of visibility i mean if someone had spotted the iceberg in time they wouldn't even have to test the the remaining like safety features so definitely visibility and analytics which is an interpretation of what we see are essential for a good defense and now we are presenting some demos so uh we'll be using the same scenario across four demos which is a mock-up online banking login page that has one third party a chat bot and in some of the runs this chatbot will be replaced by a malicious version which will try to capture the login credentials and exfiltrate them at the bottom of the page you'll see some controls they are used to

to basically to configure to reload the page with different demo settings so let's start with the baseline so here is the the page and right now we don't have any defense any isolation mechanism so this is on purpose to see what happens when isolation is lagging so this is a very simple website it mostly has first party codes loaded from virtualbank.com and it has one third party loaded from chatbot.com so you're already seeing the third party this is the non-malicious version it's it's very simple script uh it doesn't do a lot uh because it's a mock-up script all right um so the important thing is to understand that it's being loaded from the third party now that for

a third party can very easily be compromised and it has a direct way to load arbitrary codes into every user session of this website all right so next we'll show you precisely that so i'll skip the waiting parts just to keep this moving and we'll check the box of the compromise third party and reload the page and now you're seeing the malicious version let me stop here so as per the same origin policy this script is embedded which means that it has full access to the page including that login form all right so at any given moment it can access the form collect the data there and exit it in fact the code that we're

seeing that code is setting an on submit event handler so it's overriding the event handler that was there before and when the form is submitted it will collect it will do what we sometimes call form jacking it will collect all the values of every field and we'll xhr that to a domain controlled by the attacker which usually we call drop server in this case malicious dash api.js grammar dot com this compromise script is our iceberg then it is so let me get back to where we were all right so next what we will do we'll show you what happens when we type the credentials which will trigger that malicious code okay so i'm typing my username and

password submitting the form

all right and basically that malicious code is after doing what it does we'll call the original event handler so from a user perspective nothing will like seem strange this is the drop server ui let me refresh it to see from the server from the attacking server what was successfully accelerated there you go all right so now in this case the problem is obvious is lack of isolation so the next thing that we can do is just move the third party to an iframe to a cross-origin iframe and leverage the same origin policy obviously that basically forces that script to be uh adapted like in order to work but uh we'll we'll just show you the malicious

version of that run right so this is the iframe third party so we'll just enable the iframe third party compromise third party and reload the page

so immediately what you see in there maybe you cannot read it but it's a console error basically resulted from the fact that the same malicious script is now not being able to access the form hence the error okay so it was we were able to mitigate the problem but um [Music] obviously being across origin i framed uh the problem is gone like that there's no way that iframe uh can access that form but in order for the original code the non-malicious version to work we now have to ask the vendor to work from a cross-origin iframe which will basically require that vendor to change how it works also we need to change our page because we need now to move this to

iframe and let's not forget because this example is very simple we only have one third party but the average page has tens of different third parties so the overall accumulated work that it requires in order to follow this approach can be quite significant i mean not only that each one of these iframes have to be communicated asynchronously right right so you have to refactor all of the code and then now communicate asynchronously with these iframes which can create problems because uh before they work communicating synchronously right and then you know async code is much harder to create but also harder to debug right and now you have to set this protocol with a third party because you you can

only use the web messaging api so the next one uses google kaha yeah so so uh what do you see here it's a very similar case to the previous one where you're trying to protect yourself by isolating your code with uh with with some code that is isolated uh here what am i looking at uh here we've injected uh caja actually it's a secure ecmascript or cess a grandchild of kaha let's say what does it do it injects itself into the page and then it sets up a situation where it controls what apis are callable if you remember what i described earlier we can decide and whitelist exactly which apis are necessary for this function to

execute in this particular case append child and create element are the only things that are necessary and so those are the ones we whitelist and we say yeah go ahead do whatever you want compromised script all that we're going to allow you to do is call create element and append child and then uh pedro goes ahead and logs in uh pedro can log in yes from a distance uh he types in his password and now the compromise script is trying to reach in and grab the the password but it cannot because in order to grab the password it needs to do what it needs to grab dot value from the password field an api that is not

whitelisted and so when pedro logs in um uh if he he logs in correctly i get nervous every time i see this drop server because it looks like it still has a compromise script but this is the earlier password this is no new password was leaked pedro's password remains safe what is the difference between the iframe version and the caja version it is that refactoring was still required the code still needed to be changed but at least it did not need to be asynchronous anymore kaha allows you the sandboxing mechanism allows you to access to rewrite your scripts so that they are synchronously accessible as they were before and uh yeah that that that's an improvement

right like if any of you have written async code and i suspect everybody in this room has written async code if you've written async code correctly i would like to hire you but but most of us are lying when we say we can write async code correctly so what this sandboxing mechanism gives us is yes we still have to do refactoring but at least we don't need to suddenly deal with asynchronous code because chaining all of asynchronous code is very hard if only there were a different mechanism that would prevent us from having to do that yeah how about it did i set you up right completely totally so to address these caveats we have been working on a

solution called web page integrity which is basically a sandboxing solution that can be seamlessly integrated into any website by adding a javascript agent and that agent carries a rules engine which is very granular and and with it you can specifically say what you should enable at any level of granularity and or what you want to block all right so here you are seeing the dashboard of the latest threats detected which right now is completely wiped clean and uh and now what we're going to do is reload the page with that agent uh together with the compromised third party um and the the first thing that uh i will notice let me just wait and you will actually

see it on the dashboard

so the first thing that we have here is indication that something is interfering with the on submit event handler of a form so we can see um in a lot of detail what form was affected and specifically what is the new event handler that was set in that to that form so we can see this code we we can recognize this code it was the same code that i've shown you before and right now we are only uh in visibility mode so we're not blocking anything um because this is a demo and it's more like it's easier to to talk about things when we're just showing we're not blocking and here you can see the script

that's initiated the ev the the action and the specific function that triggered it so next let's see what else we can see um let's uh log in again and and and see the malicious code running and what uh you'll be able to see in the in the dashboard so obviously the the password will be captured because we're not blocking anything that's that's fine for a demo um you can see that the acceleration was detected and the types of details that we're able to show are like the specific method xhr the endpoint malicious dash api.json.com and the specific fields that were basically accelerated and again you can see the script that initiated the action and the specific function

all right so obviously uh on the on that attacker controlled interface we'll be able to see to see that password all right so uh now that we understand uh what's going on we can start mitigating it so like i said we have a rules engine so we have to write rules we're not writing rules from scratch here because we have a couple of templates so and that's basically faster okay so

okay let me stop here so this first rule so before explaining the rule basically that let me explain the anatomy of a rule so we have four sections the which pages in which you basically set the scope of the rule is it running for the whole website or just like a section or a specific page then you have the which resources and with which you can match the initiated scripts if any or or you don't care any script will do and then you have what specific action you want to match in this case we're matching any network requests sent to malicious dash api.json.com and finally you have the actions which for this rule you have the alert and

block you can you could just alert or block in this case we're doing both so what we need to do now is just enable this rule and commit the configuration and wait a few sections as uh seconds after which every user session will actually start being like enforcing this new rule all right so let me fast forward this okay we're still waiting for that configuration to be deployed then reload the page and see what happens so remember what we are doing is we are blocking communications with that domain so we are not doing anything regarding like the beyond submits event hand or rewrite so that will still happen but what we will see is whether or not we manage to block

that acceleration so again this is the same as the first one we saw okay naturally we're not blocking it and now we'll sign in to see if we manage to block it

okay let me just make it faster all right so you can see blocked prefix on the same alert so it has so we can still see the attempts but we have confirmation that it was successfully blocked right so we can actually do better uh what we can do is also prevent that on submit event handler rewrite from happening so that's so in order to do that we'll use the second rule which will basically block any behavior change that targets a form in that page all right so it's actually broader than what we needed but it's all right because it will be easier to maintain actually so we'll just enable this rule and commit it and then reload the page

okay and see what happens

so we don't even have to fill in that form so because that action takes place like immediately so here you go all right so blocks so again we can see the the that attempt but it was blocked now with this type of approach you have oh wait let me just summarize my mad scientist friend here okay all right so what you did was you had a vulnerable script that was stealing passwords you dropped a script that you were now able to configure using a ui and what you got from it was visibility that passwords were leaking you got visibility on what script was what compromise script was leaking this password so you could see what was happening

and then you were able to block the compromised password from leaking without making any changes to the original code and then you were able to even block the mutation of the event handler by the compromise script am i getting that right yes okay but i want to stress that even though it sounded like to be very reactive so first need to learn what's happening in order to like to fix it the the approach actually allows you to be very preventive for instance think about the form you can set an allow list of scripts that should have access to that form and automatically every other script is blocked so you don't have to learn uh what domains you need to block what

scripts you need to to block it's it's it's done right and the other thing i want to stress is that here you control the size of the boxes so you can have boxes of any size without having to re-engineer the application so we're getting to the end of the talk it's now time to address the challenges ahead but before we do that we must first talk about what we have been doing wrong so in regards to isolation inside the browser things have been slow and erratic and i think the main reason is that there was never one feature whose purpose was to provide full isolation inside the browser so things have been more about stitching together

different isolation mechanisms and try to cover as much ground as possible this is both error prone and complex so naturally it leaves holes it leaves blind spots beyond the browser there have been some attempts to provide like holistic web isolation one example was google kaha but suddenly sadly it was discontinued the other more recent attempt was web page integrity that we just showed you so what i was shooting for what we were shooting for in this talk is to give you a set of principles that should be guiding this critical feature which is isolation in order to build web browsers that provide developers with the primitive tools that they need in order to build uh secure web applications i

think that the three principles that we went over and i hope i managed to convince you at least part of this is the granularity of the size of the components that you are using is very critical at the function or api levels as long as you have a service or a mechanism that allows you to automatically configure web applications you have the ability to control the size of scripts stronger isolation foundations uh using weber using the browser in order to enforce the isolation mechanism is very important providing visibility and user friendliness is super important because developers are people too and visibility is super important so that when failures occur we are able to respond to them

one quick example of something that is being baked into browsers today is shadow realms this is a proposal where the api of a isolation mechanism is controlled by the developer the api looks very much like an eval it's really a safe eval where the function is called based in inside of a context that the caller controls it has a stronger isolation foundation why because the browser enforces it rather than a series of ad hoc mechanisms that are necessary why is it user friendly well developers are already familiar with eval we all know what eval means all that we're doing is controlling what context that eval is executing in it's understandable to developers it's simple to understand

it is not a series of corner cases it is just eval in a context now in the case of shadow realms it's missing visibility unlike let's say web page integrity but the way to think about things like shadow realms is not as a full-blown product but as a mechanism that browsers are providing that allows products to be built on on top of it that have this set of properties to come back to the beginning of this talk how far along are we well [Music] we've made a huge amount of progress over the last 10 15 20 years there's a projects this size take a large amount of effort particularly when the way in which we develop is changing

but great projects big projects require effort and time and uh mechanisms like web page integrity like shadow realms and all of the other things that we are building with the community with you and i and all of the security community together can allow isolation as a mechanism to build the future of web security tools one of the jokes that pedro and i had as we were going through this set of slides is in order to make a ship unsinkable the only way is to give it wings i did not realize how appropriate that was until i heard this morning's uh keynote and prior to the keynote i did not even realize that the theme of

today's of this conference is what it is to get us off the ground in order to get us off the ground what we need is to give our web applications our ship wings and i think that that's something that isolation gives us take care thank you [Applause] [Music]