Security

Explicit, verified runtime selection

Machine settings name an exact official HardwareJS release. Local roots and images infer it from their versioned kernel filename, with an explicit approved override available. Its JavaScript, HTML and release descriptor are immutable static assets hosted by brintOS at /hardwarejs/<version>/. Launchers check current approval separately and verify the artifact's size and SHA-256 before executing it. Missing selections, unknown versions and revoked releases refuse launch. A repository cannot supply an executable runtime URL or replace the host runtime by uploading JavaScript.

Browser machines

Each browser machine runs in a sandboxed iframe on its own machine domain. The authorized document handler verifies the official HTML before serving it with an embedding policy bound to the parent origin. The parent retains account credentials and gives the machine capability ports for its authorized filesystem and devices. Public release HTML is a download rather than an executable machine page on the product domain.

Guest kernels and programs execute as WebAssembly with explicit host imports. Browser device access, including WebUSB, requires the user's permission on the machine origin. These layers reduce exposure; they do not make browser, engine, or runtime vulnerabilities impossible.

Local Node and cloud machines

The Node launcher downloads only the approved official runtime. That JavaScript runs with Node privileges, so guest filesystem requests, worker messages and device inputs must be treated as untrusted. Worker threads alone are not a sandbox. The host restricts filesystem access to the selected root or disk; a local directory must not be changed concurrently by an untrusted host process.

Each cloud machine runs in its own Fargate task with no task IAM role, inbound access, platform private-network access or ECS Exec. Its supervisor receives only repository-scoped authorization for that launch generation. Stop or restart invalidates the old generation. The ECS execution role handles image pulls and logs outside the user task; its credentials are not passed to the machine. This containment limits the credentials exposed if a trusted runtime is compromised.

See runtime selection and official releases for the download and revocation contract.

Account security

• Sign in with email and password (Argon2id-hashed, never stored in plaintext) or with Google / GitHub via OAuth 2.0 / OIDC. Email verification and password reset are built in.
• Sessions are bound to a server-side cookie with the HttpOnly, SameSite=Lax, and Secure flags in production.
• Personal access tokens are stored hashed; the plaintext is shown exactly once at creation.
• A security log (/settings/security-log) captures every authentication, token rotation, and machine-permission change.

Data at rest

• Snapshots are stored encrypted with AES-256-GCM. Keys are KMS-managed and rotated on a schedule.
• Private machines are isolated by IAM at the storage layer; an exfiltration of one customer's bytes cannot read another.
• Secrets attached to a machine are stored as libsodium sealed boxes and never logged.

What we don't do

Several common attack surfaces don't exist in brintOS because we deliberately don't build them.

• We don't run a remote compute service. Your code executes in your tab. There is no brintOS-hosted VM, container, or function runtime that could be compromised to execute attacker-supplied workloads.
• We don't install anything on your machine. No native binaries, no system extensions, no privileged operations. Nothing in brintOS requires sudo, admin, or a system service. Closing the tab leaves nothing behind beyond your browser's normal storage.
• We don't intercept your network traffic without your consent. With no NIC subscription, the in-browser Linux's outbound paths are Google's public DoH resolver (over your browser's TLS — we never see your queries), the brintOS HTTP fetch worker (plaintext HTTP only, where there is nothing confidential to begin with), and — if you opt in by installing our intermediate CA — direct browser-to-destination HTTPS fetches with the TLS termination happening entirely in your tab (brintOS's servers are not on this path). On the paid Network-as-a-service, your packets ride a brintOS tunnel terminator that sees ciphertext and destinations the way any ISP does — but never your packet contents. The path your traffic takes is always one you chose.
• We don't ship native code. Everything brintOS runs is either JavaScript (in our hands and yours, equally inspectable in DevTools) or WebAssembly (sandbox-bounded by the browser). There is no brintOS-signed binary you have to trust at the OS layer.
• We don't have a debug backdoor. There is no brintOS support mechanism that injects code into a running machine, attaches a remote debugger, or reads your filesystem snapshot in cleartext. Snapshots are decrypted in-browser at boot using keys only your session holds.

Compliance

• SOC 2 Type I is in progress; Type II audit window starts at the end of FY2026.
• HIPAA / FedRAMP / FINRA / EU-AI-Act conversations welcome on the Enterprise plan.

Reporting a vulnerability

Please email security@brintos.io with a description and reproduction steps. We acknowledge inbound reports within 1 business day and aim to triage within 5. We don't yet have a formal bug-bounty programme but will gladly publicly credit researchers who help us harden the platform.