Sign in Sign up

Platform

Security

brintOS is built around a hard architectural rule: your machine runs in your tab, on your CPU. We never operate a remote runtime that can execute your code, so the attack surface starts off small and stays that way.

The outermost boundary is the browser

Every brintOS machine runs inside the browser's WebAssembly sandbox — the same boundary browser vendors have spent 25 years hardening to protect the rest of the web from malicious pages. Your host operating system already treats the browser as untrusted, by design. Whatever happens inside a brintOS session cannot escape that boundary any more than an arbitrary webpage can. Even the worst-case scenario — a successful exploit against our Linux kernel port — would still be contained inside a wasm sandbox the host distrusts by default.

This is structurally different from every cloud development environment, container runtime, or local VM you might compare us to. Those products run your workloads inside a trust boundary the host extends to them. We run inside the trust boundary the host already withholds from the web. It is the strongest possible default.

How execution is isolated

  • Process isolation by construction. Each Linux process runs in its own WebAssembly Worker with its own private user memory. Cross-process memory access is not just denied by the kernel — it is structurally impossible at the wasm level, because one Worker's wasm instance has no access to another Worker's memory at all. Shared address space bugs that would matter on native Linux cannot exist here.
  • Static linking is the default. Our minimal images build against musl and statically link every userspace binary — no LD_PRELOAD, no dynamic loader, no shared-library injection, so entire classes of Linux security bugs are simply absent. Dynamic linking is available when you need it (a full glibc userland with its own ld.so, or dlopen on musl), and where it is used it runs inside the very same per-process wasm sandbox — a compromised loader or .so is still confined to that instance's own memory, with no path to another process or to the host.
  • Hardware access by explicit permission. USB, serial, audio, MIDI, and HID access goes through HardwareJS, which can only see devices you have specifically authorized via the browser's per-origin device permission model. There is no server-side "udev rule" we can quietly add to grant access; every device requires an explicit user grant scoped to the brintOS origin.
  • Our control plane never executes your code. The brintOS servers store root filesystem snapshots, manage billing, and gate access. They are a static-content plus metadata service, not a compute platform. There is no brintOS-hosted runtime that could be compromised to execute attacker-supplied workloads or exfiltrate user data at scale, because no such runtime exists.

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.