Risky Business - Soap Box: Detection and response in the AI age

Episode Date: June 5, 2026

In this sponsored Soap Box edition of the Risky Business podcast Patrick Gray chats with Edward Wu, founder of Dropzone, about what AI is doing to detection, response and the SOC more generally. Dropzone makes AI agents that conduct alert investigations in your SOC, but will the SOC as we know it even exist in the future? Ed has a deep expertise in SOC tech, having previously led AI/ML detection engineering at Extrahop. This interview is a fantastic look at what the future may bring for detection and response professionals. This episode is also available on YouTube Show notes

Hey everyone and welcome to this special soapbox edition of the Risky Business Podcast. My name's Patrick Gray. These soapbox editions of the show are wholly sponsored and that means everyone you hear in one of them are paid to be here. And today we are chatting with Ed Wu, who is the founder of Drop Zone. For those who are not familiar, Drop Zone is I guess the OG like AI SOC company, right? Where they built an AI agent that acts as a Tier 1 sock operator. right so it helps with alert triage it's a really good use case for AI it works very well I feel like when I first started saying that a couple of years ago on this microphone people were skeptical but now when you go out there and say someone's

built a sock agent that can do alert triage people believe you right because it is a very clear-cut efficiency use case for AI so Ed is joining me today to have a nice long conversation about all sorts of stuff including the volumpolipopocalypse frontier models how the bugpocalypse is going to influence the sock, what it's going to do to detection and response, a whole bunch of stuff. Ed Wu, welcome.

Thank you for having me. So Ed, let's kick it off here, right? Like, there's been, I think the starter's pistol on the, on the whole volumpocalypse or bugpocalypse freak out was mythos, but I think we've realized since then that, you know, it's a bit bigger than mythos, and we're going to be drowning in vulnerabilities for the next five years. I guess there's a competing view, right?

There's competing views on what this means for the SOC. It either means that the way we've been doing SOC forever gets like thrown out because it can't keep up. Or it means that we lean heavily on preventative controls, try to minimize what actually makes it into the sock in the first place, and then automate as much as possible with AI in the SOC to do detection and response. But I guess like you're the one who actually works in AI and SOC technology. How do you think this goes over the next, I guess, half a decade to a decade? Like what's in your crystal ball? Yeah.

The way I think about this is with the upcoming, you know, the AI vulnerability tsunami, ultimately it's what's going to translate to is attackers are expected to have a much easier time getting onto the network. Maybe traditionally, you know, it takes them more effort to either, you know, find vulnerable vulnerabilities themselves or piggyback on kind of the timing difference between the disclosure of zero days and patching. But now the expectation is with more vulnerabilities, more zero days, they should have an easier time getting into the environment in the first place.

So now, in my mind, the detection response or the enterprise immune system, system becomes the frontier of the defense, right? When attackers are in the environment, what can we do to make sure they don't achieve their objectives? So I do believe actually see, you know, vulnerability apocalypse will make actually detection response even more relevant. And part of that is... I mean, it's funny listening to you talk about this, right? Because like it's been one of my talking points has been, well, you know, we need more preventative controls. to deal with this, right? But, you know, for the same reasons as you're talking about, which is there's just going to be more vulnerabilities, more opportunities for exploitation, right?

So the idea I've had in my head is, well, we need more preventative controls, access controls to stop people from being able to be in a position to exploit those vulnerabilities, right? But what you're saying also makes complete sense, which is you still need detection and response. So it's like, what do we need? More of everything, as it turns out. probably though we do need to swing the pendulum back towards preventative controls because I do think people have been over relying on detection response but your point that detection response is still going to be you know everything gets more important I think is your point and it's it's it's true you're right yeah I do see detection response overall to be obviously under

a lot more stress right under a lot more under a lot more pressure when attackers haven't far easier time getting the initial foothold. We always talk about the assumed breach mindset, but now it's armed with, you know, a lot more vulnerabilities and a lot more exploits. I think it's even more important to assume that attackers might already be in the environment and how do we build a DNR function

that ensures that even if the attacker is already in, they don't get to, you know, take away our crown rules. Okay, okay. So what does it look like to improve the sock or not even the sock, right? Let's just say detection and response. What does detection and response, what does detection and response look like in this paradigm? Right? Because at the moment, what you guys have built is something that is really good at automating a bunch of, you know, busy work in a sock in terms of doing that first stage alert triage, which is horrible work that everybody hates. So if you work in a sock and you don't want to do that part of the job anymore, definitely give these guys a call.

So you've automated that part, but is that what is going to, you know, is that what is automating that part of it? Is that the future? Or do we need to reimagine what detection and response looks like, you know, which I know I'm asking you, you know, you've built a business on sock automation. But I'm wondering if you're looking at the future of Drop Zone like, beyond that? Yeah.

So at Drop Zone, we started initially with a single agent. It's our AI stock analyst that autonomously investigate security alerts. But right before RSA's this year, we announced a much broader agentic stock vision, which actually incorporates seven different AI agents, each of them automating different parts of the detection response function, and then have those agents also collaborating. with each other. And that's kind of where, like, when you think about how do we leverage AI agents to make detection and response better, a lot of that comes down to we need more of everything,

we need more detections, we need more hunts, we need more threat intelligence, we need to look at more alerts, as well as we need to drastically reduce the latency across all of them. So one phrase, like we have started to use, and I think a lot of other folks in the community started to use is we really need detection and response ultimately to be operating at both machine scale and machine speed. And that means doing a lot more, but also drastically reducing the latency. Yeah, so that means, I guess what you're saying there is that AI, you know, SOC operator, part of it. you know this isn't the end state for drop zone right this is i mean you seem to be saying that's

like the beginning and now you're moving into that into that more like well how do we reimagine um detection response to operate at at machine speed speed and scale yeah absolutely and a big part of it is really looking at both the left-hand side of the alert investigations and the right hand side of the alert investigations right for example we're building agents that's focused on automating threat hunts we're also building agents that's automating detection engineering, both on the left-hand side of the alerts. And then on the right-hand side, we have agents

that's focused on scoping and performing analysis of actual incidents to help people understand, okay, now I have somebody who clicked on an executable that they are not supposed to. What do I do? Who else in the environment actually has accessed and has touched this, is the same executable? Or maybe part of the analysis will identify what are the C2 servers that the executable file reached out to and see if anybody else in the organization has communicated with the same C2 server.

And ultimately what we kind of have in mind is detection response involves a lot of distinct chunks of manual work. Like our goal historically, we automated one part, which is alerting investigations. But now we are looking at other groups of work and building specialized agents to help really force-multiply and bring a step function in those capacities as well. It's actually pretty similar to the progression you have seen with AI coding tools. Most of the AI coding tools start off by solving a single problem,

which is how do you generate more code? They focus on code generation. And for anybody who worked with AI Agenic development or AI coding, once you use an AI code generation tool for a while, you immediately discover, okay, now I can use AI to generate code, the bottleneck become code reviews. Because who's going to review all the codes that AI just generated? Okay, now a lot of the Agenic tools, in fact, I think Cloud just maybe today

or yesterday announced their like, code review solution exactly to solve this problem because when you have AI generating a lot of code, now the review becomes a bottleneck and then that's where you start to apply AI. But even after that, the next phase is, okay, we have AI code generation, we have AI code reviews, who's writing all the test, who is actually scoping out the ticket in the first place, right? And in order to really truly, you know, get software engineering specifically to machine. machine speed and machine scale, you end up having to build multiple agents, like an AIPM and AIUX designer, right? Well, you're also, under this scenario, you're also creating quite a lot of human work as well, which is kind of, you know, I guess, what are you call it, like a white pill moment, right?

Which is that software engineering still exists. It's just different now. And I mean, it's funny, right? Because we're doing a bunch of like AI coded apps for internal use at risk. business media. The funniest conversation I had with James, who's doing the apps, was yesterday where he's like, he suggested building another feature in the app. And the AI agent told him it was a bad idea and had a really good list of reasons why it was a bad idea, given the sort of information architecture that, you know, the app was built on and whatever. And he was like, huh, I just got, you know, he just got schooled by the app. But I mean, that's the point. He's building now a platform and associated mobile apps and stuff

that would have taken a team previously, but there's still a lot of work in it, right? So I think this is the thing that we're learning with AI, and I've been saying it for literally years, which is it's an amazing productivity tool that enables people to do more with less, but the idea that there's not going to be humans in the mix just doesn't seem very realistic.

Yeah, yeah, and both in SOC or you can say software development, which arguably is like two years ahead of SOC, or two or three years ahead of SOC in terms of AI adoption, is even looking ahead, you see, like, developers nowadays who are working these kind of agentic software development life cycles, actually spend their work is more intense, and they actually spend more time kind of doing designs and architectural reviews and scoping and building alignment versus actually standing on.

Right, which is like now you're writing, you know, you're kind of writing software in English, but you're still writing software. So, you know, what's changed, right? Yeah, and you have to oftentimes, like, make architectural tradeoffs, right? Because if you leave AI coding tools to do whatever, then they will always pick

the simplest pass or the shortest pass. It keeps introducing, you know, different architectural paradigms. And very soon your code base become a union of 50 architectural paradigms. And ideally, for a historical, maintainable code base you want as few number of architectural paradigms as possible. Well, and this actually, this actually brings me to another part of this conversation that I wanted to

have with you, which is, you know, it seems like a bunch of people in the SOC. They already have token budgets, right? So what they're doing is instead of looking at some of the AI like SOC platforms, they're trying to vibe code their way to a better state. And it is working, right? So they can take their existing token budget. They can vibe code some automations in the sock that solve them, you know, solve some of their bigger problems, right? So, you know, we always talk about the jar, and then you fill it with rocks, and then you fill it with pebbles, and then you fill it with sand. It seems like they're able to throw quite a few rocks into the jar. Yep. By vibe coding some of their apps. But I think also this ties into, it's, it's,

that approach is limiting, though, right? Because I think it's like any other software. Okay, you can put together a rudimentary script that does XYZ. But if you're going for the commercial tool, it's obviously had a lot more time thrown at it. And what that time gets you, what that development time from a vendor gets you these days, I mean, ideally, the end state of that is, what you're going to get is something an order of magnitude better than what you can vibe code yourself. And I think that's the part that's missed in the vibe coding. Or vibe coding is going to kill SaaS argument.

And I put my money where my mouth is. I bought quite a lot. of SaaS shares during the SaaSpocalypse. You know, the point is, I think the death of software vendors and that we're going to replace them with vibe coding because you can achieve some rudimentary things easily with your token budget. Like, I don't know, man.

I think that's a strategy that's going to feel old real quick. And look, I'm guessing you're agreeing with that because it suits your interests just fine if that's right. Yeah. Kind of vibe coding or, you know, DIY is, we definitely have seen a lot of that. I think at the end of days, there are two things I play, right? One is there's always the economy of scale, right? A software vendor is going to spend far larger R&D budgets.

But this is my point, is that that equation, that fundamental equation doesn't change just because we have AI coding agents now. You know what I mean? like using a code one person using a coding agent is not equivalent to a software development company that's very specialized you know with all of their developers using coding agents and working towards a common call yeah that that's absolutely right i can assure you modern you know software development companies are under tremendous pressure to use AI coding agents as well to to to make sure we you know achieve the productivity and kind of you know iteration speed that modern business requires

But I think there's a bigger portion, which is the second part, that we see as a historically overlooked part of DIYing or Vipe coding, which is this interesting phenomenon with AI agents where it's actually not that difficult if you have a very narrow use case to build something that just works. But the continuous maintenance and testing of that thing actually ends up. being a whole lot more expensive than the resources you need to vibe code it in the first place. Or when it breaks and no one notices until like it's, there's a real problem. That's another thing that happens with this stuff. Yeah. And this is a part like if you built an agent and you never plan to touch it and just leave as is, then I think that's one thing. But most people, when they build something, they are obviously continuously iterating on it, which means you need

continuous expertise and resources in the maintenance and testing of the product. In fact, I think modern AI, you know, modern startups building AI agents, most of us probably spend a lot more resources and efforts in quality assurance, testing, and validation, and evaluations than actually building, you know, the prompts, the agents in the first place. And that's kind of one dynamic, I think, a lot of team often under, kind of appreciate is they saw, hey, we can build this thing, you know, very quickly, but forgot about the fact that somebody needs to actually continuously test it, unless you are never touching it, right?

As long as you are continuously touching it, then you have to continuously test it and evaluate it. And that's like ongoing, a lot of ongoing maintenance and expertise that the security team will need to allocate. See, I think this is going to be the journey for a lot of your future customers. right is you started off going out there and talking to people you know this is like a couple of years ago you're out there when this was radical thinking going out there talking to companies saying hey you know we built this agent that can do alert triage and investigations and people are like wow that's pretty

crazy you know like that's a that's a very out there sort of thing whereas now I think you know you would get some early adopters and you did get some early adopters are signing up whereas now I see the customers for the future for drop zone are going to be the ones who have vibe code their own stuff for the sock and they've got a lot of value out of it when it's working. And it's also turned into a pain to maintain and monitor and, you know, update and keep relevant. And so they're going to be looking for a commercial solution. Is that happening already? Yeah, it is happening. Because these people are obviously already comfortable with the idea of using agentic AI in the sock, right?

but they've discovered that it's maybe a little bit more work than they realized to do it themselves. Yeah, we definitely have a number of prospects and customers who were kind of building this in-house. They build up a lot of conviction on the technology actually has the ability to deliver high-quality outputs. But like you said, they run into ongoing maintenance starting to become a burden. Or even sometimes, you know, the cutting-edge security engineer who vibe-coded, decided to, you know, work somewhere else. And now suddenly they are left with a tool that's kind of not really maintained. The old dev lead gets hit by a bus conundrum.

Yeah. I think at this time also, as you can imagine, a lot of people are like really interested in hiring security engineers who has AI coding or a genetic development experience. So I think the job market of that, you know, particular niche is very strong. Right. So Sally builds a vibe codes an AI sock agent and then immediately gets poached by Anthropic or something, right? Yeah. Yeah. Or Palo Alto or maybe something, you know, drops on. But yeah. So this is where, yeah, we have definitely had a number of these, you can say, boomerang conversations that's happening because of this kind of experience. But at the same time, we are seeing. you know, more teams kind of still at the beginning part of this journey, which is they finally have convictions that, okay, like, you know, cloud code plus MCP

and, you know, a lot of custom prompts can do a good enough job on some of these analysis. But I mean, that would be using like, I mean, look, that's my next question, I guess, is one thing we've seen through recent work in vulnerability development. or exploit development vulnerability research is that the model itself is not really the important part. It's the harness quite often is where the core capability kind of sits. Once a model gets to a certain level of complexity and competence. And I'm wondering though, because you have traditionally used the frontier models in drop zone to do a lot of the sort of alert triage. Are you finding that you still need to do that? Because I'm thinking a lot of

lot of people now when they're automating some of these functions in the sock, they're doing it with like Claude. They're doing it with like premium 24 karat tokens, right? They're doing it with these expensive models. It strikes me that for a use case like alert triage, that's probably overkill. And as I say, I know traditionally you've used the frontier models because you've needed to, but I'm guessing at this point, like when you experiment using lesser models, it's probably still okay. Like what's that? Where's that all at with Drop Zone?

Are you still using the top tier models? Or have you found that you can get a similar rate of effectiveness with, say, some local models or older ones? Yeah, I think you definitely don't need frontier models 100% of the time. Kind of the analogy I generally use is initially when you build a plane, you build everything out of titanium or carbon fiber because you want the best. And then over time, as you get more iterations and mileage with your playing, you start to still cut different pieces and be like, okay, do we really need this trim piece

to be in carbon fiber or titanium or we can get away with some, you know, wood pieces or plastic trim pieces, right? And over the course of the last couple of years, that's kind of essentially what we have done is if you peel back see Kurta a little bit, a typical autonomous end-to-end alert investigations at Drop Zone, we are making over 100 distinct large language model invocations. And at this point, I would say probably 20% of them, we are still leveraging, you can say, the premium models that cost an element lag, but the vast majority of the 80% of the model invocations,

we get good enough results from not using the most premium models. And also one other aspect is, generally with large language models, the latency and the cost are somewhat proportional, right? Because when a model is very, you know, premium and big, it obviously costs a lot of compute, but also because of that, it generally also takes a long time to respond.

But I mean this is what I mean about it being kind of overkill, right? Because you are burning a lot of everything just to get those results. So you want to make sure you're only using that when you really need to. Like what's the type of? of thing that needs to get kicked up into that 20% of like premium inference? Yeah, I think the biggest part is kind of the planning and the conclusion determination phase because that's kind of intellectually the most critical piece. When you are planning an investigation and you kind of a lesser model my miss certain

caveats and directed the whole investigation in the wrong direction. that obviously becomes very problematic. And then like conclusion determination, when you have 20 pieces of findings and some of them might be contradictory to each other, you kind of need more intelligence to really reason through these and make, you know, a sound judgment call. You need the right statistical weightings

when there's conflicting info. I mean, that makes so much sense. Yeah, but when it comes to like here is a, you know, 5Kabyte JSON response from a particular SIM or a particular threat intelligence feed, you definitely do not need the state-of-the-art models to make sense of them. Yeah. Yeah, well, and you don't need a, yeah, I mean, to kick off a basic automation either.

Like, what is the IP that corresponds to this domain name, etc? Yeah, yeah. And also, again, the expensive models are very slow. So if you only use the expensive models end-to-end, the whole investigation might end up taking like 20 minutes. And that's just unnecessarily long at this day and age. So when we say we go to the logical extension of this vision, right? Which is about, okay, so we've started with the tier one sock analyst, right?

And then you're kicking up to agenic everything. I mean, look, I've long said that I think the way this lands is you wind up with some big blob of storage that you're kicking logs into, you know, both structured. and unstructured data and then you're going to have agents crawling all over it and, you know, detection response and I guess real incident response and threat hunting and all of that sort of stuff is going to consolidate into an agentic thing crawling all over data. I mean, first of all, do you agree with that? And second of all, how long do you think it takes before we're there? Yeah, that's definitely a good question. I think there are a couple different components of your prediction. One is kind of this beta, big, unified data storage. At least in our experience,

the whole SIM security data lake is still pretty fragmented. I don't think the community has reached a consensus on what is actually the right approach here. One could say with AI agents, they are very good at piecing and correlating this joint data from different tools. One phrase, you see a lot of, you know, agentic stock or AI stock vendors talk about is federated search, which essentially means you don't actually need to mirror a lot of data into the same data lake in order for the system

to join, you know, cross-track data with ACTA data, with AWS data. But still, for a lot of... I mean, that is one of the powers of powerful things about agents is being able to do that, right? Being able to have something with a little bit of smarts that knows how to use an API, right? Like, beautiful.

Yeah. Correct. By the same time, there are also questions, okay, different tools might have different retention, right? It's still nice, at least for human practitioners. Well, and sometimes I'm guessing, you know, you're still going to want to pull in, like, subsets of these huge data sets into one place to kind of work on them and do some processing, right? So, yeah. Yeah. So in my mind, the unified data lake is still like a TBD.

I wish I have the, you know, the perfect answer. And so I can make some stock bats accordingly. but so far I don't have tons of good insights other than things are probably going to be somewhat fragmented and flexible. There will be people who is like, hey, let's build a big security data lake using S3 and maybe Acina, while other folks will be, hey, we are against data lakes. That's just push federated search to the end's degree

and just have an agent that's continuously piecing different pieces of data together for security analytics. But beyond that, I do... So I guess what you're saying is that the information architecture of this vision might change, but ultimately it will go agentic, you know, just maybe with a different data structure. Yeah, if you think about, you know, like detection and response in a number of layers, right? There is a security data layer. And I think that's where there are still some questions and uncertainty on which ways this will go.

But in terms of analytics layer or intelligence layer, it's pretty clear the future of detection and response, will involve a lot of agents. Like you said, detection engineering, hunting, alert investigations, threat intelligence, incident response, all of those ultimately boils down to data analytics. You know, slightly different inputs, slightly different outputs. All of those are just data analytic tasks. And that's where I definitely agree with you,

like it will be an army of agents, you know, during the JSON parsing, log analytics, you know, looking at data from different angles and also these agents working together. Like one thing we have been experimenting with, which is pretty exciting, is how do you have two different agents, such as an AI threat intelligence agent

and an AI threat hunter agent working together. So you can achieve like 24-7 autonomous emerging threat response where you can go from, you know, a random security researcher posting something on Twitter to a completed threat hunt within five hours.

So that I think is also very exciting when you have agents kind of working in these loops to autonomously improve the overall, you know, overall security posture of the environment. Well, and then you, then you, what is left for your human in that point, right? Is it just a chat bot? Is it just you rock up to work

because C-So and you just ask your detection response and threat hunting platform, hey, what's going on today? Yeah. Or does it page you? Like, hey, you know, I'm going to need you to go and like physically isolate that machine because there's something I can't contain. Like, is this, is this the end state? I remember like when I was in high school, they showed us some video about the future, you know, and what it could mean with computers. And it really was someone talking to a computer like that. and everyone was like, wow, you know, that'll never happen kind of thing. And that's really, it is like the future vision that video I saw on VHS at high school.

Like, that's what's come true. Is that where it goes? Is it seriously just a chatbot that just handles it? Yeah, that's a good question. We do think it's going to get pretty close to that. Like, when you have a lot of different agents, like automating different pieces of work, like we see the primary human, you know, practitioner, engineer, analyst responsibility to really be up-leveled, to be maybe not all the way up to Cecil,

because you can argue Cecil has a lot of board communication responsibilities and accountability responsibilities, but definitely closer to, you know, everybody should operate as like a senior manager or director level, right? So, and as a senior manager or director, you're kind of doing a couple of things. First, you are defining strategy. Like, okay, I have a lot of agents,

but still, it's not infinite number of agents. So what do I want my agent? to focus on, right? That's kind of one part, which is defining strategy. You're talking about turning literally everyone into a manager. It sounds like hell. Yeah, I guess it could be argued both ways. And it definitely involves a shift, right?

And again, this is where, obviously, as a technical founder who is building a startup, I've spent a lot of time looking at the Jentic software development. And I felt like some of that transformation is, already starting to happen within software development. The best software developers right now, I'm sure if you grab a random software developer at Anthropag and ask him, like, have you written any actual code in the last month? I'm pretty sure the answer will be no. They'll be like, hey, we haven't, I haven't written any code in the last month, but I've been like directing. Although, was it Open AI that just, no, it was GitHub just had an issue where someone using like a

compromise, like supply chain compromise VS code extension or something got owned and it's like wow, you're still using an IDE, like what's going on at GitHub? Crazy. But I know what you mean. Yeah. Yeah. And I think like I do anticipate detection response

in a couple of years to be closer to like the cutting edge software development teams where most of these software developers are not touching the code base directly. But they are continuously providing input. You know, they are debating with AI or brainstorming with AI agents on different approaches to solve the problem.

They are reviewing architecturally the work of AI, as well as ultimately also establishing the framework for AI to work well. So for a lot of people who worked as a manager, you know, one of the key responsibilities of being a manager is for each individual on the team, they might work well in different projects. So as a manager, one of your responsibility is,

create this environment where a particular individual on your team can really excel. And I think that's kind of really applies to AI agents as well. Like if you have AI agents working on some very nebulous, you know, vague projects, they are going to fumble. But if you have it working in a very tightly, strictly defined, you know, task, you know, most of the agents are going to do pretty well. So I felt like another part of the human responsibility is to identify these kind of set up these environments where the agents are going to be successful and then you can say the managers

are kind of shielding the agent or taking out a kind of tasks as the agents are not very good at. For example, the agents are not very good at, you know, building a relationship. They are not very good at convincing other teams to add additional instrumentation to the applications. They are not very good at, you know, negotiating with the finance team and network team to figure out where are the additional subnets that we should deploy NDR sensors to. So the DNR team actually have more visibility, right? Agents are not going to magically just allow you to see everything in the environment. And we know as defenders, you cannot protect what you see.

So I felt like a lot of part is like the future of DNR team will involve a lot more projects like those. Or as well as, for example, selecting new technology. If folks want to look at, you know, a browser kind of a security tool to protect against malicious browsers, browser extensions, like an AI agent is unlikely to end-to-end run the evaluation, you know, assess the personality of the engineering teams of different vendors and all of that. So there's definitely still a lot to do, but to, you know, as to recap, we do believe that in a couple years, there are we want to see. you know, see most of the security existing security engineers and analysts to either operate as like a director or senior manager, essentially like a field general kind of a role, or they are operating as special forces, like really tackling some of the, you know, most naughty and tricky projects. For example, the CEO clicked on something apparently that he's not supposed to. Are we really going to trust an AI agent to really untangle that mess?

or we actually want one of our security engineers who have expertise, who have context, and, you know, to really perform some of the remediation tasks. Yeah, yeah. Well, I mean, that's the future that we're headed for. Ed Wu, always a pleasure to chat to you, my friend, about, yeah, your vision of the future. It's fascinating stuff. Anyone interested in checking out Dropzone can do so at Dropzone.com. Ed Wu, thanks for joining me.

Sense, catch you next time.