Security Model

Encryption in Transit

All communication between the Verity app and our relay uses TLS 1.3, the latest version of the Transport Layer Security protocol. This ensures:

End-to-end encryption between your device and our edge servers
Protection against man-in-the-middle attacks
Forward secrecy (past communications remain secure even if keys are compromised)

Credential Encryption

Your cloud storage credentials (AWS keys, Backblaze keys, etc.) receive additional protection beyond TLS:

On Your Device

Credentials are stored in the OS secure enclave (iOS Keychain / Android EncryptedSharedPreferences)
Encrypted by the operating system using hardware-backed keys
Not backed up to cloud (iOS: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly)

During Transmission

Credentials are encrypted with AES-256-GCM before inclusion in the session JWT
Encryption key is derived from the relay server's secret
Even if TLS were compromised, credentials would remain encrypted

On Our Relay

Credentials are decrypted in volatile memory (RAM) only
Used immediately to authenticate upload to your storage
Memory is cleared as soon as the upload operation completes
Never written to disk, database, or logs

Your Device

AES-256-GCM encrypted credentials in JWT

HTTPS / TLS 1.3

Memory only

Cloudflare Relay

(Edge)

1Decrypt credentials

2Authenticate to storage

3Clear from memory

Never written to disk, database, or logs

Your Cloud Storage

Drive

DBX

GCS

Video uploaded. We have no access.

Relay Infrastructure

Our relay runs on Cloudflare Workers—a serverless platform where code executes in V8 isolates at Cloudflare's edge. This is not a traditional server. There is no virtual machine, no operating system, and no persistent process. The execution environment is extremely minimal by design.

Isolation Model

V8 isolate per request — Each incoming request runs in its own V8 isolate (the same sandboxing technology used by Chrome). Isolates are destroyed when the request completes.
No shared state — Workers are stateless. Credentials, video data, and session context cannot persist between invocations.
No filesystem access — Workers cannot read from or write to disk. There is no filesystem. Data can only flow to explicit storage bindings (which we do not use for credentials or video).
No network listener — Workers do not open ports or bind to sockets. There is no SSH, no remote access, no way to "connect" to a running Worker.
Memory boundaries — Even in a multi-tenant edge environment, V8 isolates enforce strict memory separation. Your data cannot leak into other processes or other customers' requests.

Attack Surface Comparison

To understand why this matters, consider what an attacker would need to do to intercept data flowing through our relay, compared to a traditional server:

Attack Vector	Cloudflare Workers	Traditional Server
OS / kernel exploits	N/A — no OS exists	Real risk if unpatched
SSH / open ports	N/A — no ports, no listener	Must be hardened
Data at rest on disk	Impossible — no disk exists	Logs, swap, temp files can leak data
Memory inspection	Extremely difficult — isolate model, ephemeral	Possible if server is compromised
Account compromise	Attacker sees code — no live traffic access	Full shell access — real-time traffic visible
Physical seizure	Nothing to seize — no persistent server	Disk contents, logs, credentials exposed

What an Attacker Would Need

To intercept data passing through our relay, an attacker would need to:

Compromise Cloudflare's internal infrastructure — extraordinarily difficult; Cloudflare is one of the most heavily defended networks in the world
Compromise the TLS termination layer — Cloudflare controls the full stack and terminates TLS at their edge
Gain access to our Cloudflare account — they could read or modify Worker code, but would not have access to live traffic or historical data (there is none)

With a traditional server, the list is much longer: exploit an unpatched OS, brute-force SSH, sniff misconfigured TLS, access swap files or logs, social-engineer credentials, compromise the hypervisor layer, or simply obtain physical access to the machine.

The Trust Boundary

In both models, you trust the cloud provider. Cloudflare could theoretically inspect Worker traffic, just as any cloud provider could inspect compute memory. The critical difference is that with Workers, there are far fewer ways for a non-provider attacker to gain access. For a stateless relay that handles credentials in memory for milliseconds, this minimal attack surface is the strongest architecture we can offer.

Relay Auditability

While our relay code is currently private to prevent exploit discovery during our initial rollout, the Cloudflare Workers platform itself is well-documented and independently audited. We publish detailed documentation of our security architecture so that our claims can be evaluated against the platform's guarantees.

We are committed to transparency and welcome security researchers to audit our implementation. Contact security@myverity.app for audit inquiries.

Session Tokens (JWT)

When you start a recording session, you receive a signed JWT (JSON Web Token) that contains:

Session ID — Unique identifier for this recording
Device ID — For rate limiting (not PII)
Encrypted destinations — Your storage configs
Expiration time — Token validity period
Signature — HS256 signature from our server

The token is verified on every chunk upload. Invalid or expired tokens are rejected.

Rate Limiting and Abuse Prevention

To prevent abuse without tracking users, we implement layered rate limiting:

Device-Based Limits

Tracked by an app-generated UUID (not a hardware identifier like IMEI)
UUID resets if you reinstall the app—no persistent tracking
5,000 chunks per hour (enough for hours of continuous recording)
3 concurrent sessions maximum
No daily session limits — record as often as you need
Device ID counters auto-expire after 24 hours

IP-Based Protection

Secondary check to prevent device ID spoofing
IP addresses are hashed (one-way) before storage
Very generous limits (10,000+ requests/day) — only catches extreme abuse
Hashed IPs auto-expire after 24 hours

Recording Reliability

Evidence preservation is only useful if the recording actually captures what you need. Our recording technology is designed for reliability under adverse conditions:

Zero-Gap Recording

Double-buffered writers ensure no frames are lost when splitting video into uploadable chunks. Standard apps lose 100+ ms per segment—we lose zero.

Thermal Management

If your phone overheats, Verity automatically reduces video quality to keep recording. Lower quality evidence beats no evidence.

Interruption Handling

Phone calls, notifications, and other interruptions are handled gracefully. Recording pauses cleanly and resumes automatically.

Attestation Redundancy

Hash chain records are backed up across three tiers including off-provider storage. Your chain of custody survives any single point of failure.

Learn more about our recording technology →

Threat Model

Threats We Protect Against

Device seizure/loss

Real-time upload means video is already in your cloud before device can be compromised.

Video tampering

Hash chain makes any modification detectable.

Data breach at Verity

We don't store video or credentials. Breach would only expose attestation hashes.

Legal compulsion

Architectural privacy: we cannot provide data we don't have.

Threats Outside Our Model

Compromised device

If your phone has malware, we cannot protect data before it's encrypted.

Network interception at the edge

TLS protects against this, but state-level actors may have other capabilities.

Physical coercion

We cannot protect against someone forcing you to reveal credentials.

Recommended: Minimal Storage Permissions

Security Best Practice

For maximum security, we recommend configuring your cloud storage with minimal permissions:

S3, B2, GCS: Use write-only credentials. Even if compromised, an attacker could only add chunks—never read, modify, or delete recordings.
Google Drive: We request only drive.file—we can only access files Verity creates, not your other files.
Dropbox: We use App folder access—Verity can only see the dedicated Apps/Verity folder. We cannot access any other files in your Dropbox.

Example IAM Policy (AWS S3)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:PutObject"],
    "Resource": "arn:aws:s3:::your-bucket/verity/*"
  }]
}

See our Storage Setup Guide for write-only configuration instructions for each provider.

Security Audits

We welcome security researchers to audit our implementation. While our relay code is currently private during initial rollout, we are committed to transparency and publish detailed documentation of our security architecture.

To report a security vulnerability, please email security@myverity.app. We follow responsible disclosure practices and will credit researchers who help improve our security.