What you trust, and for what↑ Why · Someone checks every claim before trusting it They can see, part by part, what each piece could do if it turned, and which promise stops it.
| trusted for | if it turned on you | limited by | |
|---|---|---|---|
| The core (keys, sealing, sessions) | everything | everything | short, no IO, crypto crates only (core/four-jobs, core/no-io) |
| The access checks in each node | who may do what | anyone could do anything | a key and chain per call, fail closed (call/chain, access/fail-closed) |
| The updater and the release keys | what code runs | any code, on every device | signed, logged, tiered releases (below; node/signed-releases) |
| The sandbox boundary | what untrusted code reaches | the node, as its user | a box whose only way out is the node (D-26) |
| A service (files, terminal) | its own work | what its grant reaches, never keys | no keys, a verified caller per call (service/no-keys) |
| An extension | what you granted it | what you granted it | its manifest, its own publisher's signature |
| The page's code | your tab | the tab, as you | signed releases, native mode, other devices checking (browser/unsigned-locks, browser/native-page) |
| A relay (ours or yours) | delivery | who talks to whom, when, how much; not what; holding back news of a release | sealed frames (core/four-jobs, Who sees what in Core); nodes fetch the manifest themselves every fifteen minutes (wire/release-hint) |
| Cloudflare | serving the page and the relay | the page, until native mode; delivery | as for the page and a relay |
| Us, publishing | releases | as the updater | reproducible builds, a public log, approval for the base (below) |
| The install line | the first download | that machine | its hash, on first use only; signatures after (node/installs) |
The trusted base is the first four rows: a fault there is a fault everywhere. Everything else is limited by the base.
The trusted base is named and stays small
Every file in it is listed, its size is checked against a budget, and a release says which of its files changed.
Shown when a release's notes list exactly the base files changed since the last one; a build over the budget fails.
Not built: nothing in the code or tests names this yet.
How new code arrives↑ Why · Someone checks every claim before trusting it An update can't be made for them alone, and can't change what everything rests on without someone being able to see it first.
Fixes should land fast and the base should rarely change, and asking a person each time doesn't settle that: they can't judge the diff. What a person can rely on is that what runs is what everyone else got, that anyone can rebuild it, and that a change to the base waits where it can be seen.
Every release builds byte for byte from its source
Shown when two builds of one tag on different machines give equal hashes for every artefact.
Not built: nothing in the code or tests names this yet.
A device runs no release that isn't in the public log
So a release made for one person is seen by everyone.
Shown when a node refuses a correctly signed release missing from the log, and checks the log's consistency between releases.
Not built: nothing in the code or tests names this yet.
Releases come in tiers, each with its own rule
The base, our services, and extensions. A service holds no keys and can't
widen its own grants, so it updates as soon as it's idle
(node/updates-when-idle); the base waits (below); an extension follows
its own publisher (ext/updates-separately).
Shown when one manifest with a base, a service and an extension component applies each by its own rule.
Not built: nothing in the code or tests names this yet.
A change to the base runs once the account approves it
By default approval is automatic once the release has been in the public
log for 48 hours with no rebuild disagreeing; you can choose to be asked
each time instead. Approvals are entries in the account log
(browser/approved-releases).
Shown when a base release is held for the cooling period, then applied; with "ask me" set it waits for a device's yes; a rebuild that disagrees stops it everywhere.
Not built: nothing in the code or tests names this yet.
An urgent fix to the base can skip the wait, only with two signatures
A second release key, kept apart from the first, must also sign, and the release says it is urgent. It is still in the log before it runs.
Shown when a base release marked urgent with one signature waits the full period; with two it applies at once.
Not built: nothing in the code or tests names this yet.
An update that widens what anything can reach waits for a person
Whatever its tier: a service or extension whose manifest asks for more is
held until a device says yes (access/widen-in-person).
Shown when a release whose manifest adds a right is held; one with the same manifest isn't.
Not built: nothing in the code or tests names this yet.
A release that fails on a device is undone there
The device keeps the version before and goes back to it on its own
(node/falls-back), so a fast fix can't strand a machine.
Shown when as in node/falls-back.
Not built: nothing in the code or tests names this yet.