SquareX Browser Detection and Response Demos

So one of the ways, uh, these malicious files can be actually sent to the client site is also by hiding it in the plain site. So, hiding in plain site would mean like, you know, something like, let's say there's a web resource, like for example, you have a simple webpage, and this webpage has a couple of files. This could be like a web assembly file, this could be a JavaScript file.

This could be a CSS file. Now, what attackers are typically doing is that they basically hide the malicious file payload within a small variable in your CSS file or within a small, you know, uh, section of a web assembly. And to the end user, it looks entirely like a normal file download.

So let's say you open a page, you click on a download button, it's just downloading like a normal thing. But what's really happening is that a web resource, which is already loaded on the page, is picked up by the Java script. It is triggered as a blob based download from the browser itself.

And for any proxy based solution, it's just not feasible and not scalable to go ahead and do very aggressive scanning on all the, all sorts of web resources possible. So, uh, this is an example which shows that it's also important to have some level of last pace control within your browser, which can basically detect that, hey, there's a file trigger happening, uh, whatever the way you have delivered to the page, that doesn't really matter. But the moment there is a file trigger happening, a browser based solution can basically capture it, uh, probably scan it and then stop it right there.

So I'll show you a small demo for this. So in this demo, what we're gonna look at is, uh, you know, different techniques. So as you can see on the left side, we have web assembly, which I already talked about, like, you know, is like a, a, a format which is used by a lot of websites these days.

Second, second off, also be like, you know, simple old things like graphy, where you are basically putting, uh, your malicious file as a image using any of the existing synography formats, and then triggering it like a normal download using JavaScript on the client side. And third is like, you know, all the web resources which I talked about, which is mainly things like, uh, you know, the CSS files or any kind of web resource like an S VG file. So, so what we are gonna do is, uh, we have basically set up this small page called as browser security.

This has all of these, you know, uh, things already in place so that you can go and experiment with them very easily. So the very first example you see here is basically a VAM and bear attack. So what happens in this case is that if you see on the right side, there's a network request going, and this network request is loading a web assembly file, looking at the contents of the file, you cannot really figure out, like, you know, if it contains some sort of a malicious file content as one of the variables inside.

And like I said, it's very difficult to aggressively look at all the resources which are being lowered. So in this case, we can see like, you know, through all these methods, which is, for example, the ST based method or like, you know, using the web assembly method, the file ultimately downloads like a normal file and you can just go back drag and drop it in, uh, you know, virus total to verify like a malicious file actually went through your proxy based controls. So this is just an example of like, you know, how uh, these malicious files can be hidden in very plain sight and uh, can be like, you know, uh, triggered as a download entirely on the client side using JavaScript.

So now what we are gonna do is that we are gonna look at how we can go about, uh, you know, protecting against these kind of attacks. So what you see here is basically the square X platform. And to, to give you a more insight on how really, uh, square x works.

So there are basically two main components to it. First is a browser extension, which sits on your browser. And this could be any browser.

This could be like, you know, your premium based browser. This could be Safari, this could be Firefox, whatever that browser is. So we sit inside there as an extension, and this extension is installed using Edwin Permissions.

I'll come to that later on how really it's deployed. Uh, and the second piece is basically the web platform where people can go and they can create policies or use one of the baked in policies that we provide to go ahead and, you know, create policies or apply policies over the set of users. So if I basically go ahead and show you how this looks like, so this is how the interface looks like.

So you have like, you know, all the different categories that you can basically cover when you think about any user action that is being taken. So this could be things like, you know, what is happening on from a page perspective, like for example, the content of the page, what input someone is putting in, what contents you're copy pasting, right? And then whether you're trying to print something, whether you wanna show a watermark.

So anything that happens from uh, a user perspective, that's how, uh, you know, the product has divided all the different sections into. And within each of these sections, you can go ahead and set up policies. The same goes for anything that goes outside, uh, you know, websites as well, for example, files where you can create policies for file downloads or file uploads.

Now, when it comes to a browser-based solution, uh, like I said, you know, even if a file is being constructed on the client side or the controls are applied at a last mile level where, you know, let's say whatever medium network, your file ultimately reaches that point, the moment it triggers a download, that's where product is gonna go and stop it. And when we talk about upload, it's actually the reverse. So it's a first mile control.

So if you look at the way, you know, traditional, uh, DLP solutions who are network based were working was more like you allow the network to go through from the website and they will stop it in the middle. But in this case, even before the website can pick it up, the file will be stopped. So that's like another example of having forced mile control when it comes to like, you know, DLP use cases.

And then, uh, you know, last mile controls when it comes to download. The same goes for other category of attacks as well, for example, extensions, right? Extension is something which is becoming a big problem these days.

Like we, uh, many organizations don't even have visibility on what kind of extensions users are. And you can simply create like, you know, block policies based on so many different factors, uh, using a browser based control. The same goes for identity as well, where you can basically go ahead and say like, you know, I'm gonna block any kind of risky permissions that a person can possibly give to a different application.

Or it could be things like avoiding password reuse that is happening. So like I said, you can go ahead and create policies here, or you can just pick anything that you want from a policy library, which has like bunch of these policies already baked in. So you can just pick any of them from here and use it directly in your tenant.

Now, coming back, you know specifically to creating policies. So when we create our policies, we provide, uh, three different ways to do it. One way is that you can go ahead and use our policy builder, where you go ahead and choose anything out of all this, you know, long list of properties, which are possible.

And the second way is that you can also go ahead and use, uh, AI based generator. So this is one of those things we have been, uh, uh, you know, experimenting with where we want to make the process of creating new policies and modeling, uh, protection against newer attacks very fast. So you can simply just say a sentence like, you know, Hey, I wanna block any kind of malicious file if it contains these words somewhere.

So what it'll do is I understand that sentence and automatically fill that form for you selecting the right set of properties, and you can just review it nicely and then just save it and, and try it for like a small group of users. Secondly, if you want to go ahead and write like a really, really complex policy where you feel like, you know, uh, and or conditions and things like that would become too restrictive. We also provide a way to switch to a lu script mode.

And this Lua script runs entirely on the client side. So your browser extension itself can enforce all these policies running entirely on the client side. So you can say many complex things like, you know, hey, loop through something inside the file, if you file these kind of things, just go ahead and block it.

But again, you know, this is more for people who want to make their own policies. For most cases, they would just wanna pick something from the Polish library and user, this is just me, you know, an engineering guy trying to show, show off. So yeah, so now coming back to the demo.

So what we are gonna do here is we're gonna create a simple file download policy, which says that you know, hey, I'm gonna block any kind of, you know, known malware download that is happening. And this could be delivered through any means. So the moment we put this in, it's gonna fill up the form and then we can assign it to, you know, right set of groups, which can be pulled from your entity provider.

After we save this, the policy will apply right away. Now, when we go back and try all the same methods, you will see the download blocking is getting blocked right away. So the moment you know that trigger is happening, the network requests, everything goes in and we'll be able to stop it right from the download is about to trigger on the client side through the browser.

And if you are an admin mode, you can also see advanced analysis of why this file was flagged as malicious. And uh, also, you know, you can go up and clean up the file. So, uh, as part of formats like office document, we also provide CDR capabilities where you can go ahead and strip macro from a given file and then trigger it download.

And all this happens on the client side, by the way. So in your extension itself, we'll just take the file, bisect it, and then trigger it, download. Now coming back, you know, to the, uh, to all the different things.

So you can see like, you know, even the technographic based attacks or whatever it is, all of them are basically getting blocked right there in the browser. Now coming back to the detections, so these are, this is how the detections look like. So you get every detection that you have made based on the policy right there in the platform.

Uh, there is also integration available for all the same vendors. So if you want to consume it directly from there, that's also, that's completely possible. Uh, not talking a bit on, you know, the visibility part.

So that's, that's where a browser based solution really helps. The reason is that many a times, let's say you see like a malicious server was downloaded at Max, what you get as something like, you know, Hey, this was downloaded from Chrome exe and the mark of the web says that it came from this website, that's it. But if you want to go back and track that, how really the user reached that place, it's very difficult to go through the logs and analyze and figure out like, you know, how the person reached that page because you would want to put your controls at the right place to avoid further things like that from happening in the organization.

And that's where Attack Graph comes into play. So Attack Graph is basically mapping how the user is reaching any page at any point of time. The moment, let's say there is a policy violation happening, or anything suspicious or malicious happen, the detection will come and it'll also show you how the user reached that page.

So in this case, we can see that, you know, this particular user went ahead and open a website called Browser Security and then trigger a download. com, search for the word browser security clicked on a link. So it'll add all those nodes within this particular graph.

And this gives you like, you know, an advanced, uh, visibility on what really happened. You also can enable artifact collection. So if in case it's a malicious file, you can collect the artifact, you can download it from here, you can open it in a disposable file view, which is our way of seeing isolated file view, where you put it on an environment which has internet cutoff and analyze the file and play with it, and you get like a complete analysis of the file itself as well.

Now this is interesting. So we also do interconnected graphs. So let's say the same IOC or the file was also found out by a used by or download by or uploaded by any other person in the organization.

It'll also interconnect it and show it in form of a related attack graph, which gives you a much more visibility on who all are the people who have sort of, you know, either uploaded the file or downloaded the file already. So you can see in this case, this is the common IOC, which is the, uh, you know, the share of the file. Okay.

Alright, now coming back to the slides. So yeah, so this is, uh, the first section which is mainly, you know, browser detection and response within the browser. And this extends to everything that is happening within the browser.

Uh, these are like, you know, couple of use cases. This includes things like, you know, malicious files, websites, extensions, identity based attacks, and all of them. Now, one of the most interesting one is specifically identity based attacks, because that is something which is going, you know, really wild these days.

Recently there have been cases where, uh, you know, it was actually covered by a lot of news leaders as well where, uh, people were going ahead and giving out, uh, and being victim to basically an oath based consent attack with Salesforce. So people will get like, you know, emails where they'll be given like a looking Salesforce link because it is Salesforce link, it's just that it's tied up to an application. You click on there, you put up a code there, and you're basically giving the consent for anyone to exfiltrate the data out.

This is like an example of how, uh, these kind of attacks are also becoming common and how, uh, you know, an identity based policy can help protect against it. So I already have, uh, you know, this set up. So if you see here, this is an application which is actually used, which is this, the Salesforce data loader.

So what attacker would do is that on his device, he will go ahead and download this file. After this is downloaded, it'll go ahead and create this environment. And what this environment does is that it just gives you a small code and this is the code you have to basically send it to the person you are targeting this attack to.

So what they will do is they will just go ahead and copy this code, and then they will frame an email, which is convincing enough and send it to the people who have the right access in the Salesforce, uh, the Salesforce department of the comp company. If you see like this, this is how it looks like. Now the funny part is like most of the, you know, uh, uh, mail based solutions who are looking at the mail content cannot flag this as a suspicious link.

The only thing they can possibly do is analyzing the context of the content maybe and then figure out this looks fishy. But other than that, uh, the link there is a alleged Salesforce link. It's not something you can just look at it and say like, you know, Hey, this is not Salesforce, this is like some different domain.

You cannot say that. So if someone is let's say, you know, convinced, they'll click on that and they'll put the same code, which is on the email, and the data will basically get exfiltrated, because after that you have given the access and it's a server to server communication now. So that application can just pull all the data there whenever they want.

So whenever such kind of oau consent happens, this is how a page typically looks like, where people often don't read properly and go ahead and allow it because they're like, you know, hey, it's a Salesforce link, maybe I have to allow it to see it. And that's where the problem happens. So you can see like, you know, the moment they give allow the, the, it's connected and data is gone.

So we also provide like policies pre-made for Salesforce as well, where we go ahead and mark any kind of risky permission giving and you can enforce it via an identity policy. Because what happens is, like every time you open such link, you're gonna give that consent within your browser. And the moment that consent page opens up, we will be able to figure out like what kind of risky permission this page is asking for.

And the moment we see, like, you know, hey, some employees trying to go ahead and, you know, give access to very risky permission to Salesforce, uh, it'll basically go ahead and stop right there. And if it's really a need, uh, the employee can go ahead and raise a request for an exception and the exception will go back in, admins can review it and then they can approve it, otherwise it can be blocked. I had a question.

Sure. Heavily, and again, this has been a great presentation, I just wanna make sure maybe that I didn't miss something. So I know you mentioned it'll ex exfiltrate that data if you're in an email.

So obviously if you're in a browser like Chrome or Yes Edge or whatever the case may be. But if you're in an email, is there like the extension will kind of manage the email portion of it as well? Yes.

And then as long as a policy set in place and configured, it'll just pull that data from the email and then correlate it to whatever's happening in the browser, and then both of 'em talk to each other and it's just like something's off here. Yeah. So in this case, what's happening is that the controls are in the browser.

Yeah. So let's say even if you're using something outside, like let's say Outlook, which is not part of the browser, right? Right.

Ultimately when you click on that link, it's gonna open in the browser and that's where the extension is there. That's cool. Yeah.

So that's how like, you know, all the controls are being managed by the browser. So, uh, you know, if we talk about the technical feasibility, of course it's possible to write extensions for Outlook app as well. Yeah.

But you cannot go around and support every male client. That is possible, right? That's why I was, no, I didn't, I didn't expect, I was just curious because like, it doesn't matter, like kind of the majority ones are like Outlook and you know, email and All that.

Exactly, exactly. Awesome. Okay.

But anyways, whatever app they use, ultimately they're gonna land on the browser and that's where the consent, you know, screen will be captured and the policy will be enforced. Okay, Thank You. So in this case, we are gonna enable this policy, which is gonna go ahead and block it.

So you can see that, you know, the moment you're trying to connect it, it just immediately stops right there. So it'll not allow you to go ahead and give that consent. And if you want, of course you can raise an exception if you want, but otherwise it just stopped immediately and admins can then just go back, look at, you know, how the user reads that page.

So this is the visibility part I was talking about where we can see like, you know, this particular person, uh, you know, received this email, uh, and even the center name is visible on the left side. So we were able to infer who the center was, because in this case, the link was clicked within a browser, a browser open website, and you see like, you know, this person ended up going on this link and ultimately there was an oath ask that happened and then it got stopped. So you get like a full visibility on how exactly, you know, a person is ending up on that page and it's asking for a permission and then you can make exceptions if needed.

com in there. Obviously that's open in the browser. Will you see that?

You mentioned if I open it from Outlook? Yeah. Will you see the same thing?

So in that, So in that case, what you see is basically that from an external app, something open in the browser, okay, the visibility. So You don't, obviously you don't see the yes, Yes, yes. Where you click visibility here is entirely on what's happening within the browser.

And the reason for that is because that's where, you know, the biggest gap happens because it's like a small box for any other security tool outside, you don't know what's happening in the role that, that's what we are trying to fill. Okay, so now we are gonna look back on, you know, how QX can really complement EDR. So of course, you know, there are things which we earlier talked about, which is things like, uh, you know, identity based attacks, extensions, uh, and, and anything that happens within the browser, that's something that, uh, of course we can help out with.

But anything that ultimately goes outside, like for example, you know, a file download, right? So in file download, you're sort of relying on your EDR, and that's where QX really helps because we are able to give you the attack graph visibility to that. So you don't just get the information like, you know, hey, this is this URL and this came from Chrome dot xe, but we also tell you like how exactly that person reached that page when the download really happened.

So the combination of these can be really good and it can fill in a great visibility gap, which is right now when it comes to browser. Okay, now let's talk about another very interesting case. This was an, uh, there was actually an article by Microsoft as well where they talked about the specific attack.

So, uh, midnight Visit group was basically using an RDP file. And what this RDP file was doing was that the moment you open it, uh, people will see like, oh, it's an RDP, okay, I'm gonna try it. And they'll write like some sort of a convincing message, uh, you know, explaining them why they need to open this RDP file.

Now, the moment you open that, uh, that small RDP file, what it does is that it loads all your local drives to the attacker's device. So all your local drive on your machine gets loaded there just by opening that RDP session. So, such a very small thing.

And, you know, a very, I would say, uh, creative way of delivering an attack, we are doing an exfiltration by something as trivi as an RDP file. So when such kind of new attacks happen, uh, the very first thing the security team would do is, Hey, how can I go ahead and block it for my organization? So they go around on the internet, they'll find what are the IOCs, and they will go ahead and start putting them up in a, in as a, as a block policy within their security controls.

But of course, you know, c can change, people can go ahead and create files in a different way. They can deliver it from different websites, uh, so the, the, the attacker can change their IP address as well from which they're basically connecting from, right? So all these possibilities are there.

So what I'm trying to say is that if you have, uh, you know, uh, a Lua based editor, and if you have something which is very customizable, you can go ahead and model protection against these kind of attacks in a very fast way. So this is one example just to show how policymaking against novel attacks is very fast with the browser-based platform. So we have a setup here already, which is basically, you know, the same attack.

So this was similar to how it was actually delivered. So people were shown like a Microsoft Defender page, which was obviously not hosted on the actual defender page. And what people were doing were that they were simply going ahead and downloading a file.

And this file is an RDP file. The moment you open it, and let's say you connect to it, it opens a normal, you know, session. And what's gonna happen in that session is that it's gonna go ahead and load all your local drives there.

Now, to model a, a protection against this attack very quickly, uh, you can simply go ahead and put a prompt in the policy creator saying like, you know, Hey, I'm gonna block all, all RDP download files. If they contain the commands, like, you know, redirect location 1, 1 1 column one, which is basically used to, you know, uh, redirect your location to any other place, or if it mentions these IOCs anywhere in the file, so you're not just blocking the IOC, you're also looking at, you know, the redirect command, which is basically loading your drive from your local to an external machine is also blocked. You can go ahead put that prompt there and you can see like, you know, it'll go ahead and generate a lower script for that, which will go through, uh, the file contains and stop it if these kind of commands are present in the RDP file.

Let's say you apply it. Now when you go back and let's say you trigger a download, you'll see that it immediately gets blocked and you can go back, look at the detection, so you get like a full visibility on how exactly it happened. Now this part is pretty interesting.

So there's one other thing that you can actually do because you're sitting in the browser, and this we have seen works really well for vulnerable groups. Let's say for example, someone leaving the organization or someone who is like, you know, someone from the customer support team who's getting so many things from outside. So what Attack vision does is that it's a selective feature which you can enable for those vulnerable groups.

So it'll not just map how the user reach that page, but it'll also show you a recording of what really the user was seeing when the attack took place. And the way this works is that it's not like a real video recording, which is going ahead and recording what's happening on the screen, but it basically captures what are the DOM changes happening on the page. So let's say, you know, you have like couple of diffs and an input feel, it takes that along with the styles and then do it in like different, different intervals, and then it stitches all of them together to create something like a video.

It's very lightweight because there is nothing like, you know, a heavy recorder running on the page. It's very lightweight in the sense like you're just looking at the do changes that are happening and then reconstructing as a video. And you can also, you know, enrich it with things like how your mouse pointer is moving, what the person is typing, and it can give you a full visibility of what really happened on the, on the other person's screen, which is really good for security when they're going back and looking at, you know, what really happened with that user.

Because sometimes the moment you are going back and looking at that, the link is already down. So it's very difficult to know what the user was seeing at that point of time, what made it convincing for them. So this really helps, especially for those vulnerable groups where you would want that kind of visibility.

But of course, for critical departments, if you want to turn off is a simple setting, it'll never run in that cases. Okay, now let's talk about the second one, which is browser, DLP. Now browser DLP is also interesting because DLP as a problem has been existing, you know, since ages and, uh, people have been trying different things.

They have some endpoint solution, they have something on the proxy side, but browser in itself is becoming really complicated. And you know, this can be actually seen by the gaps that can be there just by using a proxy based solution or having something on the endpoint. So again, everything which I talked about earlier regarding network request breakage, you know, using any of those embedded things or like, you know, maybe encrypting it and then sending it and you don't have the password.

So in all these scenarios, if we do it in a reverse and we also apply for DLP, so you can send a same file broken up into different, different chunks where as a whole it doesn't become a credit card number, and all of them can again be stitched together on the server side, and you have a file there. So these kind of controls, which are just looking at stuff, you know, at a proxy level, would not be enough to stop these kind of attacks. So if you look at another demo, this would be something like file chunking, which is the same as what I talked earlier, where we are going ahead and breaking a small file into different chunks.

And then on the server side, we're gonna construct all of them together and then create a file there. So, you know, this is a simple file, which is a, which has like a couple of credit card numbers. Now what we are gonna do is we're gonna go ahead and use one of the chunking methods on this page.

If we try this file directly on any of the cloud-based DLP product, this is from, uh, you know, one of those vendors. You'll see that it'll say that it contains like five or more PI identifiers, and that's what the check is. Now, we'll go ahead and try this upload using multiple network requests approach.

So if we go back there, we use Chunk, and through the network tab we can see how the request is going. Let's say you upload this file, you will see that, you know, all this file is broken up into a different network request as you can see on the right side, and the file ultimately reaches the server. Yeah, this is just an example of how you can go ahead and bypass these solutions.

But like I said, if you're using a browser based solution, your controls are first mile even before the website can pick it up, the the extension will basically stop it from going through right there. Okay? Especially, you know, with the advent of ai, uh, this is becoming even a bigger problem because now people also have complex, uh, browsers, which are like, you know, made by AI based companies like recently, you know, publicity had this comment browser.

So, uh, this is definitely great for like, you know, uh, enhancing the user workflow, but it just adds a lot of complexity when it comes to, uh, observing them and stopping these things. And that's where, you know, uh, this becomes really important to have controls also at your browser level. Okay, the next thing, which, which is very important is that if you look at how, you know, traditional DLP solutions are working, they often think of user as the biggest adversary.

Like, you know, that the user can go ahead and make mistakes, which is absolutely correct, but it's also important to consider that nowadays just by having a DLP solution that stops employees from uploading things is not enough. You definitely need something that also considers what can come from outside. As we can see from the Salesforce example earlier where, you know, the actor was basically someone from outside, they were sending that link and exfiltration is still happening.

So you need like a good combination of a control that works within the browser, which covers not just, you know, uh, employee mistakes, but also something that can come from outside. And that's how you know, you would get like a full DLP picture because you would also need controls at a network level. You also need controls using your endpoint and to cover up the gap in the middle, uh, browser DLP solution will work really well.

Uh, you know, the, the, the third section is basically on enterprise browser. This is mainly the use cases that, uh, you know, many enterprise browser vendors cover, which is private access where you say like, you know, I'm gonna allow access only if you have that particular browser in place, or only if you have our extension in case in this case. So, uh, if we talk about enterprise browsers in particular, the adoption has been a problem and the main reason has been that you cannot ask everyone to use a new browser entirely.

This would work, might this, this might work well when you're talking with contractors because they don't really have option, right? Right. But if anything comes, you know, for your own employees, it's very difficult.

There are more risks that can often come in as well. Like for example, you know, uh, reliability, so similar to, you know, what happened with, uh, you know, CrowdStrike earlier. Sometimes these things can become a single point of failure, like all your people are using a specific browser, but anything goes wrong in that the whole business is disrupted.

But when it comes to an extension base approach, you can simply go ahead and disable an extension through an admin policy. Your browser will not crash. And the browser itself also has lot of inbuilt controls that ensures that extension never use resources more than what is required.

And that is something chromium and all these browsers do really well. Next is like, you know, um, of course user behavior because you're changing a user behavior by using a new browser entirely, which might take some time. And the Nexus, uh, also the security patching piece because most of the enterprise browser vendors are based out of chromium.

So if anything, any major vulnerability fix happens in the chromium code base, they also have to relay the same thing to their code base. There's often a gap, like, you know, a few hours or a days where they have to make sure that that new change that is coming to chromium doesn't really break their code because it's basically built on top of it. But when it comes to extensions, uh, one, and the reason why we went with that approach is because, uh, in case of extensions, uh, all the API changes that happen in the extension are usually announced years before.

So Chrome will say like, you know, Hey, we are gonna deprecate this function and that will happen, like, you know, after two years, like, like would happen with manifest version two, those kind of things also happen. So it's very important to have consider risk factor as well when, uh, using different approaches. And yes, Quick question, isn't there additional problems with enterprise browsers, uh, where they're running in protected memory or whatnot?

So if the browser itself gets compromised, you now expose more of the endpoint as opposed to obviously a plugin. Yeah, plug is still limited to the browser. Yeah.

So in that case, what happens is, like, uh, when the extension is rolled out, you can pair our pair it pair that MDM script along with some hardening rules where you can go ahead and put lot of hardening things that most of these browsers also provide, like, you know, Chrome, et cetera, have their own enterprise policies where you can also enforce a lot of other things along with what happens inside the pages with extensions have controlled of. So you can use like a combination of those hardening scripts along with an extension to deliver this. And additionally, you can also go ahead and use a very lightweight agent if you want, on the machine, which can also talk with the extension if required, enforce additional things if needed.

Okay. And this is how the deployment looks like. So you typically deploy it via an MDM, uh, where you say like, you know, Hey, this is my policy, I'm gonna have the extension installed.

Uh, in cases if you have like, you know, unmanaged devices, uh, we also go ahead and integrate with the identity vendors where we act like A MFA, the moment they complete their authentication. We'll say like, you know, you don't have access to the application unless you have the extension installed. That sort of maintains that posture.

So what's the ultimate value it's adding? So if we talk about, you know, a new capability that's gonna be the browser detection response because you have protection against anything that's happening within the browser, then we have enterprise browsers where you can actually replace them or augment them. It can really work on top of that as well, because also chromium based.

And lastly, you know, enhancing capabilities like DLP where you have a little gap in the middle because of browser. And lastly, this is how the architecture looks like. Uh, if you see on the left side, this is how a typical tab looks like of a page where you know you're going ahead and accessing different things within that page.

We inject some scripts on the page and that script will go ahead and look at what different functions of particular page is calling. For example, let's say a page is saying like, you know, I wanna request for a full screen, but before it actually gets enforced, the extension can go ahead and capture it and say like, you know, Hey, I'm not gonna allow full screen permission for this website. Then they have something on the background, which is called a service worker, which you can see on the right side.

This has all those individual modules in place, which are going ahead and ensuring that the attack graph is being mapped. Uh, all the policies are being enforced, and all these modules enable themselves based on what policies are enabled at that point. And then if anything is very intensive, like let's say you wanna do an OCR of the image being uploaded, all this is offloaded to an off skin worker, which basically spins up in the background, does that work, and then closes off.

So as you can see, it's also, uh, so it's had, it has been made considering all the possibilities to make sure that, you know, the performance of a user is not disrupted at all. So, yeah, that's it. Uh, thank you so much for, uh, listening to this and I hope this was, um, helpful and gives, you know, some visibility on the gaps that could possibly be there in the browser.