Mackenzie Jackson: Hey everyone, welcome to another episode of The Secure Disclosure. David, I'm so thrilled to have you here and joining me today.
David Mytton: Thanks for having me.
Mackenzie Jackson: I kind of just want to get stuck straight into it. You're a bit of a serial entrepreneur. You've been involved in a lot of different companies, a lot of startups, both as a founder, but also in large enterprises managing things. You're now building Arcjet. This became something that you felt was needed and wasn't there in the market. At the time, this is pre-AI, just as AI is starting, 2023.
David Mytton: Developers have this terrible reputation of not caring about security, and my theory was it was because the tooling was awful. Developers have had an amazing five years because of all the amazing cloud platforms. The developer experience, they've had the best tools, particularly in JavaScript, but certainly everywhere else as well. They've had the best tools, and then when you come over to security, it's just, "Oh, you've got to download this random thing from some person's GitHub," and then it's Python 2 and all the dependencies don't work, and you've got to try and figure out.
Mackenzie Jackson: I can't relate.
David Mytton: Yeah. And I thought with developers pushing code to production, they should be able to have the same experiences as Vercel and Netlify, but it should be the same in security as well. And the idea was to provide all these building blocks that solve developers' production problems, like if they're getting spam signups, personal information shouldn't leak out of your system. You need to implement a lot of rate limiting algorithms and have them distributed globally. Those kind of problems should just be a drop-in library. It solves the problem for you. And then developers can focus on building customer features, not trying to stop all the spam signups that they're getting. So that became Arcjet, and it started in 2023. I'm really focused on developers, and the building blocks have worked, but the theory that developers were going to use it has not played out. It's agents implementing it now. It was AI, 12, 18 months ago, just the coding it, coding the CLI. But agents are implementing the product, and we're seeing that as opposed to web technology protecting websites, which is where we started. It's now protecting agents doing things where the chatbot is the entry into the workflow, but actually all of the risk is behind the scenes, like the database it's calling or the email it's sending. And so that's where we're seeing the product.
Mackenzie Jackson: Yeah. So it has changed a lot. So it's almost like you were protecting against bad actors, malicious actors. You're also now protecting against rogue AI agents.
David Mytton: Yeah, that's right. Agents doing things that they have the permissions to do, but they shouldn't do at that moment in time. Like you can send an email, great, but can you send an email to a particular recipient, and what should that email contain? Those are the questions that can't be solved by static policies anymore.
Mackenzie Jackson: I always laugh because I always wonder how long it's going to take me before I go off track for my questions. In this case, one question was what it's taking. So I have one to go somewhere else now. But something that's made me been thinking about a lot, and I think you're touching on it here, is we have this idea of non-human identities, and we've had API keys for machine-to-machine communication for a long time, and we've been able to obviously limit an API key, but we've also been able to limit the function of what it can do. Now we put an agent in there, it's also a non-human identity, because it's not human, well, for the most part, not, but it's non-deterministic, so it can do weird stuff with the same credential. So now an over-permissioned key, which was bad if someone else found it, is now terrible because the thing can use it. How do we, what's your opinion about this identity, managing identity and agents? And is your solving kind of what they're doing? How do you see us coming up with some new form of authorization and identity for agents, or do we just need to be better at controlling them? I don't know.
David Mytton: I was wondering where you were going with that question because just talking about API keys, we could spend a lot of time on that, because API keys are just the worst because they live forever.
Mackenzie Jackson: Yeah. Yeah.
David Mytton: The challenge is that all the permissions models have come from this world of humans having permissions, and they're not granular enough. Think about your inbox. You've got read/write access when you go through the Google OAuth flow, and there's no more granular permissions, like, "Okay, I've got read access." That limits quite a lot, but it means you can't do anything with the emails. So really, you want to give the agent write access. But what does that mean? Now it can delete all my emails. Can it delete emails from a certain period of time? Can it organize things? Can it add tags? Can it retag emails? Can it send emails? Maybe it only wants to send emails to my domain. Send emails to me, send emails to my close contacts, my exec team. There's all these different things that that span off from the permissions question, which just hasn't been answered at all. And none of the existing systems can handle that. You need really fine-grain authorization, which is what it's called, but nobody has that today, because it's coming from the world of humans. And then you need the session token to really be for a session. Think of OIDC. When you connect something to AWS from GitHub, for instance, you can push a build to the container registry using an OIDC identity that exists just for that build flow, and it's entirely scoped, and then it disappears. And that's the kind of thing we need for the agents. The OIDC equivalent. And then you've got the thing about certificates. Can you permission certificates within an environment? And certificates are such a nightmare. Anyway, I remember the world of 15 years ago, where I was generating the certificate using OpenSSL on the terminal to give it to Apache, and it was a static SSL certificate for the next year. And now we need a certificate that's for a specific agent that's doing something in the next four seconds.
Mackenzie Jackson: Yeah. Yeah. It is such a crazy world when we're talking about timing of how long these things live for. And dynamic secrets have been around for the longest time, but the people actually utilizing dynamic secrets properly at scale for things is probably just HashiCorp, maybe.
David Mytton: Yeah, secrets seem to be or continues to be an unsolved problem.
Mackenzie Jackson: Yeah.
David Mytton: It's only very recently that AWS has really cracked down on generating the account level secrets that you can use to access the API. You can still do it, but they really push you towards the CLI and SSO and all those things. And it's still standard just to provision the key that you use, like you use an LLM on OpenAI or Anthropic, and you get a key, and you put the key in an environment variable, and it just seems so primitive.
Mackenzie Jackson: Yeah. Yeah. We could go down here for ages, but I've got to try and wrangle it back into a little bit. We're kind of joking as we're coming in here is that Arcjet is, you can correct me if I'm using the wrong terminology or that, but I kind of think of it as some kind of firewall or something that lives inside an application rather than a WAF, which sits outside of it. It's actually looking at what's happening. It's seeing where the sinks are. That's why it can be effective with an agent out there. What do we like? Is that correct? Let's start there. And what do we call it? Because there are names out there, but none of them seem to be good.
David Mytton: Yeah. So we say "application native" to describe how it's in your code. Yeah. It's AI agentic security. So we're trying to get quite granular. And then I'd like to mention runtime security, because we're not in the coding agent. We have visibility over the coding agent, and we can hook into it, but really we're about the application once it goes into production. And so it's deployed in your cloud or wherever we happen to be deploying it, and we set in the code the flow of the execution of a workflow. So if you think about the coding agent context, you've got a chatbot, you type in what you want it to do, and then it goes off and does a lot of things. It might visit a website, might read your files, edit files, might make a database call, and then it comes back to you. Most of the activity there has happened not in the chatbot. And that's what's happening when people are building agents and they're deploying them into production. You might have an email that comes in and it's got an invoice. It's like an AP email address, and it's going to pass the invoice. It looks at your internal database to find the supplier and the information about that invoice to validate it. Then it could create a payment in your ERP. And you can see all of the risk points in that. And Arcjet sits at every single one. So in that flow, you might call this five times for the prompt injection, for the email, for the result from the passing of the PDF to make sure it didn't have indirect prompt injection. Then when you do the database call, you want to make sure it hasn't pulled out payment information. And then when it's creating the payment using an internal tool, you want to make sure that the tool parameters it's called with are within the bounds that you expect. Like it's not only create a payment for a trillion dollars, for instance. Yeah. And so that flow is where we sit in the application.
Mackenzie Jackson: Yeah, that the application native part really kind of makes sense. And I think that's because sometimes when you try and talk about this, you kind of go to, "But doesn't that isn't that what Cloudflare does?" I'm sure you I'm sure you've never heard that before.
David Mytton: No, no.
Mackenzie Jackson: But there's so much that's kind of missing from that context that can exist now when you're in here.
David Mytton: So the traditional Cloudflare model is on the network, and they want you to have all of your traffic going through them. So they can apply their rules, the WAF, the bot detection, and then they pass the clean traffic onto the origin, onto your servers. And the network level is a great place to do general analysis. That's where the DDoS protection comes in. You just don't want that traffic, generalized attacks, looking at the last stage of data loss prevention. But it doesn't have any of the application context on the network. You can't see who the user is. You don't know their pricing plan. You don't know they've just paid an invoice or they've just triggered 2FA, and so they've got an elevated permission set. And you can't change the flow of your application logic based on the security results. Like you know that the user normally logs in from the US, but suddenly they've changed their IP address, and that IP address is associated with malware for the last 15 days. It's a brand new IP address, but it's got this threat signal. And once you bring all this data in, you can start changing the logic of your application, and you can build it into the development side of things, and that gives a lot of extra power to developers. And then you have all the visibility on the platform for security teams to apply policies to make sure that their compliance requirements are met.
Mackenzie Jackson: Part of this is kind of like a last line of defense in security too for a lot of things, right? When you're working on that, obviously you want to have good security throughout the process, but then there's this kind of this last last line of defense. I'm curious what you're thinking about with kind of AI coding agents and the area is that I feel like if I take my optimistic hat on, I feel like we're going to get a lot better at certain security things. Like I feel like we're going to get better at SQL injection. My biggest gripe is that we solved SQL injection the same year we found it in 1997, and for whatever reason, it's still like 15% of vulnerabilities that we find. So I'm kind of optimistic with AI coding that we will eventually get to a point where at least it will be very dramatic, and where it does exist, it'll be extremely complex chains or something like that. So, if we can get better at all of this, do we get to a point where this type of this type of system in there isn't necessary? Just to kind of throw a really mean question at you. Or will we always have problems, and where, and I guess what I'm also trying to ask is, where did the problems move to if not serverside request forgery, SQL injection or something like that?
David Mytton: I think right now there are too many security companies, and now is a very interesting time to be building a security company because there are lots of novel attacks. But I think my prediction for the next 12 to 18 months is a massive explosion of vulnerabilities, CVEs definitely, but AI assisted attacks, maybe like the OpenAI Hugging Face one, that is a cool one to read about. I think that will become more common just because systems are being written by humans, and humans are not perfect, and there are a lot of vulnerabilities that haven't been discovered. So I think that's going to be an explosion over the next 12 to 18 months. Post that, I think it's going to decline because the holes are going to be found and fixed, and then new code is going to be written by AI that is good enough that it's not going to introduce SQL injection. It's not going to introduce these trivially exploitable problems. I don't think the zero day is going away, but I think it's going to become more like the airline industry where crashes are incredibly rare, and it's never one thing that goes wrong. Like you say, it's a chain. It's all these things that come together in one unique situation that has never been seen before and will never be seen again probably, but it resulted in the crash of the plane. And I think we'll probably see those kind of things happening, and that will reduce the need for security companies. And I think this is a big question for the industry. It's like you walk around Black Hat, and there's just so many companies, and rounding up to 100% of them are now AI security, and that can't continue. And I think there will need to be a consolidation and a rationalization of what security vendors mean, what they provide, what they do, not necessarily just it's all going to be one or two big mega companies, but the types of vulnerabilities that you're talking about, just protecting against SQL injection, just won't be necessary. And there will be questions around permissions because that's not a security vulnerability, although it could be, you'd write it up as one. It's really a configuration problem, and that can be solved, but you'll still need permissions tools to make sure it works. So some features that we have today, like you have a WAF, in Aikido we have a WAF component in Arcjet. I think the necessity of that will just disappear, and maybe it will just be the last thing on the PCI compliance checklist that you have to have. You don't really need it.
Mackenzie Jackson: It is interesting what you're saying. I'm not sure how public I should talk about this, but I'm going to. One of the components that we built at Aikido is malware detection specifically for supply chain attacks. It's our endpoint detection, because it's gigantic at the moment, and it's one of the biggest threats that we have right now.
David Mytton: I think this product will exist and be necessary for a long time, but not in the way that it is today.
Mackenzie Jackson: Yeah. You're building a product knowing that this can't be normal, so something's going to have to change, and it is kind of changing. NPM is now doing malware scanning and other areas like that. Short-lived to long-lived tokens are dying. So things are changing. So hopefully we can get on top of this particular problem. So it's a strange feeling when you're building a product that's extremely relevant right now, knowing that it's probably going to become less relevant. It's a bit of a weird kind of...
David Mytton: I think that's right. And you have a pretty big portfolio of different products, and I think that's the future of security tools. Like we have six or seven different building blocks that handle things from rate limiting, pretty straightforward, through to PII detection, prompt injection detection, which are more complicated to implement. But that's going to evolve, adding new things all the time, you're building out things all the time. Things will, it's not like you're going to shut it down or deprecate it, the usage will just gradually decrease.
Mackenzie Jackson: Yes, exactly. I think I can totally feel that. And I think it's probably nimble companies that survive, and the big boys will struggle to reinvent themselves because it really feels like you need to reinvent yourself every six months at the moment. It's pretty exhausting.
David Mytton: AI agents didn't exist 12 months ago.
Mackenzie Jackson: And then every time Claude posts a tweet, you go into two weeks of crisis, like what does this mean? Yeah, absolutely. Things are moving very quickly, and it's like a pendulum. It's like point solutions. Everyone buys 100 different tools because you want the best one. Now it's more you want the platform that can have a full understanding of the context of your application and business, and the tools themselves might not be the best, but you go back towards that point solution. Now there are too many security vendors, and I think it's time that we come back, maybe for the last time, into the bigger platforms.
David Mytton: Yeah, look, no one knows what's going to happen, but it is crazy. Just mentioning Black Hat while we're here. My claim to infamy, not really because I think three people probably read this, but I remember coming to Black Hat, I think it might have been 2023, or it was the last Black Hat before ChatGPT was released. So GPT was released that November. So it was three months. And I went in there, and every single vendor was AI security then, right? But no one could explain to me what their AI was. "What is it? Is it 400 if statements?" Like, what is the AI? Because you know, we all kind of knew it was coming. So then I wrote this article called "Black Hat, More A Than I." So more artificial than intelligent. And I wrote this whole thing about how it doesn't actually exist. And then like two months later, TPT was released, and I was like, "The most wrong article I've ever come up with."
Mackenzie Jackson: It was right at the time. It was right at the time. Look at the timestamp on the article. That's the key.
David Mytton: Yeah. It's just what we have now with AI agents is the same as we had with cloud a decade ago, except now there's like 10 times more money in the market. So everyone can adopt the best amazing branding and have the best booth at the conference. But you see companies that were founded 15, 20 years ago call themselves "AI native," which can't be the case. What do these things mean? And there's more marketing than substance, and I think that's going to be part of the consolidation of the market.
Mackenzie Jackson: Absolutely. I really think you've nailed it there.
Mackenzie Jackson: I'm going to briefly interrupt this episode to thank our sponsor of the podcast, Aikido Security. Aikido Security is your complete code-to-cloud security solution. It secures everything from the first line of code that you write all the way through your supply chain, your dependencies. And of course, Aikido is also a leader in AI pentesting and AI code auditing. So, make sure you check them out today. You can start for free at aikido.dev. All right, enough about that. Let's get back to the episode. I do want to talk about cloud though, because in 2009, you also were a founder of another company that was really on the cutting edge of the cloud space. And what I'm finding interesting is, and that was another big revolution where attack vectors changed, new vulnerabilities were discovered. You know, like the APIs and everything, everything kind of shifted then from it. Are there similarities between what we're dealing with now and kind of what we went through? And how close are those? And then I kind of want to ask later on is like, what mistakes are we doing the same now? But you know, does it feel similar to you?
David Mytton: I think so. It's just the size of the market is larger just because there are more people online and more applications deployed. Cloud 2009, that was just a couple years after AWS, and so you had S3, you had EC2, you had EBS, but no solid state storage, so things were very slow. You wouldn't run a database in the cloud. That was the funny thing at the time. And now you wouldn't run a database anywhere.
Mackenzie Jackson: Yeah.
David Mytton: So I think we're seeing it's the uncertainty. It's new technology. It's a new way of doing things, but it has changed everything that was standard for the last 10 years. And I think that's why this is an interesting time to be building things, but it's also the most dangerous time because what you might build is going to change so quickly. And AI does introduce a new threat approach, which is just non-deterministic actors that can move at machine speed, which we haven't seen before. We've got machines moving at machine speed, but they do what they're told. And now they are kind of like a genie, and they kind of do what they're told, but it's not necessarily what you expect, and they'll do different things as a result.
Mackenzie Jackson: Yeah. I mean, the Hugging Face, I've talked about it so much this week. But that is such a good example of this, of like there was no malicious instruction. There was no malicious intent. There was just malicious, well, not malicious, but just damaging outcomes from that whole thing. So...
David Mytton: It did what it was told to. It's like the Midas touch, like you don't want to turn your furniture and your food into gold. It's an amazing thing to have to be able to turn things into gold, but when you're trying to eat, it's a real problem. And I think this is similar with AI. When it has no guardrails and it's been given a particular task that could have dangerous outcomes, then that is the problem. It's going to it's going to achieve its goal. It's going to do it in a way that you didn't expect.
Mackenzie Jackson: It's terrifying sometimes what the agent can do. And it's also very interesting of kind of like this idea too of these synthetic insiders in applications and things that if you can give them a malicious prompt, they do. And we had another worm, NPM worm, Shahalude yesterday, that all started with an attack called Singularity. It wasn't a worm then, but it was the same actor as the original Shahalud went through, and they did secret scanning, but they did it with an agent if it was on your machine. It sucked, and they moved to Travelhog later, because it was better at finding secrets. But I found it so interesting. It's like, "Wow, here's a malicious dependency. And part of the malicious dependency is giving an agent that's on your infrastructure an instruction that's ultimately malicious," right? And it's using a tool like Traveler Hog to find things in the opposite way that Traveler Hog was designed for.
David Mytton: Yeah. And I think that is the Shahalude stuff is exploiting the trustworthiness of the 90s, basically, when the NPM came about later than that. But it's the philosophy of the internet of the 90s and the early 2000s, where there weren't many people online. You could basically trust everybody, and there was nothing encrypted, and it was all, everything was fine. But when you have billions of people online, that is no longer the case.
Mackenzie Jackson: Yeah. And you can't trust, and being able to execute scripts on people's machines automatically is a terrible idea in retrospect, but you can see why people wanted to be able to do that, which, I mean, and a lot of people will say, I've got to get off this path. I'll say one more thing, then I'll go wrangle back, but, you know, a lot of people say, especially last year when this was first starting, everyone's kind of like, "Why doesn't NPM do this? Why doesn't NPM do that? Why don't they change it?" And to be fair to NPM, they have done a lot of it, but also a lot of it was because it goes against the whole core philosophy of when NPM was created, which is, you know, the JavaScript ecosystem became one of the biggest ecosystems for multiple reasons, but one of it was that NPM existed, and it was the easiest place to publish stuff online.
David Mytton: Yeah, that ease helped grow that ecosystem, which was also what made that ecosystem so fragile to those types of attacks.
Mackenzie Jackson: Right. And now you've got hundreds of billions of downloads a day of packages that rely on all of these old features. And many of the packages are not actively maintained, or they are maintained by open source developers who don't have the time to keep up to date all the time with every single tooling change. And it's just, it's just a shift in the industry. It's just being mature as an industry that the IT industry and tech in general has come from just a few computers connected at universities to now everybody's connected, and every device is connected, and now we've all got 10 agents doing things.
David Mytton: It's chaos out there.
Mackenzie Jackson: I was coding the other day. I was building building something for a workshop, and I just had like four terminals open, just basically saying yes to all of I was like, "This is all my life."
David Mytton: I just need to put it in auto auto mode. Let the AI decide what.
Mackenzie Jackson: I had put it on there, but then it started registering domains on my AWS account, and I was like, "Okay, we're going to make some cards out."
David Mytton: Yeah, just let the AI decide what the AI is going to do. It'll be fine, probably.
Mackenzie Jackson: I was just like watching it. I was like, "Wait, hang on. What is it doing?" What? Like...
David Mytton: You see the invoices coming in.
Mackenzie Jackson: Yeah. Yeah. I honestly struggling to stop, to keep this conversation on track because I I I kind of want to go on forever, but I try and keep episodes to around about 30 minutes. So we have to kind of move on a little bit. And there's one thing that I was fascinated about you that I really wanted to touch on. And so you have a PhD in sustainable computing.
David Mytton: Not quite. I was doing the PhD.
Mackenzie Jackson: Right. Okay. You have almost a PhD. I have almost a I have almost a masters. So, nice. Okay. Great. But I'm definitely not going to go back and finish it. So, but you were researching, let's just say, in the in the space of sustainable comments.
David Mytton: Yes. Sustainable computing. Yeah.
Mackenzie Jackson: How's that going with the AI revolution? What's your thoughts on that? Because this one really freaks me out, especially, you know, I think you're based in London. I'm based in the Netherlands, so it's been a pretty wild summer. How do you feel this is going to evolve from the AI revolution? Like, and can we make it sustainable, or like what's your thoughts on this?
David Mytton: Yeah. Well, I started the, I did a masters at Imperial in London, and that was in environmental technology. It's a very broad read, everything from fisheries management through to disease vectors and energy systems. I specialize in energy systems. I thought it was interesting. I thought it was relevant. And that's pretty broad. It's everything from the grid through to how electricity works. And when I started, there were basically two research groups in the world, probably 20 or 30 people doing research into data center energy and the efficiency of computing systems. And so there's not many people, but data energy every so often would come up in the media, particularly related to video streaming and how watching Netflix was killing the environment. And I had a lot of fun debunking these by doing the actual research to figure out that it's not, it's not a problem. And then moved to the PhD at Oxford in engineering science, and looking specifically at cloud computing and the goal really being that we can use more computing whilst reducing the environmental impact. So I published a few papers, and then they've become some of the most cited papers in the industry because of AI in particular. And whilst I did a lot of work on energy, I also looked at water consumption, which was fairly novel because it's very difficult to find anything out about it. The companies are very secretive, and that's the main challenge. Water consumption and energy consumption are similar in their resource consumption. But with energy, the goal is net zero carbon. Everyone can understand that. Is fairly easy to understand. With water, that's not necessarily the case. The water consumption is always local. And if you're in a region where there's a lot of water available and there's no water stress, you have good infrastructure, then water is not a problem. And you can balance off the water consumption with energy. Because as you reduce water consumption, you increase energy consumption in data centers. Whereas if you're in a region that has a lot of stress and the infrastructure is not as good, then water can become a real issue. And there's a lot of hype and a lot of politics involved now because data centers have become a proxy for the AI industry, and another way to say that you don't like AI essentially. And the good news, I think is good news, is that data centers don't use a lot of energy and they don't use a lot of water. Agriculture uses far more water. It's 80% of water consumption in the US is agriculture.
Mackenzie Jackson: Wow.
David Mytton: Whereas data centers is less than 1%, and there's more water being used to grow almonds in California than there is in the overall water consumption of data centers globally. Energy is an issue though in two ways. The energy is increasing. Energy consumption is increasing. It's going to be between 6 and 12% of US electricity consumption is going to go to data centers over the next five to 10 years. The top of the range is what everyone always cites. My expectation is it's going to be the lower end of the range because that's what's happened historically because the companies don't just use exponential amounts of energy because it would cost them a huge amount of money. They're incentivized to reduce their energy consumption with more efficient systems. And that is what we're seeing already. But it becomes a big big thing when people think that it's using huge amounts of water and huge amounts of energy, and that's not the problem. The real problem is the grid is old. It doesn't grow quickly because it's designed for reliability, not for bringing on new data centers in 12 months. And the grid capacity, particularly in the US, is a big challenge, is a challenge in Europe as well. Compared to somewhere like China, they have the advantage of not having democracy. They can just do what they want. Whereas in the west, we have to actually involve people, which is a plus and a minus depending on what you're trying to do. But it means that the grid in the US is under strain because it takes a long time to build new capacity.
Mackenzie Jackson: That went in a direction I wasn't expecting. That's great. It's, but it's, I think that's part of the reasons why I love this podcast that you learn so much, so much interesting things. And yeah, you are, you are right in the sense that like all the problems of the data centers are absolutely amplified because of the anxiety, the stress, but all around all of it, not just kind of the AI models itself, but the development of these kind of oligarchs.
David Mytton: Well, it doesn't help that they're saying they're going to take everyone's job. They need to be a bit more positive about the benefits. That might be a risk in some places, but people don't want that, do they? They don't want machines to come and take their jobs. And there's no way they can't see the cloud, but they can see a data center. And I think that is going to be, that's the political challenge in the west, is demonstrating that data centers have benefits, and they can be a good part of the community if you do them in a way that engages the community. They use the resources appropriately. They're careful about the water consumption. The data centers don't want to be the villain in the story, or they don't want to be the biggest user of water in a particular region because that is very negative for their PR, and they care about PR. They're just not doing the best job, but...
Mackenzie Jackson: One of the, one of the interesting things is, you know, there's a few people, a couple in particular, they're talking about data centers in space and things like that. And I mean, the interesting thing is physics 101 is that kind of heat is very hard to deal with in a vacuum. But the solution to that is having chips that can overheat and areas like that. Could that be a potential solution? Because the water's used for cooling. If we don't need to cool these things down so much, could that happen? Or would that help? Would that create other problems? I'm just curious as someone that kind of knows about it. Could we end up in a position where if water is kind of one of the main issues in the areas, at least perceived to be, that we don't need so much of it because we're able to operate at much higher speeds?
David Mytton: Yeah, I think data centers in space, the reason why that is happening is because of the inability to build the grid infrastructure in the US. And it's a lot faster in some people's mind to build a data center in space, particularly if you already own the rocket company that's going to launch from there.
Mackenzie Jackson: Who are you thinking of?
David Mytton: I think it's a, it will be an interesting option, and I don't think it's going to replace Earth data centers. But I think it will be a way to get around some of the political challenges and then the physical challenges of building out the grid. But there are engineering problems to be solved. Like in a physical data center on Earth, you use air to transfer the heat or use water inside the inside the servers themselves. But the water, the water consumption of the of the liquid cooling is negligible. It's almost zero because it's a closed system. So they bring the water in once, and then they don't have, they don't bring it in again. It's just, it's just a closed system. With the evaporative cooling, then that can bring in, bring in water. But the water consumption, the water footprint of a data center, the majority of it is not in the data center itself. It's in the energy generation, because the energy is being generated by heating up some kind of turbine.
Mackenzie Jackson: Yeah, it spins a turbine of some kind, right?
David Mytton: And that's where the water consumption is. It evaporates into into the atmosphere. But it becomes, it's too difficult to conflate water consumption. Like if it's powered by hydroelectricity, that's renewable, but it uses a lot of water. So that increases your water footprint. But if you think about it, you wouldn't necessarily think, "Oh yeah, hydro power, that's really bad because it's using all the water." But that's not how people think of it. But that's how it's become, how it's become to be seen because of this narrative around data centers.
Mackenzie Jackson: Now I could talk about this all. I could I could go on for hours with this, but I have to, we're going to have to wrap it up. And maybe I'll just have to try and convince you to come back on to.
David Mytton: Yeah, we just do an episode on that.
Mackenzie Jackson: Yeah, I think we could have done three full episodes on different topics today. But this is like a teaser for the future episodes. Sounds good. But I do like to finish up on a game here. And the game is called Would You Rather? And basically how the game works is I give you two options. Both options absolutely suck. And you have to try and pick pick one of them. For the first one is, okay, you have an application that you're running, and you have a couple of options. The first option is that you can run the application with absolutely no firewalls. So you can't have your in your firewall in the application. You can't have a WAF. Or the alternative is you can have all of that, but all of your secrets are in a .env file or inside your Git repository, which is private, but it's in the Git repository.
David Mytton: Okay.
Mackenzie Jackson: So you got the risk of leaking secrets through code, or you have the risk, or basically you have to, you have a nightmare trying to maintain and build an application with no protections against malicious traffic and payloads and whatnot. Which would you rather?
David Mytton: I would rather have the secrets inside the Git repository. So I was just as you were describing, I was thinking through what's the probability of leakage of both, like leakage in terms of secret.
Mackenzie Jackson: Yeah.
David Mytton: Or some vulnerability. Now if the application's built in, I'm not going to name a specific language or ecosystem because that would annoy people. So if it's built in a particular ecosystem and language, then it may be more vulnerable than if it was built in another one, for instance. So, maybe if we were a Rust shop, then I would have no problem, right, deploying something. Whereas if it was, maybe PHP, then it might be a problem. But I think the chances of having a vulnerability unknown in an application that's deployed and all of the dependencies that you're going to have is much higher than the secrets being leaked. But probably the secrets being leaked is inevitable. So these are not good scenarios.
Mackenzie Jackson: I kept my promise.
David Mytton: Yeah. All right.
Mackenzie Jackson: Another one here. You talked about dependencies there. So dependency one. All of your dependencies are pinned to the latest version today, and you can never upgrade them again. So when a new CVE comes in, you just have to try and deal with that. Or you auto-pull the latest version the moment it comes in. So if any malware or if anything happens in there, so not just the risk of your application breaking, but also the risk of malware coming in and taking off. Which would you rather?
David Mytton: I definitely rather pin.
Mackenzie Jackson: Really? Yeah. Oh, hey.
David Mytton: That's what we do. We do update. So that's not in your scenario, but we also pin, because then you have at least control, and you're not you're not going to have some vulnerability come in. And also, when your developer, and maybe in this scenario, you don't have a lock file. So your developer is running npm install, which is not what you should do. You want to run npm ci. But if you're running npm install, then every developer is going to have a different version of the dependency on their system, because dependencies are updated at a ridiculous pace. And I think that would be very annoying for a development environment because stuff would break all the time. And you're going to have vulnerabilities coming in.
Mackenzie Jackson: Yeah. Yeah, definitely. This one here is that so a lot of them don't have a good answer. I've always felt that this one was the correct answer. I did have another guest that gave the opposite answer.
David Mytton: Why?
Mackenzie Jackson: And I I agreed with his rationale. I don't know if I agree with it, but I agreed. He kind of said, he said two months ago he would have said to pin them, but now the problem is that the time at which a CVE is exploitable with AI is almost like no time. So then like the risk of that becomes exponential now, where he said before you could have mitigated it, right? You have a CVE, okay, I can't update the dependency, but I can build around that to try and limit whatever it is that that CVE is. But the time that it will take to do that, the CVE is like well and truly exploitable.
David Mytton: That's true.
Mackenzie Jackson: I don't know if I agree with it, but it was like an interesting...
David Mytton: It's true that often the platforms collaborate with the disclosure process, and they'll announce the vulnerability at the same time as the platform saying, "We've patched it," or, "We deployed a rule," or whatever it might be.
Mackenzie Jackson: So maybe.
David Mytton: Yeah, look, no good no good solutions at all.
Mackenzie Jackson: We'll do one more. This one's a bit of a silly one, but would you rather use one password for absolutely everything? Not OnePassword the product, but just a singular password for absolutely every single account that you have, but it can be complex. Or you can have different passwords, but you have to store them all in Notepad on your phone.
David Mytton: Is the note locked?
Mackenzie Jackson: Well, it's on your phone. So your phone is locked.
David Mytton: Okay. Is it synced to the cloud?
Mackenzie Jackson: I'm going to, yes, it's synced to your Apple account or whatever. Yeah.
David Mytton: Yeah. I'd probably probably go with having different passwords but in a note, because I think the security of the, let's say it's Apple, good security, it's probably more secure in a note, even if it's a plain text note, than having one password, because how many accounts do you have? You might have at least 10.
Mackenzie Jackson: Yeah, add a few zeros to that.
David Mytton: Especially if you've been on the internet as long as, I just, they've all, like everyone gets those I've been pwned notifications, and then then you're, the game's over.
Mackenzie Jackson: Yeah. Yeah, for sure. Well, thanks so much for coming on. It's been a fascinating conversation. I really hope that we can have you back on again. And yeah, enjoy the enjoy Vegas in the heat.
David Mytton: Thanks a lot. Yeah.
