Frequently asked questions

What is HTMLTrust?¶

HTMLTrust is a decentralized framework for embedding cryptographic trust directly into HTML content. It enables content creators to sign semantically meaningful regions of web pages and include identity-linked metadata, so browsers and other tools can verify authorship and content integrity.

How is HTMLTrust different from existing solutions?¶

Unlike blockchain-based or DRM-centric systems, HTMLTrust is:

Lightweight: Minimal impact on page performance
Browser-compatible: Works with standard web technologies
Web-native: Designed around HTML
Decentralized: No central authority required
User-configurable: Supports personal trust policies

Existing methods like DKIM and PGP provide digital signatures, and ISCC provides content fingerprinting, but none integrate cleanly with web-native publishing or browser-based verification at the content-block level.

How does it work technically?¶

HTMLTrust proposes a new HTML element, <signed-section>, that wraps a signed region of a page. It includes:

The canonicalized content
Metadata (author identity via DID, timestamp, content hash)
A Base64-encoded digital signature

Browsers (via extensions) verify the signature against the author's public key and display trust indicators. See the spec for the exact attribute schema.

What cryptographic algorithms are supported?¶

The system supports multiple registered algorithms:

Ed25519 (ed25519): mandatory to implement
ECDSA over P-256 / P-384 (ecdsa-p256, ecdsa-p384)
RSA (rsa-pss-sha256, rsa-pkcs1-sha256)

Each <signed-section> names its algorithm via the algorithm attribute, using the identifiers above from the specification's algorithm registry.

Does it require blockchain?¶

No. HTMLTrust uses standard public-key cryptography and works with existing web infrastructure. It can optionally integrate with decentralized identity systems like DIDs, but blockchain is not required, used, or planned.

Can I sign only parts of a page?¶

Yes. Each <signed-section> is independent, so a single page can have multiple signed blocks from different authors, such as a forum or a collaborative article.

What happens in browsers that don't support it?¶

HTMLTrust degrades gracefully. Unsigned or unrecognized <signed-section> elements render as normal content. Only the verification features are unavailable. The page remains fully readable and functional.

Why does a signed page show as invalid in the browser even when the signature is mathematically correct?¶

This is a real, observed issue: HTMLTrust signs the server HTML that leaves the publishing pipeline. Browser verifiers should use the original response snapshot before page scripts or browser extensions can mutate it; if that snapshot is unavailable, they can re-request the document from the same origin. Live-DOM verification is a separate state because anything inside a <signed-section> can be changed after load.

This site hit it twice. The theme it previously used injected a <button class="copy-button">Copy</button> into every <pre> block at runtime, so the canonical text a verifier read contained "Copy" tokens the signer had never seen. The architecture page then did it again with client-rendered diagrams, which replaced each diagram's source with generated markup inside a signed region after load.

Both are fixed the same way, by removing the runtime step: this site now ships no JavaScript on any signed page, and its diagrams are static text that the signer hashes along with everything else. That is the general lesson. If a signed region's final form depends on script, the signature describes something the reader never saw.

Other common culprits:

Client-side syntax highlighters (Prism, highlight.js) that rewrite code blocks
Lazy-loading or share-button widgets that add nodes inside article content
Theme JS that decorates headings, callouts, or admonitions at runtime

What to do about it:

Configure or patch the theme so it does not inject nodes inside <signed-section> descendants
Pre-render any decoration server-side, so the signer hashes it
Move runtime-injected decoration outside the signed region (as a sibling, not a child)
Use a verifier that checks the server HTML snapshot and treats a changed live DOM as stale rather than fully verified

A mutation-skip marker such as data-htmltrust-ignore="true" has no normative effect in the current draft. This is tracked in Known Issue: Runtime DOM Mutation in the spec README.

What browsers are supported?¶

A reference extension builds for Chrome, Firefox, and Safari. Only the Chrome build is currently exercised end to end as an installed extension in automation; the Firefox and Safari bundles build and pass lint but have not been driven as installed extensions yet. Chromium-based browsers such as Edge use the Chrome build. See reference implementations for per-component verification status. The eventual goal is native browser support through a W3C standard, which is why the extension is a stepping stone rather than the destination.

What CMS platforms are supported?¶

A reference plugin exists for WordPress, and the Hugo module provides the corresponding signing partial and command-line signer. The architecture supports any CMS that can call an HTTP API and embed HTML attributes. See the CMS reference repository for details.

How does HTMLTrust handle AI-generated content?¶

Content metadata can include claims about AI involvement:

Human-only: No AI was used
Human+AI: Human-authored with AI assistance
AI+Human: AI-generated with human editing
AI-only: Fully AI-generated

These claims are signed by the author, providing a cryptographically verifiable assertion (though not a proof) of content origin.

Can HTMLTrust prevent AI training on my content?¶

HTMLTrust metadata can include explicit AI training preferences aligned with emerging standards such as Content Preferences. The signed preference travels with the verified content. Enforcement still depends on AI developers honoring it.

Is HTMLTrust an official web standard?¶

No. Two drafts exist and neither has been submitted: an IETF Internet-Draft for the wire protocol, and a W3C Community Group Report for the HTML and DOM integration. Both are published here for review before they go anywhere official.

The sequencing is deliberate. Browser-native <signed-section> is the hardest path and the last one, since browser vendors have good reason to be sceptical of signed-content proposals after Signed HTTP Exchanges. The nearer target is crawl-time verification by a search or answer engine, which needs no browser change to be useful and produces the operational evidence a standards discussion actually wants.

How can I get involved?¶

Browse the GitHub repositories for the spec, server, browser extension, and CMS plugins
Open issues or pull requests
Try the reference implementations and provide feedback
Contact jason@jason-grey.com with questions or collaboration ideas