Technical write-up · Browser security

Offline integrity: verifying bytes is only half the response

How Vellivex pins offline asset hashes and response policy, handles corrupt caches and defines the trusted-origin boundary.

By V · Published 23 October 2026 · Experimental project notes

Experimental beta. Use non-sensitive test data. Real-phone validation and independent security review are incomplete. Do not rely on these tools for sensitive communications. See what still blocks a wider launch.

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