diff options
Diffstat (limited to 'docs/meshbay-draft-v5.md')
| -rw-r--r-- | docs/meshbay-draft-v5.md | 40 |
1 files changed, 34 insertions, 6 deletions
diff --git a/docs/meshbay-draft-v5.md b/docs/meshbay-draft-v5.md index 2a0f3b1..68f6843 100644 --- a/docs/meshbay-draft-v5.md +++ b/docs/meshbay-draft-v5.md @@ -65,6 +65,7 @@ This replaces the informal assurances scattered through v4 §4.2.x and §13. | Client code integrity | ❌ **T3, accepted** | ❌ T3 | ✅ | ✅ | ✅ | | Node content authority | ✅ | ✅ | ✅ sovereign | ✅ | ✅ | | Hub cannot obtain the group key | ✅ | ✅ **since H3 closed** — except in `join_policy = "open"` groups, where it can join legitimately | — | — | ✅ | +| Deleting your account erases you | ✅ hub-side | ✅ hub-side | ❌ **files, pinned identity and bundle stay on the node** — §6.1 | — | — | | Your identity keys stay yours | ✅ | ✅ | ⚠️ **offline attack on the bundle they hold** — see §7.1. Succeeds against a weak passphrase, and yields the identity used **on that node only**: nothing on anyone else's | ✅ | ✅ | **The claim this project can make:** *the hub cannot read your content unless it ships you @@ -237,10 +238,17 @@ of the loop, so nobody has to be online when the invitee actually joins. ### 5.2 Uploads -Confined to `shared_root/.uploads/{user_id}/`, filename allowlist, no overwrite, chunk -ordering enforced, size capped. Previously uploads landed in the shared root under a -client-chosen name and overwrote anything there — which also defeated deletion -authorization, since overwriting a file made the attacker its recorded uploader. +Confined to `shared_root/uploads/`, filename allowlist, no overwrite (a colliding name +gets a suffix), chunk ordering enforced, size capped. Chat attachments land there too, so +there is one directory an operator can look at, empty, or back up. Nothing derived is +written beside them: a chat thumbnail is the decrypted file scaled by the browser, so the +node stores no second copy of an image it already holds. + +The destination has moved twice — `shared_root/` → `.uploads/{user_id}/` → `uploads/` — +and the four protections above were carried across each move deliberately. The original +version accepted a client-chosen path and overwrote whatever was there, which defeated +deletion authorization as well: overwriting a file made the attacker its recorded +uploader, and therefore the party allowed to delete it (C5a). ### 5.3 Operator interface @@ -333,8 +341,28 @@ who could delete a file. private keys, GEK bundles, keypair bundles, node IPs beyond ephemeral signaling. **Knows, unavoidably:** who is a member of what, when nodes connect, when a chat message -was posted and by whom (`chat_notify` — minimization was in the dropped phase), and -content hashes for **public** groups only. +was posted and by whom, and content hashes for **public** groups only. + +The "by whom" is a `user_id`, not a display name, since 2026-08-15. The node has to name +the author for the hub to skip them when creating notifications — it used to name nobody, +so the hub substituted the node's own account and told every author about their own +message. The exchange is `chat_notify` over the node's hub socket and it carries no +content, but it is a stable identifier: the hub can build who-talks-in-which-group-when +without reading a word. Minimizing it was in the dropped phase, and it stays a known +metadata leak rather than a solved problem. + +**Erases on request, and what survives.** A user can delete their own account from +Settings (passphrase re-entered — a live token may be a borrowed laptop), and a hub admin +can delete one. The row is tombstoned rather than dropped: username released, email and +password hash cleared, node linking key dropped, memberships, notifications and refresh +tokens removed, active access tokens refused at once by status check rather than left to +expire. Two things survive on purpose. The IP log is kept for its legal retention period +and stays attributable, since detaching it would keep the data and lose the only thing it +is for. And **nothing on a node is touched**: files, the pinned identity and the keypair +bundle live on machines the hub does not command, which is the same sovereignty that makes +§5.5 work. Deleting the hub account is not an erasure request to the operators who host +you — the operator interface (§5.3) is where that happens. Deletion is refused outright +while the account still owns groups, rather than cascading into other people's data. **No longer decides:** who holds the group key. The hub still publishes public keys, and they are still used to look up an account by name — but nothing wraps a key for a key |