Say what the verification, erasure and sealed claims actually establish - #225
Merged
404SecNotFound merged 2 commits intoSep 28, 2026
Merged
Conversation
docs/AUDIT-BRIEF.md gathers what an external reviewer of the current format needs: scope with pointers to the normative sections, what is out of scope, adversaries with the documented position on each, the evidence available, the open findings, questions for the reviewer, and a claim register linking each security claim to its evidence and to what it rests on. It says plainly that no review of the current format has been engaged. Roadmap 2.3 said authenticating an AEAD ciphertext requires producing the plaintext, and that the verify-only plaintext stays in the worker heap. The first is a property of the APIs the app calls, not of AES-GCM or ChaCha20-Poly1305. The second is false: the worker returns the plaintext to the page, which zeroes it (9.2).
The assurance wording is corrected where it claimed more than the code or the evidence does. Each change was checked against the source first. - Verify-only: the docs guide said the plaintext is discarded in the worker. It comes back to the page, which zeroes it without rendering it (9.2). SECURITY-AUDIT.md and roadmap 2.1 said passwords and plaintext live in the worker's heap; both now carry a dated correction. - Erasure: the auto-lock toasts said secrets were "wiped from memory", and the dice tool offered to "clear the log from memory". JavaScript gives no such guarantee; they now say cleared from the page. - Sealed status: "nothing leaves" became "no connections", which is what the policy check proves (SEALED_CLAIM already says blocking connections is not every way out). The in-place check said "N of N cached files match" without saying that files not in the cache are skipped; it now says how many of the manifest's files were not checked, and that a manifest from the same place shows consistency, not origin. The docs guide's "forbids every network destination" is narrowed the same way. - Verification: the verify page, VERIFYING.md, HOW-IT-WORKS.md and the README said verification proves "the bytes you ran" match the source, or that sha256sum checks the signature. It checks the files you downloaded, and the signature needs an identity from outside the site. They also pointed at "the audit" for whether the source is correct; the review on record does not cover the current format. - The inspector said "a removed slot can't hide"; a slot holder can re-seal the table, so it now says a change made without a key is reported. - The "zero knowledge" metadata keyword is removed; OUTREACH.md already rules the phrase out. The review brief now states that the repository describes its reviews two ways (external review in SECURITY-AUDIT.md, a self-audit in OUTREACH.md) and leaves which is right to the owner. The sealed-status browser test now checks the unchecked-file count against the manifest on disk, and the origin caveat. Negative controls: hiding the count and dropping the caveat each fail it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The assurance language is corrected where it claimed more than the code or the evidence supports, and a brief for a review of the current format is added. A sweep of every doc and UI string found about 60 assurance claims. Each change below was checked against the source before editing. Based on
main. It refers to roadmap 9.x, which #223 adds, but does not conflict with #223 or #224.Changes
Claims corrected
sha256sumchecks the signature; "the audit" says whether the source is rightSECURITY-AUDIT.mdkeeps its record and gains a dated correction note, not a silent rewrite. It still names none of the current-format subjects, so the README gate's scope check holds.New:
docs/AUDIT-BRIEF.md. It sets out what a reviewer of the current format needs:Needs an owner decision
The repository describes its reviews two ways.
SECURITY-AUDIT.mdcalls its findings "external review", and one section a "Third-party audit (four-agent swarm)".OUTREACH.mdsays the project is "Not audited" and has a self-audit.Only you know who performed them. The brief states the conflict and asks readers not to treat those findings as independent assurance until you settle it. I did not change the audit's or the README's characterisation.
Test plan
typecheck,test:readme,test:release-notes,test:release-gate,test:release-recipe,test:seal-verdictandtest:csp-egresspass.tests/browser/sealed-status.spec.tsnow checks the unchecked-file count against the manifest on disk. On the real build the manifest lists files the cache does not hold, so that branch is exercised. It also checks the origin caveat.Not done here
test:screenshotschecks widths only.docs/design/). These are planning documents, and their similar wording is left as written.