research: update paper with v1 evidence

.gitignore

@@ -23,6 +23,8 @@
 *.pdf
 paper/dist/
 paper/tmp/
+/tmp/
+/output/
 
 # OS files
 .DS_Store

Makefile

@@ -1,4 +1,4 @@
-.PHONY: all check ietf paper paper-docker paper-arxiv paper-arxiv-docker w3c w3c-check
+.PHONY: all check ietf paper paper-diagram paper-docker paper-arxiv paper-arxiv-docker w3c w3c-check
 
 all: check ietf w3c-check paper
 
@@ -11,6 +11,10 @@ ietf:
 paper:
 	./scripts/build-paper.sh
 
+paper-diagram:
+	mmdc $(MERMAID_ARGS) -i diagrams/architecture1.mmd \
+		-o paper/images/architecture1.png -b white -w 1200 -s 2
+
 paper-docker:
 	./scripts/build-paper-in-docker.sh
 

README.md

@@ -21,6 +21,7 @@ From the repository root:
 make check       # validate vectors and repository invariants
 make ietf        # regenerate the IETF XML, HTML, and text artifacts
 make paper       # build paper/htmltrust.pdf
+make paper-diagram # regenerate the paper architecture diagram
 make w3c         # serve the W3C draft at http://localhost:8000
 make w3c-check   # render the W3C draft and fail on ReSpec diagnostics
 ```
@@ -79,6 +80,12 @@ from `.docker/paper/Dockerfile`, then mounts the checkout into a short-lived
 container. Docker caches the package-install layer; source files and the PDF
 remain on the host. Set `HTMLTRUST_PAPER_IMAGE` to use another local tag.
 
+The generated paper diagram is committed. To change it, edit
+`diagrams/architecture1.mmd`, install Mermaid CLI with
+`npm install --global @mermaid-js/mermaid-cli`, and run
+`make paper-diagram`. Pass extra Mermaid CLI options through `MERMAID_ARGS`
+when Chromium needs a Puppeteer configuration file.
+
 ### W3C draft
 
 The W3C draft uses ReSpec. Run `make w3c`, open <http://localhost:8000>, and
@@ -88,13 +95,21 @@ writes its temporary snapshot under `$TMPDIR` when set, then `RUNNER_TEMP` or
 
 ## Understand implementation status
 
-The drafts define the target protocol. The reference repositories implement
-the stable `v0.2.2` canonicalization profile and the current end-to-end flow.
-The newest draft rules still require downstream implementation work. These
-include the v1 JCS signing object and location scope, safe signed URLs,
-parser-profile rejection, U+0040 escaping, complete RFC 8785 processing,
-resource ceilings, and the native browser lifecycle. The review documents
-identify each remaining gap.
+The reference repositories implement the v1 signing profile, including the
+JCS signing object, URL and origin scopes, HTTPS-only signed URLs, parser
+preflight, resource ceilings, and source-to-rendered browser lifecycle. The
+2026-08-28 evidence snapshot pins these tested revisions:
+
+| Component | Revision | Validation |
+|---|---|---|
+| Canonicalization | [`b0c8f305`](https://github.com/HTMLTrust/htmltrust-canonicalization/commit/b0c8f305425de190a7f209ac117d34f88c2b1946) | 123 shared fixtures across five language ports |
+| Browser verification library | [`d25c6d3c`](https://github.com/HTMLTrust/htmltrust-browser-client/commit/d25c6d3c2d0f4d67483da20853f22e94a11b89cc) | 51 tests |
+| Reference extension | [`5237f070`](https://github.com/HTMLTrust/htmltrust-browser-reference/commit/5237f07098da8b6542f0fd8f1c613ae8dbf4e6dd) | 64 tests plus a Chromium lifecycle check |
+| Directory server | [`f84f5148`](https://github.com/HTMLTrust/htmltrust-server-reference/commit/f84f51482ba2a925d9b5ff148185adf6dedef566) | 85 tests plus OpenAPI conformance |
+| End-to-end harness | [`034af226`](https://github.com/HTMLTrust/htmltrust-e2e/commit/034af22697f8b2a1c08b0c01200ca019995ca817) | Clean HTTPS simulation and CI |
+
+Native browser support remains a standards proposal. The current browser
+implementation is a Chromium extension.
 
 Current prototype repositories:
 
@@ -109,8 +124,10 @@ Current prototype repositories:
 | [htmltrust-e2e](https://github.com/HTMLTrust/htmltrust-e2e) | Combined system tests |
 | [htmltrust-website](https://github.com/HTMLTrust/htmltrust-website) | Project website and published draft copies |
 
-For a workspace-wide checkout and the combined run order, use the umbrella
-[developer guide](../README.md).
+To run the coordinated system, clone these repositories as siblings and start
+with the
+[end-to-end harness](https://github.com/HTMLTrust/htmltrust-e2e#readme). Its
+one-command workflow validates sibling paths and builds the required services.
 
 ## Contribute or report a problem
 

diagrams/architecture1.mmd

@@ -0,0 +1,9 @@
+flowchart TB
+    A[Author] -->|writes content| C[CMS signing integration]
+    K[Author private key] -->|signs region| C
+    C -->|publishes| P[Page with signed section]
+    C -->|publishes public key| D[HTTPS key endpoint or optional directory]
+    P -->|source snapshot| V[HTMLTrust verifier]
+    D -->|key and optional endorsements| V
+    V -->|interactive use| U[Browser indicator]
+    V -->|crawl-time use| I[Verified content record]

paper/ARXIV-SUBMISSION.md

@@ -27,18 +27,18 @@ This command builds the PDF and writes
 
 Inspect the printed archive listing and the final PDF before upload. The
 supplementary Study 1 source and evidence remain in
-`paper/artifacts/study1-v03/`; the paper cites that stable repository snapshot.
+`paper/artifacts/study1-v04/`; the paper cites that stable repository snapshot.
 
 ## Plain-text abstract
 
-> We specify HTMLTrust, an in-band signature protocol for semantic regions of HTML. A signed section binds normalized text and four reader-relevant attributes through a content hash. An RFC 8785 canonical JSON signing object binds that hash with the claims hash, signer key identifier, signature algorithm, publication location, signed time, and profile identifiers. Verification is deterministic after the verifier obtains the source snapshot and resolves the key; optional federated directories distribute key records and signed endorsements. The version 0.3 prototype includes five parser-backed language bindings, a reference directory, a browser verifier, and publishing integrations. All five bindings pass 118 shared canonicalization fixtures, including expected rejections. A separate Ed25519 vector fixes the signing input and signature; JavaScript and Go recompute and verify the full vector, while the remaining bindings exercise its canonicalization or payload stages. On 4,846 Common Crawl News body regions, the five independent ports produce matching digests for 119 of the 121 jointly canonicalizable inputs. Shared-core adapters agree on all 174 inputs they jointly canonicalize. The protocol separates cryptographic integrity from user-selected trust policy and defines explicit limits for replay, parser ambiguity, URL handling, and resource use.
+> We specify HTMLTrust, an in-band signature protocol for semantic regions of HTML. A signed section binds normalized text and four reader-relevant attributes through a content hash. An RFC 8785 canonical JSON signing object binds that hash with the claims hash, signer key identifier, signature algorithm, publication location, signed time, and profile identifiers. Verification is deterministic after the verifier obtains the source snapshot and resolves the key; optional federated directories distribute key records and signed endorsements. The v1 prototype includes five parser-backed language bindings, a reference directory, a browser extension, and publishing integrations. All five bindings pass 123 shared canonicalization fixtures, including expected rejections. On 4,846 Common Crawl News body regions, all five ports accepted 121; 119 of those 121 produced identical digests. A selected 47-case adversarial evaluation matched every expected outcome. The protocol separates cryptographic integrity from user-selected trust policy and defines explicit limits for replay, parser ambiguity, URL handling, and resource use.
 
 ## Replacement comment
 
 Use this comment for a replacement submission and adjust the version number if
 needed:
 
-> Updated the protocol description to match signing profile v1 and canonicalization revision 12bc7e839d5e2a858c29bba651e704e8ed036d95. Added the final 4,846-region Common Crawl operational study, including separate independent-port and shared-core results, source-transformation probes, sampling limits, and a supplementary reproducibility archive. Narrowed claims about end-to-end vector coverage, replay scope, deployment evidence, and generalizability.
+> Updated the implementation evidence to canonicalization revision b0c8f305425de190a7f209ac117d34f88c2b1946 and expanded the conformance suite to 123 fixtures. Added selected adversarial cases, signing measurements, a Chromium lifecycle check, a local HTTPS integration simulation, and a Sybil policy-sensitivity model. Clarified the historical 31.4% result and the limits of the operational sample, benchmark, browser tests, and Sybil model. Replaced the supplementary archive with Study 1 v0.4.
 
 ## Final checks
 

paper/README.md

@@ -17,6 +17,10 @@ make paper
 The build runs `pdflatex`, `biber`, and two final `pdflatex` passes. It writes
 `paper/htmltrust.pdf`, which Git ignores.
 
+The architecture image is committed. Edit `diagrams/architecture1.mmd` and
+run `make paper-diagram` from the repository root to regenerate it. The root
+README lists the Mermaid CLI install command.
+
 If TeX Live is unavailable on the host, use Docker:
 
 ```sh
@@ -60,10 +64,16 @@ Check the page limit of any external review service before submitting. The
 paper length can change as the source changes. Completed external reviews live
 under `paper/reviews/` with their submission date.
 
+PaperReview.ai accepts PDF files up to 10 MiB and analyzes the first 15 pages.
+Before submitting, use `pdfinfo paper/htmltrust.pdf` to confirm the page count
+and `wc -c paper/htmltrust.pdf` to confirm the size. Save the private review
+token returned by the service because review email delivery can fail.
+
 ## Related documents
 
 - [Repository guide](../README.md)
 - [IETF protocol draft](../ietf-draft/README.md)
 - [W3C browser-integration draft](../w3c-cg/README.md)
-- [Study 1 v0.3 supplementary artifact](artifacts/study1-v03/README.md)
+- [Study 1 v0.4 supplementary artifact](artifacts/study1-v04/README.md)
+- [Historical Study 1 v0.3 artifact](artifacts/study1-v03/README.md)
 - [PaperReview.ai round-one review](reviews/paperreview-round1.md)

paper/artifacts/study1-v04/README.md

@@ -0,0 +1,38 @@
+# HTMLTrust Study 1 v0.4 supplementary artifact
+
+This directory archives the study source and compact evidence cited by the
+HTMLTrust paper.
+
+| Field | Value |
+|---|---|
+| Study commit | `2265eebdbc20cf16e59c1d8d4571d0235f9ebadf` |
+| Canonicalization commit | `b0c8f305425de190a7f209ac117d34f88c2b1946` |
+| Corpus records | 4,846 |
+| Corpus SHA-256 | `8c6831bece6f45f25622cf011ac1fcf45d1fcda36f14b8e111566317c12c7f92` |
+| Container image ID | `sha256:579515b828ef6930af9fc52b92c79ed9bc91520577682b11de1aa14214be09f1` |
+
+[`htmltrust-study1-2265eeb.tar.gz`](htmltrust-study1-2265eeb.tar.gz)
+contains the Docker harness, tests, corpus and run manifests, aggregate corpus
+results, adversarial fixture evidence, signing measurements, and the Sybil
+policy-sensitivity model. It excludes the 1.2 GB corpus, per-record run output,
+and source WARC files. The corpus manifest identifies each WARC by filename,
+size, and SHA-256 and records the selection parameters.
+
+Verify and extract the archive:
+
+```sh
+sha256sum -c SHA256SUMS
+tar xzf htmltrust-study1-2265eeb.tar.gz
+cd htmltrust-study1
+```
+
+Start with `results/v04/README.md`. It gives the current findings, evidence
+layout, checksum command, and exact Docker commands for each experiment. The
+top-level README explains how to rebuild the pinned image and run the study
+from a clean checkout.
+
+The historical v0.2 and v0.3 evidence remains inside the archive so readers
+can trace earlier measurements. Reproducing the Common Crawl experiment
+requires the external corpus named by the manifest. Package repositories can
+change over time, so retain the recorded image when exact runtime layers are
+required.

paper/artifacts/study1-v04/SHA256SUMS

@@ -0,0 +1 @@
+be013cd01f9fa5c1be4af5c9f2ff7485a52310851a7396fb4fb6a0551e1323d8  htmltrust-study1-2265eeb.tar.gz