How SBOS limits application access
SBOS reduces unnecessary application authority over processes, files, user data, networking, localhost, devices, capture, browser state, updates, and diagnostics. These are engineering boundaries, not claims that attacks are impossible.
Threat model
SBOS assumes applications may be malicious, compromised, outdated, or broader in their access requests than users expect. It limits what those applications can reach and records lifecycle and diagnostic state for repair, support, compatibility, stability, and security analysis.
Application boundaries
Immutable core
System and core files are immutable by design. Updates go through the SBOS update process rather than applications rewriting system files.
Processes and memory
Applications cannot freely list unrelated processes or inspect and edit unrelated process memory without explicit SBOS authority.
Files and configuration
Application files, dependencies, caches, and settings remain associated with that application. User files require picker selection, permission, User Policy, or administrator rule.
Networking and devices
Network access, localhost visibility, app-to-app networking, storage, controllers, cameras, microphones, capture devices, VR hardware, screen capture, and window capture are brokered.
Browser separation
The browser runtime, managed browser configuration, and browser user data are separate state categories. The browser engine does not receive unrestricted access to every piece of browser-related user data simply because it is the browser. Cookies, session state, credentials, caches, extensions or browser-local settings, browser DRM, and media paths are handled under SBOS policy.
Updates and diagnostics privacy
Updates are staged and validated before they are applied, with rollback or recovery paths. Diagnostics focus on crashes, stack traces, invalid states, freezes, performance faults, dependency failures, API translation failures, compatibility events, service health, and lifecycle failures. Diagnostics are not an advertising or behavioral-profiling system.
Account categories and date-of-birth compatibility
SBOS local accounts use Adult, Teen, and Kid categories for User Policies and suitable defaults. These are not identity-verification categories. SBOS does not require a real date of birth merely to create a local account. When an application requires a date of birth for compatibility, SBOS provides a stable randomized compatibility date appropriate to the account category unless the user or an applicable policy explicitly chooses to provide a real date.
Realistic limits
Security still depends on correct implementation, supported hardware, current updates, sound policy, and administrator judgment. Physical access, firmware compromise, supply-chain attacks, privileged misuse, unsupported drivers, and defects in SBOS or applications remain relevant risks.