Browsers as operating systems: process isolation, profiles, extensions

Why a browser looks like an operating system

Start with the problem, because the architecture follows from it. A web page is not a document. It is a program: markup, styles and, in any page a staff member is likely to be typing into, a substantial body of JavaScript that runs on the user's processor. The browser fetches that program from a server it has never met, on the strength of nothing more than a name resolving and a certificate validating, and runs it immediately.

An operating system that ran every program a user encountered, from any source, without asking, would be considered indefensible. The browser does exactly that, deliberately, as its core function, and the web works because of it. What makes the arrangement survivable is that the browser gives that untrusted program almost nothing. The page's code cannot open a file on the disk. It cannot read another site's data. It cannot make an arbitrary network connection. Everything it is allowed to do, it does through a narrow set of interfaces the browser defines, and everything it is not allowed to do is prevented rather than discouraged.

That should sound familiar. It is the shape of Chapter 14's privilege boundary, recreated one level up. The browser has its own kernel, in the sense of a trusted core that holds the real capabilities, and its own userland, in the sense of a restricted territory where untrusted code is allowed to run and ask for things. The rest of this section is the anatomy of that split.

The browser process, the renderer and the sandbox

A modern browser divides its work across several kinds of operating system process. The one that matters most is the split between the browser process and the renderers.

The browser process is the trusted core. It is the part with real privileges, in the ordinary sense of Chapter 14: it is the process that talks to the network stack, reads and writes files on disk, draws the window frame and the address bar, holds the cookie store and the password store, and mediates every request the rest of the fleet makes. If you think of the browser as an operating system for web pages, the browser process is its kernel.

A renderer process is where a web page actually runs. It parses the HTML, applies the styles, executes the JavaScript, and works out what the page should look like. It holds the page's content in its memory: the text of the document, the values in every form field, the response streaming back from the server. It is, in other words, the process that holds the plaintext of a prompt. And it is the process the browser trusts least, because everything in it came from a stranger.

So the renderer runs inside a sandbox. A sandbox is a deliberately impoverished execution context: the operating system is asked to strip the process of capabilities it would ordinarily have, so that even if the code inside it is entirely hostile, there is very little for it to reach. A sandboxed renderer typically cannot open files, cannot make network connections of its own, and cannot see other processes. When a page needs any of those things, its renderer asks the browser process, over a defined channel, and the browser process decides whether to comply.

Chapter 14's vocabulary maps onto this without strain. The renderer is userland; the browser process is the kernel; the request channel between them is the system call interface. The reasoning behind the design is the same too. Browsers have bugs, and a page that finds one may be able to run code of its own choosing inside the renderer. The sandbox is the answer to 'and then what?' A compromised renderer is a program with almost no capabilities, sitting in a box, having to ask permission for anything interesting. Containing the damage is more achievable than preventing every bug.

Site isolation, and why there are so many processes

That accounts for two kinds of process, not fourteen. The rest of the count comes from site isolation: the practice of putting content from different sites into different renderer processes, so that one site's data is never resident in a process that another site's code is running in.

For a long time this was not the case. Browsers grouped pages into renderers loosely, by tab or by memory pressure, and relied on in-page rules to keep one site's script from reading another site's data. Those rules were enforced by the browser's own logic rather than by the hardware, and in early 2018 the Spectre class of processor vulnerabilities demonstrated that logic of that kind could be undermined. The vulnerabilities allowed carefully written code to infer the contents of memory it was not supposed to be able to read, within its own process, by observing timing side effects of the processor's speculative execution. The browsers' response was structural rather than corrective: if a site's data is never in the same process as another site's code, then reading across the boundary requires escaping the process, not just outwitting a check inside it. Site isolation was accelerated and turned on broadly for that reason. (high; Chromium's own security documentation states the Spectre motivation directly)

Two of the crowd's remaining members are worth naming. The graphics process handles the actual drawing, kept separate because graphics drivers are a historically rich source of vulnerabilities. And each installed extension generally gets a process of its own, which brings us to the two features that decide whether the organisation has any presence inside the browser at all.

Profiles: the browser's notion of identity

A browser profile is the unit of state and identity inside a browser. One profile holds one set of cookie jars, one set of active sessions, one history, one set of saved sign-ins and passwords, one set of settings, and one set of installed extensions. A second profile in the same installed browser holds a completely different set of all of those, and the two do not share. Signing in to a service in one profile does not sign you in in the other. An extension installed in one is not present in the other.

Framed against Chapter 14, a profile is the browser's equivalent of a user account on the operating system. It is the container that answers 'who is this, and what is configured for them'. One human being routinely runs two or three, and the browser encourages it: a personal profile and a work profile, switched between with a click on an avatar in the corner of the window.

For a defender this is the concept everything else in Part Three hangs from, so it is worth stating without hedging. Organisational browser policy does not attach to a person, and it does not attach to a browser installation. It attaches to a profile. The registry values Chapter 15 described, and the configuration profiles Chapter 16 described, are the operating system's mechanism for delivering settings; what those settings configure is a profile. An extension that an administrator force-installs is force-installed into a managed profile. A policy that says 'audit prompts sent to consumer AI sites' applies while the page is loaded in a profile that carries the policy.

Which makes 'which profile is this page open in' the question a defender has to be able to answer for any given control, and Chapter 19 is largely about the specific mechanics by which Microsoft and Google implement work and personal profiles in Edge and Chrome.

Extensions and content scripts

A browser extension is a third-party program installed into a browser profile, which the browser runs with a set of permissions declared up front and approved at install time. The permission model is explicit and reasonably legible: an extension declares which sites it wants access to and which browser capabilities it needs, the browser surfaces that as a list at installation, and it is granted or not. An extension that never asked to read page content cannot read page content.

The part of an extension that matters here is the content script. A content script is a piece of the extension's code that the browser injects into the renderer process running a page, so that it executes in the context of that page and can read and change the document the page has built. It runs in a separate execution context from the page's own JavaScript, so the two cannot interfere with each other's variables, but it sees the same document. It can read the text content of any element, watch a form field change, observe a submission, and modify what is on screen.

That is the whole mechanism. An extension with permission for a given site places a content script inside the renderer for that site, and from there it can see what the page holds. Nothing about it is exotic; it is the ordinary way ad blockers, password managers, grammar checkers and translation tools have always worked.

The shadow AI lens: what a browser-resident control can read, and where it stops

Now the architecture pays. Chapter 14 asserted, and Chapters 15 and 16 kept returning to, a fact that has been left unexplained until now: an in-browser data loss control can read a prompt without the device being onboarded into anything, which no other device-side control can do. The reason is a matter of position.

The prompt exists as plaintext in exactly one place on the device long enough for anything to read it: the renderer process for the AI site, between the moment the user types or pastes it and the moment the page hands it to the browser process to send. A content script injected into that renderer, or the browser's own inline DLP machinery which is built into the browser and needs no injection, is inside that process. It reads the text from the document, as the document, before any of it is serialised for the network and long before TLS encrypts anything.

Compare that with the alternatives and the asymmetry is clear. A network control sees ciphertext, because TLS has already been applied by the time the bytes leave. A kernel-side agent could in principle observe the data, but only by watching the clipboard as a paste happens, or by attaching itself to the browser, and getting a privileged agent onto the machine requires an administrative act on a device the organisation controls. The in-browser control needs neither. It needs a profile.

So the profile is the whole dependency, and it is worth being precise about what that means in practice. When a staff member opens an AI site in a managed work profile, the page loads in a renderer into which the organisation's extension has injected a content script, or in a browser whose inline policy is active because the profile carries it. When the same staff member opens the same site in their personal profile in the same browser, the page loads in a renderer with none of the organisation's code in it. Not a weakened version of the control; none of it. The organisation is not present in that process, and there is nothing to bypass because there is nothing there.

This is the profile model working exactly as designed. Profile isolation exists so that a work extension cannot read a personal banking session, which is a property users and privacy regulators both want. The same property means the work extension cannot read a personal ChatGPT session either. A defender should treat the two as one fact rather than as a feature and a flaw.

Site isolation cuts the same way, one level finer. Because each site runs in its own renderer, a content script is naturally scoped: an extension granted access to a list of AI sites is present in the renderers for those sites and absent from the rest. That is useful, because it makes a proportionate control possible; an organisation can monitor prompts sent to consumer AI services without its extension being resident in the renderer holding an employee's superannuation portal. It is also a bound. Nothing about being 'in the browser' gives an observer a view across the browser. It gives a view of the pages it is permitted to be in.

All of which yields a usable test for vendor claims. When a product says its extension 'sees everything in the browser', the accurate restatement is that it sees the content of pages, in profiles, where it is installed and permitted, while it remains installed. Every word of that is doing work. Ask which profiles it is deployed to, whether the user can remove it, and which sites its permissions cover, and a broad claim becomes a specific and checkable one.

There is a second consequence of the extension model that receives less attention than it deserves. The same mechanism that hosts the organisation's control hosts whatever the user installs. A page-summarising extension, a writing assistant, a 'chat with this page' tool: each of these is an in-browser program with a content script, reading page content and sending it to a third party the organisation never assessed. The staff member did not visit an AI website, so nothing in the network telemetry looks like AI usage, and yet the contents of every page they open, including the ones behind corporate authentication, may be leaving. On a managed profile, extension allowlisting addresses this and is a control worth having. On an unmanaged profile it is unaddressed, and it is a genuine gap in most organisations' picture of their exposure.

The summary a defender can carry into a design review is that the browser-resident control is strong and weak for the same architectural reason. The browser, having rebuilt itself as an operating system to run strangers' code safely, contains a place where the page's plaintext is visible before the network exists. That is why the control works on a device the organisation does not manage. That place is bounded by the browser's own isolation and permission model and belongs to a profile the user may choose not to be in. That is why the control is never a guarantee.

Last updated 9 August 2026