Background
The spec README already documents Known Issue: Runtime DOM Mutation — content-signing protocols that target browser-side verification have to contend with client-side scripts mutating signed content between page load and verification.
The near-term fix in the reference extension is to verify against a fresh fetch(location.href) rather than element.innerHTML (landed in HTMLTrust/htmltrust-browser-client#1 + HTMLTrust/htmltrust-browser-reference#3). That sidesteps the problem but only for browsers + a fresh-fetch path; it doesn't address the deeper architectural answer.
What we want from this issue
A spec section (and/or paper appendix) outlining how a future browser-native HTMLTrust verifier would work:
- Run during HTML parsing, before any inline or external script is scheduled — the verifier never reads a mutated DOM
- Expose the result on the
<signed-section> element as a real DOM property (e.g. section.htmltrustValid, section.htmltrustKeyid, etc.) so page scripts and UAs can consult it cheaply
- Frame the existing extension verification as a stopgap; document the spec's expectations on a conformant native implementation
- Touch the related spec design knobs:
- whether the native API should also expose endorsements / trust-policy hooks
- how trust-policy state (user trust lists, directory subscriptions) is surfaced to the UA chrome
- interaction with view-source, SSR, and SPA navigation
- relationship to existing browser content-integrity primitives (Subresource Integrity, CSP, Trust Tokens)
Definition of done
- Spec gets a new "§ Native browser verification (informative)" or similar section
- README cross-references it from the Known Issue section
- Optionally: a short note in the paper
Not in scope here
- Actually shipping in a browser engine — this is purely a design write-up to anchor future W3C-track conversation
- The mutation-skip marker (
data-htmltrust-ignore) — that's a different open question and can land separately
cc'd as an idea while triaging the runtime-DOM-mutation issue we hit on the project website.
Background
The spec README already documents Known Issue: Runtime DOM Mutation — content-signing protocols that target browser-side verification have to contend with client-side scripts mutating signed content between page load and verification.
The near-term fix in the reference extension is to verify against a fresh
fetch(location.href)rather thanelement.innerHTML(landed in HTMLTrust/htmltrust-browser-client#1 + HTMLTrust/htmltrust-browser-reference#3). That sidesteps the problem but only for browsers + a fresh-fetch path; it doesn't address the deeper architectural answer.What we want from this issue
A spec section (and/or paper appendix) outlining how a future browser-native HTMLTrust verifier would work:
<signed-section>element as a real DOM property (e.g.section.htmltrustValid,section.htmltrustKeyid, etc.) so page scripts and UAs can consult it cheaplyDefinition of done
Not in scope here
data-htmltrust-ignore) — that's a different open question and can land separatelycc'd as an idea while triaging the runtime-DOM-mutation issue we hit on the project website.