What we publish encrypted: every key and sealed secret on the site, and who can open it

By security@web-summit.dinis, 5 November 2026, 03:49 UTC, at Dinis's word: "a special review ... about all the PKI keys and encrypted secrets that we are now starting to publish on the site, for example there are some vault keys (like the one to the observability vault) that are now encrypted (only to a couple of the humans' keys)." It covers the repository at site v0.2.460. Nothing here holds a secret. Every envelope was read for its header only; none was opened.

The short answer

• Nothing has leaked. All the sealing is sound: the cryptography is standard, every fingerprint recomputes, and every key was published by the session that made it. No script by any person or agent has ever touched the keyring, the sealed files or the browser's key store (git history checked).
• "Only a couple of humans" is not who can open them. A person key is made by that person's conductor, which keeps the private half. Every secret sealed to a person is also open to their conductor's session, and to the agent that sealed it.
• The real risk is the browser, not the cryptography. Sealed secrets are opened on web-summit.sgit.ai, where scripts from several people's folders also run, and the keyring is open to any script on the page. One bad commit to someone's script would be enough to read Dinis's observability vault keys and access token the next time he loads a page. WS-164: close that path before anything else real is sealed.

What is published

The real secrets, and who can really open each

So the observability vault key is open to one human and two agents, and the sticker vault key to four humans and four agents. That is by design ("the issuing agent holds the private half too, and says so", admin/tools/person-key.mjs; WS-138), and acceptable for low-value keys. It is not "encrypted only to the humans".

Findings

1. High: secrets are opened in pages that also run other people's scripts (WS-164). The keyring (assets/keyring.js) loads on every page and exposes window.WSKeyring.open() to any script there. Non-extractable keys stop a script from copying the key, not from using it. On the same pages run scripts from people's own folders: Indi's factory.js on /people/indi/factory/, Angelo's and Jose's app.js in their command centres, and whatever any people/<id>/pages.mjs puts in a page's head. And assets/obs-view.js, having opened Dinis's envelope, writes each vault key into a link in the page (https://dev.vault.sgraph.ai/#<vault key>), where any script can read it without the keyring at all.
   • Today every one of those scripts is clean, and none has ever referenced the keyring (history checked).
   • But a single commit to any of them, by a person's agent misled by something it read, would read the observability access token and vault keys the next time Dinis opens such a page.
   • This is the case WS-132 (parts 2 and 3) and WS-117 warned about, and the condition was "seal nothing real until then". Real secrets are now sealed.
2. Medium: a person key is also its conductor's. Six conductor sessions each hold one person's private half (~/.sg-send/issued/), unencrypted on the session's disk unless a passphrase is set. Every past and future secret sealed to that person opens there too. The conductors are the agents that read the most material written by others (WS-156). Until people make their own keys (WS-117), seal to a person only what their conductor may also read.
3. Medium: who sealed it is not proven. Every ws-ecies-1 envelope is unsigned, and its by, at and recipient are not bound to the ciphertext. Anyone with push access can add a sealed "vault key" or "access token" under someone's data/sealed/ that says it came from their conductor, for example pointing them at a vault the attacker reads. Sign each envelope with the sealer's key and show "from" only when it verifies. The inbox's sealed tokens are signed; these are not.
4. Medium: nothing expires, and nothing is forgotten. The envelopes carry no expiry. Git keeps every one forever, and there is no forward secrecy. The person keys sit in browsers' IndexedDB with no end date. If any conductor's session disk, or a person's browser profile, is exposed later, everything ever sealed to that person opens. After the summit: rotate the observability access token and the vault keys sealed here, mark the person keys replaced, and seal nothing to them again.
5. Low, privacy: the second sender records how long each team member reads. assets/obs-dinis.js (observability@web-summit.dinis) sends, on every page and signed with the person's key, how long the page was visible and how far it was scrolled. It honours Do Not Track, GPC and the pause switch, and collects no IP or user-agent. Say it plainly on the start page: "the site records which pages each of us reads and for how long".
6. Holds. All six person keys' fingerprints recompute from their keys, and each was pushed by the conductor session its entry names. The append tokens can only write, and the read keys are public by design. The inbox's lane tokens are sealed per agent and signed. Every file in this inventory is in git (no secret in plain text anywhere: the gate's check 5, including the bare vault-key pattern decided on WS-122).

What to do, in order (WS-164)

1. Now, small: stop loading keyring.js (and obs-view.js) on any page that carries a script from a person's folder (pages.mjs heads, people/<id>/app/app.js). Have obs-view.js open vaults by postMessage, as the vault embed does, never with the key in a link. Add a gate check that no script under people/ mentions WSKeyring, ws-keyring, indexedDB, sealed or document.links.
2. Until 1 is done: seal nothing more that is real to a person key.
3. This week: sign every ws-ecies-1 envelope and give it an expires. The UI shows "from" only when the signature verifies.
4. After the summit: rotate what was sealed (the observability access token and vault keys, the sticker vault). Mark the issued person keys replaced, and move people to keys they make themselves, on an origin of their own (WS-117).

Update, 5 November 11:50 UTC

From the scheduled review at site v0.2.538 (team/security/reviews/2026-11-05-1150.md):

• WS-164 items 1 and 3 are done, and I checked them (90e73e39, dev@web-summit.dinis). No built page that runs a person's script loads the keyring any more: Indi's factory, Angelo's and Jose's command centres, and Dinis's lab all carry none. A pages.mjs page with any <script>, inline or external, gets no keyring. Gate check 22 refuses a person's .js that reaches for the keyring, IndexedDB, the page's links or data/sealed/. Item 2 is still open: obs-view.js still writes vault keys into links. It now runs only on pages without people's scripts, so that matters less, but keys should still never sit in the page.
• The observability vault keys now go to four people. At Dinis's word (89c5b9b6), they are also sealed to Angelo, Jose and Silvio (people/dinis/observability/sealed/<person>.json). With each person's conductor holding that person's key, four people and five agents can now open them: the four conductors and observability@web-summit.dinis, which sealed them. They are unsigned and have no expiry, like every ws-ecies-1 envelope. Rotating them after the summit now matters more.
• "Signed by Dinis's own site key carries his word" is not yet true. The channel with Agent (RiskMandate.ai) (content/family-riskmandate-agent.md) says a message signed by Dinis's site key carries his word. That key was issued by conductor@web-summit.dinis, which holds its private half, so the conductor can sign anything as Dinis. Until Dinis holds a key he made himself (WS-117), "Dinis's word" on that channel should mean a message Dinis sends himself, not one signed with the issued key.

Update, 5 November 23:50 UTC

From the scheduled review at site v0.2.684 (team/security/reviews/2026-11-05-2350.md):

• The team CRM's private vault key is now the widest-held secret (WS-170, 237ee015, at Dinis's word). It is sealed to all six people's keys (data/sealed/<person>/*-team-crm-key.json), separately to six conductor keys (data/sealed/agents/, sgit hybrid v2, signed by the conductor; Indi has two conductor keys and both got it), and to two CRM agents. With each person key also held by that person's conductor, six people and about nine agent sessions can open it, plus conductor@web-summit.dinis, which made it.
• The design limits what that key gives. Each private record is a ws-crm-env-1 envelope with its own content key, sealed only to that record's audience. Holding the vault key reads the vault's ciphertext and lets you write to it, but it does not open a record you are not in the audience of. /crm/ opens the vault key in memory and does not write it into the page or storage. The one exception: "Open the private CRM in a new window" puts the vault key into that tab's address (dev.vault.sgraph.ai/#<key>), and so into the browser's history and anything that syncs it. Prefer the in-page app.
• The sealing tool skips the checks seal.mjs makes (WS-178). crm.mjs seal-keys and crm_agents.py pick recipients by label and missing status. There is no check of the account that pushed the key (WS-106) and no ended-key check beyond status (WS-152). A key entry anyone pushes under a conductor's name would get the private CRM's key at the next run. Fix it before the next run.
• WS-156 is overridden for this vault, at Dinis's word: its key now sits with every conductor. The per-record audiences are what keep this acceptable. Keep anything sensitive in records with a narrow audience, never in plain files in that vault.
• The public CRM publishes 249 people as the summit lists them (name, role, organisation, sessions), each with its source, and no contact details (stated, and checked by the gate on this repository). It is public data, gathered into one graph: say on /crm/ how a person can ask to be removed.