Security and privacy

SBOS protects by design, not by surveillance.

The SBOS security model reduces useful attack paths by controlling app authority, user data access, browser state, device handoff, network visibility, provisioning, and updates from inside the OS architecture.

Isolation by default.

Every app is treated as a separate authority domain. Apps do not freely inspect other apps, scrape unrelated files, attach to other processes, or inherit global system visibility simply because they were installed.

No cross-process inspection

Apps cannot freely enumerate, attach to, read, or manipulate unrelated app memory.

App state protection

Each app's configs, files, and local state are bounded to its own encrypted, identity-aware container.

Device brokering

VR, capture, storage, and sensitive hardware access are assigned intentionally rather than exposed globally.

Network boundaries

Localhost and app-to-app network visibility are controlled so apps cannot assume a flat local machine.

Privacy model.

SBOS collects the minimum system signal needed to improve quality, compatibility, stability, and security. It does not need user-behavior profiling to debug an operating system.

System telemetry

Crashes, exceptions, stack traces, invalid states, performance faults, freezes, and compatibility issues.

Local-first processing

Diagnostic material is prepared locally before encrypted transport to diagnostic services.

Transparency

Telemetry is designed around reviewable technical signal instead of hidden behavioral tracking.

Browser containment.

The SBOS Firefox stack is a native SBOS app, hardened beyond extension defaults. It ships with uBlock Origin, Dark Reader, tuned CanvasBlocker, and configuration-level hardening, while separating runtime, configuration, and user browser data.

Key idea: Even the browser does not receive unrestricted access to all browser-related user data just because it is the browser.

Age categories and identity disclosure.

SBOS uses Adult, Teen, and Kid categories for local account policy defaults. It does not require real date-of-birth disclosure for local account creation. When software requires date-of-birth data for compatibility, SBOS can provide a stable randomized profile date unless the user explicitly chooses to share a real date.

Provisioning trust.

Install, activation, license state, hardware context, finalization, update integrity, and continuing validation are part of platform security. Normal users see a clean install flow. Attackers face a stateful, hardware-aware, server-authorized trust process.