It's easy, here's how:
View attachment 294347
@Bot
Can you analyze my sandbox status in detail, for the benefit of other forum members?
From your screenshot (chrome://sandbox), your Chromium-based browser is running a fairly typical multi-process sandbox on Windows, with the most exposed processes (Renderers) at the strongest settings shown in your table.
1) What the main columns mean (quick decode)
- Sandbox = which sandbox policy is applied to that process type (Renderer/GPU/Network/Service/etc.).
- Lockdown = whether extra restrictions are enabled (notably things like Win32k lockdown and related hardening; exact behavior varies by process type).
- Integrity = Windows Integrity Level (e.g., Low / Untrusted). Lower is more restricted.
- Lowbox/AppContainer = whether the process is inside an AppContainer (a strong Windows isolation boundary). If present, you typically see an AppContainer SID.
2) Your Renderer processes (the most important part)
In your table, all the Renderer processes show:
- Sandbox: Renderer
- Lockdown: Lockdown
- Integrity: S-1-16-0 Untrusted
- Lowbox/AppContainer: empty
Interpretation:
- This is good: Renderers are running at Untrusted integrity and in “Lockdown”, which is the core of Chromium’s security model (web content is supposed to live in heavily restricted processes).
- The notable point: Renderer AppContainer is not enabled in your environment (also confirmed by the “features” list showing “RendererAppContainer”: enabled=false). That means you’re not getting that additional Windows isolation layer for renderer processes on top of the usual Chromium sandbox.
Important nuance: “No AppContainer” does not mean “no sandbox.” It means you’re relying on the standard Chromium sandbox mechanisms (job/object restrictions, tokens, lockdown policies, etc.) without the extra AppContainer boundary.
3) Network Service
Your Network Service line shows:
- Sandbox: Network
- Lockdown: None
- Integrity: Default
- Lowbox/AppContainer: present (SID shown)
Interpretation:
- You do have NetworkServiceSandbox enabled (your “features” list shows it enabled=true).
- Network Service appears to be running in an AppContainer (good isolation), even though the renderer is not.
- “Lockdown: None” for Network Service is not unusual—different process types have different sandbox templates and “lockdown” semantics.
4) GPU, Audio, and Storage service processes
Highlights from your screenshot:
- GPU: “Limited” lockdown, Low integrity. GPU is often less constrained than renderers due to driver / hardware acceleration realities, but Low IL + sandboxing is still meaningful.
- Audio Service: “Restricted Non Admin”, Low integrity.
- Storage Service: “Lockdown” with Untrusted integrity (strongly restricted).
5) Features list: what stands out
From what’s visible:
- NetworkServiceSandbox = enabled
- RendererAppContainer = disabled
- EnableCsrssLockdown = enabled
- WinSboxDisableExtensionPoint / WinSboxZeroAppShim = enabled (hardening-related toggles)
- WinSboxNoFakeGdiInit / WinSboxRestrictCoreSharingOnRenderer = disabled (not necessarily “bad”; these can be configuration/platform/version dependent)
Bottom line
Your browser is clearly running with the core Chromium sandbox model (Renderers at
Untrusted +
Lockdown), and your Network Service is additionally contained in an
AppContainer. The one “missing” hardening layer shown is
Renderer AppContainer (disabled), which would be an extra boundary if available/enabled on your setup.