Cyber attacks in the Israel-Hamas war, DDoS threat trends, and Internet disruptions

Hello everyone and welcome to This Week in Net. It's the October 27, 2023 edition and Halloween is just around the corner. This week we're going for cyberattacks, disruptions, dashboards and also relevant Internet compromises. For that we're going to London, Boston and even Munich in Germany. I'm João Tomé, based in Lisbon, Portugal and we start going to London. Where's Omer Yoachimik, our product manager for DDoS protection and security reporting. Hi Omer and welcome to This Week in Net. How are you? Hi, thank you. I'm doing good. How are you? I'm good too. Where are you based? I'm based in London. I've been here since I joined Cloudflare almost five years ago. So you're like our number one person to go in terms of DDoS attacks. We've been doing this for a while in terms of DDoS reports that we published this week, the quarterly ones. For those who don't know, these DDoS reports that we do quarterly, as I was saying, they try to show the trends, may that be the different new trends that appear in the DDoS area. That is an old attack, but there's usually upgrades, right? Yeah, exactly. And a fun fact maybe is that when we first started doing these reports back in 2020, this was like literally me and another colleague doing manual queries, Vlookups in Google Sheets and manually cramping the data and crunching it. Weeks of work to generate a report. But thanks to the radar team, now that's all done with the click of a button. And then we can actually spend more time on analyzing the insights and what we see and kind of providing more context around that. So there's evolution throughout the process. And this report starts to be more in the media because some of those are really impactful and big. Some even are in the news because there was not usually a Cloudflare customer, but someone, a very big airline or something like that, was the target of a DDoS attack. So their side, their services were down. It's a typical attack still, right? Yeah, exactly. And it's getting a lot of coverage also because of just the fact that in modern warfare or modern geopolitical events, it's always accompanied by cyber activity, cyber attack activity. And so that adds another dimension to the unfolding events around the world. Usually attackers don't use just one tactic, correct? They use several and DDoS is a go-to. Yeah. And with the low barrier of entry to launch an attack or with the low barrier of entry to launch an attack, anyone that is opinionated and has some free time can launch an attack. And with very little effort, you can launch very large attacks. So it kind of paves the way for, or this is how we see hacktivist groups working, right? And so it doesn't necessarily need to be a persistent threat group or a state-level capability or state-level entity, but rather even just the lone wolf cyber attacks, if you will. Exactly. Makes sense. Let's just share my screen here to show the blog post itself, the DDoS Threat Report for 2023 Q3. Of course, we didn't mention at the beginning, but DDoS attacks are distributed denial of service attack to disrupt websites with a lot of requests that it's trying to jam and put those services or sites down, right? Yeah, exactly. It's one of the oldest attack vectors and it's still being used so much today just because it's so easy to execute as opposed to more sophisticated attacks where maybe you need to distribute malware and gain entrance into a compromised server and so on. And we start the blog post, as you were saying before, with this more specific situation in terms of Israel. After the October the 7th attack, Amos attack in Israel, the conflict in a way started, a new conflict started, and that meant also a conflict in a sense on the Internet. And in this case, this chart actually shows specifically application layer DDoS attacks targeting Israel. Yeah, exactly. And what we saw is that immediately after the Hamas attack, this was, I think, 6.30 a.m. in local time in Israel. I think it was like 12 minutes after DDoS attacks started bombarding websites and applications that provide alerts on rocket attacks and against media and newspaper websites. This is a similar trend to what we saw in Ukraine. So when Russia attacked Ukraine, there were also a lot of attacks targeting Ukrainian news websites, basically resources that can provide civilians with critical information on what's going on, if they should take shelter, and so on. And so we saw the same thing happen here. There were also Palestinian websites attacked as well. The amount of traffic or the total volume of traffic that targeted Palestinian websites were a tenth of what we saw towards Israeli websites. But compared to the total traffic to Palestinian websites, it was a lot more. It was a much substantial proportion of their traffic. So just to give, to put some numbers on it. Yeah, there we go. So we can see that in Israel, Israeli websites behind Cloudflare, on the day after the attack, the amount of attack traffic reached 4% of all traffic towards Israel. So again, on the Cloudflare network. So this means that four out of every 100 HTTP requests were part of a DDoS attack, totaling at about 5 billion HTTP DDoS attack requests over the past few weeks. But when we look at the attacks that targeted Palestine or Palestinian websites behind Cloudflare, specifically banking websites, the amount of traffic was only 454 million DDoS requests. But it accounted, you know, look at these figures, 40 and 60% of all traffic to Palestinian websites. So while the quantity was lower, was much more dramatic against those websites. In addition to those DDoS attacks, we also saw other forms of cyber attacks, like domain impersonation, the distribution of malicious applications. So one of the things that we saw is that attackers or threat actors took open source software that was written as a open source code to use the official API that people can then use that open source code to create websites and mobile apps to help civilians be alerted or to alert civilians when there are rocket attacks in Israel. And this open source was taken, a backdoor was inserted to it. And that way, people that downloaded the app had their sensitive information compromised because that app had access to their contact details, phone logs. Yeah, this was the research done by our intelligence team, the Cloud Force One team. Yeah, sensitive information like contacts, SMS, and just general information about the phone as well, your phone number, your SIM card details and all of that. We've seen kind of a wide array of cyber attacks as part of this ongoing attack, ongoing war. It's quite amazing to see and worrying, to be honest, to see that, again, like clicking on the wrong link. In this case, you see something related to Israel, you want to install or see the app about the rocket alerts, which is really important. It's really, really important. And you click on the wrong link, you install the wrong app, not the right app, and then you can be compromised, your information can be compromised. So it's all about what you trust, what link do you trust, what provider or app store or things like that you trust. Trust, in this case, is important. Yeah, I think, you know, kind of like the Zero Trust approach in the business world, right? I think that's a mindset that ordinary civilians need to adopt. Because if you see an app that's promising you something to alert you on rocket attacks, first of all, only do it from the official app stores. But also check who is the author or who is the service or who is the vendor of that application? And what permissions is the application asking for? That can give you an indication of, is this an app that I want on my phone? Because it could be a malicious app that's actually asking your phone for way more permissions in order to steal that data. But it can also be a legitimate app that just wants to use your data and sell it for ads or whatever. And, you know, that's a personal choice people can make. But in terms of malicious apps, yeah, definitely be cautious, only rely on trusted sources. And don't click links if you're not sure. If you see a recommendation to download something, search for it on Google instead. Try and find the site of that company instead. Look for official guidance. I think that's kind of the way to think about this. So have Zero Trust in what you install and what you click on, for sure. But in terms of the DDoS report, you have also here the global DDoS threat landscape. What is the take that we should have from the full quarter? So yeah, it was a very busy quarter with a lot of records breaking and new attack vectors. I think the main takeaway is that sophisticated DDoS attacks are the new norm. You can think about it like this. A small startup with one person, two people or a handful of people can very fast and very easily, with not a lot of spending money, build an enterprise-grade application that's super performant, globally available, using cloud computing platforms, using generative AI, and you name it. And that's excellent because in the past, you'd need, you know, the full scale and size and budget and headcount of an enterprise to pull that off. But now we have the attacker startup industry, which follow the same concepts. It could be a small group of people with relatively small amounts of money, even though there's a lot of money in that business, that use the same technology to create, instead of performant applications, performant botnets. This is what we're seeing. We're seeing very sophisticated, very randomized, very large attacks. They're very good at imitating user behavior. So it makes it very indistinguishable from legitimate traffic. And they've found ways to make the attacks so complicated and so large that it forced us earlier this, you know, in the past two months, to declare a zero-day attack. And we worked with Google and Amazon because they saw the same thing of how attackers were abusing an HTTP2 implementation vulnerability to launch very large attacks. I know that was a mouthful, but, you know, back to your question, the thing to keep in mind, or the main takeaway, I think, is attacks are only getting larger and more sophisticated and security is not a flip of the switch. There's automated systems. That's perfect. That blocks most of the attack traffic. But security is a process. It's about layers. And the more layers you have around you, the lower the risk of negative impact to your business continuity and availability. Keep that in mind while trying to think of how to address it. And we have kind of a list of best practices and recommendations on what to do and how to best defend yourself and improve your security posture against existing and new threats. I think also interesting here is what type of industries in each quarter are the target. They sometimes change. Other times are a little bit recurrent. In this case, any uptake we should have on the gaming and gambling companies being the bombarded ones in terms of large volume ATTP DDoS attack traffic. Yeah, game and gambling companies, as well as cryptocurrency and crypto training and everything that's very kind of real-time is a coveted target by attack. If you can disrupt or introduce latency into a game, you can cause the other team to lose or you can cause user churn. Same for gambling. If you introduce latency or an outage by launching attacks against that, those websites or mobile apps, then people can lose money because they weren't able to sell when they wanted to or to place their bet on time. So that makes it a very coveted target. And that's why we saw the most attack traffic targeting them. We've also received reports from our own customers saying that they see that their competitors are targeting them with DDoS attacks. Even users have, especially on those platforms, gaming and gambling, have very little tolerance to latency. And if there is a latency or outage or an outage, they will just exit and go to use a different game or a different platform. So this is why we continue to see them as one of the most attacked industries. A lot of charts here explaining the level of increased attacks, which is huge. 8.9 trillion DDoS attack requests blocked by Cloudflare last quarter. A growth of 65% compared to the previous quarter, which is a lot, right? Yeah, definitely. Anything we should take from this report other than this very big attack and how DDoS is relevant more than ever? Regarding the top attack vectors, I think for the second quarter in a row, we see that DNS attacks are the most common or the most popular vector of choice or method of choice by attackers. The DNS services are obviously, it's the phone book of the Internet, right? It resolves the website Cloudflare .com to an IP address. So your computer knows where to connect to. Attackers attempt to disrupt access to websites without actually taking them down. So if your website is on Cloudflare, the chance of it going down due to a DDoS attack is very low. But if you DDoS the DNS provider and they don't have proper protection in place, then even if your service is up and performant and highly available, but users' computers can't resolve the domain address to an IP, they'll get an error and it'll be an outage. But you as the website admin won't see anything unless you also manage the DNS infrastructure. And so this is why I think it's one of the most common or the largest attack type that we see. Also worth mentioning in the second section of the kind of reduced, reused, and recycled, we look at the top attack vectors every quarter, but we also pay attention to the changes in the attack types. And this quarter is no different than other quarters where we see increase in various types of amplification types of attacks that are UDP based. And so here we can see a multicast DNS flood. This is just one example of how attackers are always kind of going back and trying to reuse all the attack vectors based on vulnerable or exposed servers to create DDoS attacks. We also have the radar report. So it transforms the blog post in a sense in a report that you can browse and see different sections at the top source of different types of attacks and the targets and the sources of the attacks. A lot to explore here for sure. What takes, should someone have from this report, like the too long and didn't read type of situation? So for the threat, for the emerging threat and attack vectors, I would say do some housecleaning first of all. If you operate an IT infrastructure, take time to understand which of your services or servers are exposed to the Internet and shouldn't be. Maybe they're being used, exploited to launch DDoS attacks. If you block the relevant ports, relevant IPs with your firewall, then you can reduce the amount of DDoS attacks or the amount of DDoS attack traffic in the world. If you are not operating that type of infrastructure or if you're looking to defend against DDoS attacks, keep in mind that approach that I mentioned before or implement that. Security is about layers. Implement a positive and negative security model and rely on on-demand, always on automated protection. Because like even in the 2.6 terabit per second attack that we saw this quarter, the attack lasted 15 seconds and most of the attacks are very short, even the largest ones. So you want to have that automated inline protection to protect you against those attacks. Because even if the attack is short, very short-lived, recovering from it can take much longer. You can use the analogy of a boxing match. Getting punched in your face will take a fraction of the second, but it might knock you out and you may need time to recover from it. So that's why we kind of recommend to have all of these protection layers enabled and also to raise organizational awareness and to prepare for such things. We've had, in the past, organizations come to us under attack and they didn't even have a runbook, you know, a process of what to do if they are DDoSed. And we helped them, we guided them, we provided them the support they needed. Not having that type of readiness or not being prepared can cost you a lot of time and to resolution, which impacts business revenue, reputation, and also causes, you know, employee fatigue, constantly having to deal with these things. And we know that security personnel and staff shortages are a real thing and fatigue is a real thing. So, you know, delegate as much as you can to automated measures and proactive mitigations that are put in place. And I remember in Portugal, to that aspect, that last year there was a big attack on an airline and the attackers apparently used DDoS to put the security teams on alert while attacking in other vectors too. So, if you don't have a good DDoS protection, the teams will have more work. And if they have more work there, the attacker possibly is attacking in other parts, just trying to make teams a little bit more not ready on the specific side they should. I remember a conversation that I had with one of our largest customers saying that I was I don't remember the exact quote, but it was during incidents, our cognitive levels or our cognitive capacity is very low. We're constantly being bombarded by questions and demands from management, sales, customer support, other teams that are being impacted, same time, at the same time, we need to, you know, mitigate the attack, mitigate the risks. And it can be too much for, you know, one person or a team to handle. And so, being prepared in advance can reduce a lot of that. Absolutely. You were mentioning the list of recommendations before and in your blog, in the end of the blog, you have here a list of recommendations that is in our software docs to all customers. So, there's a bunch of advices here for customers that they can follow through that is in the blog specifically, right? Yeah. And if you click on the prevent DDoS attacks, we have on the left side there. Yeah, there we go. So, we have this learning path and we have this for securing applications and others, which kind of walks you through the concepts and kind of explains what recommendations to take and also why. So, these are more of a kind of educational and an educational guideline to help you implement and protect your Internet properties. Yeah, you don't need to be an expert. You can follow through this step by step and be better protected too, right? Exactly. This was great. Thank you, Omer, for all of your explanations. And that's it. See you next time. Thank you. See you next time. Bye. Next, we go to the U.S. to talk with David Belson, our head of data insights about outages and disruptions. Hello, David, and welcome to This Week in Net. You are in Boston, right? I am, just north. We're actually going to be about 80 degrees this weekend. We're cold. So, Massachusetts. Actually, that's a word when I was starting to learn English. It was very difficult to say the state of Massachusetts. It's still difficult for people that live here too. It's a whole separate segment though that we can do on all the town names in Massachusetts and why they're all impossible to pronounce. Exactly. And you wrote a blog post this week, a recurrent blog post in terms of being quarterly one about Internet disruptions and outages. There's a lot of different causes and types of outages over the world in a given quarter. And we had a few examples this last quarter, right? Yeah, absolutely. From a cause perspective, very similar to what we've seen over past quarters. A number of government directed shutdowns, and those are arguably the worst. Several instances of submarine cable maintenance causing connection issues, as well as submarine cable damage causing connection issues, wildfires, earthquakes, cyber attacks. And then of course, some outages and connectivity issues where they were observed in our traffic, but where the provider never discussed the root cause. Exactly. That's also recurrent sometimes. Unfortunately, yeah. And more recently, we had not in the quarter blog post because the quarter ended in late September, but more recently, we also had the Israeli -Palestinian conflict. We were following that separately. So those will be included as appropriate in the fourth quarter summary, but in sort of a more real-time basis, we're including those in the Outage Center, as well as on our social media, as you show here. Exactly. This is the October 16 update, and a lot of networks impacted, and some of the districts in the Gaza Strip specifically have been having less Internet than usual. In some cases, 80% drop in traffic compared to pre -conflict. Yeah, I think the last few now, I think, are running out of fuel. So in that particular case, it's just because of the blockades and whatnot. They just simply can't keep their equipment powered. Exactly. The power outages are also impacting there. And you were mentioning our Outage Center on Palfe radar, and here it is. People can browse and see and select different periods of time. Different timeframes. And even 12 months, right? Yep. Yeah, definitely a very rich, for better or for worse, a very rich set of outages that we've observed over the last year. And if you actually scroll down, you can also go and filter the table there by start date, end date. Basically, you can sort them by the various columns, or if you want them to look just for a particular location. Let's go into the quarterly Internet disruption summary here. You already told us about different types of outages. Where do you want to start? We'll start with Iraq. It's right up front there, and seems to be, unfortunately, a frequent feature in these blog posts. Over the last several years, this goes back, I don't know even how many years at this point, but Iraq is one of the countries that started to implement Internet shutdowns on basically a daily basis, more or less, for three or four hours a day, in an effort to prevent cheating on exams. So they have these sets of nationwide exams that are given, and I guess in an effort to prevent students from sharing. I think at some point, there was theft of exam material beforehand. So they were trying to shut down the Internet to prevent people from sharing photos of it or whatever, or to prevent people from sharing answers during the exam periods. And we saw, again, multiple rounds, not only in, I guess I call it the main section of Iraq, the main part of the country, but also several in the Kurdistan region to the north. So separate schedule, same intent, same reason. The thing here is that it's not entirely clear whether these shutdowns are actually effective in terms of preventing the cheating. Some, you could look at it and say, well, they keep doing it. So maybe they are effective. We also had shutdowns related to submarine cables. So there were a couple of them that we saw, like Liberia here, and then another one that impacted multiple countries. So the Liberia one, I think, was just an issue with the ace cable, which sees frequent problems. And the interesting note here is that the ace cable serves as the sole source of Internet connectivity between Europe and Liberia. So basically, there's a heavy reliance on this cable for Liberia to get Internet connectivity. There's no redundancy there, right? Right. Or limited redundancy at the very least. Maybe they have another way of getting to Asia or the rest of Africa, but Europe is a non -trivial Internet hub. So that's the only way to get up there. That's definitely problematic. And this was for a few hours, right? Yeah. So they recovered fairly quickly, which was good. Yeah. And in this particular case, there was an undersea landslide in a canyon that impacted two cables and then ultimately impacted connectivity for multiple countries. In some cases, the countries had alternate connectivity that they could take advantage of. In some cases, they really needed to wait until things got fixed. The other ones I wanted to talk about were in Palau and Guinea. Those were also submarine cable related. But it goes back to similar to what we saw with Liberia. In these two particular cases, the maintenance on the relevant cables was planned. So in the case of Guinea here, it took Internet connectivity out completely for a period of several hours, about eight hours that they were down. And then in Palau, the planned maintenance took them offline for about three days. That's a lot. So Palau and Guinea, I think both... My geography is terrible, so I apologize. Palau definitely is in the South Pacific, so much harder to reach. So basically, they appear to be completely reliant on or near completely reliant on the submarine cable. The quote that I included in the post talks about some backup satellite connectivity. But clearly, we weren't seeing much traffic over that satellite. We also have cyber attacks related, right? Yep. So University of Michigan during the quarter, it was right after school started, so really, basically terrible timing. They were hit with a cyber attack. And I think in an effort to isolate themselves and prevent them from spreading and to do forensics internally, they ultimately chose to disconnect or largely disconnect their network from the Internet. So University of Michigan owns multiple autonomous systems. The primary one that they appear to use is this one, 36375. This was on the news everywhere, the fires in Hawaii, the wildfires that killed so many. And we've seen this in the past as well. It's an unfortunate occurrence, obviously, and it's infrastructure damage. Homes, businesses, infrastructure, power outages. The physical infrastructure was destroyed, including presumably wiring and poles and whatnot, but then also the power outages. So I think what we see here is the impact of that, with it starting on August 7th, as the fires really began to spread, and then remaining low for about three weeks, and then starting to pick up gradually at the end of August, and growing slowly through September. And again, the destruction can bring those not only power, but also networks down, and it takes a long time to recover. The earthquake in Morocco is another situation on that regard, right? Yeah, absolutely. So in that particular case in early September, there was a pretty significant earthquake there. A lot of damage, a lot of building and infrastructure damage. So we saw, if you looked at it at a country level, you can see here that there's some nominal sort of loss of traffic over the course of time. But I think the graphs that you had put together, that looked at traffic patterns on a more regular basis, on a more regional level, you can definitely see the impact. You can see traffic fall, 50%, 60%, 70% as the earthquake occurs, and then remain at lower levels over the course of the next several days until things get cleaned up, and repairs start, and whatnot. There was also some Starlink and Sky, like you were saying before. Yeah, so what we talked about in the beginning, Starlink and Sky were two outages that we observed over the course of the quarter, where there was... In Starlink's case here, they did acknowledge the outage, which is always nice to see that the provider says, yep, we're having a problem. Unfortunately, what they didn't do was say, this is what caused it. That's something, as we track these, that's what we look for, is to say, okay, yep, we saw this loss in traffic, and now we want to know why it happened. There was a similar outage last quarter. That one, they had at least acknowledged and said, there was some sort of digital certificate problem within our infrastructure. We cleared that up, and that fixed the problem. Again, with Sky in the UK, you can see a little bit of a dip in traffic there for a few hours. People were complaining all over Twitter about the inability to connect. Sky's support account did say, yep, we acknowledge there's a problem on our network, but again, they never talked about why that problem occurred. We continue to monitor all of those in our social media, Mastodon, Twitter, Radar.com. Mastodon, Twitter, X, whatever, BlueSky, and then, of course, the Cloudflare Radar Outage Center. Here it is. Thank you so much, David. This was great, and have a good week. See you next time. Thank you, you too. This week, we also had a blog post, actually two blog posts, about Okta Compromise. That is very alarming. Okta is a security company. Cloudflare is a customer. They have a lot of customers, and we explain how we mitigate that risk, and also how we put available a tool to everyone to make this so that this attack will be obsolete in the future. What is important to have in mind is that this was an attack that our systems, our security incident response team, CERT, discovered on October the 18th, 2023, and no Cloudflare customer information or systems were impacted. This was thanks to a real -time detection and rapid action that we have in our security incident response team, and also the fact that we use our own product, Zero Trust, that gives us a little bit more edge in terms of protection, and also we use hardware keys. With that, we were able to mitigate completely this attack. In terms of the Okta Compromise, we're going to do a dedicated, this week in an episode next week, about it. Also important to highlight is that we introduced, one year ago, cache rules, a new way to customize cache settings on Cloudflare. This provides more flexibility for how users cache content, offering precise controls, a user-friendly API, so a lot of integrations. It was released one year ago. More than 100,000 websites have been using it, but now it is generally available. With that, we also put together Cache Reserve as a generally available product, and that helps enhance control to minimize egress costs. It's important, and it's included in the analytics shown in the cache overview section on the Cloudflare dashboard. If you want to learn more about it, you can see the blog. Last but not least, we also published a blog post about true new features that will help make email routing more secure, flexible, and powerful than ever. This is email routing subdomain support with new API security protocols. Next week, we're going to have Celso in our show, so we're going to talk with him about this and other topics. Hello, hello, everyone. I'm Dan Hollinger. I am part of the product team here at Cloudflare, and I help manage our tenant and partner platform. I've been with Cloudflare going on nine years now, and I'm currently dialing in from beautiful Munich, Germany, Munich, Bavaria. I'm sitting outside my apartment enjoying the nice fall breeze we have going. I'm originally from small town Ohio. A fun fact is I grew up on an egg farm with about 100,000 chickens. So after learning to master how to handle all of those eggs, now I get to master how we build our platform to better support large integration partners as well as large direct enterprise customers. Today, we launched a blog post describing our first UI for our partner and tenant platform. Ultimately, we had an amazing integration platform that we built a few years back for one of our largest cloud integration partners, but we did not have a UI for it. So ultimately, a lot of the functionality that it came with, account management, subscription management, we did not have fully realized in our dashboard. With the release of blog post, we were announcing the general availability to all of our tenant administrators that they would now be able to access the core functionality of the tenant platform in the dash. So they can now create accounts, they can manage all of their accounts, they can get additional insights both on the security level of the account as well as any performance issues that might be bubbling up from the account. So this gives them that top-down view of all of the child accounts and resources they might be using. And our goal is to continue to improve the UI over time. So early next year, we'll be releasing tenant user management as well as additional features to make it easier to work with Cloudflare at scale. And that's all for that blog update. I hope everyone has a wonderful week or weekend. We end it for this week with our CDO John Graham-Cumming answering a few questions that were sent by our audience. Here's Ask the CDO. I got a question about how did your background in mathematics shape your approach to tech and programming? Well, I think one thing that's important to know is what I did at university was a degree called mathematics and computation. And it was actually the full mathematics syllabus at the university with this thing called computation added on. And you'll notice that the name of it was not computer science, it was not computing, it was not programming, it was computation. And it was very much about the theory of computation. You think about things like Turing's work, the lambda calculus. So it's probably not a surprise. A lot of what I did was in functional languages, in particular in Common Lisp and also in ML. And ML was quite heavily used. So at university, the sorts of computing I was doing were quite mathematical. And there was quite a heavy emphasis on algorithms, analysis of algorithms, and also design of them. And also things like the big O notation and figuring out the runtime of your algorithm, for example. What there wasn't was much. And then I think there was one course where we actually did something which I would view as super practical, which was probably write something in C. For example, I actually ended up learning C after I left university, for example. So I think I had a very mathematical grounding in computing. And I think probably the things I like in computing tend to be quite mathematical algorithms, which I find particularly fascinating, particularly probabilistic algorithms. And I think because I had such a strong functional programming background, that's something I've always been drawn to as a way of thinking. Because I think that the difference between people who program functional languages and an imperative or languages most people are used to is a bit like the difference between people who use RPM calculators and regular calculators. It's a different mindset. And funnily enough, that actually drew me to GNU Make. Because GNU Make, you can think of as functional programming in many ways. And if you look at a thing I created called the GNU Make Standard Library, it really is all functional programming inside there. So I think quite a lot. I sort of think of myself as a mathematician who veered off into computer science rather than a computer scientist.