Security
The security model, and its limits
This page describes what LiveVault actually enforces and where it stops. The second half is a list of things it deliberately does not claim, because a security page that only lists strengths is not useful for deciding whether to trust something.
Tokens
How share links are generated and stored
- Generation
- Each share token is 32 bytes from the operating system's cryptographic random source, encoded base64url — 256 bits of entropy, 43 characters. Guessing one is not a practical attack.
- Storage
- Only the SHA-256 digest of the token is written to the database. The token itself is returned once, at creation, and never persisted. Someone who obtains a database dump cannot reconstruct a working link from it.
- Lookup
- Validation hashes the incoming token and looks up the digest. A token that does not exist and a token whose link was already deleted return the same response, so the endpoint cannot be used to learn which tokens were once real.
- Rate limiting
- Token validation is capped per IP address. Combined with the entropy above, brute force is not viable.
Sessions
How viewing is locked down
- One session per link
- Starting a session marks the link as in use. A second browser attempting to open the same link while a session is live is refused.
- Browser binding
- A session is tied to an opaque per-browser key. The browser that opened the link can reconnect and resume its own session; another browser cannot adopt it.
- A view is charged on open, not on finish
- The view counter increments when the session starts. Abandoning a link halfway still consumes the view, otherwise a single-view link could be reopened indefinitely by never completing it.
- Sequential reveal
- Assets unlock one at a time and the order is enforced server-side. Requesting asset three while asset one is incomplete is rejected by the API, not just hidden in the interface.
Delivery
How media reaches the viewer
- Private bucket
- Media is stored in a private Cloudflare R2 bucket. No object is publicly readable and no object URL is ever handed to a browser.
- Session-bound stream tickets
- To fetch bytes, the viewer presents a short-lived signed ticket bound to one session, one link, and one asset. It expires in five minutes and is signed with a secret separate from the admin login secret.
- Why not presigned URLs
- A presigned storage URL would be cheaper to serve but is, by design, a directly shareable link to the raw file. That defeats the product, so media is proxied through the API after a session check instead.
- No caching
- Media and link responses are sent with no-store, so they are not retained by intermediate caches or the browser's HTTP cache.
Expiry and deletion
How links end and data is removed
- Two independent limits
- Every link has a view budget and an absolute deadline. Whichever is reached first ends the link. An unopened link still expires on schedule.
- Deletion is a separate step
- Expiry ends access; a separate purge deadline governs when the media is deleted. A background worker removes the objects from storage first, then drops the database record.
- Failed deletions are retried
- If storage deletion fails, the record is left in place so the next cleanup pass tries again. The system will not mark media deleted while it is still sitting in the bucket.
- Manual destruction
- An admin can end a link immediately. Any live session is torn down and the purge deadline is brought forward.
Deterrence
What the viewer reacts to
These controls raise the effort required to capture content casually and create a record when someone tries. They are not a guarantee.
- What is detected
- The viewer reports print-screen key presses, devtools shortcuts, escape, context-menu attempts, copy attempts, fullscreen exit, and the window losing focus.
- What happens
- Print-screen, devtools shortcuts, and escape end the link immediately. Softer signals count as a warning; the second warning ends it. Every signal is written to an audit trail with a timestamp.
- Desktop only
- Real links open on desktop browsers only, because the reveal flow depends on a focused, hover-capable window and these signals are unreliable on mobile. Opening on a phone is refused and logged — it does not destroy the link, so the recipient can simply switch to a laptop.
- Device detection is not a security boundary
- Device type is inferred from client-reported hints, which are trivially spoofable. It is treated as a usability control. The actual boundary is the token plus the session record, both of which are checked server-side.
Admin access
How the sending side is protected
- Approval gating
- Signup is open, but only the first account is approved automatically. Every subsequent account is created pending and cannot upload or create links until an existing approved admin lets it in.
- Password storage
- Passwords are hashed with bcrypt at cost factor 12 and are never logged.
- Single active session
- A login token is only honoured while it matches the session currently recorded on the account. Signing in anywhere else invalidates the previous token immediately.
- Token theft is not portable
- Admin tokens are additionally bound to the browser key used at login, so a stolen token presented from a different browser is rejected.
Limits
What LiveVault does not do
LiveVault cannot prevent screenshots or screen recording in a web browser. It deters casual capture, reacts to suspicious behaviour, and records what happened.
We do not prevent screenshots
A browser cannot block the operating system's screen capture. Print Screen, macOS screenshot tools, and OS-level screen recorders all work. LiveVault detects what it can, reacts, and logs it — that is deterrence, not prevention.
We do not prevent a camera pointed at the screen
Nothing in software can. If a recipient can see the content, they can photograph it.
We do not claim the recipient's device is trustworthy
Once media is decoded and displayed, it exists in that machine's memory. A determined technical user with control of their own browser can extract it.
We are not end-to-end encrypted
Media is encrypted in transit and at rest by the storage provider, but the server can read it in order to stream it. If you need a model where the operator provably cannot see your content, LiveVault is not that product today.
We do not offer a compliance certification
There is no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test. Claiming otherwise would be false.
Reporting
Found a vulnerability?
Email it. There is no bug bounty programme and no formal SLA, but reports are read and taken seriously, and I will tell you honestly whether and when it will be fixed.