Section 2: Sandboxing

The Big Picture: A Sandbox for Risky Things

A child's sandbox is a box of sand where play can get messy but nothing escapes. A software sandbox is the same: a small, fenced-off place where a program can run, and if it turns out to be bad, it can only mess up the inside of the fence.

Section 1 showed the walls Windows builds around every process. A sandbox makes the walls tighter for programs we trust less.

The sandbox idea (applies everywhere):

1. Least privilege: give a program only what it needs, nothing more.
2. Brokers: if it needs something extra (like saving a file), a trusted helper process outside the sandbox asks you, then does it.
3. Throw-away: some sandboxes are deleted when you close them.

Example: the browser sandbox. Modern browsers (Edge, Chrome, Firefox) split themselves into many processes. The process that draws a web page (the renderer) runs with very low rights. It cannot open your files or start programs. If a web page tricks it, the attacker lands in a cell with no tools. To save a download, the renderer asks a broker process, which has more rights and applies checks first.

 Web page       ┌──────────────────────┐  asks politely  ┌───────────────┐
 (untrusted) →  │ Renderer (sandboxed) │ ──────────────► │ Broker        │
                │ no files, few rights │                 │ (more rights) │
                │ low integrity        │ ◄────────────── │ checks first  │
                └──────────────────────┘     answer      └───────────────┘

2.1 Windows Sandbox Concept

What it is: Windows Sandbox is a feature that gives you a clean, temporary copy of Windows in a window. You can run a suspicious program in it. When you close the window, everything inside is deleted.

It is built on the same virtualization ideas as Hyper-V (Section 1.3): a light virtual machine (a pretend computer running inside your real one).

Facts:

How it stays light. It does not keep a full second copy of Windows. Instead, it shares the read-only Windows files of your real PC and keeps only a small private layer for changes. That is why it starts in seconds. (Exact design details depend on your Windows version.)

   YOUR REAL WINDOWS                WINDOWS SANDBOX (a light VM)
 ┌─────────────────────┐          ┌─────────────────────────────┐
 │ Your files, apps    │ walled   │ Fresh Windows, nothing saved│
 │ Your accounts       │ off      │ Run the unknown file here   │
 └─────────────────────┘          │ Close window = all deleted  │
                                  └─────────────────────────────┘

How to turn it on (once, needs admin): Control Panel → Programs → Turn Windows features on or off → tick Windows Sandbox → restart. You would then start it from the Start menu. On Home edition the option is simply not there.

Do not rely on it for everything. A sandbox lowers the risk. It is not a guarantee, because "escape" bugs are possible (rare). Do not type real passwords into a sandbox that is running unknown software.

Other tools with the same idea: the browser's own sandbox, Microsoft Defender Application Guard (an older Edge isolation feature that Microsoft has been retiring; check current Microsoft guidance), and third-party tools such as Sandboxie. These are named only so you recognise them.

2.2 AppContainer Isolation (UWP Apps)

What it is: AppContainer is a sandbox built into Windows for individual apps. UWP apps (Universal Windows Platform apps, many from the Microsoft Store) run inside one. Some browser helper processes and other Windows components use AppContainer too.

How it works: An app in an AppContainer gets a special identity (its own SID, a unique ID). By default it can touch almost nothing. It gets capabilities (permissions) only if the app declares them in its manifest (a settings file that lists what the app needs), and the user accepts where needed.

What AppContainer limits:

 ┌── AppContainer for "Photo app" ────────────────────────┐
 │ Own folder: yes      Pictures library: yes (declared)  │
 │ Documents: NO        Camera: NO (not declared)         │
 │ Other apps' memory: NO      Global registry: NO        │
 └────────────────────────────────────────────────────────┘

Why this is better than the old desktop model. A classic desktop (Win32) program runs with everything you can do. It can read all your files, because you can. An AppContainer app runs with much less than you can. That is least privilege in action.

Important limits (be honest):

• Many programs are still classic desktop apps that run without a sandbox. The Store model covers only part of what you run.
• Packaged apps (MSIX) can run in a "full trust" desktop mode that is not AppContainer, depending on how the developer built them.
• Windows 11 also has Win32 app isolation, a newer AppContainer-based option for desktop apps. Availability and use depend on the Windows version and the developer.
• Settings → Privacy & security shows and controls which apps may use the camera, microphone, location and more. The switches there are exactly these capabilities.

Where you can see it: A Store app's private data lives under C:\Users\<you>\AppData\Local\Packages\. Process Explorer can flag processes that run in an AppContainer.

Windows tip: If a Store app asks to use your camera, that is the capability system asking for your consent. If you say no, the app really cannot reach the camera, because Windows blocks it, not because the app is polite.

Summary