By V · Published 23 October 2026 · Experimental project notes
By V · 23 October 2026. This note describes the reviewed VVault/VRelay 0.2.9 offline implementation. It explains a bounded integrity mechanism, not a guarantee that a browser application is safe to use for sensitive communications.
A response has bytes and policy
A browser’s interpretation of a file depends on more than its body. Content type, Content Security Policy, permissions and isolation headers influence how code executes. A correct body hash does not authenticate arbitrary cached response headers.
Build a canonical manifest
The build asks the same route handler used for live delivery for each offline asset’s canonical response. It records the SHA-256 integrity value and canonical headers. The offline release identity hashes the manifest and service-worker template, so changes to either generate a different cache identity.
Verify, then reconstruct
The service worker’s verifiedResponse requires a complete policy map, reads the response bytes and compares their SHA-256 digest with the manifest. It then constructs a new status-200 response using those bytes and release-pinned headers. It does not return the mutable cached response object.
This discards unsolicited cached metadata such as redirect or download headers. Required policy fields include content type, CSP, permissions policy, referrer policy, isolation headers and cache control. Installation verifies responses before storing them. Every intercepted offline read verifies again to detect later corruption.
Fail closed, with recovery instructions
Missing files, mismatched digests or incomplete policy metadata produce a 503 response with recovery guidance. The tool does not silently substitute an unverified network response for an intercepted offline asset. A failed new installation removes that new cache; a repeated installation of an existing release verifies rather than rewriting its files.
The boundary this does not cross
The manifest and service worker are delivered by the origin. An attacker controlling that origin may serve a malicious worker and matching manifest. Hashes do not independently establish who wrote the code or whether it is safe. Offline installation also does not establish physical network isolation, a trustworthy OS, or an absence of browser extensions.
How to assess the evidence
Review both the worker and the build-generated manifest logic. Fault tests should include changed bodies and changed response headers, not just missing files. The detailed development record distinguishes internal regressions from uncompleted phone-browser validation and independent review.
Service worker · Manifest assembly · Recorded review and scope
← All guides · Share test feedback ↗
Keep exploring
- Inside VVault: passphrase encryption and strict envelope parsing
- V Cipher: QR transport, message authentication and replay boundaries
- Development log 01: key handling and offline integrity
- Development log 02: making release evidence easier to check
- Development log 03: the validation work still ahead
- How to test local message encryption with VVault
- How to transfer ciphertext without sharing the passphrase
- An Android app-firewall test checklist for VGuard
- How to read security claims before testing a privacy app