WEBVTT 00:00:00.000 --> 00:00:03.620 So if you accidentally type a percent sign followed 00:00:03.620 --> 00:00:06.480 immediately by a lowercase s into a text message, 00:00:06.960 --> 00:00:08.279 the person on the other end is just going to 00:00:08.279 --> 00:00:10.199 assume you made a typo. Right. They just think 00:00:10.199 --> 00:00:12.080 your thumb slipped on the keyboard. Exactly. 00:00:12.220 --> 00:00:15.339 It means absolutely nothing to them. But if you 00:00:15.339 --> 00:00:17.899 misplace that exact same two -character sequence 00:00:17.899 --> 00:00:21.219 percent sign, lowercase s in a piece of foundational 00:00:21.219 --> 00:00:24.140 C code, you can trigger a massive memory leak. 00:00:24.500 --> 00:00:27.100 Oh, easily. Or corrupt data. Or just completely 00:00:27.100 --> 00:00:29.219 crash an entire operating system. Yeah, it's 00:00:29.219 --> 00:00:31.500 definitely not a typo in that context. Welcome 00:00:31.500 --> 00:00:34.280 to the deep dive. Today we are looking at something 00:00:34.280 --> 00:00:37.280 incredibly specific and honestly kind of wild. 00:00:37.549 --> 00:00:40.469 Our source material today isn't some sprawling 00:00:40.469 --> 00:00:43.649 research paper or a textbook. No, it's actually 00:00:43.649 --> 00:00:46.509 just a single Wikipedia disambiguation page. 00:00:46.609 --> 00:00:49.049 Right, a single page dedicated entirely to this 00:00:49.049 --> 00:00:52.250 tiny cryptic symbol percent S. And our mission 00:00:52.250 --> 00:00:55.570 today is to uncover how this specific decades 00:00:55.570 --> 00:00:58.590 -old placeholder convention acts as this critical 00:00:58.590 --> 00:01:01.149 invisible bridge. A bridge between human intent 00:01:01.149 --> 00:01:05.129 and machine execution. Yes, from the lowest most 00:01:05.129 --> 00:01:07.390 fundamental levels of software architecture. 00:01:07.960 --> 00:01:11.040 right up to the web browser that you, the listener, 00:01:11.239 --> 00:01:13.359 are probably using to listen to this deep dive 00:01:13.359 --> 00:01:15.920 right now. It really is a fascinating artifact 00:01:15.920 --> 00:01:17.939 of digital history. I mean, when you look at 00:01:17.939 --> 00:01:20.439 a disambiguation page for something this granular, 00:01:20.959 --> 00:01:23.939 you generally expect a list of highly esoteric, 00:01:24.099 --> 00:01:26.620 completely unrelated definitions. Like just random 00:01:26.620 --> 00:01:30.040 jargon. Exactly. But instead, what emerges from 00:01:30.040 --> 00:01:33.030 this page is a universal logic. We are looking 00:01:33.030 --> 00:01:35.209 at a fundamental agreement about how computer 00:01:35.209 --> 00:01:38.450 systems handle dynamic, unpredictable information 00:01:38.450 --> 00:01:41.230 across wildly different areas of computing. Okay, 00:01:41.269 --> 00:01:43.989 let's unpack this, because I want that aha moment 00:01:43.989 --> 00:01:46.510 for everyone listening. To figure out why this 00:01:46.510 --> 00:01:48.950 tiny symbol has such an outsized impact, we have 00:01:48.950 --> 00:01:51.590 to start at the absolute bedrock of modern computing. 00:01:51.950 --> 00:01:53.870 Which means we have to talk about the C programming 00:01:53.870 --> 00:01:56.250 language. Right. According to our sources, the 00:01:56.250 --> 00:02:00.010 primary identity of %S is its role as a C string. 00:02:00.780 --> 00:02:03.099 Specifically, it's used as a format specifier 00:02:03.099 --> 00:02:05.700 in these functions called print and scan. Now, 00:02:05.959 --> 00:02:08.139 for the listener who writes code every day, those 00:02:08.139 --> 00:02:10.639 are super familiar terms. But let's drill down 00:02:10.639 --> 00:02:12.879 into the actual mechanics of what those functions 00:02:12.879 --> 00:02:15.939 are doing with this exact symbol. What's fascinating 00:02:15.939 --> 00:02:19.120 here is that to really get it, we have to understand 00:02:19.120 --> 00:02:22.199 a fundamental quirk of C. OK, lay out on me. 00:02:22.280 --> 00:02:24.840 Well, unlike higher level languages, think like 00:02:24.840 --> 00:02:27.599 Python or JavaScript, things people might be 00:02:27.599 --> 00:02:30.080 more familiar with, dash C, doesn't actually 00:02:30.080 --> 00:02:32.840 have a built -in string data type. Wait, really? 00:02:33.039 --> 00:02:34.719 It just doesn't know what a string of text is. 00:02:34.840 --> 00:02:37.800 No, it inherently doesn't understand what a word 00:02:37.800 --> 00:02:40.879 or a sentence is. It only understands raw memory 00:02:40.879 --> 00:02:44.319 addresses and single individual characters. So 00:02:44.319 --> 00:02:46.620 how do you write a word, then? So a string in 00:02:46.620 --> 00:02:49.719 C is just an array of individual characters stored 00:02:49.719 --> 00:02:52.599 in sequential memory slots, and it always ends 00:02:52.599 --> 00:02:54.919 with a very specific stopping point called a 00:02:54.919 --> 00:02:57.280 null terminator. OK, so it's less like a whole 00:02:57.280 --> 00:03:01.199 word and more like, I don't know, a row of mailboxes. 00:03:01.280 --> 00:03:04.080 And each mailbox has one letter inside it until 00:03:04.080 --> 00:03:06.240 you hit a mailbox with a stop sign in it. That's 00:03:06.240 --> 00:03:08.620 a perfect way to visualize it. So when a programmer 00:03:08.620 --> 00:03:11.960 wants to output text to the screen using a standard 00:03:11.960 --> 00:03:14.449 library function like print, which is just print 00:03:14.449 --> 00:03:16.449 format, right? Right. The computer isn't just 00:03:16.449 --> 00:03:19.229 naturally reading a word. It has to be given 00:03:19.229 --> 00:03:22.729 like step by step directions to a memory location 00:03:22.729 --> 00:03:25.550 and told to read byte by byte until it hits that 00:03:25.550 --> 00:03:29.120 stop sign. Yes. And that mechanism is precisely 00:03:29.120 --> 00:03:32.180 why the format specifier is absolutely required. 00:03:32.500 --> 00:03:36.419 Percent S. Exactly. Let's say a programmer writes 00:03:36.419 --> 00:03:39.039 a printf command that says, welcome back, user. 00:03:39.780 --> 00:03:42.419 But they want the program to dynamically insert 00:03:42.419 --> 00:03:44.960 the actual username of the person logging in. 00:03:45.000 --> 00:03:46.979 Because they don't know who's going to log in 00:03:46.979 --> 00:03:50.000 yet. Right. So they use percent S. The string 00:03:50.000 --> 00:03:51.979 literal in the code looks something like, quote, 00:03:52.259 --> 00:03:55.120 welcome back, comma, percent S, unquote. OK, 00:03:55.300 --> 00:03:57.289 I follow. When the compiler sees that percent 00:03:57.289 --> 00:03:59.870 sign and the S, it knows it's looking at a format 00:03:59.870 --> 00:04:02.669 specifier. It tells the program, hey, at this 00:04:02.669 --> 00:04:04.370 exact spot in the output, jump to the memory 00:04:04.370 --> 00:04:06.629 address I'm providing, read the character array 00:04:06.629 --> 00:04:09.229 you find there, and print it out until you hit 00:04:09.229 --> 00:04:11.009 the null terminator. I mean, that makes total 00:04:11.009 --> 00:04:12.849 sense. It's basically like playing game of Mad 00:04:12.849 --> 00:04:15.349 Libs. Mad Libs. Yeah, exactly. You have a sentence 00:04:15.349 --> 00:04:17.550 printed on a page with a blank line underneath 00:04:17.550 --> 00:04:20.339 the word noun. The structure of the sentence 00:04:20.339 --> 00:04:22.759 is totally fixed, but the actual meaning changes 00:04:22.759 --> 00:04:25.579 depending on what random word gets dropped into 00:04:25.579 --> 00:04:28.120 that blank space. That's a great analogy for 00:04:28.120 --> 00:04:31.600 what %s is doing in print. So is it essentially 00:04:31.600 --> 00:04:33.920 just a designated empty box waiting for a package? 00:04:34.240 --> 00:04:37.040 It is. But here is where I get tripped up with 00:04:37.040 --> 00:04:40.079 that analogy. Because a physical blank space 00:04:40.079 --> 00:04:43.420 on a piece of Madlib's paper has a fixed size. 00:04:43.600 --> 00:04:46.720 Yes, it does. If I type a massive thousand -word 00:04:46.720 --> 00:04:50.199 paragraph into a prompt that was only expecting 00:04:50.199 --> 00:04:53.639 a short five -letter username, how does %s handle 00:04:53.639 --> 00:04:56.120 that size difference? Does the designated box 00:04:56.120 --> 00:04:59.470 just like... stretch magically in system memory. 00:04:59.689 --> 00:05:01.930 And that right there is exactly the danger on 00:05:01.930 --> 00:05:04.910 why memory management in C is notoriously unforgiving. 00:05:05.189 --> 00:05:07.529 No, the box does not magically stretch. Uh -oh. 00:05:07.709 --> 00:05:09.589 Yeah. This becomes critically important when 00:05:09.589 --> 00:05:11.490 we look at the other function mentioned in our 00:05:11.490 --> 00:05:13.610 source material scan. Okay, so print is for printing 00:05:13.610 --> 00:05:16.269 out, scanf is for scanning in. Broadly, yes. 00:05:16.600 --> 00:05:20.399 While print outputs data, SCAMF reads standard 00:05:20.399 --> 00:05:22.379 input, like the actual keystrokes you type on 00:05:22.379 --> 00:05:25.420 a keyboard. Got it. So if the program uses SCAMF 00:05:25.420 --> 00:05:28.680 with a %s specifier to ask for your name, it 00:05:28.680 --> 00:05:31.720 is allocating a specific finite chunk of memory 00:05:31.720 --> 00:05:34.660 called a buffer to hold exactly what you type. 00:05:34.800 --> 00:05:37.480 OK, but wait. So if I type 100 characters into 00:05:37.480 --> 00:05:40.420 a buffer that was only built to hold 10, and 00:05:40.420 --> 00:05:43.720 that % specifier is just... blindly telling the 00:05:43.720 --> 00:05:46.860 system to write my input into memory, what actually 00:05:46.860 --> 00:05:49.079 happens? The system does exactly what it is told. 00:05:49.240 --> 00:05:52.100 No way. Oh, yes. It writes the first 10 characters 00:05:52.100 --> 00:05:54.060 into the allocated buffer, and then it just keeps 00:05:54.060 --> 00:05:55.660 right on writing the rest of your characters 00:05:55.660 --> 00:05:58.019 into the adjacent memory addresses. Wait, so 00:05:58.019 --> 00:06:00.060 it just spills over? This is over. It overwrites 00:06:00.060 --> 00:06:01.899 whatever was sitting next door in the system's 00:06:01.899 --> 00:06:04.500 memory. This is what's called a buffer overflow. 00:06:04.800 --> 00:06:07.240 Oh, wow. I've heard that term in cybersecurity 00:06:07.240 --> 00:06:10.500 stuff. You absolutely have. Because a buffer 00:06:10.500 --> 00:06:13.040 overflow can corrupt other data, it can crash 00:06:13.040 --> 00:06:16.199 the entire program, or even worse, it can create 00:06:16.199 --> 00:06:18.939 severe security vulnerabilities where malicious 00:06:18.939 --> 00:06:21.540 code is written directly into an executable memory 00:06:21.540 --> 00:06:24.699 space. Just because the program blindly trusted 00:06:24.699 --> 00:06:27.199 the percent specifier to handle whatever was 00:06:27.199 --> 00:06:30.100 typed? Exactly. Man, that paints a much clearer 00:06:30.100 --> 00:06:31.939 picture of why this two -character symbol is 00:06:31.939 --> 00:06:34.699 so critical. I mean, it isn't just a polite, 00:06:34.819 --> 00:06:37.240 helpful placeholder. No, not at all. It is a 00:06:37.240 --> 00:06:39.899 strict structural contract between the compiler 00:06:39.899 --> 00:06:43.480 and the system's memory. The program is completely 00:06:43.480 --> 00:06:47.060 relying on percent s to accurately marshal raw 00:06:47.060 --> 00:06:50.500 data streams in and out of the CPU without destroying 00:06:50.500 --> 00:06:52.870 the surrounding architecture. And that massive 00:06:52.870 --> 00:06:55.189 reliance is what elevates the symbol from just 00:06:55.189 --> 00:06:57.689 a simple coding syntax to a foundational piece 00:06:57.689 --> 00:06:59.389 of digital infrastructure. Because it's everywhere, 00:06:59.389 --> 00:07:02.029 right? Yes, it was standardized decades ago in 00:07:02.029 --> 00:07:05.189 the POSEX specifications. And because C is the 00:07:05.189 --> 00:07:07.790 absolute bedrock of operating systems like Unix, 00:07:07.889 --> 00:07:10.389 Linux, and Windows. Basically everything we use. 00:07:10.730 --> 00:07:13.889 Basically everything. That tiny agreement about 00:07:13.889 --> 00:07:16.870 how to handle dynamic text became woven into 00:07:16.870 --> 00:07:19.529 the fabric of almost all modern software. Which 00:07:19.529 --> 00:07:23.079 actually brings us to... a massive conceptual 00:07:23.079 --> 00:07:25.899 leap in our source material. Oh, the pivot. The 00:07:25.899 --> 00:07:29.339 pivot. So we've just established how %s is the 00:07:29.339 --> 00:07:31.839 universal agreement for inserting dynamic text 00:07:31.839 --> 00:07:34.920 strings in isolated C programs. But then the 00:07:34.920 --> 00:07:37.259 Wikipedia page pivots entirely away from text. 00:07:37.639 --> 00:07:39.439 Completely different domain. Right. It moves 00:07:39.439 --> 00:07:42.519 to system time. Our sources show that %s is used 00:07:42.519 --> 00:07:45.360 to represent seconds in the straff time format 00:07:45.360 --> 00:07:48.370 string. specifically to check the Unix timestamp. 00:07:48.610 --> 00:07:50.730 Yes, strap time. Wait, so it goes from holding 00:07:50.730 --> 00:07:53.209 a string of letters to holding a string of seconds. 00:07:53.350 --> 00:07:55.230 So what does this all mean for how a computer 00:07:55.230 --> 00:07:58.709 experiences now? If we connect this to the bigger 00:07:58.709 --> 00:08:01.129 picture. We really have to look at the abstraction 00:08:01.129 --> 00:08:04.189 of time and computing. Human time is a messy, 00:08:04.529 --> 00:08:07.110 localized, highly subjective construct. Yeah. 00:08:07.310 --> 00:08:09.449 I mean, we deal with leap years, daylight saving 00:08:09.449 --> 00:08:12.509 time adjustments. Exactly. And 24 different time 00:08:12.509 --> 00:08:14.769 zones across the globe. It's hard enough getting 00:08:14.769 --> 00:08:16.470 three people in different states on the same 00:08:16.470 --> 00:08:19.699 video call. Right. Now imagine an international 00:08:19.699 --> 00:08:22.720 banking system trying to reconcile billions of 00:08:22.720 --> 00:08:25.959 microtransactions across time zones. If every 00:08:25.959 --> 00:08:28.639 server was doing its own localized calendar math, 00:08:28.899 --> 00:08:31.000 it would be impossible. The whole system would 00:08:31.000 --> 00:08:34.259 just collapse. So system architects bypassed 00:08:34.259 --> 00:08:37.100 the human calendar entirely. They created the 00:08:37.100 --> 00:08:39.690 Unix timestamp. OK, so what is that exactly? 00:08:39.950 --> 00:08:42.190 Instead of tracking months, days and hours, the 00:08:42.190 --> 00:08:45.049 Unix APOC simply tracks the total number of seconds 00:08:45.049 --> 00:08:48.350 that have elapsed since midnight on January 1st, 00:08:48.350 --> 00:08:51.769 1970 in coordinated universal time. Wow. Wait, 00:08:51.769 --> 00:08:53.909 so it's just one number? Just one number. It 00:08:53.909 --> 00:08:56.350 is a single relentless integer ticking upward 00:08:56.350 --> 00:08:58.470 every single second. It doesn't care about time 00:08:58.470 --> 00:09:00.309 zones. It doesn't care about leap months. It 00:09:00.309 --> 00:09:03.450 is purely objective machine time. Just a massive 00:09:03.450 --> 00:09:06.289 32 bit or 64 bit integer constantly growing in 00:09:06.289 --> 00:09:09.889 the background. OK, but a human system administrator 00:09:09.889 --> 00:09:12.610 can't just look at a log file that says event 00:09:12.610 --> 00:09:15.029 occurred at 1 .7 billion seconds and actually 00:09:15.029 --> 00:09:17.029 know what that means. No, of course not. The 00:09:17.029 --> 00:09:19.289 machine still needs to translate that raw integer 00:09:19.289 --> 00:09:22.490 back into a human readable date. And that translation 00:09:22.490 --> 00:09:24.990 process is handled by a function called straftime. 00:09:25.269 --> 00:09:27.830 It takes a time structure and formats it into 00:09:27.830 --> 00:09:29.690 a readable string. I see where this is going. 00:09:30.090 --> 00:09:33.389 Right. Just like print needed format specifiers 00:09:33.389 --> 00:09:35.950 to know where to insert variables, strifetime 00:09:35.950 --> 00:09:38.610 relies on a whole library of placeholders to 00:09:38.610 --> 00:09:41.149 format the date. Like what? Well, you can use 00:09:41.149 --> 00:09:45.370 %y for the year, %m for the month, but our disambiguation 00:09:45.370 --> 00:09:49.049 page specifically highlights %s. Okay, but in 00:09:49.049 --> 00:09:52.429 the context of this time function, %s does not 00:09:52.429 --> 00:09:55.570 mean insert a string of text. Right? Correct. 00:09:56.090 --> 00:09:59.809 In StrafTime, %s means extract the raw integer 00:09:59.809 --> 00:10:02.070 of the Unix timestamp. Wait, I want to make sure 00:10:02.070 --> 00:10:04.450 I'm following the logic there. The compiler designers 00:10:04.450 --> 00:10:06.450 had a whole alphabet of letters to choose from. 00:10:06.549 --> 00:10:10.230 They did. Why recycle the exact same %s symbol 00:10:10.230 --> 00:10:13.269 that already universally means C string and assign 00:10:13.269 --> 00:10:16.129 it to mean raw integer of seconds in a completely 00:10:16.129 --> 00:10:18.129 different function? I mean, that just seems like 00:10:18.129 --> 00:10:20.909 a massive recipe for confusion. It seems counterintuitive 00:10:20.909 --> 00:10:23.149 at first glance, absolutely. But it actually 00:10:23.149 --> 00:10:26.210 reveals this beautiful efficiency in system design. 00:10:26.769 --> 00:10:29.409 We have to look at the desired output of the 00:10:29.409 --> 00:10:32.029 strut time function. The entire goal of that 00:10:32.029 --> 00:10:34.529 function is to generate a formatted string of 00:10:34.529 --> 00:10:37.549 text for a log file or a display. Even though 00:10:37.549 --> 00:10:39.929 the Unix timestamp is an integer under the hood, 00:10:40.350 --> 00:10:42.210 the system needs to print it out as a sequence 00:10:42.210 --> 00:10:45.129 of text characters. So the fundamental nature 00:10:45.129 --> 00:10:47.370 of the placeholder hasn't actually changed. Oh, 00:10:47.509 --> 00:10:49.629 it's still basically saying, hey, something dynamic 00:10:49.629 --> 00:10:52.330 belongs here and I will format it as a string 00:10:52.330 --> 00:10:54.899 for the final output. Exactly. It's highly context 00:10:54.899 --> 00:10:56.840 dependent. So the system parser looks at the 00:10:56.840 --> 00:10:59.700 function calling it. If it's a standard input 00:10:59.700 --> 00:11:02.600 or output memory allocation, percents means look 00:11:02.600 --> 00:11:05.399 for a null terminated character array. Yes. But 00:11:05.399 --> 00:11:07.639 if it's system time formatting, percents means 00:11:07.639 --> 00:11:10.059 grab the epoch seconds integer and stringify 00:11:10.059 --> 00:11:12.740 it. You know that. That is incredibly elegant. 00:11:13.100 --> 00:11:16.019 It basically acts as a universal translator between 00:11:16.019 --> 00:11:19.000 the machine's infinite ticking clock and the 00:11:19.000 --> 00:11:23.240 human need to pinpoint a reality in a text file. 00:11:23.480 --> 00:11:26.039 And that elegance is exactly why the convention 00:11:26.039 --> 00:11:29.480 has survived for over 50 years. The underlying 00:11:29.480 --> 00:11:32.899 complexity of memory pointers and 64 -bit integers 00:11:32.899 --> 00:11:35.639 is completely abstracted away by those two simple 00:11:35.639 --> 00:11:38.100 characters. Which perfectly sets up the final, 00:11:38.200 --> 00:11:40.159 and honestly, maybe the most surprising section 00:11:40.159 --> 00:11:41.960 of our source material. Leaving out of the back 00:11:41.960 --> 00:11:44.200 end. Exactly. Because we've been swimming in 00:11:44.200 --> 00:11:46.519 the deep back end this whole time, memory addresses, 00:11:47.080 --> 00:11:49.929 POSX standards, Unistee Box. But the deep dive 00:11:49.929 --> 00:11:52.669 surface is right to the front end interface now. 00:11:52.809 --> 00:11:55.769 Right to where the user is sitting. Yes. The 00:11:55.769 --> 00:11:58.169 same symbol operating deep in the memory allocation 00:11:58.169 --> 00:12:01.269 of an operating system is actively used by everyday 00:12:01.269 --> 00:12:04.690 web surfers. It really is. According to the disambiguation 00:12:04.690 --> 00:12:07.350 page, percent functions in modern web browsers 00:12:07.350 --> 00:12:10.600 as a smart bookmark marker. It's used in quick 00:12:10.600 --> 00:12:12.779 search boxes for customization in browsers like 00:12:12.779 --> 00:12:15.519 Opera, Chromium, and Firefox. This is a perfect 00:12:15.519 --> 00:12:17.820 example of back -end logic bleeding into front 00:12:17.820 --> 00:12:20.519 -end user agency. To appreciate what is happening 00:12:20.519 --> 00:12:22.860 mechanically here, we need to think about how 00:12:22.860 --> 00:12:25.399 a web browser actually interacts with a search 00:12:25.399 --> 00:12:28.480 engine. When you go to a massive site like Wikipedia 00:12:28.480 --> 00:12:32.340 or YouTube, you usually use their graphical user 00:12:32.340 --> 00:12:34.480 interface. Yeah, I load the homepage, I find 00:12:34.480 --> 00:12:36.720 the search bar in the DOM, I type my query, and 00:12:36.720 --> 00:12:38.960 I click the little magnifying glass icon. Right. 00:12:39.139 --> 00:12:41.279 And then the website processes your request and 00:12:41.279 --> 00:12:43.639 loads a new page with your results. Standard 00:12:43.639 --> 00:12:46.200 internet stuff. But underneath that graphical 00:12:46.200 --> 00:12:48.779 interface, the website is really just processing 00:12:48.779 --> 00:12:52.019 an HTTP GET request. OK, break that down for 00:12:52.019 --> 00:12:54.639 me. When you search for, say, black holes on 00:12:54.639 --> 00:12:57.620 a site, the browser takes your search term, encodes 00:12:57.620 --> 00:13:01.480 it, and appends it to the site's URL as a query 00:13:01.480 --> 00:13:03.399 string parameter. Oh, like when the URL gets 00:13:03.399 --> 00:13:06.220 super long at the top? Yes. The resulting URL 00:13:06.220 --> 00:13:09.419 might look something like domain .com slash search 00:13:09.419 --> 00:13:12.179 question mark q equals black plus holes. Right, 00:13:12.179 --> 00:13:15.539 right. The website's server reads that URL, extracts 00:13:15.539 --> 00:13:17.779 the query parameter, and serves the results. 00:13:18.159 --> 00:13:20.399 OK, so here's where it gets really interesting. 00:13:21.679 --> 00:13:25.240 say that browsers like Firefox and Chromium allow 00:13:25.240 --> 00:13:27.940 you to set up a smart bookmark by taking that 00:13:27.940 --> 00:13:31.539 target site's search URL, stripping out the specific 00:13:31.539 --> 00:13:35.159 query, and replacing it with %s. Exactly. So 00:13:35.159 --> 00:13:37.019 you save a bookmark that just looks like domain 00:13:37.019 --> 00:13:41.600 .com slash search question mark q equals %s. 00:13:41.759 --> 00:13:45.340 Yes, and the browser natively understands that 00:13:45.340 --> 00:13:49.379 %s is an argument marker. It recognizes it as 00:13:49.379 --> 00:13:51.970 an argument string, basically a blank space waiting 00:13:51.970 --> 00:13:54.090 for dynamic input. I've heard people describe 00:13:54.090 --> 00:13:57.330 this as like a digital teleportation pad where 00:13:57.330 --> 00:13:59.669 you type a word in the address bar and it magically 00:13:59.669 --> 00:14:02.129 beams into the website's search engine. Teleportation 00:14:02.129 --> 00:14:04.669 pad is fun, but mechanically... Mechanically 00:14:04.669 --> 00:14:06.450 isn't it much more like a train switch track? 00:14:06.590 --> 00:14:08.129 A train switch track. Okay, walk me through that 00:14:08.129 --> 00:14:10.289 analogy. Well, think about it. The browser's 00:14:10.289 --> 00:14:12.929 address bar is the track. Normally, if I typed 00:14:12.929 --> 00:14:15.590 a standard URL, the train just drives straight 00:14:15.590 --> 00:14:17.350 down the track to that specific destination. 00:14:17.389 --> 00:14:19.529 Okay, I follow. But with a smart bookmark... 00:14:19.559 --> 00:14:22.740 I assign a custom keyword. Let's say I just use 00:14:22.740 --> 00:14:25.399 the letter W for Wikipedia. The browser has my 00:14:25.399 --> 00:14:27.960 template URL saved in the background, complete 00:14:27.960 --> 00:14:31.179 with the %s placeholder, which acts as the switch 00:14:31.179 --> 00:14:34.320 mechanism on the track. Right. When I type W 00:14:34.320 --> 00:14:37.639 followed by my search term, my payload, basically 00:14:37.639 --> 00:14:41.039 the browser sees the keyword, activates the switch 00:14:41.039 --> 00:14:43.559 track, and natively concatenates my search term 00:14:43.559 --> 00:14:45.799 directly into the middle of that URL string. 00:14:45.879 --> 00:14:48.480 right where the %S is sitting. That is a much 00:14:48.480 --> 00:14:50.500 more accurate representation of the mechanism, 00:14:50.799 --> 00:14:52.899 yes. So it isn't teleporting. No, the browser 00:14:52.899 --> 00:14:55.179 is performing local string substitution before 00:14:55.179 --> 00:14:57.779 it ever makes a network request. Locally. Yes. 00:14:58.240 --> 00:15:00.059 It takes the argument string you provided in 00:15:00.059 --> 00:15:03.240 the address bar, finds the %S in your saved smart 00:15:03.240 --> 00:15:05.720 bookmark template, swaps the placeholder for 00:15:05.720 --> 00:15:09.659 your text, and then fires off the HTTP GET request. 00:15:09.840 --> 00:15:12.899 So it completely bypasses the home page's user 00:15:12.899 --> 00:15:16.009 interface. It skips loading the DOM. It skips 00:15:16.009 --> 00:15:18.370 the graphical search bar. Exactly. It just routes 00:15:18.370 --> 00:15:20.909 my payload directly into the site's backend query 00:15:20.909 --> 00:15:23.090 parameters. And this raises a really important 00:15:23.090 --> 00:15:25.049 question about how we interact with the web. 00:15:25.629 --> 00:15:29.330 By utilizing Percent S as a smart bookmark marker 00:15:29.330 --> 00:15:32.610 for your quick search boxes, the user is effectively 00:15:32.610 --> 00:15:36.070 bypassing the curated, heavily designed experience 00:15:36.070 --> 00:15:38.690 that websites want you to have. That's so true. 00:15:38.769 --> 00:15:41.669 You are stripping away all the bloated UI of 00:15:41.669 --> 00:15:44.539 the modern internet. interacting almost directly 00:15:44.539 --> 00:15:46.559 with the database routing of the servers you 00:15:46.559 --> 00:15:49.379 visit. It totally empowers the user to just hack 00:15:49.379 --> 00:15:52.059 their own browser workflow I mean instead of 00:15:52.059 --> 00:15:55.139 being a passive consumer endlessly clicking through 00:15:55.139 --> 00:15:58.460 menus, you are using a piece of legacy programmer 00:15:58.460 --> 00:16:01.440 logic to dictate the exact flow of information. 00:16:01.879 --> 00:16:03.340 Precisely. You literally just type a keyword, 00:16:03.620 --> 00:16:06.419 hit space, enter your term, and boom, you instantly 00:16:06.419 --> 00:16:08.419 generate the exact search results page you wanted. 00:16:08.600 --> 00:16:11.059 And the fact that browser developers chose %s 00:16:11.059 --> 00:16:13.299 for this exact feature is not an accident at 00:16:13.299 --> 00:16:15.299 all. They could have used any syntax in the world. 00:16:15.320 --> 00:16:17.500 They could have used an asterisk or brackets 00:16:17.500 --> 00:16:20.039 or a custom variable like, you know, bracket, 00:16:20.279 --> 00:16:21.940 insert search here bracket. Right, something 00:16:21.940 --> 00:16:24.399 more human readable. But the developers building 00:16:24.399 --> 00:16:27.539 Chromium and Opera and Firefox are software engineers. 00:16:27.919 --> 00:16:31.200 They were raised on C and Unix. To them, PerSense 00:16:31.200 --> 00:16:34.460 natively means insert dynamic string here. It 00:16:34.460 --> 00:16:37.419 was just the most logical, universally understood 00:16:37.419 --> 00:16:40.580 convention to use for a tile replacement feature. 00:16:40.940 --> 00:16:44.139 It's the ultimate blank check in computing. And 00:16:44.139 --> 00:16:46.100 tracing its journey through the source material 00:16:46.100 --> 00:16:49.200 today really gives you a profound sense of how 00:16:49.200 --> 00:16:51.679 technology iterates on itself. It really does. 00:16:51.860 --> 00:16:53.820 I mean, we started with the rigid memory architecture 00:16:53.820 --> 00:16:56.740 of C. We watched percents act as a strict pointer 00:16:56.740 --> 00:16:59.500 for character arrays so that print and scamp 00:16:59.840 --> 00:17:02.279 could handle human text without triggering buffer 00:17:02.279 --> 00:17:04.839 overflows. Right. And then we saw how that same 00:17:04.839 --> 00:17:07.440 convention of handling the unknown was adapted 00:17:07.440 --> 00:17:11.220 by POSIX standards to basically wrangle the abstraction 00:17:11.220 --> 00:17:13.759 of time itself. This is wild. Straftime uses 00:17:13.759 --> 00:17:16.339 the exact same two characters to pull the relentless, 00:17:16.380 --> 00:17:19.299 invisible count of the Unix epoch and format 00:17:19.299 --> 00:17:21.900 it into a reality that a human system administrator 00:17:21.900 --> 00:17:24.579 can actually read. And finally, we watch that 00:17:24.579 --> 00:17:27.000 logic surface right in the address bars of Chromium, 00:17:27.240 --> 00:17:30.349 Opera, and Firefox. placeholder became a front 00:17:30.349 --> 00:17:32.970 -end tool, allowing us to perform local string 00:17:32.970 --> 00:17:35.869 concatenation and bypass website interfaces through 00:17:35.869 --> 00:17:39.009 Custy HTTP routing. It really highlights a defining 00:17:39.009 --> 00:17:41.809 characteristic of digital infrastructure. What's 00:17:41.809 --> 00:17:44.289 that? Well, we often assume that as technology 00:17:44.289 --> 00:17:46.930 becomes more advanced, the underlying code must 00:17:46.930 --> 00:17:49.390 become entirely unrecognizable from what came 00:17:49.390 --> 00:17:51.789 before. Sure, we assume it's constantly reinvented. 00:17:51.869 --> 00:17:54.109 But efficiency dictates that when a solution 00:17:54.109 --> 00:17:57.170 perfectly solves a fundamental problem, like 00:17:57.170 --> 00:18:00.430 how to safely hold space for unknown beta, that 00:18:00.430 --> 00:18:03.539 solution becomes immortalized. The complexity 00:18:03.539 --> 00:18:06.019 of the modern web is built entirely on these 00:18:06.019 --> 00:18:08.859 simple, reliable agreements established decades 00:18:08.859 --> 00:18:12.500 ago. It's basically the quiet, functional scaffolding 00:18:12.500 --> 00:18:14.859 holding up the sleek drywall of the internet. 00:18:14.960 --> 00:18:16.700 That's a great way to put it. And I think that 00:18:16.700 --> 00:18:18.859 is the most compelling takeaway for you listening 00:18:18.859 --> 00:18:21.539 today. Every single time you use a quick search 00:18:21.539 --> 00:18:24.099 box or a smart bookmark in your browser, you 00:18:24.099 --> 00:18:26.460 aren't just using a neat UI trick. No, you're 00:18:26.460 --> 00:18:29.559 actively participating in a 50 -year -old computing 00:18:29.559 --> 00:18:32.880 tradition. Exactly. You are reli— on the exact 00:18:32.880 --> 00:18:35.059 same logic that helps core operating systems 00:18:35.059 --> 00:18:37.619 manage system memory and understand the flow 00:18:37.619 --> 00:18:40.480 of time. It connects your daily mundane web surfing 00:18:40.480 --> 00:18:42.960 directly to the foundational history of computer 00:18:42.960 --> 00:18:45.099 science. Which leaves us with a lingering thought 00:18:45.099 --> 00:18:47.779 to chew on as we wrap up this deep dive. We've 00:18:47.779 --> 00:18:49.839 spent this entire time exploring how a simple 00:18:49.839 --> 00:18:53.140 two -character marker from the 1970s is still 00:18:53.140 --> 00:18:55.680 silently parsing our URLs and routing our daily 00:18:55.680 --> 00:18:58.960 internet traffic in 2026. Yeah. If the sleek 00:18:58.960 --> 00:19:01.579 modern digital world is still completely dependent 00:19:01.579 --> 00:19:04.480 on a legacy C format specifier to understand 00:19:04.480 --> 00:19:07.619 our intent, how many other invisible decades 00:19:07.619 --> 00:19:09.819 old placeholder conventions are quietly dictating 00:19:09.819 --> 00:19:11.740 the boundaries of the technology you use every 00:19:11.740 --> 00:19:12.140 single day?