A Birthday Week teaser, (online) waiting rooms, and typo traps

Hello, everyone, and welcome to This Week in Net. It's the September 22nd, 2023 edition. And today we're not only celebrating one year of episodes here, but also birthday week that is just around the corner. We're going to go over what to expect. I'm João Tomé, based in Lisbon, Portugal, and with me I have, as usual, our CTO, John Graham -Cumming. Hello, John, how are you? I'm very well, thank you. Nice to see you. Getting ready for birthday week is getting exciting now. True. And we discussed birthday week last week with a bit of history, when it started, why is it relevant for us and how it started innovation weeks, in a sense. And now birthday week is around the corner. I think this is a record in terms of blog posts, right? More than 40? I don't know if it's a record. What I know is it's a tsunami of blog posts, because I'm reading them all. And there's one day when they're in 10 blog posts. That's a lot. And there's another day when there's nine. And the days go like this, seven, eight, eight, nine, ten. So actually, it builds up throughout the week. It goes from just seven on the first day to 10 at the end of the week. So yeah, it's going to be a very busy week. One year, actually, we were starting to do This Week in Net in this format. It was with GA Week that last year was just before birthday week. Just before birthday week. You're right. That was our first This Week in Net. Is that right? It was when we started. 38 episodes now. 38 episodes. Amazing. Well, here we are. Happy birthday to This Week in Net as well, I suppose. True. It's one year, but that's something. Before we go to the birthday week teaser, in a sense, we also have a few blog posts from this week. Our blog continues to be busy, in a sense. It does. Actually, I've been reviewing all the blogs for birthday week, but that doesn't stop the other blogs from coming. So we've got a bunch of other ones coming along. So yeah, we've had a few things this week. And actually, I think we've got another blog post today that's going to come out, right? True. That one's for me. So I know a bit about that. Before we go, actually, to the blog post, I was seeing this internal conversation about chairs. And you were saying that you remember when those chairs where you kneel, kneeling chairs, right? Were popular in the 90s. And now they're coming back. It's so funny, right? Because there was a discussion about, as you say, on the internal chat, there was a discussion about what chairs do people like to sit on, right? Especially because we've all started working at home. Suddenly, the chair you have at home for working on your computer has become much more important. And so people were discussing what they had. And as you say, there was a long discussion. But a couple of people mentioned kneeling chairs. If you haven't seen one of these chairs, basically, it has two pads where your knees go and a sort of seat, but no back. So you have to hold yourself upright. And that was the idea. You're sort of in this kneeling position and you hold yourself and it's meant to give you this very good posture. And these things somehow come back into fashion. And what amused me is in my first job, which was in 1992, so 31 years ago, I wasn't quite my first job. I worked in WH Smith before that, my first proper job, let's put it that way. All of the cool kids, that included me because I wanted to be cool, had kneeling chairs because it was going to give us this great posture while we were typing. And then kneeling chairs, I don't know what happened. They just disappeared. And then of course, we were just sitting in chairs for a while. And then I think, especially because when I was in Silicon Valley, those Herman Miller chairs, they were the thing everybody had. And I actually own one of those, which I bought from a bankrupt company after the dot-com crash. And truly, I mean, I've had that chair since the dot-com crash, so that's probably 20 years. And they are extremely well-made, those Herman Miller Aeron chairs. And that's what I sit in at home quite often. But all of a sudden, kneeling chairs are back, but there was an interlude. The interlude was standing desks, right? Standing desks. So we've gone through these ways. They're still around. They're still around too. But anyway, yes, kneeling chairs are back. True. I can tell you the first time I saw a kneeling chair was in a Portuguese government minister office. It was the minister of science and technology. And I was interviewing him like a few years ago, and he had like this amazing kneeling chair. And he told me, I only use this like for more than 20 years. So there you go. So he's an OG. It was the first time I saw. So he was one of the original. He was. He didn't like, I think I stopped at some point. I think after I moved to the US, kneeling chairs weren't quite a thing. But in 1992 in the UK, if you were a programmer, that was the right way to have that nice posture. So there you go. I had one very light, the one on the right there. Very, very light that. I used to sit like that all day long. So let's go to the blog. We had a few blog posts this week. The first actually was on Friday. We didn't have time to mention making content security policies, CSPs easy with PageShield. Great. Yeah. Well, let's click on that one, because this is all about doing something which, you know, if you think about Cloudflare, you think about the Cloudflare network with all of the servers around the world and what we do with traffic as it comes through our network, protecting against DDoS, about WAFs and acceleration, all this kind of stuff. PageShield is an unusual product for us because it actually runs on the client side, i.e. in your browser. And the idea is to protect against attacks that go against JavaScript in the browser. So there is a problem, right? And which is, you know, there's a thing called Magecart, some people might remember, which was some malicious JavaScript injected into web pages, which can then steal, your passport details or your credit card number or stuff like that. So protecting within the client is important. That's what PageShield is all about. And PageShield uses a standard called content security policy. And content security policy really allows the web server to say to a web browser, hey, the content in this website can only come from, let's say, certain domains. And that's actually quite a powerful thing because you can limit many of these types of attacks because they can't come from third-party locations. But like many things on the web, content security policy is quite complicated to set up. And so PageShield has this really nice mechanism for creating policies in this release. And so it can go through and it can examine what your website does, can then recommend policies to you and help you build them automatically. So the idea is that, you know, we can help you control using this thing that's built into a browser because it's a standard, you know, how JavaScript is executed in the browser, where that JavaScript comes from. So a nice addition to PageShield. And PageShield is a great way of protecting against browser-based attacks. There's a few examples here for Stripe or Zendesk. Well, there's a worked example of imagining a website that has a checkout page and checkout uses Stripe for the payment and you want to allow Stripe in there, but you don't want other things to be in that location. And so it allows you to build those kinds of things up. A lot of talk about suggestions and the major CSP directives being... Well, also, if you look at the number of CSP directives there are, just look at this long, long list, this is why it's complicated to set this stuff up. And so, you know, PageShield can help you with that. These small improvements also makes a difference. In those who are setting things up and don't want vulnerabilities problems, right? Well, it's yet another way of protecting against, you know, a class of attacks. In this case, third-party JavaScript injected into web pages. And, you know, PageShield helps with that in general. So yeah, check it out. Should we go to rate limiting analytics? Yeah, let's go to rate limiting. This is new. Yay. So rate limiting, something lots of websites use. It's like, how much traffic should I get per second, for example, or per second from a particular end user. A very useful technique to prevent a website or an application for getting overloaded, especially when it might come under attack from bots or something. Lots of people use rate limiting as one of the tools for attacking things. And understanding what rate limiting is doing is very, very important. So we've added this new view in our security analytics, which allows you to take a look at the rate limiting decisions that are being made. And so you can see exactly what we did and why certain things were rate limited. And, you know, this will give people an idea of what's, you know, what's going on and perhaps are they being attacked by a particular address or is it a particular browser, you know, as a particular bot. So you can go in and take a look at this, hopefully gets people to, you know, understand what is happening. And then it allows them to set a reasonable threshold as well. Because one of the things you want to do is say, well, this is the sort of normal level of traffic I get. And I want you to start slowing things down if it goes above a certain amount. And so knowing what normal looks like is super helpful. And this is one of the things you can do with rate limit analysis. The other thing we've announced in here is throttling. And what throttling does is instead of blocking, so it might be that you say, you know, if this IP address, for example, or this fingerprint goes over a certain number of requests per minute, per second or whatever, then block it. Right? That's one option. Just like no more requests from you. Or we'll just keep a log of it. We'll just keep an eye on it. Right? Well, between those two worlds, you might want to do something else. You might not want to just log it and you might want to not totally block it. Well, the option is throttling. So that will allow you to slow down somebody by only allowing a certain number of requests per second or per minute from their end user. So the throttling is available as part of rate limiting. So visibility into what's happening and on top of it, you know, a new piece of functionality which allows you to throttle requests coming in to slow them down to something that your end server can cope with. Exactly. Where should we go next? Speaking of lots of traffic, let's talk about waiting rooms. So another way of dealing with overload is to make people wait. Right? So rate limiting just stops people getting access or with throttling slows down. You can't do so much. Right? Waiting room, we've all seen waiting rooms. We've tried to buy tickets for a show or if you may remember during the pandemic, we've tried to get in a queue to get the vaccine. A waiting room is the thing that allows a customer to say, hey, I can handle this many users at once. And so don't let in more than this many users at once because otherwise my, you know, ticket buying service will get overloaded. And so waiting room does exactly that. A request comes into Cloudflare and the waiting room, if it's above a configured limit, it will put you in one of those queues where it says, you know, your number blah, blah, blah in the queue or your wait time is this much. And this is a very popular product for all sorts of things where they might get overloaded traffic at, you know, very spiky traffic, but they don't want to drop it. They want to actually give those customers a fair shot. And so waiting room is the product. It's been around for a while. Three years now. This is a very detailed blog about how we actually make a decision about putting people in a queue on our network because our network is highly distributed. And so making a decision about, oh, you visited the website. Do you get let in? You can go straight to buy the tickets you wanted, or do you get put in the queue is quite a complicated thing. And there's been a lot of work on making this work geographically because some things will be localized. Like, I mean, not very long ago, there was a ticket sale for Taylor Swift in Portugal. Well, a very large number of those users will have been in Portugal, but also people will be willing to travel from all over Europe to see Taylor Swift, right? And maybe from... That happened, yeah. That's right. So we didn't do Taylor Swift, but a waiting room would have had to have been used that can cope with a global pattern of interest. And so this blog really talks about how that works and how we ensure fairness for people wherever they're connecting to the Cloudflare network. And with the latency focus, the experience should also be smooth and good for the user, right? Smooth, it should be fair. You should get in the queue. You should know how long you're waiting. And so this really very, very detailed blog looks at, you know, what it looks like. This graph is kind of interesting. This is like, if you look at the graph, you can see a sudden queue of users, right? This is like, you know, something goes on sale and then off it goes like that. So you can kind of see this is how spiky that kind of traffic can be. We have had an example related to not this particular situation, I think, for the Eurovision in terms of voting. Yes, Eurovision voting. It was like, I don't know what time it was because I was getting a bit tired by that point. But whenever the voting started, I think it was like nine o'clock at night or something. No, maybe later. Later, later than that. Yeah. 10 p.m. Yeah. Every time the voting started, there's a sudden peak, right? True. And these, you were mentioning in the pandemic, these things are more so relevant now than possibly a few years ago, because people are trying to go to shows. People are trying to do stuff. Yes. A lot of people. So that brings a lot of people, thousands and thousands, to one website. And that's a problem when you're trying to buy a ticket, do things like that. Well, this is incredibly frustrating if the website you're going to falls over while you're trying to buy your ticket. It's better to be in a queue and waiting than have a dead website. That's what this is about. And if you're interested in how we think about this, how we allocate, who's going to get in and all of the mathematics behind it and the architecture, this is a great blog post for you. Definitely a very, very interesting analysis of what we do. Yesterday, we also had a call for email security now works with CrowdStrike Vulkan log scale. Email security and you're using Vulkan log scale. They work together. You can ingest data and get it displayed in the CrowdStrike dashboard. So yes, very nice integration with CrowdStrike. Love to work with them. Exactly. This is a partnership. A lot of partnerships are coming also next week, but we'll go into those in a little bit. And today we also have this typo related type of blog post. You wrote this, you know, when I was reviewing this, I really thought, I really felt for you because getting the spell check and not to change xMaple to example must've been a nightmare. And I actually, you deserve a medal because I read through it and I checked every single time you had said xMaple.com or example.com and they were a hundred percent correct. It was never a mistake. So that must have been a lot of work, but yeah, you can tell us a bit more about that. But the basic story is here that there is a domain name example.com allocated by the IETF for examples and for testing. And it exists, it's a real thing. And we use it extensively in our documentation. People wouldn't use it for testing. There are people who typo that and they type in xMaple.com for whatever reason, that's the typo they make. And that gets quite a bit of traffic and Cloudflare actually owns xMaple.com. And so you've dug into the traffic it's getting. So tell us about it. Sure. First of all, I was surprised. First, how relevant, generally speaking, example.com is. It's much more used than I would expect, to be honest. And then how much traffic xMaple.com, that seems something really different when you say it orally, but when writing, it's just a two letter mistake. You just switch two letters and that's it. Actually, I put in a different color, the two letters that are different there. And it makes a difference. These were like two surprises. First of this example.com reserved domain name that is pretty much used for testing, for all sorts of things. Even Apple uses, when you go to the Apple settings, Apple uses example.com there, just to give you an example. And if you go to example.com, of course, you will see this information, but also xMaple.com has a similar information, but it also says, chances are you got here by mistake. Because to be honest, this is not an advertised domain. People go there by mistake. And I did a bit of xMaple history because this belongs to a customer before that was getting a lot of traffic and getting a lot of traffic means financial cost. So this came to, to Coffler for that reason, for others not to explore it in a malicious way also. And as you say, a bit like ICANN has IP as well. That was another one where there was getting, it was getting overwhelmed with requests and we helped out there too. Exactly. That's also a specific example there. And how much traffic it gets. I was amazed to see that over the period of the last year, 12 months, it had 2.4 billion HTTP requests, which is a lot. It's increasing. That was interesting. That resilience is getting worse. People aren't getting better at typing. They're not. And there's a 8 million daily average. So 8 million requests hitting that side for all sorts of reasons. Most of the traffic is bot traffic. It comes from automated systems. Makes sense because example.com is used for automated systems, testing routers, testing things. So it made sense that this had like traffic specific to that. There's a bunch of data here in terms of HTTP protocols also that are used because it's more automated. It's not as preoccupied in terms of HTTPS. That was interesting. I thought, we know from Cloudflare radar data that web requests, 99.3% of them are encrypted. In the human type of way. The human type way or just in general. And here it's the opposite. It's mostly non-encrypted, which tells us probably it's automated systems that may be old or simple or whatever. So interesting to see that. Not a lot of cyber attacks, but the ASN that was generating more traffic was a French one from Boik Telecom from France, an ISP, a big ISP there followed by Google Cloud in Japan specifically. So we've chatted with Boik. We told them that they're looking for the needle in the haystack, I guess, of something, probably somewhere in their network is someone's typoed example.com into xMaple. It doesn't really hurt them, right? It's not malicious. It's just a mistake, but something to clean up. So they'll no doubt do that. In that discussion, actually, they said that, hey, this is really difficult to find like a needle in a haystack to find these types of things, which was the router that had xMaple instead of example.com. Those things are difficult. Maybe there's some version of their routers that's deployed that's got a typo in it or something like that. We've seen that sort of thing in the past, actually, with the software that's in your router, in your home from your ISP. We actually had another example against a website that allows you to look up, given a MAC address, the manufacturer. And there was an Italian ISP where they didn't cache that. And it was just banging us with requests for looking stuff up. And actually, what was interesting was at some point they fixed it. And obviously, they rolled out a software patch and that dropped off again. But again, that customer was having a really hard time because of the traffic load from sort of systems that shouldn't really be doing that, but it's just an error. I was surprised, writing this, how much typos have a way in inserting themselves into Internet problems, like network problems, or even refer, which is a type of word that is related to HTTP and of the HTTP pros. Okay, the funny thing about the thing you're referring to there in the referrer header is in HTTP, there's a thing called the referrer header, which tells you where the request, the page that the request was on, where someone clicked. I clicked on a page there. Tim Berners-Lee in the original HTTP proposal, he spells it three different ways. He spells it referrer with two Rs, which is what it should be. He spells it one R, which is what everybody uses on the web now. The actual header has one R in it. Also, at one point, he types it as reefer. There was a typo that got into the web. Literally, the referrer header is R-E-F-E -R-E-R colon. There's only one R in the middle of it. Typos can persist. That can persist, exactly. We saw also some spikes coming from Reddit posts. I also noticed GitHub pages that someone by mistake put xMaple instead of example. There's a few trends here about email trends. All sorts of email trends. You have this list of examples of people, addresses that people have made up. Clearly, people are trying to make up a fake email address to enter somewhere and enter it, but they typo the word example. And so, fake name at xMaple .com, John Smith at xMaple.com, Han Solo at xMaple.com. Han Solo is my favorite. Your name at xMaple.com. That almost seems like somebody literally says, type in your name here, so they type in your name at xMaple.com. Really pretty interesting. People are trying to do this, and of course, that actually has a consequence, which is that traffic actually gets sent to it. Exactly. There's a bunch here for those who want to explore, and also the popularity of xMaple.com that appears in our top 100 ranking list on Radar. I thought that was really interesting. So, xMaple.com is one of the top 100 websites, right? It is. Has nothing on it. It's really interesting. It tells you that there's a lot of systems that use xMaple .com as it was intended, as an example or for testing, and it actually generates quite a lot of traffic. But I guess this is a good news story, xMaple.com, it's down in the 100,000th website, right? It's pretty high if you ask me, 100,000th. It is. It's mostly about how making mistakes is human, and the Internet is full of those. And there's this Vint Cerf quote that I really love about that. Yeah, exactly, about typos can really cause outages and all sorts of problems. Thankfully, Apple just gave us a new autocorrect, right? So maybe the new autocorrect will solve this for us. Maybe, let's hope so. And now let's go to birthday week, because birthday week is just around the corner. On Sunday, it's the first blog post. I know, and I haven't written it yet. I've half written it, but yes, the welcome post is on Sunday, and then the real onslaught of blog posts kicks off on Monday. What can we say about it? What can people expect from it? Well, look, first of all, we're a teen. We're 13. This is our teenage years, this sort of coming of age in some cultures, right? So this is a big moment for Cloudflare, 13 years. What's coming this week? Well, all sorts of goodies, all sorts of gifts. I'm going to broadly say privacy. There's a lot of stuff around privacy technologies. There's a lot of stuff around performance technologies, because we want to make the Internet faster, right? That's one of our themes, right? Making things faster. There's a bunch of stuff around AI. I don't know if you've heard of that, but apparently that's- I heard. But that's a thing. That's a thing. Lots of machine learning and AI. We actually have an entire day dedicated to AI announcements, because there's- It's Wednesday, right? It's Wednesday. Yeah, exactly. Wednesday is the AI day. There's actually machine learning and AI spread throughout the week, because we're both announcing a bunch of stuff. And of course, we use machine learning and AI ourselves, so we talk about some of the stuff. There's actually some simplification of pricing, because in some of our products, things have got- We've ended up occasionally with overlapping products that got a bit confusing. So we're going to actually fix the pricing. So it makes, again, simple and transparent and easy to understand what you're paying for. But yeah, it's 13 years. I always have a hard time predicting the future. And I went back and I looked at 2010, right? So 2010, 13 years ago, when we did our first Microsoft launch, what was new then? I was trying to think about that. Then I'll be able to think about, okay, 2010, let me tell you. The iPhone 4, so it was- Okay. That's a good one. The first iPad. Okay. I think that was the last launch that Steve Jobs did, actually. Maybe you're right. I didn't know that. Then Microsoft Kinect for the Xbox, which brought us depth cameras. That was a pretty big deal. Inception was in cinemas. I still haven't seen it. I've had 13 years. I still haven't seen it. I don't get around to seeing it. I've seen Oppenheimer now. Okay. I haven't seen Barbie. I need to see Inception. And TikTok was huge in 2010, but not TikTok, the song by Kesha. Oh, that's a good twist there. It's a twist. So given all of that, is it possible for me to predict the next 13 years? What we're trying to do at Cloudflare is build the future because it's easier to build it than predict it. So lots of stuff coming this week that we think will help people build the future on Cloudflare. And that's a good teaser to have, in a sense. Last question. Who do you think, in terms of types of customers, developers, will be more happy with what's coming next week? I mean, there's a lot of stuff here. And I think anyone who's interested in doing something with AI, anyone who's interested in privacy, but also there's other things like there's a big thing around climate and carbon emissions. There's a big thing around performance, big thing around security. So this is going to cover every aspect of Cloudflare. And you're going to see partnership announcements. You're going to see a couple of really surprising new products that I think people won't have thought about. And you're going to see us poke AWS in the eye. That's true. And it is all about cost also, which is really... It's all about cost also. Yes. Yeah. Yeah. Don't pay AWS for something you shouldn't ever be paying for. We'll give it to you for free. And in fact, we'll give you money for it. So not only will you not pay AWS, but we'll give you what you would have paid out of AWS so that you don't have to pay a silly Amazon tax. And that makes a difference, especially for startups that are starting, putting taxes. And if you are getting bigger, you will have to pay more. So it's a tax for the future. We'll find out next week, Tuesday. Exactly. Stay tuned. Stay tuned. Exactly. As Cloudflare TV usually says, tune in, geek out. Exactly. And we will see you. You and I will be together next Friday, trying to make sense of birthday week. With a lot of the announcements. Stay tuned. All right. See you next week. Bye -bye. Bye. That's a wrap. Hello, everyone, and welcome to Lisbon, Portugal, and to our This Week in Net program. Hello, and welcome to This Week in Net, already with a Christmas vibe, for sure. I'm Jean Toumer, based in cold Lisbon. And with me, I have, as usual, our CTO, John Graham-Cumming. Hello, John. It's not that cold, Joao. It is cold. It is cold for Lisbon. All right. It's cold for Lisbon. And I've got a jumper on. For those who don't know, what is Minitel? Look, I'll show you. I've got one right here. Press this right button. You see this? There you go. This is a Minitel, this thing. It seems like an old TV. It looks like an old TV, and it's got a keyboard that pops out the front. You're already, like, dressed for Thanksgiving, right? Actually, I don't know if anybody in the U.S. would actually dress with a turkey hat on. I got this in England for Christmas at some point.