Daniel's been thinking about cookies — not the kind you eat, the kind that follow you around the web. He wants to know why we need them in the first place, whether they're becoming less important, and how they actually enable that thing where you add a jacket to your cart on your phone and somehow it's waiting for you on your laptop. There's a lot of confusion about what cookies actually do versus what people think they do, so let's dig in.
And the timing is perfect, because we're living through the tail end of the biggest cookie upheaval in web history. Chrome's been phasing out third-party cookies for years, Safari and Firefox already did it, and as of right now we're down to roughly one percent of Chrome users still on third-party cookies. The thing most people don't realize is that almost none of this affects the cookies that keep you logged in or keep your shopping cart intact. Completely different category.
Which is exactly where the confusion lives. People hear "cookies are dying" and assume the whole mechanism is being retired. So let's rewind to nineteen ninety-four and ask: why did we need cookies in the first place?
The problem is that HTTP is stateless. Every single request your browser makes to a server is a completely fresh handshake. The server has no memory of who you are or what you just did. You could be on page three of a checkout flow and the server treats you like a stranger who just walked in off the street. That was fine for serving static documents, which is what the early web was — here's a page, here's another page, they don't need to know about each other.
And then someone tried to build a shopping cart.
Lou Montulli at Netscape in nineteen ninety-four. He was twenty-three years old, working on the Netscape browser, and e-commerce was starting to become a thing. The problem was brutally simple: a user adds an item to their cart, clicks to another page, and the cart is empty because the server has no idea they're the same person. Montulli needed a way for the browser to carry a little token that said "hey, it's me again." So he invented the cookie. The original spec was about three pages long.
Three pages. That's a recipe for dinner, not a core internet protocol.
And it shows in what it didn't include. No encryption, no expiration controls, no concept of same-site versus cross-site. It was a quick hack to solve an immediate problem. The server sends a Set-Cookie header in its response, the browser stores it, and on every subsequent request to that domain the browser echoes it back in a Cookie header. That's it. That's the whole mechanism.
So walk me through what actually happens when I visit an online store and add something to my cart.
You land on the site, your browser sends a GET request. The server generates a unique session ID — something like "A-B-C-one-two-three" — and sends back the page along with a header that says Set-Cookie: session equals A-B-C-one-two-three. Your browser stores that cookie in its cookie jar, keyed to that domain. When you click "add to cart," your browser sends another request, and this time it automatically attaches Cookie: session equals A-B-C-one-two-three. The server sees that, looks up the session in its database, and says "ah, this is the same user — I'll add the jacket to their cart record." Every click, every page load, that cookie rides along silently.
And if I close the browser and come back?
Depends on whether the server set an expiration. If it's a session cookie with no expiration, the browser deletes it when you close. If it's a persistent cookie with an explicit Expires or Max-Age attribute, the browser keeps it on disk. So when you come back tomorrow, the cookie is still there, the browser sends it, and the server recognizes you. Your cart is still waiting.
Which is the thing everyone experiences but nobody thinks about until it breaks. Now, where does this go wrong when people talk about cross-device sync? Because that's the part Daniel was asking about — the jacket on the phone showing up on the laptop.
This is the single biggest misconception about cookies. Cookies do not sync across devices. They can't. They're stored locally in each browser's cookie jar. Your phone has one set of cookies, your laptop has a completely different set. There is no magic cookie cloud that follows you around.
So how does the cart actually follow me?
The cookie is just a key. On your phone, the cookie contains session ID "A-B-C-one-two-three." On your laptop, it's a completely different session ID — "X-Y-Z-seven-eight-nine." The trick is that both of those session IDs map to the same user account in the server's database. When you log in on your phone, the server creates a session and links it to user ID forty-two. When you log in on your laptop, the server creates a different session and links that to user ID forty-two. The cart isn't stored in cookies — it's stored in the database, under user ID forty-two. Both sessions point to the same cart because they point to the same user.
So the cookie is the valet ticket, not the car.
And the car lives in the server's garage. When people say "cookies sync my cart across devices," they're attributing magic to a mechanism that's actually quite dumb. The cookie just says "I am session X." Everything else happens server-side.
Which means if you're not logged in, cross-device sync is impossible, regardless of cookies.
Correct. And that's a deliberate design choice by most e-commerce platforms. Some sites try to do anonymous cross-device matching using fingerprinting or IP addresses, but that's fragile and increasingly blocked by browsers. The reliable path is: log in, and the server connects the dots. The cookie is just the transport layer for the session token.
Let's back up to the architecture for a second. You mentioned the cookie jar is per-domain. How does that differ from the Same-Origin Policy?
This is where a lot of developers get tripped up. The Same-Origin Policy is about JavaScript access to data — it says a script from one origin can't read data from another origin. So a script on evil-dot-com can't read your banking page's local storage. Cookies don't follow the Same-Origin Policy. They follow domain matching. A cookie set for example-dot-com will be sent to example-dot-com and all its subdomains, regardless of protocol or port. So H-T-T-P-S colon slash slash example-dot-com and H-T-T-P colon slash slash example-dot-com both get the cookie, unless you set the Secure flag.
Which is why Cross-Site Request Forgery is a thing.
If you're logged into your bank and you visit a malicious site, that site can trigger a request to your bank's domain. Your browser will happily attach your session cookie, because the request is going to the bank's domain. The bank sees a valid session and processes the request. That's CSRF in a nutshell, and it only works because cookies don't respect origins — they respect domains.
And local storage is different?
Local storage is scoped to the exact origin — protocol, domain, and port. A script on one origin cannot read local storage from another origin, period. But local storage also doesn't get sent automatically with requests. You have to explicitly attach it via JavaScript. That's both a security feature and a usability limitation — it means local storage can't replace cookies for things like automatic session identification on page load.
So cookies are less secure by design, but more convenient by design.
That's the trade-off. And it's why the flags matter so much now. HttpOnly means JavaScript can't read the cookie, which blocks a whole class of cross-site scripting attacks. Secure means the cookie only goes over H-T-T-P-S. SameSite equals Lax or Strict controls whether the cookie is sent on cross-site requests. With all three flags set properly, a first-party session cookie is actually quite robust. The insecurity usually comes from misconfiguration, not from the mechanism itself.
Which brings us to third-party cookies and why they're being dismantled. What's the actual distinction?
A first-party cookie is set by the domain you're visiting. You go to amazon-dot-com, amazon-dot-com sets a cookie. That's first-party. A third-party cookie is set by a different domain that's embedded on the page. Amazon's page includes an ad iframe from doubleclick-dot-net, and that iframe sets a cookie under doubleclick-dot-net. Now every site that embeds a DoubleClick ad can read that same cookie, because it's always doubleclick-dot-net setting and reading it. That's how cross-site tracking works — the third-party cookie becomes a persistent identifier that follows you across completely unrelated sites.
And this is what's actually being killed.
Yes. Safari started blocking third-party cookies by default in twenty seventeen with Intelligent Tracking Prevention. Firefox followed with Enhanced Tracking Protection in twenty nineteen. Chrome announced deprecation in twenty twenty, went through multiple delays, and is now in the final rollout. The Privacy Sandbox APIs are the intended replacements — the Topics API for interest-based advertising, the Protected Audience API for remarketing, the Attribution Reporting API for measuring ad effectiveness.
But here's what I think most people miss: none of this touches first-party cookies. Your login session, your shopping cart, your site preferences — those all still work exactly the same way.
And that's the second big misconception. "Cookies are dying" means third-party cookies are dying. First-party cookies are not going anywhere. They're too fundamental to how the web works. Every alternative to first-party cookies — local storage, token-based auth in headers, federated identity — either requires JavaScript to function or doesn't provide the same automatic, passive session continuity.
So what actually changes for the average user?
The visible change is that ads stop following you around quite so aggressively. You look at a pair of shoes on one site and they don't haunt you across every other site you visit for the next three weeks. The invisible change is that the ad tech industry is scrambling to rebuild its targeting infrastructure around first-party data and the Privacy Sandbox APIs. Instead of a third-party cookie that says "user six-one-four-seven likes hiking," you get the Topics API, where the browser itself infers your interests locally and shares broad topic categories with advertisers — and only for a limited time.
The browser becomes the gatekeeper instead of the ad network.
Which is exactly what Corn observed a while back — the web is moving from tracking being everyone's game to being the browser vendor's game. Google, Apple, and Mozilla now decide what tracking is allowed and what isn't. That's a massive shift in who controls web privacy.
And it creates an interesting knock-on effect. If you can't track users anonymously across sites, the incentive is to push them to log in everywhere. Every site wants you authenticated, because that's the only reliable way to build a persistent user profile.
The authenticated web. And it's already happening. More login prompts, more paywalls, more "sign in with Google" buttons. The death of third-party cookies is accelerating the consolidation of identity into a handful of large platforms. Google, Facebook, Apple — they become the identity providers for the entire web. That has privacy implications that are arguably worse than third-party cookies. With cookies, tracking was distributed across thousands of ad networks. With federated identity, it concentrates in three or four companies.
It's the privacy whack-a-mole we keep seeing. You solve one problem and create a different one. But let's talk about what developers should actually be doing right now, because Daniel's question is practical — are cookies becoming less important, and what replaces them?
For first-party functionality, cookies are not becoming less important. They remain the standard mechanism for session management. What is changing is that developers need to stop relying on third-party cookies for anything. If you have a feature that depends on a third-party cookie — an embedded widget, a cross-site integration, an analytics tracker that uses its own domain's cookies — it's already broken for the vast majority of users.
What about legitimate cross-site uses? An embedded payment widget from Stripe, for example.
That's what CHIPS is for — Cookies Having Independent Partitioned State. It lets a third-party service set a cookie that's partitioned by the top-level site. So Stripe embedded on site A gets a different cookie than Stripe embedded on site B. The cookie still works for the payment flow, but it can't be used to track the user across sites. There's also the Storage Access API, which lets a third-party iframe request permission to access its cookies, with the browser prompting the user or applying heuristics to decide.
So the tools exist, but they require explicit opt-in rather than working silently in the background.
And that's the theme of the whole transition. The web is moving from implicit, invisible state sharing to explicit, user-visible permission models. Cookies were a hack that worked by default for twenty-five years. We're now adding the consent and scoping that should have been there from the start.
Let's talk about the cross-device question more practically. Daniel mentioned e-commerce carts syncing across devices. If I'm building a shopping experience today, what's the right architecture?
Design around authenticated sessions from the start. Don't try to do anonymous cross-device sync — it's fragile, it's increasingly blocked, and it's a terrible user experience when it fails silently. The server-side database is your source of truth. When a user logs in on any device, you create a session, link it to their user account, and all their data — cart, preferences, order history — is available immediately because it's stored against the user record, not the session.
And the cookie is just the session key.
Just the key. The real engineering work is in the backend — making sure your session store is fast, your database queries are efficient, and your cart merge logic handles edge cases. What happens when a user has items in an anonymous cart and then logs in? Do you merge the anonymous cart with their saved cart? Do you replace one with the other? Those are product decisions, but they're enabled by the architecture of having a single source of truth server-side.
Which brings us to the audit question. If you're running a site today, what should you check about your cookie usage?
First, look at every cookie you set and ask whether you actually need it. A surprising number of sites set cookies by default just because the framework does — session cookies, CSRF tokens, analytics identifiers. Some of those are essential, some aren't. Second, check your flags. Every cookie that's used for authentication should have HttpOnly and Secure set. SameSite should be Lax at minimum, Strict if you can tolerate it. Third, set explicit expirations. Don't rely on session cookies for anything that should persist — if you want a user to stay logged in for thirty days, set Max-Age to two million five hundred ninety-two thousand seconds and be done with it.
Two million five hundred ninety-two thousand seconds. That's a very Herman way to say thirty days.
It's the actual value that goes in the header. The browser doesn't know what a "day" is.
Fair enough. And what about the transition away from third-party cookies? If I'm running ads or analytics?
If you're in ad tech, you're already deep in the Privacy Sandbox migration. The Topics API, Protected Audience, Attribution Reporting — these are the new primitives. They're more complex than just dropping a third-party cookie, but they preserve some of the use cases while adding privacy guardrails. If you're a publisher running ads, you need to make sure your ad stack supports these APIs, because the old programmatic infrastructure is breaking. If you're just running analytics on your own site, first-party cookies are fine — Google Analytics four, for example, uses first-party cookies and doesn't rely on third-party cookies at all.
So the practical advice is: audit your first-party cookies, abandon any third-party cookie dependencies, and move cross-device logic server-side.
And if you're building something new, don't even think about third-party cookies. They're a dead mechanism walking. Design your architecture assuming every user interaction starts stateless and you need to establish identity explicitly.
Which is, in a weird way, returning to the original problem Montulli was solving in nineteen ninety-four. HTTP is stateless. Every request is a stranger. We've just spent thirty years building layers on top of that, and now we're peeling some of them back.
But with one crucial difference. In nineteen ninety-four, the answer was "let the browser carry a token automatically." In twenty twenty-six, the answer is increasingly "let the user authenticate explicitly, and let the server manage state." The token is still there — it's still a cookie in most cases — but the trust model has flipped. We used to trust the browser to manage identity passively. Now we're moving toward active, user-mediated identity.
Which is where Federated Credential Management comes in. FedCM, the thing that's supposed to make "sign in with Google" not just be a privacy nightmare in a different wrapper.
FedCM is Google's proposal for a privacy-preserving federated identity API. Instead of the identity provider dropping a third-party cookie that tracks you everywhere, the browser mediates the login flow. The identity provider tells the browser "this user is logged in," and the browser tells the website "here's a token, but I'm not telling you who the identity provider is unless the user consents." It's a step toward decoupling identity from tracking. But adoption is slow, and the big identity providers have mixed incentives.
They benefit from the tracking.
They benefit enormously from the tracking. Every "sign in with Google" button gives Google visibility into which sites you use and when. FedCM would limit that visibility. So there's a tension between the privacy-preserving architecture and the business models of the companies that need to implement it.
So given all of that, where does this leave us? Are cookies becoming less important?
Third-party cookies are becoming extinct. First-party cookies are as important as ever. The mechanism isn't going away — the scope is narrowing. We're moving from a web where any domain could set a cookie that followed you everywhere to a web where cookies are tightly scoped to the site you're actually visiting. The cookie itself is just a delivery mechanism for tokens, and tokens aren't going anywhere. What's changing is who controls the token and what it can be used for.
And the cross-device sync that Daniel was asking about — that's not a cookie story at all. That's a database story with cookies playing a bit part.
The cookies are the nametags at the door. The actual party is happening in the server room.
If you take one thing from this whole discussion, it's that cookies are keys, not vaults. They don't store your cart, they don't sync your devices, and they're not following you around the web. They're just little tokens that say "I am this session." The intelligence — and the privacy risk — lives in what the server does with that information.
And the second thing is that the cookie deprecation you keep hearing about is specifically about third-party tracking cookies. Your login sessions, your shopping carts, your site preferences — those cookies aren't going anywhere. But you should still audit them, because misconfigured cookies are a security liability whether they're first-party or third-party.
One question keeps nagging at me, though. We're trading cross-site tracking by ad networks for centralized identity silos run by Google, Apple, and Facebook. Is that actually better? With third-party cookies, tracking was distributed and relatively transparent — you could block it, clear it, inspect it. With federated identity, your login becomes the tracking mechanism, and it's much harder to opt out of being logged into your own accounts.
That's the tension that FedCM and the various privacy proposals are trying to address, but none of them have really solved it yet. The post-cookie web might be more private in the sense that random ad networks can't build profiles on you, but it might also be more concentrated in the sense that three companies know everywhere you go online. Whether that's a net win depends on how much you trust those three companies.
And whether you have any choice in the matter. Thanks as always to our producer Hilbert Flumingtop for making this show happen. This has been My Weird Prompts. If you want to send us your own questions — about cookies, about web architecture, about why your shopping cart keeps emptying itself — email the show at show at my weird prompts dot com. We'll be back soon.
