It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder

Hello and welcome. Thanks for coming to my talk. It's a jungle out there. What's going on inside your modules folder? My name is Firas, and I'm an open source maintainer. I started WebTorrent, and StandardJS. I've been doing open source since 2014. In the past, I volunteered on the Node.js board of directors, and I also teach a class on web security at Stanford University. Now I'm the founder of a startup called Socket, which helps protect the open source ecosystem.

Before we get started, let me tell you a story. On January 13th, 2012, over 10 years ago, a developer named Faizal Salman published a new project to GitHub. It was called UAParserJS, and it parsed user agent strings. Now, lots of people found this project useful. And so over the next 10 years, Faizal continued to develop the package, along with the help from many open source contributors. He published 54 versions, as the package grew in popularity. It eventually grew to 7 million downloads per week. Eventually being used by nearly 3 million GitHub repositories.

Now, let me tell you a different story. On October 5th, 2021, on a notorious Russian hacking forum, this post appeared. A hacker was offering to sell the password to an NPM account that controlled a package with over 7 million weekly downloads. His asking price was $20,000 for this password. Now, this is where the two stories intersect. Two weeks later, uaparser.js was compromised, and three malicious versions were published. Malware was added to these packages that would execute immediately whenever anyone installed one of the compromised versions. So, now let's take a look at what that malware does. So, this is the package JSON file for the compromised version. And you'll see that it uses a pre-install script. So, this means that command will run automatically any time this package is installed. So, now let's look at what that script does. So, the first thing you'll see is that it splits based on the operating system of the target. On Mac, nothing happens, which is lucky for Mac users, but Windows and Linux users aren't so lucky.

And you'll see here that command prompt has spawned for each of these platforms using child process.exe. So, now let's take a look at what that pre-install.sh script does. The very first line fetches the user's country and figures out whether the from Russia, Ukraine, Belarus, or Kazakhstan, and stores that in a variable. Now, if the user comes from one of those countries, then the script exits without doing anything further. However, if you come from any other country, then the script proceeds to download an executable file from this IP address, mark that file as executable, and then run it.

And now based on these command line flags, you can see here that this program is a Monero miner, which is going to be used to mine the Monero cryptocurrency for the attacker. Now, this is the script on Windows. It's very similar. So it starts off with downloading that same or similar Monero miner, but it also downloads a DLL file as well and runs that. And then here you can see it just starting up the Monero miner and registering the DLL file on Windows.

Now, what does this extra DLL file do? Well, it steals passwords from over 100 different programs on the Windows machine, as well as all the passwords in the Windows credential manager. So, yikes, this is a really nasty piece of malware. And, you know, anyone unlucky enough to run this lost all their passwords and had to do, you know, kind of a complete reset of their online accounts. Not a fun time. So, this is kind of the aftermath. So, this package was published for about four hours. And the open source community was pretty diligent and reported it, and the maintainer was also quite diligent. And so, you know, anyone who happened to install it during the four-hour window was compromised, but it was removed relatively quickly. Any software builds done in projects without using a lock file were compromised. And anyone who was unlucky enough to update to this new version of the package or maybe who merged a bot PR to update to this new version during this time would have also been compromised.

So, this was big news in the JavaScript world, and I'm guessing you may have already heard about this attack. But this is really just the tip of the iceberg. So, we've been tracking packages that are removed from NPM for security reasons, and we've seen over 700 packages removed for security reasons in just the last 30 days. And I think this trend is accelerating as attackers take advantage of the open ecosystem and the trust that maintainers have for each other and the sort of liberal contribution policies that we've all sort of adopted in the modern open source era. So, I think 2022 will be the year of supply chain security, as the awareness of this issue is now coming to the fore. So, one question you might ask is, why is this happening now? I want to start by just pointing out that what we're trying to do here is kind of crazy. We're trying to download code from the Internet, written by unknown individuals that we haven't read, that we execute with full permissions on our laptops and our servers, where we keep our most important data. So, this is what we're doing every day when we use NPM install. And I just have to say really quickly that I personally think it's a miracle that the system works. And that it's continued to mostly work for this long.

It's a testament, I think, to how good most people are. But unfortunately not everyone is good. So, let's dive into why this is happening now. The first reason is that 90% of your app's code comes from open source. So, we're really standing on the shoulders of giants. And open source is the reason why we can get an app off the ground in hours and days instead of weeks or months. And it's the reason that we don't need to be an expert in cryptography or in time zones or the virtual DOM to build a powerful modern web app. It's also the reason why your Node modules folder is one of the heaviest objects in the universe.

Another reason is that we have lots and lots of transitive dependencies. The way that we write software has changed. We use dependencies a lot more liberally. And so, installing even a single dependency often leads to many, many transitive dependencies that come in as well. A 2019 paper at the Usenix conference found that installing an average package introduces an implicit trust on 79 third-party packages and 39 maintainers, creating a surprisingly large attack surface. And so, what we have here is a visualization that my team at Socket created that shows you what Webpack looks like. If you kind of go into the node modules folder and really look at what's inside. Each gray box represents a package and each purple box represents a file or files inside of a package. As you take away each layer of the dependency tree, you'll find more packages inside the top-level package until you get down to the bottom. This is just an insane number of files and just a lot of modules flying around here.

The next reason is that no one really reads the code. There are some people who do, but by and large, people don't look at the code that they're executing on their machines. One big reason is that npm really doesn't make this very easy. If you go to the package page for UAParser.js and click on the explore tab here, you'll see that you can't even see the files of this package, so people have to resort to clicking the GitHub link and going and checking GitHub and hoping that the code on GitHub matches the code that's on npm, which is not necessarily true. But that's okay. That's okay. We can rely on Linus' law that given enough eyeballs, all bugs are shallow. So, if there is a security issue in a package or malware in a package, we can rely on others to find it, right? But if everyone does that, then who is finding the malware? And so, maybe this is the reason why on average a malicious package is available for 209 days before it's publicly reported. This comes from a research paper by Ohm et al. So, that's 209 days during which the wrong npm command can end extremely badly. And I find this number personally very shocking. A 2021 paper at NDSS, a prestigious security conference, also found similar results, including that 20% of these malware persist in package managers for over 400 days and have more than 1,000 downloads.

And the fourth reason is that popular tools give a false sense of security. A lot of popular tools scan for known vulnerabilities. So, in 2022, I believe this is no longer sufficient. We can't just scan for known vulnerabilities and stop there. And yet, that's what the most popular supply chain security products do, leaving you vulnerable.

The thing is, it can take weeks or months for a CVE or known vulnerability to be discovered, reported, and detected by tools. And so, it's just not fast enough. So, it may be worth taking a minute here to just quickly distinguish between known vulnerabilities and malware because they're very different. Vulnerabilities are accidentally introduced by maintainers, by the good guys, and they have varying levels of risk. So, sometimes it's okay to intentionally ship a known vulnerability to production if it's low-impact. Even if you have vulnerabilities in production, they may not be discovered or exploited before you update to a fixed version, so you have some time to address these kinds of issues, usually.

Now, malware, on the other hand, is quite different. Malware is intentionally introduced into a package by an attacker, almost never the maintainer, and it will always end badly if you ship malware to production. You don't have a few days or weeks to mitigate the issue. You need to really catch it before you install it on your laptop or on a production server. But in today's culture of fast development, a malicious dependency can be updated and merged in a very short amount of time. And so, unfortunately, this leads to increased risk of supply-chain attacks, because the quicker you update your dependencies, the fewer eyeballs that have had a chance to look at the code. And so, I really think we need a new approach to detect and to block malicious dependencies. But before we get into that, let's look a little deeper into how a supply-chain attack actually works and the mechanics of it.

So, we downloaded every package on NPM, and we spent a few weeks poking around. The download was 100 gigs of metadata and 15 terabytes of package tarballs. And as we poked around this metadata and all these packages, we noticed a few trends in the types of attacks we saw. So, I'm going to go over these attacks. These are what we found. So, there are attack vectors, which is sort of how the attacker tricks you and gets you to run their code in the first place. And then, there are tactics, which are what the attack code actually does or the techniques that the attacker uses to hide their code. So, let's talk about attack vectors. The first and the most common attack vector is typo squatting. So, typo squatting is when an attacker publishes a package which has a very similar name to a legitimate and popular package. And so, you can see here, there are two packages here with very similar names and one of these is malware and one of these is the real package, but I would guess that it would be hard for you to know that without actually cracking open these packages to see what's inside.

So, let's open up the malware package and take a look at what it's doing. So, you can see here, again, it's using an install script, which is a very common technique that malware uses. And if you open up this install script to look at the code, you'll find that the file is heavily obfuscated. But I can tell you, even without knowing exactly what this code is doing, you can bet this is not something that you want to run on your machine.

The next attack vector that we saw is called dependency confusion. So, this is pretty closely related to typosquatting. Dependency confusion happens when a company publishes packages to an internal NPM registry and uses a name that hasn't been taken yet on the public NPM registry. So, later an attacker can come along and register a package with the same name as the public version and confuse internal tools, so that internal tools will accidentally install the public version. So, this is why it's called the dependency confusion attack. So, looking through the recently deleted NPM packages, we were able to find a bunch of likely dependency confusion attacks, and most of these packages had malicious code in them. So, all these packages have names which appear to conflict with internal company package names. You can see here a whole bunch of different organizations, including governments, were affected by this. And here are a bunch more, clearly targeting these specific companies here in this list.

And finally, the third vector that we see a lot is hijacked packages. So, these are the ones that you usually see in the news quite a lot. So, criminals and thieves finding ways to infiltrate our communities and infect popular packages. Once they infect a popular package, once they get control of it, and they can publish to it, they'll steal credentials or install backdoors or abuse compute resources for cryptocurrency mining. And so, these happen for various reasons. So, sometimes it's because a maintainer chooses a weak password or reuses a password or maybe the maintainer gets malware on their laptops. This is also kind of not helped by the fact that NPM doesn't enforce 2FA for all accounts currently, although they are starting to enforce this for the most popular accounts. And finally, sometimes maintainers just get tricked and give access to a malicious actor. This is partially just due to the fact that maintainers are overworked and when someone offers a helping hand, it's sometimes hard to say no to the help. So this is also a big vector as well.

So now let's talk about some attack tactics. So what does this attack code actually do? As we mentioned, install scripts are a huge vector. Most malware is in install scripts. And so this is a quote from a paper we mentioned earlier. So most malicious packages, actually 56% start their routines upon installation, which might be due to poor handling of arbitrary code during install. So in the npm package manager, packages are allowed to just say, hey, when this package is installed, we want to run some code. And so unfortunately though, install scripts do have some legitimate uses. So we can't just disable them. It's not an easy problem to solve. So let's take a look at just an example. Another example of an install script, again, you'll see it right here in the package.json file, super common. The next is privileged API usage. So we see packages accessing the network, accessing the file system and accessing environmental variables. This is very, very common because when an attacker runs code, what they want to do is steal some secrets and they need the network to exfiltrate those secrets. So this is a typical example of malware that does that. So you can see here that it's making an HTTP request to an IP address, and it's sending some data. The data it happens to be sending is process.env which contains all the environment variables in the environment. And then here is actually another file that it includes, which is a different exfiltration technique that uses DNS instead of HTTP. So the way this works is it creates a DNS resolver, and then it does a... It gathers the environment variables, and then it does a DNS lookup with those variables as the subdomain.

So it's just another way to get the data out of the system. And finally, we have obfuscated code. So we took a look at an example of this earlier. So obfuscated code like this is just obviously it's really hard to see at a glance what it's doing, although there are tools to attempt to unobfuscate code like this. There's also another kind of obfuscation, which is attackers can publish different code to npm than they do on GitHub. And so you know when they do that, as I mentioned earlier, npm doesn't make it easy to see what code is actually in the npm package. And so a lot of people who are trying to evaluate a package will rely on the code that's on GitHub and there's no guarantee that that code is the same.

Okay, so now let's talk about how you can protect your app. So we asked ourselves this question when we were working on... My company was working on a product called Wormhole, which lets you share files with end-to-end encryption. And our goal was to try to build the most secure and private way to send files. So we did all the usual security things that we could think about. We thought about security early in the design process. We wrote tests, we enforced code reviews, and we were pretty thoughtful about the dependencies that we chose to use. But, you know, we still felt like we could do better. And so we started thinking really carefully about this problem and what we could do to make it better.

So the first kind of thing I recommend is that you can just try choosing better dependencies. You know, if you shift code to production, you are ultimately responsible for it. And, you know, as an industry, I think we need a mindset shift here because people assume that they can just install stuff from the internet and that it's going to be safe. And it's not necessarily true. And if you're shipping code to production that includes open source code, then really ultimately that code is part of your app. And so you are ultimately responsible for the behavior of that code.

And, you know, the most popular open source license, the MIT license, actually literally says this in the license, it says that the open source code is provided as is with no warranty of any kind and in no event shall the author be liable for any claim damages or liability. And so, you know, while this is legally true, most people don't think of their open source this way. And I think we really do need a mindset shift.

The other thing is very few of us actually read the code that we're shipping to production. And so we rely on other heuristics to help pick dependencies. So maybe, you know, we look at does the code get the job done? Does it have an open source license? Does it have good docs? Does it have lots of downloads and GitHub stars? Does it have recent commits? Does it have types? And does it have tests? And we're not really cracking open the code to go much beyond this. So what that means is that we're sort of not aware of what the code may be doing.

And so, we built a tool at Socket to help with this problem. So you can quickly at a glance get an idea of the security of a package. And so this is what it looks like. So you can go to Socket and look up packages to figure out what behavior the package has. And so in this example here, you can see that this package contains install scripts. And that's called out very prominently on the page. So it's the first thing that you see. And this package also happens to contain binary, you know, or native code, which means that it's not easy to audit the code. It's not like a human readable. And so both of these issues are called out. And in this case, it's not necessarily this is not a supply chain attack by any means. But it is nice that this is called out very prominently so that you can make an informed decision if you want to use this package or not. You can also see that we have very helpful quality scores that show up at the top of the page as well.

Now, let's take a look at another example. So this package here, Angular Calendar, is quite a useful package. It's a calendar component that shows up on the page and renders a little calendar. But if you dig into its dependencies, you'll actually find that some of its dependencies are doing quite invasive things.

So here, you'll see that one of its dependencies contains install scripts. It also runs shell scripts and accesses the file system and accesses the network. So this is probably not something that you would expect a web component to be doing. And so it may be worth a little bit of further investigation to figure out what's going on here before you use this package.

The other thing that we do that's quite cool is we can highlight when packages do these things, and put that directly in line in the code. So in this package here, I opened it up to take a look at the files. And I could see here that the module is accessing the network, as well as accessing environment variables. And I can see the exact lines where the package is doing each of these things. And so it makes it a little bit easier to get an idea of what a package is doing before you run it.

So if you want to research packages on Socket before you use them, this is the URL you can use. And I highly recommend you take a look at some packages there, and use that information to make an informed decision before you select a package.

Okay, the other thing you can do is think about updating your dependencies at the right cadence. So what do I mean by this? So there's a question about, like, how quickly you should update your dependencies. And this is actually a question we struggled with on our team as well. So if you, you know, you can think of it as should we update slowly, or should we update really, really quickly and aggressively? If you update too slowly, you're exposed to known vulnerabilities. And you're running code that's old and that you know, may have issues, may have some bugs that have been fixed in the newer version. And so there's some downsides to updating too slowly.

On the other hand, if you update too quickly, you expose yourself to supply chain attacks, because you're now running code that may have been published, you know, literally yesterday or, or in the last couple of days, which means that you haven't had that many eyeballs able to look at the code. And so, you know, if as you think about security, you have to balance, you know, this, this tradeoff, and there really is no perfect solution here. It's just a hard problem.

Another idea is to audit every dependency. So, you know, if you're building a truly security critical application, like we were doing with wormhole, then you, you know, one option is to literally read every line of code of your dependencies. So if we, again, put this on, on an axis of starting from full audit on the one hand, reading every line of code to YOLOing on the other hand, and, you know, by YOLOing, I mean, like doing nothing? How closely should you audit your dependencies? And what you see here is we're in the same situation. We have tradeoffs and really no good, no good solutions. So doing a full audit is something that only the biggest and richest companies seem to do in practice. It's a lot of work. Usually you need to have a security team looking at every one of these packages, and we also have to approve them one at a time and add them to an allow list, which is really slow. And this is expensive just because of the time and the effort that it takes. On the other hand, doing nothing and just installing whatever you want without, even looking at the code, has its downsides. So it means that you're vulnerable to supply chain attacks.

It's risky. And a breach or bad security press can be expensive, especially as regulators start to crack down on this issue more. And so this is another difficult trade-off. What do you do? And most teams, I think, are on the side of doing nothing, and, but I think this is just a hard problem.

So one thing that we tried to do when we were building Wormhole is to sort of think about, happy medium. Is there a way to use automation to kind of do something in the middle? And so what we want to do and what we've, what we ended up doing is using automation to automatically evaluate all of our dependencies. So we could use static analysis to look through packages to try to find malware, hidden code, typos, squatting attacks, and this kind of thing. And that way we can manually audit only the most suspicious packages. So we could spend our limited team resources looking at the code for the most suspicious packages. And that's the most high impact way that we could spend our time. And so this is, this seems much better to me than an all or nothing approach where you either audit everything or you just hope for the best and look at nothing.

And then the other thing we wanted to do is make sure that the security information was shown directly in pull requests so that the developers on our team were empowered to solve the security issues that they saw before they deployed into production. So what does this actually look like? So this is the bot that we created. It's implemented as a GitHub app that you can install on your GitHub repository. And whenever it sees that the package json file or the yarn.lock file has been modified, it will take a look at the new dependency that's been added and it will run a full health report against that dependency. And if there's any issues found in it, it will leave a comment with whatever the issue is that was discovered. So that way the developer reviewing the pull request can look at it and have their attention drawn to this potential issue. In this screenshot here, you can see that I accidentally installed the package browser list instead of browser list, which is actually a very easy mistake to make. And for that reason, the typo package actually has something like 700,000 downloads a year. So this is really, really helpful. This is the kind of thing that augments your review process. And it's very low cost since it only raises issues that are really worth your attention. And it runs automatically. So if you want to actually try this app out, we've actually published it for anyone to use. It's free. So you can install our GitHub app by just going to Socket.dev. And I recommend you give it a try and let me know what you think. It has a bunch of cool features. So it actually can block typosquats, which as I just showed you earlier, but also can block malware, detect hidden code, detect privileged API usage, such as the use of file system network, child process, etc. And also it can detect suspicious updates.

So these are updates that significantly change the package's behavior. So we have a whole bunch of things we look for in packages. We actually have 70 detections in five different categories. So we have supply chain risk, quality, maintenance, known vulnerabilities, and license. And we wrote, basically, these are just all static analysis rules that we wrote. You can kind of think of this as a linter in a way. So it's sort of looking at the package's code and then looking for these different problems. We tried to focus all of the rules on problems which are something that you, as a user of the package, really want to know about, and not things that require a lot of knowledge of the internals of the package. So the things that it finds need to be actionable to you as the developer choosing to use this package. And so that's what we tried to do in our rule development here.

So yeah, if you want to try this out, if you want to poke around our website and look at these different issues, you can try it out at socket.dev. And we have made it free for open source forever, and if you have a private repo, it's free while we're in beta, and I really do want people to give us a shot and share their feedback with us, because this supply chain security problem is big and only getting bigger. And I really do want the community to share their feedback with me on this. And I think together we can really do a good job improving supply chain security in 2022 and making 2022 not the year that the supply chain is destroyed, but rather the year that it's protected better than ever. So please share your feedback with me. There's my email and my Twitter, and also we're hiring at Socket if you're interested in working on this project and helping to secure the software supply chain. Thanks for your time.

Hey, thanks for joining us. Glad to be here, and I didn't mean to scare you. There's a lot to do, there's a lot of solutions, so I wouldn't be too scared. I think we can solve the problem, hopefully. Hopefully, well, most people are very concerned and want to do more. Well, it's good. I feel happy that people want to do more, but they should do more. Well, they can do so with Socket.dev. How do you feel about this? This deviation, 70% and then 27% moderate, and 3%, not at all? I'm actually pleasantly surprised that we have this many developers who are concerned about the issue. Now, I don't know how much my talk influenced their voting as they were watching. I was probably helping push this number up by all the examples I was going over of malware and supply chain attacks that have happened on NPM. But I think it's encouraging that people want to do more and that there are actually some things they can do to help with that, including installing Socket or checking out our tools. Yeah.

So, first question is from myself. There's multiple security scanners. I know from the top of my head, we have StackHawk and we have Sneak. And what sets your product apart? Yeah. So, I think the main thing to keep in mind when evaluating tools like this is if they will protect you from just vulnerabilities as well as malware and supply chain attacks. So, it's almost like a standard. I would say that there are tools to scan for vulnerabilities. That's what NPM audit does. That's what Dependabot does. There's a lot of stuff out there that does this kind of, I would say basic vulnerability scanning. The real threat that we've seen in the last year is from this new type of attack, supply chain attacks that involve usually a package being hijacked and code being added by a bad guy. And there's this period where before that is discovered, anyone who installs that hijacked package is going to have their computer compromised. And if you're really unlucky, this isn't discovered for a couple of weeks and it makes it into production. And this has happened in many cases in the past. And so I think the way we want to distinguish Socket from all the other stuff that's out there is what can you actually do to scan a package by looking not at some database to say, has a security researcher found a problem with this and written a report about it a couple of weeks ago, the question is really, what is this package going to do? Like what are its capabilities? Is it going to talk to the network and is it going to read files and we're going to analyze the actual code in the package before you install it to answer those questions for you? And so that's really the difference. And that's where I think we need to go with all the tools in this security space.

And a little bit related. So I don't remember the name of the package, but there was a really popular package, and a month or two back, the author pulled it from GitHub and said, free Aaron Swartz, something like that. Do you remember what I'm talking about? So yes, this will be also caught because you have a significant code change, right? So also catch those issues. Yes. It's not enough to, this is a perfect example actually, where a lot of the approaches that other companies and other teams who are trying to solve this problem are taking wouldn't have really caught this problem because this is where you have a maintainer themselves adding malware or bad code into their own package. And so relying on things like code signing, for example, would not have really done anything in this case because the maintainer himself would have had the keys to sign his code. Or if you're looking at a vulnerability database, this is not going to be in a vulnerability database. And so, sorry, I'm getting a phone call right now. Yeah. So anyway, I think that incident was actually really illustrative of the challenges with the other approaches and why really what you want to do is get into the actual code and look at what it's doing. Yeah. I used to work at a medical tech company. And then it was always the scenario if you do an update, then you actually would have to read all the code that was new. And yeah, so I tried to avoid any dependencies because well, that's just too much work to read everything that's new in all your dependencies. So yeah. But yeah, having security scanners would help a lot.

The first question is from Will Shadow real address some of these issues? So I think realms are an interesting proposal. And I think they've been making some pretty good progress through the standards committee. Although I'm not really following it very closely. So I might not be the best person to ask this question to, but my understanding is there should be some way to use this feature, this realms feature to kind of sandbox code. And I know it's really tough to get a sandbox to work really reliably, but if this feature works the way that I think it does and if a bunch of asterisks attached to this statement, we may eventually be able to use a feature like this to go beyond basically just analyzing a package and saying, OK, this is going to talk to the network or this is going to talk to the file system. But actually at runtime, being able to say for a package, this package declares that it doesn't ever need to talk to the network and in fact we're going to actually enforce that at runtime. We're going to make sure that it doesn't do XYZ behavior that it doesn't need. And so if it suddenly starts to do that, then we'd be able to block that. I think it's also interesting to look at deno and see how they do their command line flags where for those who've played with deno a bit, it has this sort of idea of like allow fs, allow net that you can pass on the command line that's pretty interesting. Although that's pretty much for an entire process and not on a per package basis, which kind of makes it less useful for stopping supply chain attacks, because usually you have to allow the network if you want to build a web server. And so it doesn't really give you much protection if one of those dependencies gets compromised. But it is an interesting place to go from.

Yeah. All right. Thanks. We have one more minute. So it's from a hill to the wood. What would you suggest for getting engineers to care about securing our dependencies? I feel like because no one reads the code, etc, they will only care when something already goes wrong.

No, it's a really tough problem. I mean, it's really difficult because, you know, engineers are already there's so much to do. There's always technical debt to fix. There's so much of a backlog and we're just trying to ship features and get our jobs done. And so it's add another thing onto the plate of developers is asking a lot.

I think one argument I would make to those developers to convince them to care is that, you know, ultimately we're craftsmen and we have to be, I guess, craftspeople. We really have to care about like the work that we're creating. And we should have pride in the software that we create and that we ship to production. And part of that is really making sure that the code that we ship behaves as intended and doesn't compromise our user data or compromise our users in any way. And so, it's really part of the responsibility of being an engineer. And with the right tools, and I'm biased but I think Sockett's trying to do a good job here, you can make it not so difficult and so onerous on the developer and make it something that's kind of fun to do as part of the development process.

Yeah. Well, actually, security, if you come to think of it, it should be after maybe accessibility. No, maybe even before accessibility. It's the most important thing. It's more important than your fancy command line settings. It's more important than your 60 FPS animations. It's the most important thing. Yeah, that's also an answer, I think.

Well, we are out of time for Q&A, but Feroz is going to be in a speaker room on spatial chat. So, you can click the link in the timeline below. Feroz, thanks a lot for scaring us and entertaining us. It's been a pleasure having you. Yeah, thanks Mateen. I appreciate the good questions and it's been an honor to be here. So, thanks a lot. Appreciate it. All right, bye-bye.