DEV Community: Shreyansh Builds

I Walked Away from Cybersecurity. A Phishing Attempt on My Own Code Dragged Me Back In.

Shreyansh Builds — Wed, 07 Oct 2026 13:55:02 +0000

Last year, I stopped concentrating on cybersecurity. A different technical domain piqued my interest and got me distracted. That being said, recently an automated phishing campaign hit my production content. I write technical articles on dev.to and recently got a notification for a comment left on one of my posts. The account was supportdev. The comment was extremely urgent social engineering to create a sense of panic:

Dear User,
Due tо an inсrеase in bot activitу оn the рlatform, wе rеquire vеrify оf yоur account.
Pleаsе lоg іn vіa thе link belоw:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadlinе - 12 hours.
Sincerely, Dev Suрport

When I clicked through, it was exactly what you'd expect from a credential-harvesting trap: a cloned dev.to logo paired with a custom Vue-rendered payment form aggressively demanding credit card details to "verify" my identity.

My dormant cybersecurity brain suddenly woke up. This huge, completely irrational adrenaline rush I got.

Logic tells me I had one data point and one only. A single spam comment on a blog post. A normal user would just hit "Delete" and move on. But my brain didn't see it logically. It went straight into full Hollywood movie logic.

You know those cyber-thriller movies where the lone hacker finds a random, tiny glitch, starts pulling at the thread, and suddenly it escalates into a high-stakes battle between a random guy in his room and a massive, shadowy global syndicate?

That's just the sort of kick I wanted. I did not want this to be a lonely spam bot. I wanted this to be a big automated network. I wanted the excitement of the chase. I wanted to be the random guy that exposes the infrastructure.”

So, with just movie delusion and a long-standing love for forensics, I opened my Linux terminal and tried to map it out.

Phase 1: Technical Breakdown of the Initial Lure

Before diving into the network architecture, I would like to decompose the exact comment code. The attackers were using a clever way around automated guardrails.

1. Unicode Homoglyph Obfuscation

When I ran the raw string of the comment through a character inspector, the mechanism for evading dev.to's automated spam filters became clear. The attacker wasn't using standard Latin text. They relied on Unicode homoglyphs—characters from different scripts (like Cyrillic) that look identical to Western characters to the human eye but have entirely different hex values:

Expected Latin o (U+006F) was replaced with Cyrillic о (U+043E).
Expected Latin a (U+0061) was replaced with Cyrillic а (U+0430).
Expected Latin e (U+0065) was replaced with Cyrillic е (U+0435).

By salting the copy with these characters, the text reads flawlessly to a panicked user while looking like completely benign, non-blacklisted strings to simple regex or automated keyword filters.

2. Initial Infrastructure Reconnaissance

I dropped the URL path into a basic WHOIS evaluation to finger the domain anti-bot.icu.

bash

$ whois anti-bot.icu
Domain Name: ANTI-BOT.ICU
Registrar: PDR Ltd. / PublicDomainRegistry
Creation Date: 2026-09-25T08:30:32Z
Registry Expiry Date: 2027-09-25T23:59:59Z

Use code with caution.

The domain had been provisioned exactly two days before the account was spun up and deployed. The operation was fresh, active, and running on a tightly controlled timeline. I immediately packaged this data and submitted a formal abuse ticket to PublicDomainRegistry (Case #53471908) requesting an immediate infrastructure suspension.

Phase 2: Bypassing the Anti-Analysis Defenses

This is where the cinematic hunt became highly technical. When security researchers look at a phishing site, threat actors look back. The kit was heavily armored to prevent anyone from investigating its source code.

1. Client-Side Fingerprinting and Cloaking

When I attempted to extract the site’s raw HTML payload using a standard command-line utility, the origin server rejected the handshake:

$ curl -A "Mozilla/5.0" https://anti-bot.icu
HTTP/1.1 403 Forbidden
Content-Type: text/html

The application was employing defensive user-agent and client-side cloaking. It checked for valid browser headers, canvas rendering parameters, and Cloudflare verification loops before exposing the actual malicious payload. If you weren't browsing from a real, active desktop profile, it served a generic, custom HTML page stating "Oops! Something is wrong." to hide its intent.

I successfully bypassed this cloaking ring by routing an isolated scanner (urlscan.io) to capture an authentic browser engine fingerprint and hold a persistent cf_clearance cookie session.

2. The Rickroll Debugger Trap

Once inside the DOM, things got genuinely hilarious. The kit developers embedded an anti-forensics library called console-ban v3.2.0.

The scripts were configured to detect whenever the browser's Developer Tools panel (F12 or Ctrl+Shift+I) was opened. The absolute millisecond a security engineer opened DevTools to inspect the active network sockets, the library triggered an infinite loop of execution blocks via a debugger; statement, locked up the browser tab, and forcibly redirected the window to a Rickroll music video.

// Conceptual representation of the console-ban defensive routing
import ConsoleBan from 'console-ban';
ConsoleBan.init({
  redirect: 'https://youtube.com', // The Trap
  write: 'Debugger active. Access denied.'
});

To complement this, the page disabled standard context menus (oncontextmenu="return false"), blocked text selection, intercepted Ctrl+U / Ctrl+S commands, and applied a subtle hue-rotate(4deg) CSS filter layout to frustrate simple visual analysis and automated screenshot matches.

Phase 3: Deconstructing the Data Harvesting Engine

Once the cloaking and defense walls were cleared, the core system opened up. The actual phishing landing zone was a slick, multi-tiered credential-harvesting machine.

                   [ Client Browser ] 
                           │
                           ▼ (Bypasses 403 Cloak)
                [ "ACCOUNT VERIFICATION" ]
           (Hotlinked dev.to wordmarks & logos)
                           │
                           ▼ (User clicks "Verify")
                  [ /merchant/order/id ]
            (Vue.js Client App / Fake Card UI)
                           │
                           ▼ (Real-time tracking)
                [ Socket.IO WebSocket ]
         (Real-time push / Scripted Operator Chat)

1. The Cloned Interface

The root landing page was configured with full multi-language translation architecture natively handling 10 separate languages (EN, DE, FR, IT, ES, PL, PT, NL, TR, RU) dynamically parsed through navigator.language to scale the attack vector globally.

function detectLang() {  
  var lang = (navigator.language || navigator.userLanguage || 'en').toLowerCase().substring(0,2);  
  var supported = ['en','de','fr','it','es','pl','pt','nl','tr','ru'];  
  return supported.indexOf(lang) >= 0 ? lang : 'en';  
} // Kit multi-language evaluation logic

2. The Vue-Driven Card Capture UI

The checkout path located at /merchant/order/<campaign_id> was not standard, static HTML. It was configured as a client-side rendered Single Page Application (SPA) built on Vue.js v2.6.10 and vue-swal v1.0.0. This architectural choice explains why primitive HTTP scraper bots could never capture the input elements—they required an active Javascript runtime environment to paint the capture form onto the screen.

To maximize social-engineering trust, the developers baked in an animated payment card wrapper element with a highly unique hook: a dummy field masking dropdown that read "Unlock your account to view autofill suggestions".

This gave the illusion of an actual, integrated OS or security browser function, building synthetic legitimacy so users would input their full card names, CVVs, and expiry parameters.

At the bottom of the form layout, fine print explicitly asserted:

"By clicking 'Next', you confirm your intention to connect your account to Square API."

This is a false/borrowed brand reference. The page had no physical integration with Square’s engineering APIs—it was purely using the trusted financial identity of a massive global payment processor to lower user defenses.

3. Real-Time WebSockets & Scripted Social Engineering

The kit featured a highly responsive chat component at /supportChatFrame/<id> driven by a custom supportSocketClient.js payload. The engine opened a direct WebSocket communication channel to a Node.js/Express backend, assigning each target session a unique client identification string:

// Extracted payload elements
socket.emit('register', {
  adId: '5K0N5G7M9C4',
  supportToken: localStorage.getItem('supportToken')
});

The system tracked user activity in real time. If a target paused or hesitated on the input page, the WebSocket automatically pushed scripted responses down the line to combat user skepticism:

"If you are afraid to enter your card data, do not worry, because the data is double encrypted with the PCI24 protocol..."

Security Check: There is no such thing as "PCI24". The recognized financial framework is PCI DSS. The kit simply fabricated a technical-sounding acronym to manufacture credibility and pressure victims.

The Smoking Gun: Mapping the Broader Network

This wasn’t a minor, isolated script running out of a single garage. It was part of an extensive, highly automated software kit.

Two days after submitting my initial report, the plot escalated. By running behavioral profiling across dev.to, I uncovered 5 distinct accounts (including handles like devsupportss and devsupporte) all leveraging the exact same automated comments.

Simultaneously, a parallel infrastructure nodes emerged through independent URL shorteners (tr.ee/dev-verified) pointing to a second active domain: antibot.casa.

When I extracted the raw source files for both anti-bot.icu and antibot.casa, I hit the ultimate architectural link. Deep within the components of both independent deployment instances sat an identical, explicit developer comment left inside the source tree:

<!--Добавляем div для вставки дополнительного HTML-кода-->

Translated directly from Russian, it states: "Adding a div for inserting additional HTML code."

Forensic Interpretation

While a shared language artifact in code doesn't provide concrete geopolitical attribution (as phishing kits are routinely bought, leaked, and shared across global dark web forums), it serves as a definitive architectural fingerprint. It proves with near-absolute certainty that both domains were generated by the exact same centralized, reusable multi-brand phishing kit deployment process.

Threat Remediation and Current Status

Thanks to the rapid processing of the compiled evidence log, the infrastructure take-down was a complete success:

anti-bot.icu: Officially suspended by PublicDomainRegistry under Case #53471908.
supportdev: Account completely neutralized and now returns a clean 404 Not Found.
antibot.casa: Taken down independently shortly after discovery.
Secondary Accounts: Instantly caught by dev.to’s automated heuristics engines and forcibly locked down into inactive spam_* handles.

Indicator of Compromise (IOC)	Type	Entity Status	Forensic Link Confidence
`anti-bot.icu`	Domain	SUSPENDED	Confirmed (Primary landing zone)
`antibot.casa`	Domain	OFFLINE	High (Identical templates & code comments)
`supportdev`	DEV Account	MUTED (404)	Confirmed (Source of spam vector)
`<!--Добавляем div...-->`	Code Artifact	ACTIVE FINGERPRINT	Confirmed (Shared kit software footprint)

This entire case served as a massive personal wake-up call. Sometimes walking away from a technical field like cybersecurity is the only way to remind yourself why you fell in love with it in the first place. It took an automated threat actor targeting my own platform content to give me that real-world Hollywood movie rush again.

The hunt is ongoing. I am continuing to trace passive OSINT indicators, monitor certificate transparency chains, and log shortener vectors to track exactly where this kit attempts to re-surface its infrastructure next.

Stay safe, double-check your platform administration alerts, and never trust a support message that requires credit card data to verify your terminal workspace.

Is AI Making Us Dumber? 🤔

Shreyansh Builds — Mon, 28 Sep 2026 06:27:02 +0000

A few years ago, when I was just getting started with programming, I built a proper game using Pygame. It wasn't anything revolutionary, and it certainly wasn't going to win any awards, but I remember the process. I had to actually think. How should the player move? How should collisions work? What happens when something hits something else? How should I structure the logic? Why isn't this thing working?

I'd search through documentation, read things I didn't completely understand, try something, break something, debug it, change it, run it again, and eventually figure out what was wrong. Sometimes I'd spend hours solving something that, looking back, was probably a very simple problem.

But the important part wasn't that I eventually wrote the code. I had to do the thinking required to get there.

And that's what has been bothering me lately.

Not because AI can't do these things. It absolutely can. In many cases, it can do them faster than I can. And that's exactly where the problem gets interesting.

We used to do the thinking first

When AI first started becoming a serious part of everyday software development, I think most of us viewed it primarily as a tool for executing tasks. You still had to understand what you wanted, research the problem, go through documentation, figure out why something wasn't working, make decisions, and then ask the machine to help you implement it. AI was helping with the execution; the thinking was still largely ours.

But that boundary has been moving.

Today, I can describe an idea to an AI and have it research the problem, read documentation, decide on an approach, write the implementation, encounter an error, debug it, change the implementation, and try again. Suddenly, the entire process that used to require me to sit down and mentally wrestle with a problem can happen with a few prompts.

That's incredible.

It's also a little unsettling.

Because we usually call this productivity. And technically, it is. If I can produce the same result in two hours instead of ten, I've become more productive.

But there's another ratio we don't really talk about:

Output produced vs. thinking performed.

What happens to that ratio when we keep pushing more and more of the thinking onto AI?

The thing we don't measure

Imagine two people building the same application. The first person spends ten hours building it. They read documentation, make architectural decisions, write code, encounter bugs, debug them, change their approach, and eventually finish.

The second person gives the requirements to an AI agent. The agent researches the relevant libraries, writes most of the code, runs it, fixes the errors, and produces something usable in two hours.

Who was more productive? Obviously, the second person — at least if we're measuring productivity by output divided by time.

But did the second person learn as much? Did they exercise the same problem-solving ability? Did they develop the same intuition for recognizing bad architecture? Did they understand the same number of failure modes?

Maybe. Maybe not.

And that's the difficult part to measure.

We've become very good at measuring what AI helps us produce. We're not nearly as good at measuring what happens to the abilities we no longer need to exercise.

It's a bit like going to the gym and hiring someone else to lift the weights for you. You still got the weights moved. You just didn't get stronger.

Obviously, thinking isn't as simple as muscle strength, and AI isn't literally doing all of our thinking for us. But the analogy raises an uncomfortable question:

If we constantly outsource a particular kind of thinking, do we eventually become worse at doing it ourselves?

And this isn't just about coding

This is where I think the conversation gets much bigger than software development. AI is slowly moving into almost every domain where humans perform cognitive work. Students can ask AI to explain an entire chapter, solve their homework, summarize a book, create flashcards, and even write their assignments. Writers can ask AI to research a topic, create an outline, generate a draft, and rewrite it. Designers can describe an idea and get a visual representation in seconds.

Researchers can use AI to search through enormous amounts of information and summarize findings. Analysts can feed data into AI and ask it to find patterns. People can ask AI to write emails, make presentations, plan trips, analyze documents, explain complicated concepts, and make decisions between different options.

And the technology is only getting better.

The important part isn't that AI can now do these things. The important part is how much of the process we're willing to hand over to it.

Because there's a difference between:

"Help me do this."

and:

"Do this for me."

That difference might seem small.

It isn't.

The convenience trap

Let's take something extremely ordinary. Suppose you're trying to understand a new technical concept. Before AI, you might have searched for documentation, found three different explanations, rejected one because it was terrible, found another that was too advanced, watched a video, read some Stack Overflow answers, tried an example yourself, encountered an error, and gone back to the documentation.

It was inefficient.

It was also learning.

Today, you can simply ask:

"Explain this to me like I'm a beginner."

And you'll probably get a pretty good explanation immediately.

That's fantastic.

But here's the problem: the difficult part of learning something isn't always understanding the final explanation. Sometimes the difficult part is getting to the explanation yourself. Searching, comparing, being confused, following the wrong path, realizing you're wrong, trying again, and connecting two seemingly unrelated pieces of information are all part of the process.

That entire process is mentally expensive.

And that's exactly why we want to avoid it.

AI is incredibly good at removing that friction, which is precisely what makes it so useful — and potentially, precisely what makes it dangerous when we use it for everything.

We are optimizing for the wrong thing

Modern technology has spent decades trying to remove friction from our lives, and we've gotten extremely good at it. We have calculators because doing arithmetic manually is slow. Search engines because looking through encyclopedias is slow. GPS because figuring out routes manually is slow. Autocorrect because typing everything perfectly is annoying.

And now we have AI because thinking through certain tasks is slow.

In isolation, none of these things are bad. In fact, they're incredible. But there's a subtle difference between removing unnecessary work and removing useful mental effort.

If I use a calculator to multiply two large numbers, I'm probably not losing anything important. But if I use AI to solve every programming problem I encounter without ever trying to understand the problem myself, I'm not just saving time. I'm also skipping the mental exercise that comes with solving it.

And unlike a calculator, AI doesn't just automate one narrow operation. It can increasingly handle entire chains of cognitive work.

That's a very different kind of tool.

The productivity paradox

Here's the weird part: the better AI gets, the harder this problem becomes.

Imagine AI becomes so good that it can build an entire application from a few paragraphs. Why would I spend six hours learning a framework? Why would I read the documentation? Why would I debug the issue myself? Why would I understand how the system works internally?

If AI can do it better and faster, the rational decision seems obvious:

Let AI do it.

And that's where I think the productivity conversation gets incomplete.

There are actually two different outcomes.

More output 📈

I can build more things, write more, research faster, automate more tasks, and learn certain things faster. That's genuinely valuable.

Less practice 📉

I solve fewer problems myself, spend less time being stuck, read less documentation, make fewer decisions from first principles, encounter fewer failures, and spend less time figuring things out.

And those things were never just obstacles.

They were also practice.

So we might end up in a strange situation where our output per hour keeps increasing while our independent problem-solving ability doesn't increase at the same rate — or perhaps even declines in some areas because we're practicing less.

I don't think we know yet exactly how large that effect will be.

But I think it's worth taking seriously.

What happens when AI enters the decision-making loop?

There's another step that worries me even more.

Using AI to execute a decision is one thing. Using AI to make the decision itself is another.

Imagine I tell an AI:

"Build me a web application."

It can generate the code. Fine.

Now imagine I say:

"Decide what architecture I should use, which database I should choose, which libraries I should use, and how the system should be structured."

Now I've delegated part of the engineering judgment.

Go one step further:

"Research the market, figure out what product I should build, identify the target users, create the strategy, and build the MVP."

Now AI isn't just executing. It's participating in deciding what should be done in the first place.

We're entering a world where a small team — or even one person — can use AI systems to perform work that previously required entire groups of people. You can build companies with AI, create products with AI, produce marketing material with AI, conduct research with AI, and automate operations with AI.

That's an incredible expansion of individual capability.

But it also means we're increasingly allowing machines to participate in the parts of the process that used to require human judgment.

And I don't think we should blindly assume that this has no cost.

The dependency loop 🔄

This is the part that I find the most interesting.

Imagine this happens gradually: AI gets better → we use it more → we practice certain skills less → those skills become less familiar → doing the task manually starts feeling harder → we rely on AI even more → AI gets better again.

And the cycle continues.

Eventually, something that you could do yourself starts feeling unnecessarily difficult because you haven't exercised that ability in a long time.

That's what I mean when I say:

Are we slowly getting dumber?

Not necessarily in the sense that our intelligence is disappearing. But perhaps we're becoming less capable of operating independently in areas where we've stopped practicing.

There's an important distinction there.

But should we just stop using AI?

Absolutely not.

At least, I don't think that's the answer.

It would be ridiculous to argue that we should go back to doing everything manually just because doing things manually requires more thinking. We didn't stop using calculators because people were worried about arithmetic skills. We didn't stop using search engines because people were worried about memorization. We didn't stop using compilers because programmers might forget how to write machine code.

Technology is supposed to make us more capable.

And AI can absolutely do that.

The question isn't:

"Should we use AI?"

The better question is:

"What should we use AI for?"

There are tasks where I have no problem handing things over completely. If I need to transform a large amount of repetitive data, automate some boring task, or generate a first draft that I will heavily modify, why would I waste hours doing it manually?

That's exactly what tools are for.

But there are other things where I think the struggle itself is valuable: learning, problem-solving, writing, research, designing systems, making decisions, and understanding why something works.

And sometimes, I think we should deliberately not take the shortcut.

Maybe we need an "AI gym" 🏋️

Here's the funny thing: we already understand this concept in other parts of our lives.

If you want to become physically stronger, you don't just buy a machine that lifts weights for you. You exercise. If you want to become better at playing an instrument, you don't listen to someone else play every song for you. You practice.

If you want to become better at solving problems, perhaps you also need to actually solve problems.

Maybe we need the equivalent of an AI gym — a place where we deliberately practice doing things without AI.

Not because AI is evil. Not because humans are inherently better. But because some abilities are worth maintaining.

Maybe that means occasionally reading documentation without asking an AI to summarize it, trying to debug a problem yourself before asking for the answer, writing something from scratch before asking AI to improve it, researching a topic yourself before asking AI to summarize the research, or trying to design a solution before asking AI to design one for you.

And then using AI afterward as a second opinion, a reviewer, a teacher, or an accelerator.

That feels very different from simply asking:

"Do this for me."

So, is AI making us dumber?

I don't know.

And I don't think anyone can confidently answer that question yet.

AI is still relatively new, and the long-term effects of widespread cognitive outsourcing are difficult to measure. Maybe we'll adapt. Maybe our definition of useful intelligence will change. Maybe AI will free humans from boring cognitive work and allow us to focus on more creative and meaningful problems.

I hope that's what happens.

But I also think there's a risk that we become so good at getting answers that we forget how to find them. So good at generating things that we forget how to create. So good at asking AI to solve problems that being stuck with a problem starts feeling unbearable.

And maybe that's the thing we should be careful about.

Because AI becoming smarter isn't necessarily the problem.

The problem would be if we became less willing — or less capable — of thinking for ourselves.

I still use AI. A lot. And honestly, I don't see myself stopping.

But sometimes, when I find myself about to ask AI to solve something, I try to stop for a moment and ask myself:

"Do I actually need help with this, or am I just avoiding the thinking?"

Maybe that's the balance we're going to have to figure out.

Because the goal of AI shouldn't be to make humans unnecessary.

It should be to make humans more capable.

And if we're not careful, we might optimize so hard for productivity that we forget to ask what capabilities we're trading for it.

What Happens Before a Network Packet Leaves Your Device?

Shreyansh Builds — Thu, 17 Sep 2026 17:11:44 +0000

Have you ever wondered what actually goes on behind the scenes when we type youtube.com and hit Enter?

Let's remove the whole internet for a moment.

Forget about all the routers, cables, data centers and servers. Let's just focus on your laptop.

How does a request actually leave your laptop and enter the universe of the internet?

That's what we're going to look at.

And don't worry, we're not going to treat a "server" like it's some magical computer sitting in a secret room somewhere. A server can literally be another computer running some software and waiting for requests.

The same goes for a lot of the other things we'll encounter — they're mostly just different pieces of software and hardware doing specific jobs.

So let's start with something familiar.

Let's open YouTube

Let's take youtube.com as our example — one of the most used sites on the internet.

When we type youtube.com, the browser actually interprets this request roughly as:

https://www.youtube.com/

Or, conceptually:

www.youtube.com:443

The first one might be familiar to a lot of you people.

But what the hell is the second one?

The 443 is the port.

By default, when we use HTTPS, port 443 is used. There's another one — the less secure guy — HTTP, which traditionally runs on port 80.

But wait, what exactly is a port?

If you're wondering what ports are and how they work, well, that would make another article.

For simplicity, there is something called an IP address, which is like the address of a device, and ports are like small rooms inside that device.

A device can be running many different network applications at the same time. One application might be waiting for connections on one port, while another application is using a different port.

So when we say:

93.184.216.34:443

we're essentially saying:

"I want to communicate with port 443 on the device having IP address 93.184.216.34."

The IP address helps us identify which device we're trying to reach, while the port helps identify which network service on that device we're trying to talk to.

And just like we have domain names because remembering IP addresses for every website would be a nightmare, we also have names for commonly used network protocols.

HTTP and HTTPS are two of them, but there are many others.

DNS is used for translating domain names into IP addresses. SMTP is used for sending email. FTP is used for transferring files.

There are many more protocols, each designed for different kinds of communication.

If you're wondering how all these protocols actually work, well, that can make several more articles.

For now, let's stay with our YouTube example.

What does the browser actually want?

Now that we have a destination and a protocol, what is the browser actually trying to communicate?

At the HTTP level, a simplified request could look something like this:

GET / HTTP/1.1
Host: www.youtube.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Now, what the hell are we looking at here?

This is simply the browser describing what it wants from the server.

GET is the HTTP method. It basically tells the server that we want to retrieve something.

The / represents the root resource of the website.

HTTP/1.1 tells the server which version of HTTP is being used.

And then we have:

Host: www.youtube.com

which tells the server which website we're trying to access.

There are also several other headers here. They can carry information about things like the browser, accepted content types, compression, language, cookies, caching and so on.

If this looks like a lot of information for something as simple as opening a website, don't worry about it.

At this level, the important thing is simply that the browser has some data it wants to send.

And eventually, that data is going to become part of a network packet.

Not a magical internet object.

Just data, with some additional information attached to it so that the different parts of the network know what to do with it.

But there is a problem.

The browser can't simply take this HTTP request and throw it at the Wi-Fi adapter.

There are several things that need to happen first.

That's where our laptop's operating system and networking stack enter the picture.

Before the packet leaves

So, the next time you type a URL into your browser, remember that the request doesn't magically jump from the browser into the internet.

It starts as something very simple:

data that an application wants to send somewhere.

From there, different parts of your computer work together to figure out where that data needs to go, how it should be packaged, and how it can eventually be handed over to the network.

And all of this happens before the packet ever leaves your device.

What looks like a simple action — typing youtube.com and hitting Enter — is actually your browser, operating system, networking stack and network hardware quietly working together in a fraction of a second.

The internet may look like this huge, complicated thing from the outside. But when you zoom in, it's mostly a collection of smaller, understandable pieces doing their jobs and passing data between each other.

And that, to me, is what makes networking interesting.