Trust & Security

[1] Passwordless sign-in

vvault has no password to steal. You sign in with a one-time code sent to your email, or with Google or Apple. There is nothing to reuse across sites, nothing to leak in someone else's breach, and nothing for a phishing page to capture and replay later.

Codes expire, are rejected after a small number of wrong attempts, and are rate-limited per IP so a code cannot be guessed by brute force.

[2] Two-factor authentication

You can add a second factor in Settings → Security: an authenticator app (TOTP), a phone number, or a passkey. Once enabled, signing in needs the factor as well as the code.

[3] A PIN on the app itself

Work-in-progress music can be as sensitive as anything else on your laptop, and a laptop is often unlocked and unattended. You can set a PIN that locks vvault itself, so an open browser is not an open vault.

The PIN is never stored in a form that can be read back. It is hashed with scrypt using a salt unique to your PIN, compared in constant time so the comparison itself leaks nothing, and checked on the server — the browser never receives the hash and cannot be tricked into approving itself.

[4] Private by default

Everything you upload starts private. Nothing is reachable, indexed or listed until you decide it should be.

When you do share, you choose exactly how far it goes: invite only, anyone with the link, or for sale. A track's own link and the pack it sits in are governed separately, so publishing a pack never quietly publishes the track's own link — and a link you have not created does not exist.

[5] Your audio is not on the open web

Audio lives in a private bucket. It is never served from a public URL that could be guessed, scraped or shared onward by accident.

Every play and every download is served through a signed link that expires. When it expires it stops working, so a URL copied out of a browser's network tab is not a permanent key to your master.

[6] Access enforced in the database, not just the interface

Hiding a button is not security. vvault's access rules are enforced by row-level security policies in Postgres, underneath the app: a request for something you may not have returns nothing, whoever is asking and whatever the interface did.

That is the difference between a control and a suggestion. It is also why a private track stays private even when it sits inside a pack somebody else can open.

[7] Encryption and where your data lives

Traffic is encrypted in transit with TLS. Files and database contents are encrypted at rest with AES-256 by our infrastructure providers — Supabase, running on AWS.

Your content is hosted in the European Union. vvault is operated from Belgium, and the GDPR applies to us directly rather than by extension.

Direct messages: on iOS, conversations can be end-to-end encrypted, and media is sealed with a per-message key. The web app does not implement that yet — messages sent from a browser are protected in transit and at rest, but they are not end-to-end encrypted, and an end-to-end encrypted conversation opens on mobile. We would rather say so than let the word “encrypted” do work it has not earned.

[8] What we do not have yet

Security pages usually list only wins. Here is what vvault does not have, so you can judge the rest of this page knowing the gaps.

• No third-party penetration test. We have not had an external firm attack the platform. When we do, this page will say who and when.
• No SOC 2 or ISO 27001 certification. We are a small operation and have not been through either audit.
• No bug bounty programme, and no automated threat-monitoring vendor. Reports reach a person, not a queue.
• No end-to-end encryption on the web. See section [7].

[9] Reporting something

If you find a vulnerability, email vvaultapp@gmail.com with enough detail to reproduce it. Reports go straight to the person who maintains the platform.

We will not pursue you for reporting a genuine issue in good faith. Please give us a reasonable chance to fix it before publishing, do not access or modify anyone else's data while testing, and do not run tests that degrade the service for other people.