How Every Major Browser Quietly Made Cookie Management Harder — and Why That's Not an Accident

There was a time, not so long ago, when Firefox shipped with a per-site cookie manager. It lived in Preferences, under Privacy, and it did exactly what you'd expect: it listed every domain that had planted a cookie in your browser, let you inspect them individually, and let you delete them surgically — one site at a time, without touching anything else. It was a small, unglamorous feature, and nobody wrote breathless blog posts about it. It was just there. And then, gradually, it wasn't.

The removal didn't arrive as a dramatic announcement. There was no changelog entry that read "Removed: the thing that let you control your own browser." It happened the way these things always happen — through successive rounds of UI "simplification," each one individually defensible, each one removing a small lever of control from the user's hand. The old cookie list became the "Manage Data" dialog at about:preferences#privacy, which still technically lets you search by domain and delete selectively, but which is now buried deep enough that most users will never find it. The lock icon in the address bar offers a "Clear cookies and site data" button, but only for the site you're currently visiting — you can't use it to audit or prune your broader cookie footprint. And the old right-click-and-delete granularity? Gone entirely from the mainstream UI. If you want that level of control now, you need the Web Developer Tools and the Storage Inspector — a workflow designed for developers debugging authentication flows, not for ordinary users managing their own privacy.

Firefox isn't alone in this. It's not even the worst offender. Chrome has never offered meaningful per-site cookie management in its consumer UI. Safari hides cookie controls behind a "Privacy" tab that most users interpret as a Do Not Track toggle and nothing more. Brave, to its credit, blocks aggressively by default, but even Brave has moved toward coarser-grained controls over time. The trend is universal and it is moving in one direction: away from user control and toward managed defaults that happen to serve advertising infrastructure.

The question worth asking is not why did Firefox remove this feature but why did every browser converge on the same answer at the same time.

Follow the Money to Mountain View

Mozilla is a nonprofit. This is the thing people say when they want to distinguish Firefox from Chrome, and it's technically true — the Mozilla Foundation is a 501(c)(3). But the Mozilla Corporation, which actually builds Firefox, is a taxable subsidiary, and its finances tell a story that undermines any romantic notion of nonprofit independence.

Mozilla's CFO, Eric Muhlheim, testified during the Google antitrust trial that roughly 85% of Mozilla's revenue comes from a single source: Google paying to be Firefox's default search engine. In the 2022 financial statement — the most recent publicly available at the time — that meant $510 million out of $593 million in total revenue came from Google search royalties. The current deal expires at the end of 2026, and after Judge Mehta's September 2025 ruling in the DOJ antitrust case allowed Google to continue making such payments, Mozilla can presumably negotiate a renewal. But the structural dependency remains: Firefox's survival is funded by the world's largest advertising company.

This is not a conspiracy theory. It's a publicly reported financial arrangement. But it does mean that every Firefox product decision exists within a context where the organization's primary revenue source has a direct, material interest in how cookies behave in the browser. Google doesn't need to send Mozilla a memo that says "make cookie deletion harder." The incentive structure speaks for itself. When your funder makes money from persistent user tracking, you are unlikely to ship features that make it trivially easy to disrupt that tracking. You don't have to be corrupt for this dynamic to operate. You just have to be an organization that wants to continue existing.

The Google antitrust trial surfaced how deeply this dependency runs. Mozilla's own financial officer used the phrase "downward spiral" to describe what would happen to Firefox without the Google deal. Other browsers like Vivaldi and Brave have built alternative revenue models that don't depend on Big Tech partnerships, but Mozilla — despite two decades and hundreds of millions of dollars annually — never diversified in any meaningful way. That failure isn't incidental to the cookie question. It's the substrate on which the cookie question sits.

The Dark Pattern of Inconvenience

Let's be precise about what happened. Nobody at Mozilla — or Google, or Apple — sat in a conference room and said "let's make it harder for users to delete cookies so advertisers can track them longer." That's not how institutional incentive corruption works. What happens instead is subtler and more durable: features that serve user autonomy get deprioritized. They don't get maintained. They accumulate UI debt. Eventually someone on the UX team flags them as "confusing" or "low-engagement" and proposes folding them into a simpler interface. The meeting where the feature dies is full of people who genuinely believe they're improving the product. The outcome is indistinguishable from deliberate sabotage, but the process is almost entirely unconscious.

This is a textbook dark pattern, and it has a name: friction as policy. The idea is simple. You don't need to prevent users from doing something if you can make it annoying enough that most of them don't bother. Every additional click between "I want to delete this cookie" and "this cookie is deleted" is a filter. Each step eliminates a percentage of users who would otherwise have cleaned their cookie jar. The ones who remain — the power users, the privacy-conscious, the people reading articles like this one — are a rounding error in the engagement metrics. The ad industry doesn't care about us. They care about the 95% who never open about:preferences at all.

The result is a browser landscape where cookie persistence is the default and cookie management is an expert activity. This is precisely the arrangement that maximizes advertising value. The longer a cookie lives, the more behavioral data it accumulates, the richer the advertising profile, the higher the CPM. A cookie that gets deleted after every session is worthless for behavioral targeting. A cookie that persists for months because the user never found the "Manage Data" button is a goldmine.

The Security Case Nobody's Making

The conversation about cookies is almost always framed in terms of privacy and advertising. But there's a security dimension that deserves more attention, because it changes the risk calculus entirely.

Stale cookies are an attack surface.

An authentication cookie that persists for weeks or months after you last actively used a site is a session hijacking target. If an attacker can exfiltrate that cookie — through XSS, a compromised extension, a man-in-the-middle attack on an unencrypted connection, or even physical access to the machine — they can impersonate your session without needing your password. The longer the cookie lives, the wider the window of vulnerability. Sites that set long-lived session cookies without proper rotation or binding are endemic on the web, and the user's only defense is to delete those cookies regularly.

Beyond session hijacking, persistent cookies are tracking vectors with a time dimension. A cookie that spans months of browsing builds a behavioral fingerprint that is far more identifying than a cookie that covers a single session. Cross-site tracking — even with third-party cookies increasingly restricted — still functions through first-party cookie chaining, where a network of sites owned by or affiliated with the same advertising entity share identifiers through first-party cookies and server-side syncing. Deleting cookies frequently disrupts these chains. Leaving them in place completes them.

There's also the question of forensic footprint. Cookies are artifacts. They record where you've been, when you were there, and often what you did. On a shared machine, a compromised machine, or a machine subject to legal discovery, a fat cookie store is a detailed behavioral record that you never consciously chose to create. The user who would have deleted these cookies weekly — who would have, if the browser still made it easy — is now carrying months of browsing history in a format that's trivially readable by anyone with access to the filesystem.

The security framing matters because it recontextualizes the "simplification" narrative. When Mozilla or Google removes fine-grained cookie controls and calls it a UX improvement, they're not just making a privacy tradeoff. They're making a security tradeoff. They're increasing the attack surface of every user who would have pruned their cookies but no longer does. And they're doing it in the name of simplicity.

What Still Works

The situation is not hopeless, but the solutions now require the user to do work that the browser used to do for them. Here's what's still available as of mid-2026.

Firefox's surviving controls. The about:preferences#privacy path still works. Navigate there, scroll to "Cookies and Site Data," and click "Manage Data" (or "Manage browsing data" in newer builds). This opens a dialog that lets you search by domain and delete selectively. It's clunky, it requires you to know which domains to search for, and it doesn't support any kind of automated schedule — but it exists. Additionally, clicking the lock (or shield) icon in the address bar while on a site gives you a "Clear cookies and site data" option for that specific domain. This is useful for one-off cleanups but doesn't scale to routine maintenance.

The Storage Inspector. Firefox's Web Developer Tools include a Storage tab that provides full, granular access to cookies, localStorage, sessionStorage, IndexedDB, and cache storage for the current site. You can right-click individual entries and delete them. This is the closest thing to the old per-site cookie manager, but it's a developer tool, not a user tool. You access it via Ctrl+Shift+I (or Cmd+Opt+I on macOS) and navigate to the Storage tab. The fact that this level of control now lives exclusively in developer tooling tells you everything about how the browser vendors view cookie management: it's a debugging feature, not a user right.

Cookie AutoDelete. This is the extension that most directly replaces what Firefox took away — and then goes further. Cookie AutoDelete automatically wipes cookies from domains when you close their tabs, with a whitelist for sites where you want persistence (your self-hosted services, banking, anything you actually want to stay logged into). It restores the "default delete, exception keep" model that is the only sane default for a security-conscious setup. The original Cookie AutoDelete extension was effectively killed on Chrome by the Manifest V3 transition in mid-2025, but a forked version migrated to MV3 remains available on GitHub for sideloading into Chromium browsers. On Firefox, it still works through the standard extension store.

uBlock Origin. Beyond its well-known ad and tracker blocking, uBlock Origin provides per-site controls that include cookie-related filtering. It's not a dedicated cookie manager, but in combination with its dynamic filtering rules, it can prevent cookies from being set in the first place for domains you don't trust. On Firefox, uBlock Origin remains fully functional. On Chrome, the Manifest V3 transition has degraded its capabilities, which is itself another chapter in the same story.

Container Tabs (Firefox only). Firefox Multi-Account Containers let you isolate sites into separate cookie jars. Cookies set in one container don't leak into another. This doesn't solve the deletion problem directly, but it limits the blast radius of persistent cookies — a banking site's cookies in a "Finance" container can't be read by anything in your general browsing container. Combined with Cookie AutoDelete, containers provide a defense-in-depth approach to cookie hygiene.

The Bigger Picture

The cookie management story is a microcosm of a broader pattern in consumer software: the steady removal of user-facing controls under the banner of simplification. The word "simplification" does real rhetorical work here. It frames the removal of capability as a gift to the user — we're making things easier for you — when the actual beneficiary is the platform's business model. The user who loses the ability to selectively delete cookies hasn't been simplified. They've been disempowered.

This pattern recurs across the entire browser ecosystem. Chrome removed the ability to disable individual extensions per-site. Safari removed the ability to view and manage individual website permissions in a consolidated list. Firefox removed the old about:config warning page and replaced it with a more alarming one, adding friction to the power-user workflow. Each change, in isolation, is minor. In aggregate, they constitute a systematic transfer of control from the user to the platform.

The trend also maps onto a broader shift in how the technology industry relates to its users. The operating assumption used to be that users owned their machines and the software was a tool that served them. The current assumption — embedded in every "simplified" UI, every buried setting, every grayed-out option — is that users are participants in a platform and the software mediates their relationship to it. Cookie management is a perfect case study because cookies are literally the mechanism by which this mediation occurs. The cookie is the artifact of the platform's claim on the user's behavior. Making it harder to delete is making it harder to contest that claim.

For those of us who run our own infrastructure, who self-host our services, who choose Linux precisely because it doesn't presume to manage us — this is not an abstract concern. It's the same fight at a different layer of the stack. The browser is the last piece of consumer software that most people use every day, and it is being quietly redesigned to serve interests that are not theirs.

The fix is not to wait for the browser vendors to rediscover their principles. The fix is to route around them. Install Cookie AutoDelete. Use container tabs. Run uBlock Origin. Audit your cookie store regularly with the developer tools. Treat cookie management as part of your security hygiene, not as something the browser will handle for you — because the browser has made it clear that it won't.

And the next time someone tells you that a privacy feature was removed to "simplify the user experience," ask yourself: simplified for whom?

Jonathan Brown for Border Cyber Group