Vault security

The Vault is deterrent-tier protection - designed to make screen-recording-and-leak attribution easy, not to make it impossible. OBS or QuickTime can still capture playback, but the captured copy carries identifying watermarks. This page documents the security mechanics in depth.

A stronger tier - server-side watermark burn-in plus air-gapped review - is on the roadmap.

The Vault pages also carry an in-app spotlight guide (open the gear menu and choose "Show guide") that walks through sharing and playback in-product.

Token + share

Each share carries:

  • Token - generated with ~256 bits of entropy. Hashed before storage; the raw token only appears in the URL.
  • Recipient email - registered to the share. Code requests + access codes go to this email.
  • Session nonce - incremented on every successful code-verify. Used for device-kick.
  • Locked-until - rate-limit timestamp. Bumps on too-many failed code attempts.
  • Expiry - default 7 days, configurable from 1 to 90 days when the share is created.

Producer can revoke any time.

  1. Producer creates share -> email goes out with the magic link (from the Vault sender, [email protected]).
  2. Recipient clicks link -> lands on the viewer page.
  3. First-time recipient accepts the recipient terms (a short confidentiality / NDA notice) before anything else. The acceptance is recorded to the forensic log. Return visits skip this step once accepted.
  4. Recipient requests a code -> Grace generates a 6-digit code, stores it hashed with a 10-min TTL + 5-attempt limit.
  5. Email goes out with the code.
  6. Recipient types the code -> on match, the session is established.
  7. Viewer loads the player.

Session

After successful verify:

  • The session is per-share (not per-user) - each share gets its own cookie name (vault_sess_<shareId>), so concurrent shares to the same viewer do not collide.
  • It's HTTP-only - JavaScript can't read it.
  • It's secure - sent only over HTTPS.
  • It's signed - the server validates every range request.
  • TTL - 24 hours. Sliding refresh when more than an hour old.

Device kick

The session nonce bumps on every successful verify. The session includes the nonce. When the next range request comes in, the server checks the cookie's nonce against the share's current nonce. If they don't match (because someone else verified more recently), the cookie is invalid.

Net effect: only the most recently verified device can keep playing. If the recipient shares the link + code with someone else, the second person verifies (bumping the nonce) and the first person's stream breaks on the next range request.

Range-only stream

The stream endpoint refuses non-range requests. This prevents a fallback path from pulling a full multi-gigabyte file into memory at once.

Watermarks

The viewer player draws two watermark layers on top of the video element:

Layer 1 - Persistent corner watermark

Bottom-right of the player area:

  • Recipient email
  • Share ID (first 8 characters)
  • UTC timestamp (refreshed every 30 seconds)

Pointer-events disabled + user-select disabled + monospace font for visibility.

Layer 2 - Large diagonal wandering watermark

The recipient email + share ID, much larger, set at ~12% opacity, rotated -20 degrees, with position transforms that update every 8 seconds. (The live UTC timestamp lives only on the corner layer.) It wanders across the frame on a pseudo-random path so the watermark can't be cropped out of a captured rect.

Both layers can't be hidden via DevTools without breaking the page entirely.

Forensic log

Every viewer interaction is logged. The event types written today:

  • Code request - recipient requested an access code. (Accepting the recipient terms on a first visit also writes this event, tagged in metadata.)
  • Code verified - code matched and the session was established.
  • Code failed - code didn't match.
  • Play start - first range request after verify.
  • Device change - session nonce mismatch detected (a newer device verified).

Each event captures: share, event type, user agent, IP, time.

(The event schema also reserves a few types that are not emitted yet - seek, playback complete, and revocation-seen - so this list can grow without a schema change.)

When a leak surfaces, the producer can pull the log and match the watermark on the leaked copy to the corresponding code request + IP.

Upload path

Vault screener uploads go direct from your browser to cloud storage - the server never buffers the file body. The server hands the browser a temporary upload URL (10-minute TTL); the browser uploads to it; then the browser tells the server "done" and the screener row is created.

For large cuts, the browser switches to a multipart upload automatically past about 100 MiB: the file goes up in parallel chunks with per-part retry, and the in-progress upload is aborted cleanly if you cancel.

Cap enforcement:

  • Files up to 5 GiB upload in a single request; larger files (up to about 5 TiB) upload via multipart.
  • Allowed extensions: .mp4, .mov (videos only).
  • Uploads also count against your org's pooled storage quota, checked before the upload URL is issued.

Dailies vs screeners

The same security infrastructure powers both. Dailies are stored as screener rows under the hood but excluded from the master screeners list - they surface only on the dailies page.

Plan gating

During the open beta the Vault is available to every account.

(When paid plans return, the four Vault sections - Screeners, Dailies, DIT, Screener Sharing - will be Studio-only. Standard-plan orgs will see those sidebar items with a STUDIO pill; clicking will open an upgrade prompt instead of routing.)

What we don't protect against

  • Camera-recording the screen (a person physically holding a phone, recording the monitor).
  • Trusted device leaks - if the recipient is logged in and gives the codes to a friend, the friend's IP / device just shows up in the forensic log.
  • High-end captures where the watermark is at a known frame position and can be inpainted out.

For productions that need stronger protection, the Fort Knox tier is on the roadmap:

  • Server-side watermark burn-in (each viewer gets a re-encoded copy with their watermark baked into pixels).
  • Local-LLM screening on a hardware-air-gapped device for sensitive cuts before they leave the building.