Use the fragment for what it actually provides
In an HTTPS URL, the fragment after the hash is interpreted by the browser and is not part of the HTTP request target. A static viewer can therefore load from a hardened origin while the compact report remains client-side. It need not appear in a server path, query string, application log, analytics request, or report database.
That property is useful, not magical. A fragment is not encryption, access control, authenticity, or revocation. Anyone who can see or copy the complete URL may see the carried report. The design must minimize the payload and explain its bearer nature.
Minimize before encoding
Portable reports should carry only the smallest reviewed set of findings needed for the handoff. Names, internal identifiers, images, free text, prompts, technical diagnostics, questionnaire answers, model output, and operational metadata usually do not belong in the fragment.
A compact, versioned binary or similarly constrained representation reduces QR density and limits disclosure. The full private record remains on the customer-controlled source system; the phone view is a deliberate derivative, not a database export.
Establish authenticity, not just integrity
A signature beside an arbitrary public key proves only that the same unknown party created both. The viewer needs a trust root it already recognizes, plus a certified report key or another controlled key-distribution method. It verifies the trust chain, key status, payload structure, and applicable time policy before rendering anything.
Use standard cryptography with domain-separated signed objects and dedicated keys. Report signing, TLS, release signing, SSH, and device identity should not share key material. Unknown versions and retired trust anchors fail closed.
Make the viewer forget
The static application should copy the fragment into memory, remove it from the visible address with browser history replacement, verify it, and avoid every unrelated network request. No analytics, remote fonts, customer-support widget, service worker, local storage, cookie, or report backend is needed.
Refresh can intentionally lose the report. That behavior is sometimes preferable to browser persistence. If a durable user-held document is required, give it a separately authorized archival signature and make the bearer-disclosure tradeoff explicit rather than quietly extending a temporary handoff.
- Serve a self-contained application under a strict Content-Security-Policy.
- Remove the fragment before validation errors or rendering.
- Keep temporary handoff and durable archive semantics cryptographically distinct.
Include the origin in the threat model
A compromised static origin can replace the verifier and read future fragments. Signed payloads do not make served JavaScript trustworthy. The viewer release therefore needs the same care as an appliance release: reviewed source, immutable artifacts, strict headers, minimal code, pinned trust roots, deployment provenance, health verification, and rollback.
The ingress and browser remain trust boundaries. Screenshots, photographs, clipboard history, extensions, malware, shoulder surfing, and a copied PDF can all bypass application intentions. Privacy engineering should state those limits plainly.