Keys the page can't take
Keeps 5 promises
The core asks its host to sign or decapsulate, and never sees the key. A browser keeps WebCrypto keys that can't be exported; a machine uses a TPM, a Secure Enclave or a security key. Signatures and key exchange are hybrid and both halves must hold (D-2), so the half that can't be exported keeps a copied half from forging anything, even while ML-DSA and ML-KEM live in wasm memory. A browser holds a device key the log admits, never the account key. WebAuthn's PRF gives a secret only the passkey can produce, which seals what the browser keeps as bytes.
Native mode
Keeps 2 promises
On a machine running a node, the browser opens the OS from localhost,
served by that node from its signed release; elsewhere, an extension holds
the key and its code comes signed from its store. Either is another origin,
so another browser node, paired like any device. The log records the
release hashes the account approved, and a device approves each update;
native mode, an extension or the service worker after a clean load checks
it. A build of its own per person would not help: a proxy that can replace
the page replaces that too.
Noticing interception
Keeps 6 promises
- A native node trusts only bundled roots and the issuers our CAA allows
- Where a relay ends its own TLS, its challenge is bound to the channel
- A relay that sees a client's TLS fingerprint disagree with its browser warns the account, not the page
- A page that finds an update unsigned locks its keys and warns
- Another device checks what our origin serves
- A browser where interception was seen stays locked until a person clears it
A challenge sent from the page to the server proves nothing: a proxy that ends TLS forwards the challenge and the answer unchanged. So:
- A native node never reads the system's store. An inspection box works by adding its CA there, so the node sees a certificate it doesn't trust.
- A relay that ends its own TLS signs the nonce with the TLS exporter
value (RFC 5705) under its key in the log (
wire2/relay-signs); a proxy holds two TLS sessions, so the values differ. Native nodes only, since a browser can't read the exporter, and not on a relay behind Cloudflare's edge, which ends the TLS itself. - A proxy opens its own TLS with its own library, so its JA3/JA4 fingerprint doesn't match the browser it claims to be. A warning sent back down that connection would be stripped, so it goes to the other devices.
- After one clean load the page and its service worker are ours; when the network serves a page or a service worker that the release key didn't sign, the network is tampering. It is a race, since the proxy may tamper with only the browser's own update request.
- A node elsewhere can tell a local proxy from us serving bad code, against the signed release and a public log of release hashes.
Where it breaks: an attacker who replaces the page before any clean load, in a browser without native mode, runs every check in their own code. This catches inspection boxes, antivirus and captive portals, not them.