From 3706e6de2c44c7abdc77cc5f098a81b8941a7a0e Mon Sep 17 00:00:00 2001 From: Dan Connolly Date: Wed, 7 Oct 2026 04:32:44 -0500 Subject: [PATCH] =?UTF-8?q?fixup!=20docs:=20webkeys=20=E2=80=94=20ids=20as?= =?UTF-8?q?=20bearer=20capabilities,=20kept=20out=20of=20URLs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The cache page now follows the paper's form (fragment + skeleton page), with the XHR replaced by a Cap'n Web call taking the key in-band. Generated-by: Claude Opus 5.5 --- docs/webkeys.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/webkeys.md b/docs/webkeys.md index 7cfb215..80fe68c 100644 --- a/docs/webkeys.md +++ b/docs/webkeys.md @@ -78,9 +78,13 @@ fragment and the pattern got its standard form. minted by `newUniqueId()`, never derived from anything; all the authority, none of the log-trail - diigo-cache's ids are already webkeys in substance (bearer secrets); - the honest deviations, both known: keys travel in **POST bodies** - rather than fragment+XHR — same leak profile, simpler under a - form-driven UI with no skeleton page; and a hash of the id would + the cache page now follows the paper's form — `/cache/#`, a + skeleton page, its script passing the key to the server — with the + XHR replaced by a [Cap'n Web](https://github.com/cloudflare/capnweb) + call that takes the key *in-band*, as a method argument + (`api.cache(key)`), returning a capability. The forms elsewhere still + carry keys in **POST bodies** (same leak profile as the fragment). A + hash of the id would stand in wherever log-correlation is wanted (the swissHash discipline; `shashKey`, whose prefix is also the on-screen fingerprint). The bug that prompted this note: a cache id briefly