Deep Dive: How Session Isolation Actually Works

Session isolation sounds like a single property and is really two requirements pulling in opposite directions. The first is that no state may be shared between identities. The second is that state must persist within an identity. Systems that deliver only the first are common and feel secure while quietly making every persona look brand new on every visit, which is a pattern of its own.

Start with what a browser accumulates. Cookies are the obvious part and the smallest. Underneath sit localStorage and sessionStorage, IndexedDB, the Cache API, service worker registrations that can outlive the tab that installed them, permission grants for notifications and location, and the HTTP cache — which can be probed for timing differences that reveal what a browser has seen before. Any of these can carry an identifier, and several can carry one that survives a naive attempt to clear things.

This is why clearing cookies has not been meaningful advice for a long time. It addresses one store out of many, and the stores that remain are the ones a user has no interface to inspect.

The common answer is a browser profile per identity, and it genuinely does partition all of the above. Its limits are not about storage at all. Profiles run on your machine, so they share your connection, your hardware, and therefore your fingerprint. They also accumulate on your disk, which turns your own device into the place where every compartment can be found together — a consideration that has nothing to do with what any website can see.

Persona Kit takes a different position: the session should not run on your machine at all. A persona is launched into an isolated browser session, running on your own Steel Browser deployment, and you drive it live from the dashboard. What a site measures is then a property of the persona and its environment rather than of your laptop reported repeatedly under different names, and nothing is left behind locally when you are done.

The lifecycle is where the second requirement is met. On launch, the state previously saved against that persona is restored into the session. You work. On release, the session's cookies, localStorage, sessionStorage, and IndexedDB are written back to the persona. The next launch starts from where the last one ended.

That write-back is doing more work than it appears to. Without it you have perfect isolation and a persona that presents as a brand new visitor every single time: no session cookie, no returning-user flag, no stored preferences, no history of having been there before. Sites treat first visits differently from returning ones — more verification, more consent flows, more scrutiny on anything that follows. An identity that is permanently on its first visit while also having an account that is months old is holding two contradictory stories, and it is a contradiction that gets more conspicuous the longer the account exists.

Persistence is also what makes the arrangement usable day to day. Signing in from scratch on every launch means solving a login and often a second factor every time, which is both tedious and its own signal — a genuine user of a service is not re-authenticating on every visit from an unrecognised device.

Alongside the state, each persona keeps its own browsing history, and actions land on a single activity trail per persona that covers both what you did to the persona and what the persona did on the web. This is the part that turns isolation from a security property into something you can operate. Twenty perfectly isolated sessions with no record of what happened in them is a system you cannot debug: when one persona starts behaving differently from its siblings, the history and the trail are how you find out whether it was the session, the exit address, or something the site did.

It is worth being explicit about what session isolation does not cover, because the phrase invites more confidence than it should. It does not cover the exit address — two personas sharing one proxy share an IP, and that is a stronger link than any cookie. It does not cover the device profile, which is why personas carry their own. It does not cover timing: two isolated sessions driven by one person within the same minute are correlated by the clock regardless of how cleanly their storage is separated.

And it does not cover the credentials themselves. Isolated sessions with the same password across two personas are one breach away from being linked, which is why the vault sits next to the persona rather than in a file somewhere. Isolation keeps the browser's state apart. Keeping the identity apart is a larger job, and the browser session is one part of it.