I. The most dangerous computer you own

Ask people which of their computers holds their most valuable secrets, and most will point to a laptop or a phone. The honest answer is usually a browser tab.

The tab is where people bank, shop, sign documents, talk to their doctors and, increasingly, hold digital money. It runs code written by strangers, downloaded a moment ago and mixed together on a single page: the site’s own code, its analytics, its advertising, its chat widget, and the hundreds of open-source packages each of those pulls in. It is a triumph of engineering and the busiest crossroads in the history of computing.

The question this article asks is an old one in a new setting: how do you let many programs share one machine without letting any of them betray the others? Operating systems spent half a century learning to answer it. Inside a browser tab, for most practical purposes, the question has barely been asked.

II. A decentralized operating system in a browser

GRIDNET OS is, to our knowledge, the first attempt to build a fully decentralized operating system with a dedicated web-based sub-system. Its state lives on a decentralized network rather than on anyone’s servers, and its user interface runs in an ordinary browser, with windows, a taskbar, a file manager, a wallet and applications that we call UI dApps. We described the foundations in the peer-reviewed paper “UI dApps Meet Decentralized Operating Systems”, and UI dApps have been part of GRIDNET OS for some time.

UI dApps handle things that matter: identities, cryptographic keys, payments, files. The work described here extends the security assurance of that existing sub-system. Its goal is that a flaw, a malicious update or a compromised library in one dApp cannot reach into another dApp, or into the operating system itself, and that the people who use GRIDNET OS can verify what they are running.

To see why that takes real engineering, we first have to look at how a JavaScript application actually runs.

III. How a JavaScript application actually runs

When a browser loads a page, it creates a realm: a complete, self-contained JavaScript world. A realm has one global object (in a web page, the familiar window object), and one set of intrinsics, the built-in objects every program relies on. Among them are the prototypes from which every array, object and promise inherits its behaviour, the network function used to fetch data, and the cryptography interface used to generate keys and random numbers.

Every script on the page runs in that one realm. It does not matter whether the code arrives in a script tag, a bundled file, a module or a dynamically loaded plug-in. It all shares the same global object, the same built-in prototypes, the same memory heap and the same event loop that schedules work. It also shares the same origin, which is the combination of scheme, host and port that the browser uses to decide whose cookies and stored data a piece of code may touch.

Programmers organise this world into classes and modules, and it is tempting to think of these as walls. They are not. A JavaScript class is a function and a prototype object living on the shared heap. A module is a scope: it hides names from its neighbours, which is good engineering, but it runs in the same realm and calls the same shared built-ins. Even the language’s truly private class fields, which outside code cannot read directly, do their work by calling those same shared built-ins, which any neighbour can change.

In other words, a single tab is a single principal, a single “who” in security terms. Everything inside it acts with the same authority. The browser has no idea that the payment form and the advertising script are different parties with different interests, and it has no mechanism to treat them differently.

IV. The shared execution context hazard

Because everything shares one realm, any code that runs can quietly change the world that every other piece of code depends on. JavaScript allows this by design; it is what made the early web so adaptable.

A script can monkey-patch a prototype, for instance by replacing the method every array uses to join its elements, so that each time any code anywhere calls it, a copy of the data goes elsewhere first. It can replace the global network function with a wrapper that reads every request and response. It can wrap the random-number generator used to create keys and make its output predictable. It can wrap a constructor so that every object of a given kind is observed from birth. And any object reference that leaks, through an event, a callback or a shared cache, hands the holder everything that object can reach.

None of this requires a bug in the browser. Nothing in the language stops it, because inside one realm there is nothing to stop: every piece of code is equally trusted. The only defence is never to load anything malicious, and modern software makes that a heroic assumption, because a typical application pulls in hundreds of third-party packages, each maintained by someone you have never met.

The record of real incidents is sobering:

• event-stream, 2018. The maintainer of a widely used npm package handed it over to a volunteer, who added a new dependency containing hidden, encrypted code. The code waited until it found itself inside one particular Bitcoin wallet application and then tried to steal its users’ funds. It was discovered by chance, after it had already been distributed.
• British Airways, 2018. Attackers modified a JavaScript file served on the airline’s own website so that payment details typed into the booking pages were also sent to a domain the attackers controlled. Hundreds of thousands of customers were affected, and the UK regulator fined the airline £20m.
• polyfill.io, 2024. A domain that a very large number of websites used to load a small compatibility script changed hands, and the script began serving malicious code to some visitors. Every site that loaded it had, in effect, handed a stranger the keys to its pages, as Sansec’s analysis describes.

The browser’s most famous defence, the same-origin policy, did nothing in any of these cases, and could not have. It protects one origin from another, keeping one website from reading another website’s data. It does not protect scripts of the same origin from each other. Once malicious code runs inside your origin, it is you.

V. What the platform offers, and where it stops

Browser makers and standards bodies have not been idle. Over the years they have built a set of tools, and each closes one gap:

• Sandboxed frames with opaque origins. A page can host content in an embedded frame that the browser treats as belonging to no origin at all, a unique and anonymous one. Code inside cannot read its host’s cookies, storage or page, and it gets its own realm with its own built-ins.
• Message channels and structured cloning. Separate realms can talk by passing messages through dedicated channels. What crosses is a copy of plain data, never a live reference into the other side.
• Web Workers. Code can run on a separate thread with its own global object, again communicating only by messages.
• Content Security Policy. A site can declare which sources of script it is willing to run and forbid techniques such as evaluating strings as code.
• Trusted Types lock down the most dangerous ways of writing raw HTML into a page, and Subresource Integrity lets a page refuse any script whose contents do not match a known fingerprint.
• Hardened JavaScript, an idea that grew out of the object-capability research community, locks down a realm by freezing its intrinsics, so that nobody can patch the shared built-ins afterwards.

These are excellent tools, and GRIDNET OS uses all of them. But each is a part, not a system. A sandboxed frame gives you a sealed room, but no door, no idea of who is inside and no way to grant that occupant a specific permission. Content Security Policy decides which code may arrive, but not what it may do afterwards. A frozen realm cannot be patched, but everything inside it is still equally powerful. What is missing is the thing that turns separate rooms into a working building: an operating system.

VI. What operating systems learned the hard way

The problem of many programs sharing one machine is as old as time-sharing, and it produced some of the most influential ideas in computer science.

In the late 1960s the Multics project, a joint effort of MIT, Bell Labs and General Electric, organised privilege into concentric protection rings, with the most trusted code at the centre and ordinary programs at the edge. The hardware itself enforced the boundaries, as described in “A hardware architecture for implementing protection rings” in 1972. Unix, born at Bell Labs as a deliberately simpler successor, kept the essential idea in two rings: a kernel that manages memory, files and devices, and a user mode in which every program runs in its own protected address space. A program cannot touch the kernel or another program directly. It must ask, through a narrow, well-defined set of system calls.

In 1975, Jerome Saltzer and Michael Schroeder distilled the lessons of that era into “The protection of information in computer systems”. Their design principles are still taught today. Among them: least privilege (every program should operate with the smallest authority that lets it do its job), complete mediation (every access should be checked, every time), fail-safe defaults (the default answer is no) and economy of mechanism (keep the security-critical part small enough to understand).

A decade earlier, in 1966, Jack Dennis and Earl Van Horn had proposed a different way to think about permission in “Programming semantics for multiprogrammed computations”. Instead of asking “who are you, and are you on the list?”, a system could hand each program unforgeable tokens, which they called capabilities, each conferring one specific right over one specific object. If you hold the token, you may do the thing; if you do not, you cannot even name it. That idea runs through KeyKOS in the 1980s, through the formally verified microkernel seL4, whose proof of correctness was published in 2009, and through the handles of Google’s Fuchsia operating system. It also runs through the microkernel tradition, in which even the system’s own services are separate programs that cooperate only by passing messages.

Put those ideas together and you have a recipe: a small, trusted kernel; untrusted programs in separate spaces; a narrow door of system calls; authority carried by specific capabilities rather than by ambient identity; and every request checked. The recipe has protected servers, phones and spacecraft for decades. GRIDNET OS applies it inside the browser.

VII. A kernel, and a user mode for every dApp

In the new design, GRIDNET OS divides its web sub-system into two kinds of principal. The system runs in kernel mode, in the operating system’s own realm: the window manager, the taskbar and menus, the keychain that holds cryptographic keys, storage, networking, the package installer and the screens that ask for your consent. Every UI dApp runs in user mode, as a package principal of its own.

That includes the built-in ones. The Wallet, the Settings app, the File Manager and the App Store sit on the same side of the line as a game written by a stranger. Where a built-in dApp once reached directly into the system’s internals, that reach becomes a proper system call behind a capability, available on the same terms to any dApp granted that capability. No dApp is royalty.

Each dApp window runs in its own sealed realm: a sandboxed frame with a fresh, opaque origin that matches no other. The browser’s own walls now stand between one dApp and the next, and between every dApp and the system. One window is one frame and one package is one principal, much as one process is one address space in Unix. A dApp inside its realm can draw its interface, run its logic and keep its own data. It cannot read another dApp’s memory, inspect the system’s internals or even touch the window frame it sits in, because that frame belongs to the kernel.

VIII. The door: system calls over a typed binary channel

A room with no door is useless. A dApp still needs to save files, sign transactions, open network connections and request payments. In GRIDNET OS it does so the way a Unix program does: through system calls.

Each realm has exactly one door to the system, a private message channel created by the kernel when the window is born. Requests travel through it in a compact, typed binary encoding, the same efficient format the operating system already uses to talk to the decentralized network, so data arriving from the network can pass through as the original bytes without being reinterpreted on the way. Each request names an operation from a fixed, versioned list. New operations are added at the end and existing ones are never renumbered or reused, so a dApp written today keeps working as the system grows.

Four properties make the door hard to abuse:

• The caller is attested. The kernel knows which dApp is calling because the channel itself is bound to that dApp, never because the dApp says so.
• Every call is checked. Authorisation happens at the door, on every call, in keeping with Saltzer and Schroeder’s complete mediation.
• Only data crosses. Plain values and handles go through; live objects and references into the kernel never do.
• Long work stays controllable. Results that arrive over time, such as a streamed AI answer, flow with built-in back-pressure, can be cancelled, and end in a named outcome rather than silence.

Some information is needed constantly and synchronously: the current theme, the active identity, the size of the screen. For these, the kernel pushes a read-only snapshot into each realm and keeps it up to date, in the spirit of the small read-only pages that Linux maps into every process for fast reads. Reading it never needs a round trip, and writing to it is impossible.

IX. Capabilities instead of ambient power

A dApp in GRIDNET OS holds capabilities: specific, revocable rights to request specific kinds of operation. In the kernel each one is represented by a handle, rather like a file descriptor in Unix, and the dApp can only use the handles it has been given. A game might hold the right to its own storage and nothing else. The Wallet holds the right to request payments, but even it cannot move money on its own authority.

That is because anything done on behalf of the user, such as signing in their name, paying from their wallet or relaying traffic under one of their identities, also requires the user’s consent. Consent screens are drawn by the kernel, above every dApp window, so no dApp can fake, cover or pre-click one. And the most sensitive material never crosses the door at all. A dApp can ask the system to sign something, seal a message or derive a shared secret, but private keys and session secrets stay in the kernel. The dApp receives the result, never the key.

Resources are budgeted too. Each dApp has limits on how fast it may call the system, how much data it may move and how much memory and processor time it may use. When a limit is reached, the request is refused with a named reason the dApp can understand and show, rather than with a mysterious failure.

X. Hardening the system against itself

Walls between dApps protect the system from the dApps. But the system is software too, built on libraries, and a subtle flaw in any of them could become a way in. So the kernel realm is hardened at boot.

Before any dApp starts, the operating system locks its own realm down in the manner of Hardened JavaScript: the shared built-ins are frozen, so that no code, whether a stray library or a deliberate attack, can afterwards patch the prototypes, the network function or the cryptography that the kernel relies on. Attempts to break that rule are logged with enough context to trace their cause. Content Security Policy is enforced on the system’s own pages from the first build, and the dangerous practice of evaluating strings as code is removed.

The same thinking applies to the system’s own files. The operating system’s code is checked against a known baseline. A system module whose bytes have drifted from that baseline is not loaded into the trusted kernel; it is reported by name, and the component that needed it refuses to start rather than run on something it cannot vouch for. Code for dApp windows is delivered by the kernel from that verified cache; a sealed realm never fetches its own code.

XI. Signed by its authors, recorded by the system

Isolation limits what a dApp can do once it runs. It does not tell you whether the dApp you are about to install is the one its authors wrote. For that, GRIDNET OS uses signed packages and a system registry.

Every version of a dApp is signed by its authors with their on-chain identity. The package itself lives on GRIDNET’s decentralized storage and is identified by its fingerprint, a short code computed from its exact contents. Change one byte and the fingerprint changes.

Each dApp also has a registration: a file in the decentralized file system, owned by the system rather than by any user, that records every version ever published, its fingerprint, and who was allowed to write the dApp at the moment that version was published. Because the system owns the record, no single user can delete or quietly rewrite it, not even the dApp’s own developer. Versions can be added and withdrawn, but history cannot be erased, and any version ever published can be checked against it.

At install time the kernel asks two questions. Does the package match the fingerprint in the registry? And was it signed by someone who was genuinely allowed to write this dApp when that version was published? If either answer is no, installation stops. If the signer has changed since your last update, you are told by name who signed it and since when, and asked for your consent. Developers publish into a namespace tied to their on-chain identity, so nobody can register a dApp under someone else’s name.

Projects that want shared ownership can choose, when they first deploy, to let their community decide who may publish new versions, through votes weighted in the same Sybil-resistant way as the ratings described next. That choice is fixed at deployment and cannot be quietly changed afterwards.

XII. Ratings with something at stake

A signature proves who wrote a dApp. It does not prove that the dApp is any good, or that its authors are honest. For that, people rely on each other’s judgement, and GRIDNET OS gives that judgement a structure.

Users can rate each version of a dApp on two separate scales: QUALITY (does it work well?) and SAFETY (does it behave honestly?). Ratings roll up into a score for each version, then for the dApp, and finally into the reputation of its developer across everything they have shipped.

Open ratings invite fraud. In 2002 John Douceur showed, in “The Sybil Attack”, that without some cost attached to identity, one attacker can always create enough fake participants to outvote everyone else. GRIDNET OS answers this with the voting-power rule from our own research, SPIDE: Sybil-proof, Incentivized Data Exchange. A rating counts only when it is backed by proven stake, value that the voter has demonstrably committed to their identity, and voting power grows slightly faster than that stake. One identity holding everything therefore outweighs the same value spread across many accounts, so splitting yourself into a crowd makes you quieter, not louder. The same rule governs every vote in the system.

Stake is never confiscated. A developer who ships something harmful does not lose a deposit; they lose something worth more in the long run, their name. Ratings stay in the voters’ own records on the network, where anyone can read them and nobody can hide them.

XIII. Nothing looks different

Security that makes software unpleasant to use tends to get switched off. So the design sets a firm rule: sealing the rooms must not change how anything looks or feels, and it pays for that rule with engineering.

The window’s chrome, its title bar, borders and resize handles, stays in the kernel; only the window’s body holds the sealed frame, and the frame is never moved once it is placed, because moving it would reset it. Menus, tooltips, dialogs and notifications are drawn by the operating system on the dApp’s behalf, using the same libraries and themes as today, so nothing is clipped at a window’s edge. Free-form overlays that a dApp paints itself are given a carefully bounded “escape” area around the window rather than being cut off. Dragging, resizing, focus, keyboard shortcuts, text input in every language, copy and paste, drag and drop between windows, themes and dark mode, touch gestures, safe areas on phones and the on-screen keyboard are relayed across the boundary so that they behave exactly as they did.

To keep windows quick to open, the system prepares sealed frames in advance and hands one over the moment a dApp starts, behind the same opening animation users already know. A dApp developer writes the same code against the same interfaces; the whole operating system is still available, only now it is reached through the door. If we have done our job, nobody will notice anything except that the system has become much harder to subvert.

XIV. What remains, stated plainly

No security design removes every risk, and saying so is part of the job. A dApp can still mislead its users within its own window, by drawing something that looks like what it is not. Sealed realms that share a browser process, as they often do on phones, remain exposed in principle to the class of processor side channels made famous by Spectre. A runaway dApp can still slow its own process down, which is why there is a watchdog. And the browser’s own permission prompts, for the camera or the microphone, name the operating system rather than the dApp, so the system adds its own explanation first.

These residual risks are known, bounded and documented, and the remainder of the design is built so that each one stays contained to the dApp that causes it.

XV. What this changes

Every era of computing has had to learn the same lesson. Shared machines need walls, and walls need doors that are watched. Mainframes learned it; personal computers learned it at great cost; phones learned it with sandboxes and signed app stores run by single companies.

What GRIDNET OS adds is the last step. The rules that protect you are not enforced by one firm’s review team, and the record of who wrote what is not kept on one firm’s servers. The kernel enforces them in your own browser, the registry lives on a network that nobody owns, and reputation is earned from people with real stake in the outcome. Trust stops being something you are asked to give and becomes something the system can show.

XVI. Built in the open

None of this is finished, and we will not pretend otherwise. It is being built live on our YouTube channel, almost every day, mistakes included, and the hour-by-hour view lives on our Discord #live-development channel. The security extension is at the development stage and is not public yet.

This article is the overview. A dedicated research paper on UI dApp isolation, signed packages and Sybil-resistant ratings in a decentralized operating system is upcoming. It will cover the design in depth and compare it with prior work.

We think this might work. Let’s keep building.