You have clicked past thousands of cookie banners. You have probably never asked the obvious question: why cookies? The name has nothing to do with baking, and it is not an acronym invented by a marketing department. It came from an old Unix term, borrowed in 1994 by a 24-year-old engineer solving a problem that still defines how connected systems are built.
The problem: the web had no memory
HTTP is stateless by design. Every request arrives at the server as a complete stranger. The server answers it, forgets everything, and waits for the next one. That was a deliberate and rather elegant choice for a protocol built to serve linked documents — it kept servers simple and made them scale.
It also made a shopping cart impossible. In 1994, Netscape Communications was working with a client who wanted exactly that: an online store where the items you picked on one page were still there on the next. There was no mechanism for it. The server had no way to tell whether two requests came from the same person.
One option was to keep a table of every visitor in server memory. That does not scale, and it means the server is holding state for people who wandered off ten minutes ago. Netscape engineer Lou Montulli took the opposite approach: make the client carry the state. The server hands the browser a small piece of data, the browser stores it, and it sends that data back on every subsequent request to the same site. The server stays stateless. The browser does the remembering.
Where the name came from
Montulli did not invent the concept, only its application to the web. Programmers already had a word for a small opaque token that gets handed to something and comes back unchanged: a magic cookie. The term was well established in Unix circles, describing data a program receives, holds onto without inspecting or understanding, and returns later to prove continuity. The recipient does not need to know what is inside — that is the whole point.
That is exactly what a browser does with a cookie. It stores an opaque string it cannot interpret and hands it back on request. So Montulli clipped "magic cookie" to "cookie," and the name stuck.
The mechanism shipped in Netscape Navigator and spread quietly. Most users had no idea it existed until press coverage in early 1996 put cookies in front of a general audience and kicked off the privacy debate that has never really stopped. The IETF formalised the mechanism in RFC 2109 in 1997, and RFC 6265 replaced it in 2011 as the specification still in force.
Why this matters for embedded and IoT systems
Here is the part that makes the story more than trivia. Your IoT devices do not send cookies — a temperature sensor on an ESP32 is not running a browser. But they use the exact same architectural pattern, and understanding the lineage makes the design decisions clearer.
A connected device authenticates once, receives a token, and presents that token on every subsequent call — over HTTPS to a REST endpoint, or as credentials in an MQTT CONNECT packet. The device treats that token as opaque. It does not parse it, validate it, or understand its contents. It stores it and hands it back. The broker or API server, meanwhile, keeps no per-device session in memory; it validates the token on arrival and stays stateless. That is Montulli's 1994 design running on a microcontroller with 320 KB of RAM.
Once you see it that way, three things stop looking like plumbing and start looking like the core of your fleet's security posture:
Expiry. A cookie has a lifetime, and so should a device token. A credential that never expires is a credential that is compromised forever the moment someone dumps your firmware. Short-lived tokens with refresh are harder to implement on constrained hardware, but they turn a permanent breach into a temporary one.
Rotation. Cookies get reissued. Device credentials need the same treatment, which means your firmware architecture has to support receiving and persisting new credentials over the air — a requirement that is painful to retrofit and cheap to design in from the start.
Revocation. The hardest one. Cookies can be invalidated server-side; a stolen device token needs the same kill switch. If your only answer to a compromised device is a firmware recall, you do not have a security model.
The same reasoning applies to what you put in the token. Web cookies moved from storing user data directly to storing an opaque session identifier, precisely because the client is not a trustworthy place to keep anything meaningful. Devices in the field are even less trustworthy — they can be physically opened, their flash read, their traffic intercepted. Assume the token will be extracted, and design so that extraction is survivable.
The pattern outlives the name
Thirty-plus years on, cookie banners have made the word faintly annoying to most people. But the idea underneath is one of the more durable pieces of engineering the web produced: push state to the edge, keep the server stateless, and use an opaque token as the thread that stitches requests together. It scaled the web to billions of users, and it is scaling IoT fleets now for exactly the same reason.
Building connected hardware or the web platform behind it? Fluidwire works across the whole stack — firmware, PCB design, and the cloud services that tie a fleet together. Tell us what you are building and we will tell you honestly whether we are the right fit.
Top comments (0)