We made the internet usable by making it invisible.
That was a good trade for adoption and a bad trade for understanding.
Most developers can write fetch() calls all day without a clear mental model of DNS, TCP, TLS, and HTTP. Most users can spend their whole lives online without ever learning what a resolver does, why a certificate warning matters, or why “the site is down for me” could mean fifteen different things before the request ever reaches the app server.
I don’t mean this as nostalgia for hand-editing modem settings.
I mean it as an observation that opacity has costs, and the bill keeps showing up in security and operations.
The Abstraction Stack
Every layer of the internet hides the one below it. HTTP hides TCP. TLS hides the handshake. DNS hides the resolution chain. Cloud services hide servers. Frameworks hide HTTP. And at the very top, a developer writes fetch('/api/data') and expects it to work.
When it works, abstraction is beautiful. Productivity goes up. Barrier to entry goes down. You don’t need to understand packet fragmentation to build a web app. Good.
When it breaks, abstraction becomes a wall. The developer who never learned what DNS does can’t debug a resolution failure. The one who doesn’t know what CORS is spends three hours fighting browser errors. The one who copied a TLS configuration from a blog post can’t explain what any of the settings mean when the auditor asks.
The Cost of Not Knowing
I see the same patterns over and over:
DNS misconfiguration that nobody can debug. A migration goes wrong. The site is down. The team stares at the deploy pipeline because that’s the system they understand. Nobody checks DNS because nobody has a mental model of how DNS propagation works, what TTL means, or why the old records are still cached somewhere.
Security headers copied without understanding. A scanner says “add these headers.” The team adds them. One of them — Content-Security-Policy — breaks the site because nobody understood what it does. They add 'unsafe-inline' to make it stop breaking. The header is now present and useless. The scanner is green. The security is theater.
TLS errors treated as mysteries. “The certificate is fine, I just renewed it.” But the intermediate is missing. Or the hostname doesn’t match. Or HSTS is set with a one-day max-age. Nobody on the team knows what these mean because TLS is something the cloud provider handles. Until it doesn’t.
CORS confusion. Developers fight CORS errors for hours without understanding that CORS is a browser security mechanism, not a server bug. They find a Stack Overflow answer that says “add Access-Control-Allow-Origin: *” and the error goes away. They’ve removed the security. The error going away was the bad outcome.
Cloud Made It Worse
Managed services are incredible for productivity and terrible for understanding.
When you provision a database with a button click, you don’t learn about replication, connection pooling, or backup verification. When your DNS is managed by a CDN, you don’t learn about zone files, delegation, or TTL. When your TLS certificate is auto-provisioned, you don’t learn about key management, CA trust, or certificate chains.
This is fine until something goes wrong. Then you’re debugging a system you’ve never seen the inside of, using a mental model that stops at “I clicked the button and it worked before.”
The cloud didn’t just abstract away servers. It abstracted away the knowledge of how servers work. An entire generation of developers has built production systems without ever SSH-ing into a machine, reading a log file directly, or configuring a network interface.
The Generational Shift
Early internet users had to understand protocols to get online. Not deeply — but enough. You configured DNS servers in your network settings. You knew what an IP address was because you typed them. You had a rough model of “my computer talks to a server, the server sends back a page.”
Current users have no such model. The internet is a magic window. Content appears. If it doesn’t, something is broken and someone else should fix it.
This isn’t a complaint about users. Users shouldn’t need to understand TCP. The abstraction is correct for users.
The problem is when developers and system administrators have the same level of understanding as users. When the people responsible for building and operating internet services treat the underlying protocols as someone else’s problem.
What We Could Do
I’m not arguing that everyone should understand BGP or read RFCs. But basic mental models would prevent an entire category of mistakes:
“DNS translates names to numbers, and the translation is cached for a while” — this one sentence prevents half of all DNS confusion during migrations.
“HTTPS encrypts the connection, not the site. The padlock means encrypted, not trustworthy” — this prevents misplaced trust in phishing sites.
“A CDN caches your site closer to users, but if the CDN goes down, your site goes down too” — this sets correct expectations about infrastructure dependencies.
“CORS is the browser stopping a request that might be dangerous, not the server being broken” — this saves hours of confused debugging.
These aren’t deep technical concepts. They’re one-paragraph explanations. And most people building on the internet don’t have them.
The Irony
We’ve built the most sophisticated communication system in human history, and the people using it — even the people building on it — mostly don’t know how it works. The abstraction succeeded so completely that the knowledge it was abstracting over is disappearing.
The internet runs on DNS, TCP, TLS, HTTP, and BGP. These protocols were designed by people who understood every layer. They’re now operated by people who understand almost none of them. The gap is filled by automation, managed services, and hope.
It works. Usually. When it doesn’t, the debugging takes ten times longer than it should because nobody has the mental model to know where to look.
We didn’t stop teaching how the internet works on purpose. We just made it unnecessary to know. And then we confused “unnecessary” with “unimportant.”