Legal

Privacy policy

Last updated 29 July 2026

This policy describes the actual data handling in the product as built, not a generic template. Where something is not yet formalised, it says so.

Who is responsible

LiveVault is operated by an independent solo developer. For any privacy question or request, contact owner@livevault.live. There is no separate data protection officer.

What is stored

Uploaded media

Files uploaded to create a secure link are stored as objects in a private Cloudflare R2 bucket. Nothing in the bucket is publicly readable. Media is never written durably to the application server's filesystem; uploads pass through a temporary file that is deleted as soon as the object is stored.

Link records

Each secure link stores, in MongoDB Atlas:

  • a SHA-256 digest of the share token — never the token itself
  • the label you gave the link, and the original filename of each asset
  • file type, size, and the storage key of each object
  • the view limit, views used, and the absolute expiry deadline
  • link status and the reason it ended

Viewer sessions

When a recipient opens a link, a session record is created holding the detected device type, an opaque per-browser key, which assets have been revealed, and a count of any restricted actions detected. No name, email address, or account is required from a recipient, and none is collected.

Audit trail

Link creation, session start and completion, blocked device attempts, deterrence signals, expiry, and deletion are recorded with timestamps. This exists so a sender can see what happened to something they sent.

Admin accounts

Sending requires an account, which stores a name, an email address, and a bcrypt hash of the password. Plain-text passwords are never stored or logged.

What is deliberately not collected

  • No analytics. There is no Google Analytics, no Plausible, no product analytics SDK, and no third-party tracking script anywhere on this site.
  • No advertising or profiling. Nothing is shared with advertisers and no behavioural profiles are built.
  • No IP address retention. IP addresses are used transiently in memory for rate limiting and are not written to the database.

Cookies and browser storage

LiveVault sets no cookies. It does use your browser's localStorage for two values:

  • a random per-browser key, which binds a viewing or admin session to the browser that started it
  • your admin login token, if you are signed in as a sender

Both are first-party, both stay on your device, and clearing site data removes them. Neither is used for tracking.

Where data is stored

The application server runs on Render in its US West (Oregon) region, as specified in the deployment configuration in this project's repository. Records are stored in MongoDB Atlas, and media in Cloudflare R2. If you need the exact region of the database cluster and bucket confirmed in writing before sending anything sensitive, email and ask — that is a reasonable question and you will get a specific answer rather than a vague one.

How long data is kept

  • Media: deleted from object storage after the link's purge deadline passes. For normal links that is shortly after expiry; for public demo uploads it is at the fifteen-minute deadline. A background worker performs the deletion and retries if the storage provider rejects it, so media is never marked deleted while it still exists.
  • Link and session records: removed together with the media.
  • Audit events: retained after the link is gone, so a sender keeps the record of what happened. They reference the deleted link by identifier and contain no media.
  • Admin accounts: retained until deletion is requested.

Who can access your media

Recipients holding a valid, unexpired token, within its view budget. Beyond that, the operator has technical access to the database and storage bucket, because the service decrypts media in order to stream it. LiveVault is not end-to-end encrypted, and this policy will not pretend otherwise. If your threat model requires that the operator provably cannot read your content, this is not the right tool today.

Media is not accessed for any routine purpose. There is no manual review, no content scanning, and no training of any model on uploaded content.

Sub-processors

These third parties process data on LiveVault's behalf:

  • Render — application hosting
  • MongoDB Atlas — database
  • Cloudflare R2 — media storage
  • Vercel — hosting for this website and the viewer interface

Fonts are served from Google Fonts at build time and bundled with the site, so your browser does not request them from Google when you load a page.

Your rights

You can ask what is held about you, ask for a copy, ask for corrections, or ask for deletion. Email owner@livevault.live. Requests are handled personally, normally within a few days. There is no automated self-service export yet; when there is, this page will say so.

Security

Share tokens carry 256 bits of entropy and are stored only as hashes. Media is served through short-lived, session-bound tickets rather than public URLs. Passwords are hashed with bcrypt. Traffic is served over HTTPS. The Security page describes the model in detail, including its stated limits.

There has been no third-party security audit or penetration test. That is a fact about the current state of the project rather than a claim of safety.

Children

LiveVault is not directed at children and accounts are not knowingly created for anyone under 16.

Changes

Material changes will be reflected here with an updated date at the top, and noted in the changelog.