From 2acd1b17ad94536e4a0504087adcd9dc936896ea Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Wed, 14 Oct 2026 23:33:17 +0200 Subject: docs: a browser is not linked as a device A browser keeps no identity between connections, so a key approved for it is gone by the next one: the guide, the design and the interface no longer offer it. With browser access off, the application and the command-line client open the account's groups; the linking form, shown in the application only, now says "this computer". Co-Authored-By: Claude Opus 5.5 --- docs/MESHBAY_DESIGN.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'docs/MESHBAY_DESIGN.md') diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index 49baa6a..a9502d8 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -702,8 +702,9 @@ groups, and it is made **in the desktop application, never in a browser**: The hub keeps a **mirror** of the setting as a preference (`browser_access`), written by the application at each start and change. It grants nothing — no node reads it — and exists so a browser can say why a group will not open and name the -way in: turn it on from the application, or approve this browser from it (device -linking, §3.3), which gives the browser identities of its own. Were a browser able +way in: turn it on from the application. A browser is not linked as a device (§3.3): +it keeps no identity between connections, so a key approved for it would be gone by +the next one. Were a browser able to turn it on, somebody holding only the passphrase could sign in on the web, flip it, and have the owner's own application upload the identities at its next start — under the pepper that same sign-in hands out. @@ -1116,8 +1117,8 @@ the proof, because each is something a caller needs *in order to* prove possessi of the group key: a returning browser has to recover its identity, a new member has no key to prove with, and a new device of a known member has none either — the group key is wrapped for an identity the node pinned, and a machine that keeps no -bundle there (the desktop application, the command-line client, a browser with -browser access off) holds no such identity until another device approves it. +bundle there (the desktop application, the command-line client) holds no such +identity until another device approves it. Nothing else qualifies. Filing a device request is **inert**: nothing is admitted until a device already pinned countersigns it, the code is bound to the new keys, the request is bounded per connection (5) and per account (10 pending), and it is -- cgit v1.2.3