Speed against assurance
Keeps 8 promises
- The trusted base is named and stays small
- Every release builds byte for byte from its source
- A device runs no release that isn't in the public log
- Releases come in tiers, each with its own rule
- A change to the base runs once the account approves it
- An urgent fix to the base can skip the wait, only with two signatures
- An update that widens what anything can reach waits for a person
- A release that fails on a device is undone there
The question isn't how often you're asked; it's what has to go wrong for bad code to run. With these in place it takes the release key, a release that everyone gets (the log), that nobody rebuilds differently in 48 hours (the cooling period), and, for the base only, the second key to skip that. A fix to a service, which is most fixes, applies within hours. A fix to the base applies in two days, or at once with both keys. A device that took a broken release goes back to the last good one.
Splitting by tier only helps while the tiers stay apart: a service gets each call with a verified caller and never sees a key, so a service release can't reach what the base guards. That's why the base is named and budgeted, and why moving code into it is a change to this part.
The release keys are hybrid like the account's (D-2) and live off the
servers: the first on the publisher's own machine, the second apart from
it. The public keys are compiled into every node. The log is append-only
and public, checked by nodes against each other (browser/checked-elsewhere
does the same for the page).
Open
- Which public log: our own, anchored in a public one, or an existing transparency log.
- Who rebuilds independently, so the cooling period means something: every node can, which is slow; a few named rebuilders, which is trust in them.
- The page's code is the weakest row: until native mode, whoever serves the origin can serve the tab anything before its first clean load.
- Revoking a release key, and rotating to a new one, through the account log.