ZENOS
ZENOS is an open-source desktop OS that aims to keep information and data from leaking, by building the protection
into the operating system itself. It is for anyone: companies, public offices, families and individuals, and people
use it the way they use any computer today. Every file carries a security level. Opening, moving and sending
files is governed by that level, key issuance goes through an approval request, and anything that looks like a
leak stops the machine until responsible officers release it from their own devices.
Status: Developer Preview (proof of concept). ZENOS is not yet safe for real sensitive data.
Several protections are demonstrations that run with ordinary user privileges. Read
docs/THREAT_MODEL.md before you evaluate it, and do not describe it as secure.
What it does
| Area | What exists today | Status |
|---|
| Levelled, sealed files | Files saved into a level folder (L1–L5) are encrypted into .zen with the level in a signed header; plaintext is only ever opened in RAM (/dev/shm). | Working PoC |
| Approval-based key issuance | Opening above your level files a request; the required number of approvers grows with the level; approvals are signed with each approver's key. | Officers sign on their own devices (ZENOS Messages); demo keys only without enrolled officers |
| Anomaly stop | Bulk reads, transfers to removable media and unusual egress freeze the session and lock the screen; release needs several officers' signatures. | Enforced by a root service (installed system); officers sign the release on their own devices (ZENOS Messages) |
| Tamper-evident ledger | Hash-chained local log, anchored with Merkle roots and shipped to audit nodes off the PC, which refuse rewritten history. It records file openings, approvals (which officer's passkey, whether the phone was near) and sign-ins to the PC (sign-in, sign-out, wrong passwords, screen locks). | Working (installed system); one node per ministry, not yet a multi-party consortium |
| Distributed storage | Sealed files are fragmented and replicated across storage nodes. | PoC (local test nodes) |
| Level-gated AI | Which AI may touch a file depends on its level (external AI hidden at L4+). | UI and policy only |
| Messenger | End-to-end encrypted messages (Signal protocol via libsignal), channels, calls (LiveKit, self-hostable). | Working PoC |
| Apps | Browser (WebKitGTK, tabs, bookmarks), ZENOS Office for Word, Excel and PowerPoint files (the LibreOffice engine in a ZENOS window: no network, the file only in memory, no macros), PDF, Images, Video, file picker. | In 0.2.0. On 632 public files (4 Nov 2026): every file opened and saved, old .doc and .xls files included (no .ppt file found yet); tables, merged cells, print areas, formulas, conditional formats, charts and slides kept in every file that had them; borders kept in full in 185 of 218 workbooks, pictures in 80 of 85 Word files. Compared after saving, not against Microsoft Office (tests/office/results, docs/OFFICE_ENGINE.md) |
| Proven decisions | Whether a file opens, an approval counts, a stop is released, content may flow to a place, a ledger is intact and a send is allowed are decided by one program built from Lean proofs (docs/FORMAL_VERIFICATION.md). | Working; the proofs are checked on every build |
| Server records (ZENOS Data) | A server program keeps its records with no plaintext and no key at rest: each record encrypted, copied to storage peers, its key split among key peers of different parties that release a share only for a signed-in person, a registered purpose and a level within their clearance (docs/DATA_STORE.md). | In 0.2.0 (zenos-grid); tested, not yet used by a real server program |
| Sign-in with the phone | Passwords saved in the browser are encrypted with a key only the person's phone produces (passkey, WebAuthn PRF); each sign-in is approved on the phone with fingerprint or face and a matching code. | Working PoC; tested with software and virtual passkeys and on a physical iPhone (5 Nov 2026: passkey, PRF, an approval, and the phone-near check with an iPad in the PC's place); not yet on Android (docs/PHONE_KEYS.md) |
Design principles: staff should not need training (Windows-like layout, familiar controls); nothing depends on a
single vendor; the browser engine is WebKitGTK, not Chromium.
Repository layout
core/ desktop side: sealed files and approvals (zenos.py), browser, app shell, file picker, lock screen
apps/ Documents, Sheets, Slides (Vite + TypeScript), PDF, Images, Video; apps/common: their local server
messenger/ ZENOS Messages: client, relay, web UI, calls (AGPL-3.0)
desktop/ KDE Plasma integration: launcher, level indicator and monitor plasmoids, .desktop files
system/ root services (sbin/, systemd/) and the shared library installed to /usr/lib/zenos (lib/)
storage/ storage grid nodes (erasure code, certificates, repair)
packaging/ the zenos and zenos-grid packages and the installer image
config/ example configuration for the servers
tests/ unit tests
formal/ the decisions of keyd and guardd in Lean 4, with their proofs (zenos-decide)
third_party/ modified KDE plasmoids (kept under their original GPL/LGPL licenses)
docs/ architecture, security, threat model, formal verification, glossary, design notes, release process
feedback/ the feedback board: a Cloudflare Worker (src/worker.js) with a D1 database
site/ the project website (zenos-os.org): a static site, no build step
tools/ site-features/build.py (feature pages for site/) and github_activity.py (the board's activity feed)
dev/ pieces for the WSL2 development machine: VNC desktop service, input-method autostart
This is the beginning of the README. Read the rest at the original. Read the full README ↗
