diff options
Diffstat (limited to 'docs/MESHBAY_DESIGN.md')
| -rw-r--r-- | docs/MESHBAY_DESIGN.md | 21 |
1 files changed, 19 insertions, 2 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index cd97aa2..d63f722 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -2261,7 +2261,24 @@ What running it establishes, and what each fact costs: - **The device's hub key lives in the main process, never in the renderer.** Generated, stored and used there; the interface asks for a signature and is never handed a key. Same rule as the save dialog, and for the same reason: the renderer - parses decrypted content from nodes, which is attacker-controlled input. + parses decrypted content from nodes, which is attacker-controlled input. The + secret store that holds it is not reachable from the page either: a generic + read and write by name was a way to take the key and to replace it, and nothing + in the interface used it. +- **The page administers the local node by operation, never by route.** It names + one of the operations the interface performs (`NODE_OPS` in `main.js`); the main + process checks the arguments — ids are ids, names are encoded — builds the + request and adds the node's token. `node:start` writes the hub this application + is signed in to and a username the hub would register, never a value the page + supplies verbatim. **What widens what the node shares or admits, or replaces its + group key, is confirmed by a dialog the main process draws**: hosting a group, + sharing a folder not chosen in the native folder picker (one chosen there is its + own confirmation, so the ordinary path asks nothing twice), rotating the key, + clearing the denylist, and pointing the node at another account. The words come + from the interface's catalogues, read by the main process; the page sets the + language and nothing else. An in-page confirmation is one a script in the page + can answer for itself. **Every channel answers only the packaged page's top-level + document.** - **OS-backed secret storage is real on a desktop and honest without one.** With a keyring it is keyring-backed; headless, the same code reports unavailable and **refuses to store rather than downgrading silently**. @@ -3435,7 +3452,7 @@ had already been asked. | **O1** | Initial key setup in the pre-proof window — deferred; that window is where C4 and C5b came from | | **O2** | A LAN enrolment door — one endpoint, bounded window, one-time code, closing permanently on success | | **O3** | `device_policy {allow_bundle: false}`, signed by a pinned key — **the mechanism that actually closes C4** (§3.7) | -| **O4** | Isolating the node-admin panel from the process holding user keys | +| **O4** | Isolating the node-admin panel from the process holding user keys. **Narrowed**: the panel reaches the node through named operations, and what widens the node is confirmed natively (§8.2); it still runs in the renderer that parses node content | | **O5** | An unlock key in the environment, for the **node** | | **O6** | The engine version floor, verified rather than assumed | | **O8** | A minimum client version in the hub version endpoint — **done** (§5.6) | |